From narten@us.ibm.com Fri Nov 1 07:46:42 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AC821E8383 for ; Fri, 1 Nov 2013 07:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bRF9sphHABD for ; Fri, 1 Nov 2013 07:46:33 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8C90A11E8146 for ; Fri, 1 Nov 2013 07:45:58 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 Nov 2013 10:45:57 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 1 Nov 2013 10:45:56 -0400 Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 73B706E803A for ; Fri, 1 Nov 2013 10:45:54 -0400 (EDT) Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by b01cxnp22035.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA1EjtHH47972388 for ; Fri, 1 Nov 2013 14:45:55 GMT Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id rA1EjtEc007294 for ; Fri, 1 Nov 2013 12:45:55 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-76-46-87.mts.ibm.com [9.76.46.87]) by d01av03.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id rA1EjtnW007209 for ; Fri, 1 Nov 2013 12:45:55 -0200 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rA1Ejrn4007816 for ; Fri, 1 Nov 2013 10:45:54 -0400 Message-Id: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> From: Thomas Narten To: nsc@ietf.org Date: Fri, 01 Nov 2013 10:45:53 -0400 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110114-7182-0000-0000-000008F9ED40 Subject: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:46:43 -0000 Looking at the proposed charter (https://datatracker.ietf.org/doc/charter-ietf-sfc/), it includes: > Specifically, the SFC WG is chartered to deliver the following: ... > > 5) Manageability: This document will address the management of service > function chaining including relevant MIBs and YANG information and > data modules, and service function chaining diagnostics. And in the milestones, says: > Request the IESG for publication of an Informational document defining > SFC manageability including diagnostics, and MIB and YANG > information/data models to IESG My take is that this group will need to do some work in this space. But it is not at all clear to be yet *what* that work will be. IMO, having the charter say we will do MIBs and YANG info models may be getting ahead of ourselves. As an initial step, I think we need to look at requirements. I don't know if we really understand just what we want to "manage". For example, any information model dealing with services presumably will depend on deciding to what degree service are "discovered" dynamically vs. just having their existance configured as part of an overall orchestration system. My suggestion would be to tweak the mileston wording to make clear we will first do some work to scope what we need to do in this space, and then figure out the specific deliverables. Personally, I'm OK with just having the charter say we will do requirements and then recharter when we have a better idea of exactly what we need to do. What I don't think we should do yet is commit to doing (say) a YANG module. We may decide we want to do so later, but I think its premature to say so now. Thoughts? Thomas From melinda.shore@gmail.com Fri Nov 1 08:22:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC2E11E8397 for ; Fri, 1 Nov 2013 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0OxrLDBH7Jx for ; Fri, 1 Nov 2013 08:22:49 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6D08311E81C3 for ; Fri, 1 Nov 2013 08:22:49 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t61so4170713wes.27 for ; Fri, 01 Nov 2013 08:22:48 -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=dOyXgb+1B6uf0Rf5uIC+IGgR/TgVMW0ylP9MtME33no=; b=cebW3O//pvLXZNeG9j1QG5eYmLV3bk0MTxdNI/VX9zP/zpzPW4OQ9G8UT/CLYzyNbs B7pSThSD0rK9M33MRDC2mnqEiMSoFOME5unuPr9UHIXOpbWIg1WOdKswLBLTOCMjS4zb TJN9paJ91CPBadwtFeDJ65n3iMD8pezdPWi6bFZ/MowClVu45+tSUGK+EDmOCPEyQLrj 9rUP+HNMn7vvQqTUbw6zLV85mMGWLAKpi0mTKUEBLda0TBqDSuvPB2Si4e5chSJ7Q/uB ikJcENZ68zFWxCGTh5qQOZN2WFK5w02ExIqoSt2QbSw52bhjaaJrrN6ePKbEco+sfllO HtXA== MIME-Version: 1.0 X-Received: by 10.180.24.137 with SMTP id u9mr2706541wif.5.1383319368618; Fri, 01 Nov 2013 08:22:48 -0700 (PDT) Received: by 10.227.132.198 with HTTP; Fri, 1 Nov 2013 08:22:48 -0700 (PDT) Received: by 10.227.132.198 with HTTP; Fri, 1 Nov 2013 08:22:48 -0700 (PDT) In-Reply-To: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> Date: Fri, 1 Nov 2013 07:22:48 -0800 Message-ID: From: Melinda Shore To: Thomas Narten Content-Type: multipart/alternative; boundary=f46d04447f6793dd4104ea1f2340 Cc: nsc@ietf.org Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:22:50 -0000 --f46d04447f6793dd4104ea1f2340 Content-Type: text/plain; charset=ISO-8859-1 I think that level of specificity is pretty clearly getting ahead of things (like, oh, say, requirements). FWIW nsc/nfv operational issues, including management, will be discussed during the opsawg session on Tuesday. We're already seeing some draft submissions. Melinda --f46d04447f6793dd4104ea1f2340 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

I think that level of specificity is pretty clearly getting = ahead of things (like, oh, say, requirements).=A0 FWIW nsc/nfv operational = issues, including management,=A0 will be discussed during the opsawg sessio= n on Tuesday.=A0=A0 We're already seeing some draft submissions.

Melinda

--f46d04447f6793dd4104ea1f2340-- From narten@us.ibm.com Fri Nov 1 08:51:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD99D11E81C6 for ; Fri, 1 Nov 2013 08:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPU7avpRI-NZ for ; Fri, 1 Nov 2013 08:51:41 -0700 (PDT) Received: from e9.ny.us.ibm.com (e9.ny.us.ibm.com [32.97.182.139]) by ietfa.amsl.com (Postfix) with ESMTP id F388211E815F for ; Fri, 1 Nov 2013 08:51:40 -0700 (PDT) Received: from /spool/local by e9.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 1 Nov 2013 11:51:40 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e9.ny.us.ibm.com (192.168.1.109) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 1 Nov 2013 11:51:37 -0400 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 4612238C803B for ; Fri, 1 Nov 2013 11:51:36 -0400 (EDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA1Fpac29961886 for ; Fri, 1 Nov 2013 15:51:37 GMT Received: from d03av01.boulder.ibm.com (localhost [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rA1FpafC028873 for ; Fri, 1 Nov 2013 09:51:36 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-76-46-87.mts.ibm.com [9.76.46.87]) by d03av01.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rA1FpYt3028762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Nov 2013 09:51:35 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rA1FpYHP020268; Fri, 1 Nov 2013 11:51:34 -0400 Message-Id: <201311011551.rA1FpYHP020268@cichlid.raleigh.ibm.com> To: Melinda Shore In-reply-to: References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> Comments: In-reply-to Melinda Shore message dated "Fri, 01 Nov 2013 07:22:48 -0800." Date: Fri, 01 Nov 2013 11:51:33 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110115-7182-0000-0000-000008FA24A5 Cc: nsc@ietf.org Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 15:51:48 -0000 So, Jim and I chatted some more about this issue, and our current thinking is that the first step here is a combination of requirements and framework. And that it's even unclear whether to call this "managment" or "control plane". For framework, we need to understand what types of operations need to be done in this space. For example, information needs to get pushed out to the Service Functions that allow them to properly understand and process the data packets (and the service header fields/metadata associated with those data packets). But there are (at least) two rather different ways to do this. One could view it as management problem, where information needs to be pushed out to the individual service points via something like netconf. I.e., one is "managing" the service functions and "configuring" them. This could be done as (say) part of a more general orchestration system. Or, the info could be distributed via routing protocols. Those two approaches are very different in terms of protocol/solution implications. Hence, a framework discussion would help sort out how to approach this space. Thomas From jmh@joelhalpern.com Sat Nov 2 17:48:59 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAB8821E80F4 for ; Sat, 2 Nov 2013 17:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oZAc0vk45v40 for ; Sat, 2 Nov 2013 17:48:55 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 523B421E8128 for ; Sat, 2 Nov 2013 17:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 10D6D1C01C69; Sat, 2 Nov 2013 17:48:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-b83d.meeting.ietf.org (dhcp-b83d.meeting.ietf.org [31.133.184.61]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8FBFD1C01C68; Sat, 2 Nov 2013 17:48:54 -0700 (PDT) Message-ID: <52759D75.7090907@joelhalpern.com> Date: Sat, 02 Nov 2013 20:48:53 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Thomas Narten , Melinda Shore References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311011551.rA1FpYHP020268@cichlid.raleigh.ibm.com> In-Reply-To: <201311011551.rA1FpYHP020268@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nsc@ietf.org Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 00:49:00 -0000 I tend to prefer to recognize a strong distinction between application processing and forwarding logic. This leads me to treat information needed by service instances to service packets as a very different kind of thing than routing / forwarding information. Whether that kind of information is injected into the applications via management or "sdn" (for any particular value of "sdn" you choose) doesn't really matter to me. Yours, Joel On 11/1/13 11:51 AM, Thomas Narten wrote: > So, Jim and I chatted some more about this issue, and our current > thinking is that the first step here is a combination of requirements > and framework. And that it's even unclear whether to call this > "managment" or "control plane". > > For framework, we need to understand what types of operations need to > be done in this space. For example, information needs to get pushed > out to the Service Functions that allow them to properly understand > and process the data packets (and the service header fields/metadata > associated with those data packets). > > But there are (at least) two rather different ways to do this. One > could view it as management problem, where information needs to be > pushed out to the individual service points via something like > netconf. I.e., one is "managing" the service functions and > "configuring" them. This could be done as (say) part of a more general > orchestration system. > > Or, the info could be distributed via routing protocols. > > Those two approaches are very different in terms of protocol/solution > implications. > > Hence, a framework discussion would help sort out how to approach this > space. > > Thomas > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From dromasca@avaya.com Sun Nov 3 07:15:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1147511E82A9 for ; Sun, 3 Nov 2013 07:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.802 X-Spam-Level: X-Spam-Status: No, score=-102.802 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h2diODq56cs4 for ; Sun, 3 Nov 2013 07:15:32 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E3EA311E82A4 for ; Sun, 3 Nov 2013 07:15:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAAtodlLGmAcV/2dsb2JhbABZgmYhOFO/ToEaFnSCJQEBAQEDEihLBAIBCA0EBAEBCxQJBzIUCQgCBAESCBqHXwEMoHecJhMEjyc4BoMagQ4Dnm6LJYMmgio X-IronPort-AV: E=Sophos;i="4.93,626,1378872000"; d="scan'208";a="35326015" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Nov 2013 10:15:01 -0500 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Nov 2013 10:09:38 -0500 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0146.000; Sun, 3 Nov 2013 16:14:59 +0100 From: "Romascanu, Dan (Dan)" To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Manageability tasks for SFC Thread-Index: AQHO1xE21PKWKYeDHkmUH2yU+FKGwZoToJaw Date: Sun, 3 Nov 2013 15:14:58 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA12929027@AZ-FFEXMB04.global.avaya.com> References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> In-Reply-To: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Nov 2013 15:15:38 -0000 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, November 01, 2013 4:46 PM > To: nsc@ietf.org > Subject: [nsc] Manageability tasks for SFC >=20 > Looking at the proposed charter > (https://datatracker.ietf.org/doc/charter-ietf-sfc/), it includes: >=20 > > Specifically, the SFC WG is chartered to deliver the following: > ... > > > > 5) Manageability: This document will address the management of service > > function chaining including relevant MIBs and YANG information and > > data modules, and service function chaining diagnostics. >=20 > And in the milestones, says: >=20 > > Request the IESG for publication of an Informational document defining > > SFC manageability including diagnostics, and MIB and YANG > > information/data models to IESG >=20 > My take is that this group will need to do some work in this space. But > it is not at all clear to be yet *what* that work will be. IMO, having > the charter say we will do MIBs and YANG info models may be getting > ahead of ourselves. >=20 > As an initial step, I think we need to look at requirements. I don't > know if we really understand just what we want to "manage". For example, > any information model dealing with services presumably will depend on > deciding to what degree service are "discovered" dynamically vs. just > having their existance configured as part of an overall orchestration > system. >=20 > My suggestion would be to tweak the mileston wording to make clear we > will first do some work to scope what we need to do in this space, and > then figure out the specific deliverables. Personally, I'm OK with just > having the charter say we will do requirements and then recharter when > we have a better idea of exactly what we need to do. What I don't think > we should do yet is commit to doing (say) a YANG module. We may decide > we want to do so later, but I think its premature to say so now. >=20 > Thoughts? >=20 > Thomas >=20 [[DR]] I fully agree with Thomas here.=20 Regards, Dan From narten@us.ibm.com Wed Nov 6 10:38:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DEF11E81FA for ; Wed, 6 Nov 2013 10:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rro6wmsk8TSS for ; Wed, 6 Nov 2013 10:38:25 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id 650D111E8127 for ; Wed, 6 Nov 2013 10:38:24 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Nov 2013 13:38:23 -0500 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Nov 2013 13:38:22 -0500 Received: from b01cxnp22033.gho.pok.ibm.com (b01cxnp22033.gho.pok.ibm.com [9.57.198.23]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 9701A38C8045 for ; Wed, 6 Nov 2013 13:38:20 -0500 (EST) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA6IcLqK53411944 for ; Wed, 6 Nov 2013 18:38:21 GMT Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id rA6IcLMV014948 for ; Wed, 6 Nov 2013 13:38:21 -0500 Received: from cichlid.raleigh.ibm.com (dyn9050019207.mts.ibm.com [9.50.19.207] (may be forged)) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id rA6IcHUS014729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Nov 2013 13:38:19 -0500 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rA6IcGwu024956 for ; Wed, 6 Nov 2013 10:38:16 -0800 Message-Id: <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> To: nsc@ietf.org In-reply-to: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> Comments: In-reply-to Thomas Narten message dated "Fri, 01 Nov 2013 10:45:53 -0400." Date: Wed, 06 Nov 2013 10:38:16 -0800 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110618-5806-0000-0000-00002356BA71 Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:38:32 -0000 There have been some additional offline discussions on this topic, and we propose to change the charter in the following ways: New text for item 5) in the charter: 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. Replace previous milestone on management with: May 2014 Consult with OPS Area on possible charter modifications for management and configuration of SFC components Thomas From Tina.Tsou.Zouting@huawei.com Wed Nov 6 10:41:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0742D11E822E for ; Wed, 6 Nov 2013 10:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.105 X-Spam-Level: X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=-1.709, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWl6ZaLzv0J2 for ; Wed, 6 Nov 2013 10:41:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A4B5811E81DB for ; Wed, 6 Nov 2013 10:41:18 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXP62913; Wed, 06 Nov 2013 18:41:16 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 18:40:34 +0000 Received: from SJCEML401-HUB.china.huawei.com (10.212.94.42) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 6 Nov 2013 18:41:13 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.123]) by sjceml401-hub.china.huawei.com ([::1]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 10:41:06 -0800 From: Tina TSOU To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Manageability tasks for SFC Thread-Index: AQHO1xE4VPRVK6dDGUqes0UvjQ3f9ZoZFrAA//96cTA= Date: Wed, 6 Nov 2013 18:41:06 +0000 Message-ID: References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> In-Reply-To: <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.200] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 18:41:26 -0000 RGVhciBUaG9tYXMsDQpGdWxseSBhZ3JlZWQuIFRoYW5rIHlvdSBmb3IgdGFraW5nIGNvbnNpZGVy YXRpb24gb2YgaXQuDQoNClRoYW5rIHlvdSwNClRpbmENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBUaG9tYXMgTmFydGVuDQo+IFNlbnQ6IDIwMTPE 6jEx1MI2yNUgMTA6MzgNCj4gVG86IG5zY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW25zY10g TWFuYWdlYWJpbGl0eSB0YXNrcyBmb3IgU0ZDDQo+IA0KPiBUaGVyZSBoYXZlIGJlZW4gc29tZSBh ZGRpdGlvbmFsIG9mZmxpbmUgZGlzY3Vzc2lvbnMgb24gdGhpcyB0b3BpYywgYW5kDQo+IHdlIHBy b3Bvc2UgdG8gY2hhbmdlIHRoZSBjaGFydGVyIGluIHRoZSBmb2xsb3dpbmcgd2F5czoNCj4gDQo+ IE5ldyB0ZXh0IGZvciBpdGVtIDUpIGluIHRoZSBjaGFydGVyOg0KPiANCj4gICAgIDUpIE1hbmFn ZWFiaWxpdHk6IFdvcmsgb24gdGhlIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YNCj4g ICAgICAgIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2YgU0ZDIGNvbXBvbmVudHMgd2ls bCBjZXJ0YWlubHkNCj4gICAgICAgIGJlIG5lZWRlZCwgYnV0IGZpcnN0IG5lZWRzIHRvIGJlIGJl dHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQo+IA0KPiBSZXBsYWNlIHByZXZpb3VzIG1pbGVz dG9uZSBvbiBtYW5hZ2VtZW50IHdpdGg6DQo+IA0KPiAgICAgTWF5IDIwMTQgQ29uc3VsdCB3aXRo IE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNoYXJ0ZXIgbW9kaWZpY2F0aW9ucw0KPiAJICAgICBmb3Ig bWFuYWdlbWVudCBhbmQgY29uZmlndXJhdGlvbiBvZiBTRkMgY29tcG9uZW50cw0KPiANCj4gVGhv bWFzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBuc2MgbWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K From narten@us.ibm.com Wed Nov 6 11:07:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B24BE21F9C68 for ; Wed, 6 Nov 2013 11:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHKHA5lK9yU7 for ; Wed, 6 Nov 2013 11:07:37 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by ietfa.amsl.com (Postfix) with ESMTP id CF1CC21F9D18 for ; Wed, 6 Nov 2013 11:07:37 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Nov 2013 12:07:37 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 6 Nov 2013 12:07:35 -0700 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 09E1F1FF001A for ; Wed, 6 Nov 2013 12:07:20 -0700 (MST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA6J7YsS310546 for ; Wed, 6 Nov 2013 12:07:34 -0700 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rA6J7Y1j019553 for ; Wed, 6 Nov 2013 12:07:34 -0700 Received: from cichlid.raleigh.ibm.com (dyn9050019207.mts.ibm.com [9.50.19.207] (may be forged)) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rA6J7Ug4019250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 6 Nov 2013 12:07:33 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rA6J7RLT029096 for ; Wed, 6 Nov 2013 11:07:28 -0800 Message-Id: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> From: Thomas Narten To: nsc@ietf.org Date: Wed, 06 Nov 2013 11:07:27 -0800 X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13110619-8236-0000-0000-000003803008 Subject: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 19:07:44 -0000 Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ietf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, please speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergone significant change in recent years with the introduction of virtualization, network overlays, and orchestration. Service delivery is currently both a technical and organizational challenge that involves significant modification to the network configuration. Services are typically implemented by the ordered combination of a number of service functions that are deployed at different points within the network. Today, a common deployment model has service functions physically inserted on the data forwarding path between communicating peers. Going forward, however, there is a desire to move to a different model, where service functions are not required to reside on the default data path and traffic is instead steered through services, wherever they are deployed. For a given service, the abstracted view of the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). Since a given service function may be available on more than one node within a network, a Service Function Chain is instantiated via the selection of specific service function instances and the network nodes on which they are provided, thereby forming a service topology: this is called a Service Function Path. The service functions may be applied at a specific layer within the network protocol stack (network layer, application layer, etc.). The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment. It will produce a framework for service function chaining that includes the necessary protocols or protocol extensions to convey the service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. The working group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. Specifically, the SFC WG is chartered to deliver the following: 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining. 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as requirements on the protocol mechanisms. 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs. 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem statement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for management and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG requirements for a generic service function chaining encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic service function chaining header encapsulation Thomas From jmh@joelhalpern.com Wed Nov 6 13:45:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BD721E81D0 for ; Wed, 6 Nov 2013 13:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLW3ltT-VySG for ; Wed, 6 Nov 2013 13:45:26 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id C4A9421E81C4 for ; Wed, 6 Nov 2013 13:44:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id A46F33C3098; Wed, 6 Nov 2013 13:44:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-9207.meeting.ietf.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 47C9C3C309A; Wed, 6 Nov 2013 13:44:26 -0800 (PST) Message-ID: <527AB839.8040608@joelhalpern.com> Date: Wed, 06 Nov 2013 16:44:25 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Thomas Narten , nsc@ietf.org References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> In-Reply-To: <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:45:30 -0000 I find the proposed wording of bullet 5 a little odd. Service functions are applications. I would hope that application management is out of scope for this working group. (I can't tell if I have a problem with the actual milestone, as that depends upon exactly what the scope of a service function chain component is. Management of the chaining seems worth discussing. Yours, Joel On 11/6/13 1:38 PM, Thomas Narten wrote: > There have been some additional offline discussions on this topic, and > we propose to change the charter in the following ways: > > New text for item 5) in the charter: > > 5) Manageability: Work on the management and configuration of > service functions in support of SFC components will certainly > be needed, but first needs to be better understood and scoped. > > Replace previous milestone on management with: > > May 2014 Consult with OPS Area on possible charter modifications > for management and configuration of SFC components > > Thomas > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From melinda.shore@gmail.com Wed Nov 6 13:50:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A951D21E8185 for ; Wed, 6 Nov 2013 13:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZHMzFqrR-Ea for ; Wed, 6 Nov 2013 13:50:11 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id D62BC21E811C for ; Wed, 6 Nov 2013 13:50:02 -0800 (PST) Received: by mail-pa0-f52.google.com with SMTP id bj1so281964pad.11 for ; Wed, 06 Nov 2013 13:49:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=AWDk34t2eFMW9SErsByhh3q/05o2k7QNlHcKEygC3JM=; b=l3k9CEa8KyOF6TEtdQQ0M6ypetklzbCnv6jkjFnk8yNBtgoB58ciPOVMDLJWtK1Pw+ m+dIF2nbC/1ZLY2D0YRZAflZt89zsrFysdhYIWGizGR2GUbBz3vhpjVW9pgyhv9fX6d0 EAsEfx5CBApSnes2t5sui3t4N5lPyV1mxLt5s2He2BiFaTJJuf/0bKfL6N6uPR9a3NYG tTDmUxZnx+DRPbXEDnxVrICRLc8wUo7TKdlX9s5/tKoFO7aBTwOV7j5LLaHQ68GND5cT Hp9zaCmxnWE6A0WDyjnmtgCmEtjpuZhoMD2I24fSigUH0CSd6vT2jrgQuVl8AMRMv5cX TiWQ== X-Received: by 10.66.65.195 with SMTP id z3mr6063263pas.47.1383774598482; Wed, 06 Nov 2013 13:49:58 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:655f:664c:edd9:dba4? ([2001:67c:370:144:655f:664c:edd9:dba4]) by mx.google.com with ESMTPSA id qw8sm226511pbb.27.2013.11.06.13.49.56 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 13:49:57 -0800 (PST) Message-ID: <527AB983.5090208@gmail.com> Date: Wed, 06 Nov 2013 13:49:55 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: nsc@ietf.org References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> In-Reply-To: <527AB839.8040608@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 21:50:30 -0000 On 11/06/2013 01:44 PM, Joel M. Halpern wrote: > I find the proposed wording of bullet 5 a little odd. > Service functions are applications. I would hope that application > management is out of scope for this working group. (I can't tell if I > have a problem with the actual milestone, as that depends upon exactly > what the scope of a service function chain component is. Management of > the chaining seems worth discussing. Right, I think it's worth thinking about visibility into and management of each of the service functions, independent of the application they're supporting. Things like status monitoring and reporting, instantiation, etc. Melinda From diego@tid.es Wed Nov 6 14:09:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D2821E80A6 for ; Wed, 6 Nov 2013 14:09:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWVzcrfjuEbY for ; Wed, 6 Nov 2013 14:09:02 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B601711E8156 for ; Wed, 6 Nov 2013 14:08:55 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MVV009N046JU8@tid.hi.inet> for nsc@ietf.org; Wed, 06 Nov 2013 23:08:43 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 35.64.03197.BEDBA725; Wed, 06 Nov 2013 23:08:43 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MVV009MW46JU8@tid.hi.inet> for nsc@ietf.org; Wed, 06 Nov 2013 23:08:43 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.151]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Wed, 06 Nov 2013 23:08:42 +0100 Date: Wed, 06 Nov 2013 22:08:42 +0000 From: "Diego R. Lopez" In-reply-to: <527AB983.5090208@gmail.com> X-Originating-IP: [10.95.64.115] To: Melinda Shore Message-id: <2DB18EAA-417F-4F82-B3AC-8841BD6B440B@tid.es> Content-id: <787D159E90939A4D89411694273493AE@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: [nsc] Manageability tasks for SFC Thread-index: AQHO2yEO/GrIKxIIyEK+08EE3bYNeZoYv5t3///y3YA= X-AuditID: 0a5f4068-b7f3e8e000000c7d-63-527abdebc60c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42Lhinfg0n29tyrI4N5rQYvj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+XJnYwFu4QqFh8Wb2D8I9jFyMkhIWAicXbPHXYIW0ziwr31 bF2MXBxCAgcYJfbe+8wK4XxllNix/h4ThDOTUaJx3gQ2kBYWAVWJnvUfWEFsNiD7UfNvsFHC AnoSjb++gtVwCmhK/Og4CLVCQeLPuccsILaIgLbE9rsNYDazgLLE8+O/wGxeAUuJZc+usUPE zSTmbVrLDBEXlPgx+R5QDQdQXF1iypRciBJxiebWm1BjFCWmLWpgBLEZBWQl3s2fzwqxSl9i 2aOfUGutJC6+bmGCOEdAYsme88wQtqjEy8f/oB7ezSjxp2cV0wRGiVlIzpiF5IxZCGfMQnLG LCRnLGBkXcUoVpxUlJmeUZKbmJmTbmCol5Gpl5mXWrKJERJ1GTsYl+9UOcQowMGoxMPrUFUV JMSaWFZcmXuIUYKDWUmEVyAUKMSbklhZlVqUH19UmpNafIiRiYNTqoGx2H1d9N3kmJt9PgXt 3cF7V/4Mmmv1aEnCO456Ft2379Wqnh6/H3B5tunP6dHxOZMv+5qzN0acYmg/Z/TygvKJIE9V t4jpBVrPjqnYvM88cmlHodL/iChDnyvZafVRYYFOR09q7a+UYZTjZLbsvdJ4vlnRQSM1nMtS qOnqz1WSwfefS8Yuq1BiKc5INNRiLipOBAAAlSUWmAIAAA== References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> Cc: "" Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:09:06 -0000 SSBhZ3JlZS4gUHJvYmFibHkgdXNpbmcgdGhlIHdvcmRpbmcgc3VnZ2VzdGVkIGJ5IE1lbGluZGEg KCJtYW5hZ2VtZW50IG9mIGVhY2ggb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zLCBpbmRlcGVuZGVu dCBvZiB0aGUgYXBwbGljYXRpb24gdGhleSdyZSBzdXBwb3J0aW5nIikgd291bGQgbWFrZSB0aGlu Z3MgY2xlYXIgaW4gdGhhdCByZXNwZWN0Li4uDQoNCkJlIGdvb2RlLA0KDQpPbiA2IE5vdiAyMDEz LCBhdCAxMzo0OSAsIE1lbGluZGEgU2hvcmUgd3JvdGU6DQoNCj4gT24gMTEvMDYvMjAxMyAwMTo0 NCBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOg0KPj4gSSBmaW5kIHRoZSBwcm9wb3NlZCB3b3Jk aW5nIG9mIGJ1bGxldCA1IGEgbGl0dGxlIG9kZC4NCj4+IFNlcnZpY2UgZnVuY3Rpb25zIGFyZSBh cHBsaWNhdGlvbnMuICBJIHdvdWxkIGhvcGUgdGhhdCBhcHBsaWNhdGlvbg0KPj4gbWFuYWdlbWVu dCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgd29ya2luZyBncm91cC4gIChJIGNhbid0IHRlbGwg aWYgSQ0KPj4gaGF2ZSBhIHByb2JsZW0gd2l0aCB0aGUgYWN0dWFsIG1pbGVzdG9uZSwgYXMgdGhh dCBkZXBlbmRzIHVwb24gZXhhY3RseQ0KPj4gd2hhdCB0aGUgc2NvcGUgb2YgYSBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluIGNvbXBvbmVudCBpcy4gIE1hbmFnZW1lbnQgb2YNCj4+IHRoZSBjaGFpbmlu ZyBzZWVtcyB3b3J0aCBkaXNjdXNzaW5nLg0KPg0KPiBSaWdodCwgSSB0aGluayBpdCdzIHdvcnRo IHRoaW5raW5nIGFib3V0IHZpc2liaWxpdHkgaW50byBhbmQNCj4gbWFuYWdlbWVudCBvZiBlYWNo IG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucywgaW5kZXBlbmRlbnQgb2YNCj4gdGhlIGFwcGxpY2F0 aW9uIHRoZXkncmUgc3VwcG9ydGluZy4gIFRoaW5ncyBsaWtlIHN0YXR1cyBtb25pdG9yaW5nDQo+ IGFuZCByZXBvcnRpbmcsIGluc3RhbnRpYXRpb24sIGV0Yy4NCj4NCj4gTWVsaW5kYQ0KPg0KPg0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2Mg bWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9y IEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9w ZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAg ICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBk ZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8g eSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8g bcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRz IGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBv ZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlz Y2xhaW1lci5hc3B4DQo= From jmh@joelhalpern.com Wed Nov 6 14:26:39 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65E221E809E for ; Wed, 6 Nov 2013 14:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmOHGOijDjYJ for ; Wed, 6 Nov 2013 14:26:31 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 43A7511E814D for ; Wed, 6 Nov 2013 14:26:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3DAAF4C0453; Wed, 6 Nov 2013 14:26:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-9207.meeting.ietf.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id DAC4E4C0454; Wed, 6 Nov 2013 14:26:30 -0800 (PST) Message-ID: <527AC214.8030409@joelhalpern.com> Date: Wed, 06 Nov 2013 17:26:28 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Melinda Shore , nsc@ietf.org References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> In-Reply-To: <527AB983.5090208@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:26:39 -0000 That still looks like application management. In fact, it looks like the exact same application management you want when you are not doing service chaining. Which is why I have trouble seeing how it fits in this working group. Yours, Joel On 11/6/13 4:49 PM, Melinda Shore wrote: > On 11/06/2013 01:44 PM, Joel M. Halpern wrote: >> I find the proposed wording of bullet 5 a little odd. >> Service functions are applications. I would hope that application >> management is out of scope for this working group. (I can't tell if I >> have a problem with the actual milestone, as that depends upon exactly >> what the scope of a service function chain component is. Management of >> the chaining seems worth discussing. > > Right, I think it's worth thinking about visibility into and > management of each of the service functions, independent of > the application they're supporting. Things like status monitoring > and reporting, instantiation, etc. > > Melinda > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From melinda.shore@gmail.com Wed Nov 6 14:27:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E82611E8175 for ; Wed, 6 Nov 2013 14:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPr4CHo+WvpE for ; Wed, 6 Nov 2013 14:27:45 -0800 (PST) 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 B810F11E816F for ; Wed, 6 Nov 2013 14:27:45 -0800 (PST) Received: by mail-pd0-f178.google.com with SMTP id x10so148681pdj.23 for ; Wed, 06 Nov 2013 14:27:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=Xl4dSDqmWfipMi9LLO+/XVVl/T0u+iNK6mnjuhbyVZU=; b=os3CDxumNcWBmXwWU2L0PNbOh37o4lPfuwu3dvOB6T32U9WBd/csRtqRo2nOgN40ZC SA/efw1p74GR9vBhbumsoBa35lUeWb4oNtxGzfCjbi7Ro2GB8Mam0TKBTqJsnMl8Di7S Y2t6KBd1VRyqPNZFKsEcyZ8NOknlZZ57+fp3fMfFh3MhjwtG/rB9wTwuydZmWj2YZbQW S8xOjOJRG0TzLauwH8k+soU+mPYse2vXUuhIBtv8cScgAG35vKGA0FRs07YN0Kqi/ZW0 l2RIqkqSre6GM3+1PHqS4Lb3M+vkkJwugz1hS5L89YfNJZjnqBMorv1fdQ8h8KomFjBS iXZg== X-Received: by 10.68.209.232 with SMTP id mp8mr5535035pbc.129.1383776865110; Wed, 06 Nov 2013 14:27:45 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:655f:664c:edd9:dba4? ([2001:67c:370:144:655f:664c:edd9:dba4]) by mx.google.com with ESMTPSA id ho3sm352205pbb.23.2013.11.06.14.27.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 14:27:43 -0800 (PST) Message-ID: <527AC25D.9020802@gmail.com> Date: Wed, 06 Nov 2013 14:27:41 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Joel M. Halpern" , nsc@ietf.org References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> <527AC214.8030409@joelhalpern.com> In-Reply-To: <527AC214.8030409@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:27:46 -0000 On 11/06/2013 02:26 PM, Joel M. Halpern wrote: > That still looks like application management. In fact, it looks like > the exact same application management you want when you are not doing > service chaining. Which is why I have trouble seeing how it fits in > this working group. It may not fit in *this* working group but you'd still need interfaces on the services to effect management functions. Melinda From andre.beliveau@ericsson.com Wed Nov 6 14:31:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE7721F9DF1 for ; Wed, 6 Nov 2013 14:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goeKDefgyRYP for ; Wed, 6 Nov 2013 14:31:27 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CB02D21F9DAF for ; Wed, 6 Nov 2013 14:31:26 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-ff-527ac33cf106 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B5.03.04556.C33CA725; Wed, 6 Nov 2013 23:31:25 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 17:31:24 -0500 From: Andre Beliveau To: "Joel M. Halpern" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] Manageability tasks for SFC Thread-Index: AQHO1xE2xUvwbVRET0GrKYgdYkxSspoY5GUAgAA0A4CAAAGJgIAACjYA//+scHA= Date: Wed, 6 Nov 2013 22:31:24 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C2CBAF4@eusaamb103.ericsson.se> References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> <527AC214.8030409@joelhalpern.com> In-Reply-To: <527AC214.8030409@joelhalpern.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyuXSPn67t4aogg4Wv+Sw+nnrDZNHWNovF 4vi+/WwOzB47Z91l91iy5CeTx7kp3xkDmKO4bFJSczLLUov07RK4Muavjy04x1ux7l9gA+Mc 7i5GTg4JAROJ+b3fWCBsMYkL99azgdhCAkcYJWZ/Tepi5AKylzFKHF20ihUkwSZgJPH+yiRG EFtEoFRi379/YLawgJ5Ew69TQDUcQHF9iSOLeCBK/CTurZzOBGKzCKhIXLzaDFbOK+ArcebA dSaI+Q8YJS5/6GYE6eUE6v3xIBikhlFAVmLDRIjbmAXEJW49mc8EcaeAxJI955khbFGJl4// sULYyhJLnuyHqteRWLD7ExuErS2xbOFrZoi9ghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sq Ro7S4tSy3HQjw02MwNg4JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamDcVPh2g9JX2VR/zWMnbvVlXjiT2b9CastE8ekqApdNPmivFHBc80vnCuvRQFGu qN1bgw3injWI2CkLfM2J3jzh4bLXa8/7ftssX6o58fOTVlujRoNimzN7fxV4TG/pvj69+Xvc 3ratez8Yze/86jitdkdfwUpPlaNltWnVi7UnPYvZluL96nOUEktxRqKhFnNRcSIAxl8sslsC AAA= Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:31:32 -0000 How about this formulation: "Work on the management and configuration of SFC components related to the support of Service Functions Chaining will certainly be needed, but first needs to be better understood and scoped." -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: November-06-13 2:26 PM To: Melinda Shore; nsc@ietf.org Subject: Re: [nsc] Manageability tasks for SFC That still looks like application management. In fact, it looks like the e= xact same application management you want when you are not doing service ch= aining. Which is why I have trouble seeing how it fits in this working gro= up. Yours, Joel On 11/6/13 4:49 PM, Melinda Shore wrote: > On 11/06/2013 01:44 PM, Joel M. Halpern wrote: >> I find the proposed wording of bullet 5 a little odd. >> Service functions are applications. I would hope that application=20 >> management is out of scope for this working group. (I can't tell if=20 >> I have a problem with the actual milestone, as that depends upon=20 >> exactly what the scope of a service function chain component is. =20 >> Management of the chaining seems worth discussing. > > Right, I think it's worth thinking about visibility into and=20 > management of each of the service functions, independent of the=20 > application they're supporting. Things like status monitoring and=20 > reporting, instantiation, etc. > > Melinda > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Wed Nov 6 14:33:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A01921F9F0A for ; Wed, 6 Nov 2013 14:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jn38ZFs0TtbQ for ; Wed, 6 Nov 2013 14:33:45 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCC221E812E for ; Wed, 6 Nov 2013 14:33:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 73BB94C0506; Wed, 6 Nov 2013 14:33:40 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-9207.meeting.ietf.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1C2264C0505; Wed, 6 Nov 2013 14:33:40 -0800 (PST) Message-ID: <527AC3C1.2020304@joelhalpern.com> Date: Wed, 06 Nov 2013 17:33:37 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Melinda Shore , nsc@ietf.org References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> <527AC214.8030409@joelhalpern.com> <527AC25D.9020802@gmail.com> In-Reply-To: <527AC25D.9020802@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:33:51 -0000 We don't generally include in a WG charter work that we hope some other working group will choose to do. Yours, Joel On 11/6/13 5:27 PM, Melinda Shore wrote: > On 11/06/2013 02:26 PM, Joel M. Halpern wrote: >> That still looks like application management. In fact, it looks like >> the exact same application management you want when you are not doing >> service chaining. Which is why I have trouble seeing how it fits in >> this working group. > > It may not fit in *this* working group but you'd still need > interfaces on the services to effect management functions. > > Melinda > > > > From melinda.shore@gmail.com Wed Nov 6 14:33:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4B221E8165 for ; Wed, 6 Nov 2013 14:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHYVL+vbqgku for ; Wed, 6 Nov 2013 14:33:56 -0800 (PST) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B98D621E8161 for ; Wed, 6 Nov 2013 14:33:56 -0800 (PST) Received: by mail-pd0-f171.google.com with SMTP id w10so154780pde.30 for ; Wed, 06 Nov 2013 14:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=poLE1rsZnklopdUVc1+TBs+gji86OsJsbu/fLZl7Lnk=; b=sxrz1fPP/74zgeuMscfKp8vUkiLGSaxErtjgtHZ41deZDzu0FoS53KxQ4roylDSVm9 SLxGq95TJ1EoCcLi0sTkji0SqRm32muoFe4/0xthOgRpAPyMEaHEhHCxm5UwH1B2/T6l BdzTCp4KLhV4McP/lnRehUydqJiLGiUv+bsoFzTM2pwHgaYDdpe8RRLC/HADDItYlQDc ewKxQE035cOrQhJsZC2cNV4boSAjfklf2NghnXjhaEeSkCLRA2Nwp8BSvHgoo8XVJkLj CgH4mrje7aY8+TSd3AWEi0srVMR67uop28quUt8Z91lL3MIbWWBXO7JwZkW7hL46Nxv3 hAJQ== X-Received: by 10.66.129.141 with SMTP id nw13mr6261215pab.167.1383777236231; Wed, 06 Nov 2013 14:33:56 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:655f:664c:edd9:dba4? ([2001:67c:370:144:655f:664c:edd9:dba4]) by mx.google.com with ESMTPSA id xe9sm1133678pab.0.2013.11.06.14.33.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 14:33:55 -0800 (PST) Message-ID: <527AC3D1.9030404@gmail.com> Date: Wed, 06 Nov 2013 14:33:53 -0800 From: Melinda Shore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Andre Beliveau , "Joel M. Halpern" , "nsc@ietf.org" References: <201311011445.rA1Ejrn4007816@cichlid.raleigh.ibm.com> <201311061838.rA6IcGwu024956@cichlid.raleigh.ibm.com> <527AB839.8040608@joelhalpern.com> <527AB983.5090208@gmail.com> <527AC214.8030409@joelhalpern.com> <3049626EAC5C3E43866CD2692A7E19AC1C2CBAF4@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C2CBAF4@eusaamb103.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 22:33:57 -0000 On 11/06/2013 02:31 PM, Andre Beliveau wrote: > How about this formulation: > > "Work on the management and configuration of SFC components related > to the support of Service Functions Chaining will certainly be needed, > but first needs to be better understood and scoped." Works for me. I think a key question is whether or not the work can be started without a rechartering. Melinda From christian.jacquenet@orange.com Thu Nov 7 01:29:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6442C21E80ED for ; Thu, 7 Nov 2013 01:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C9hJSz2x8TN for ; Thu, 7 Nov 2013 01:29:08 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9745311E80FE for ; Thu, 7 Nov 2013 01:29:07 -0800 (PST) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1851718C198; Thu, 7 Nov 2013 10:29:06 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id B697035C06D; Thu, 7 Nov 2013 10:29:05 +0100 (CET) Received: from PUEXCB1C.nanterre.francetelecom.fr ([10.101.44.9]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Thu, 7 Nov 2013 10:29:04 +0100 From: To: Thomas Narten , "nsc@ietf.org" Date: Thu, 7 Nov 2013 10:29:03 +0100 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: Ac7bI3sVWI7GlWznR+S34UJ8qyUZVAAdKMuA Message-ID: <5017_1383816545_527B5D61_5017_5850_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15EE3E3F041@PUEXCB1C.nanterre.francetelecom.fr> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> In-Reply-To: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.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="us-ascii" 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.7.51214 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 09:29:13 -0000 Hi, A few comments inline. [snip]=20 Today, a common deployment model has service functions physically inserted = on the data forwarding path between communicating peers. Going forward, how= ever, there is a desire to move to a different model, where service functio= ns are not required to reside on the default data path and traffic is inste= ad steered through services, wherever they are deployed.=20 [CJ] This last sentence reads strange to me. I don't think there is a desir= e to move to a different model per se, but rather the need to enforce diffe= rentiated traffic forwarding policies that best accommodate the very nature= of the different yet complex services, for the sake of optimized service d= elivery and operation. Such services are designed as the (ordered) combinat= ion and invocation of several elementary functions that are located in vari= ous regions of the network or devices connected to that network. The above = sentence seems to suggest that function chaining has no value if the said f= unctions are located on the default data path, which I think is wrong. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. [CJ] The above causality effect (introduced by the "since") is slightly mis= leading, as there is need to instantiate functions anyway, that is whether = the said function is unique or not. I would therefore suggest something in = the following spirit: "A service function chain is structured by the select= ion of specific service functions that may reside in different network node= s, thereby forming a service function path. A given service function may be= supported by different network nodes and the service function chains that = include such function are structured so that such function is unequivocally= identified." =20 The service functions may be applied at a specific layer within the network= protocol stack (network layer, application layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. [CJ] rather "service delivery and operation". It will produce a framework for service function chaining that includes th= e necessary protocols or protocol extensions to convey the service path and= service path information to nodes that implement service functions, as wel= l as mechanisms for steering traffic through service functions.=20 [CJ] Such framework document should be explicitly mentioned in the mileston= es below. The working group will also examine what information needs to be gathered f= rom the network [CJ] "...from the network nodes" and service functions in support of service function chaining and how that= information may be made available to nodes that implement the service func= tions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, [CJ] What does "placement of capabilities" mean exactly? It sounds like an = organic approach (rather than a functional approach introduced by the inven= tory of the various building blocks) which I don't think belongs to an arch= itecture document. For example, whether a NAT64 function is embedded in a G= GSN or elsewhere is clearly not the kind of consideration that should be ta= ken into account at this stage, because it's rather implementation-specific. management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, [CJ] What does "service function path realization" mean? Does this suggest = considerations about how a SFC is structured, picking network functions, up= per layer functions or a combination thereof? If so, I would elaborate acco= rdingly. and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. [CJ] And yet, the "architecture" milestone explicitly identifies management= considerations (which I fully support). If manageability strictly refers t= o SF configuration and management, I would agree this is not in the scope o= f the WG. But I would then elaborate on what management means in the contex= t of the architecture document above: I think this would relate to the abil= ity for the PDP to dynamically discover the service functions that are supp= orted by the network nodes, the actual structuring of the different chains,= how the corresponding SFC-derived policy provisioning information is provi= ded to the classifier nodes, how chains are managed as a function of the ev= ents that may occur in the network (e.g., a node becomes unavailable) and h= ow such events affect SFC operation or design. =20=20=20=20 Proposed Milestones [CJ] Please add a milestone about the framework, as mentioned above. Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation [CJ] Cheers, [CJ] Christian. Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From jguichar@cisco.com Thu Nov 7 06:50:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BE921E821F for ; Thu, 7 Nov 2013 06:50:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRQ4v+f06Msw for ; Thu, 7 Nov 2013 06:50:35 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id B79D321E8216 for ; Thu, 7 Nov 2013 06:50:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2177; q=dns/txt; s=iport; t=1383835833; x=1385045433; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KJiQpkHe7HUY/R48h5ITFsvOZYS8pbhvD0+cFfYs1Qo=; b=An6JthkPZxODQpFL9XezlKlxY8ckeYt+ZEAZE4xbMisGMumJOySf22He d/J6XDgMnScZowVamlk7Rjo3NvW0f1muSNxQNZTabR9ARXWrtHV4vKWxK KBOPrqoWx1TqYGa9MWFgTX7J3DELfIfOQdBrUq2H2N5Z7DNJFY6XlP0dF U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAHmne1KtJV2b/2dsb2JhbABagwc4U78OgSUWdIIlAQEBBAEBATc0FwYBCBEEAQEBHgkuCxQJCAIEARKIAQ29CgSPYAaEKgOYDJIKgyaCKg X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="scan'208";a="281973811" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2013 14:50:32 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA7EoUpp010661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 14:50:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 08:50:30 -0600 From: "Jim Guichard (jguichar)" To: Andre Beliveau , "Joel M. Halpern" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] Manageability tasks for SFC Thread-Index: AQHO1xE32mPR7jbNUUKYPDg9qHxD75oY9SkAgAA0AoCAAAGJgIAACjcAgAABYQCAAL25gA== Date: Thu, 7 Nov 2013 14:50:30 +0000 Message-ID: In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C2CBAF4@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.229.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 14:50:40 -0000 I prefer this wording as what we are really interested in here is what information needs to be pushed to participating SFC components to realize a service function chain and associated service function path. On 11/6/13 5:31 PM, "Andre Beliveau" wrote: >How about this formulation: > >"Work on the management and configuration of SFC components related >to the support of Service Functions Chaining will certainly be needed, >but first needs to be better understood and scoped." > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Joel M. Halpern >Sent: November-06-13 2:26 PM >To: Melinda Shore; nsc@ietf.org >Subject: Re: [nsc] Manageability tasks for SFC > >That still looks like application management. In fact, it looks like the >exact same application management you want when you are not doing service >chaining. Which is why I have trouble seeing how it fits in this working >group. > >Yours, >Joel > >On 11/6/13 4:49 PM, Melinda Shore wrote: >> On 11/06/2013 01:44 PM, Joel M. Halpern wrote: >>> I find the proposed wording of bullet 5 a little odd. >>> Service functions are applications. I would hope that application >>> management is out of scope for this working group. (I can't tell if >>> I have a problem with the actual milestone, as that depends upon >>> exactly what the scope of a service function chain component is. >>> Management of the chaining seems worth discussing. >> >> Right, I think it's worth thinking about visibility into and >> management of each of the service functions, independent of the >> application they're supporting. Things like status monitoring and >> reporting, instantiation, etc. >> >> Melinda >> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Thu Nov 7 07:38:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3B621E80E8 for ; Thu, 7 Nov 2013 07:38:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBiJO4pysVcV for ; Thu, 7 Nov 2013 07:38:05 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 16A6121E8130 for ; Thu, 7 Nov 2013 07:37:59 -0800 (PST) Received: from mail27-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 15:37:59 +0000 Received: from mail27-tx2 (localhost [127.0.0.1]) by mail27-tx2-R.bigfish.com (Postfix) with ESMTP id 2C09F1801F8; Thu, 7 Nov 2013 15:37:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz9371I146fIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail27-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(199002)(189002)(52314003)(56816003)(77096001)(76576001)(54356001)(87266001)(69226001)(53806001)(76786001)(76796001)(76482001)(2656002)(77982001)(79102001)(56776001)(54316002)(59766001)(46102001)(81342001)(63696002)(51856001)(33646001)(19580405001)(81816001)(19580395003)(87936001)(80976001)(81686001)(83322001)(74366001)(85306002)(83072001)(47976001)(50986001)(74876001)(31966008)(81542001)(74662001)(74316001)(4396001)(74502001)(74706001)(47736001)(49866001)(66066001)(47446002)(80022001)(65816001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail27-tx2 (localhost.localdomain [127.0.0.1]) by mail27-tx2 (MessageSwitch) id 1383838677226670_11862; Thu, 7 Nov 2013 15:37:57 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.246]) by mail27-tx2.bigfish.com (Postfix) with ESMTP id 310A880078; Thu, 7 Nov 2013 15:37:57 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 15:37:56 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 15:37:56 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 15:37:42 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.196]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.240]) with mapi id 15.00.0810.005; Thu, 7 Nov 2013 15:37:42 +0000 From: Ken Gray To: "christian.jacquenet@orange.com" , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yOIO5kXBDEbfUuFoaYF28RaHZoZgVGAgABlSL4= Date: Thu, 7 Nov 2013 15:37:42 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com>, <5017_1383816545_527B5D61_5017_5850_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15EE3E3F041@PUEXCB1C.nanterre.francetelecom.fr> In-Reply-To: <5017_1383816545_527B5D61_5017_5850_1_983A1D8DA0DA5F4EB747BF34CBEE5CD15EE3E3F041@PUEXCB1C.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 00235A1EEF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 15:38:14 -0000 A few of my own comments in line.=0A= ________________________________________=0A= From: nsc-bounces@ietf.org on behalf of christian.ja= cquenet@orange.com =0A= Sent: Thursday, November 07, 2013 4:29 AM=0A= To: Thomas Narten; nsc@ietf.org=0A= Subject: Re: [nsc] Current Proposed SFC charter=0A= =0A= Hi,=0A= =0A= A few comments inline.=0A= =0A= [snip]=0A= =0A= Today, a common deployment model has service functions physically inserted = on the data forwarding path between communicating peers. Going forward, how= ever, there is a desire to move to a different model, where service functio= ns are not required to reside on the default data path and traffic is inste= ad steered through services, wherever they are deployed.=0A= [CJ] This last sentence reads strange to me. I don't think there is a desir= e to move to a different model per se, but rather the need to enforce diffe= rentiated traffic forwarding policies that best accommodate the very nature= of the different yet complex services, for the sake of optimized service d= elivery and operation. Such services are designed as the (ordered) combinat= ion and invocation of several elementary functions that are located in vari= ous regions of the network or devices connected to that network. The above = sentence seems to suggest that function chaining has no value if the said f= unctions are located on the default data path, which I think is wrong.=0A= =0A= [KG] So cut the sentence after "data path" and nobody will be offended?=0A= =0A= For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=0A= this is called a Service Function Path.=0A= [CJ] The above causality effect (introduced by the "since") is slightly mis= leading, as there is need to instantiate functions anyway, that is whether = the said function is unique or not. I would therefore suggest something in = the following spirit: "A service function chain is structured by the select= ion of specific service functions that may reside in different network node= s, thereby forming a service function path. A given service function may be= supported by different network nodes and the service function chains that = include such function are structured so that such function is unequivocally= identified."=0A= =0A= [KG] OR, you could just snip the word "Since" from the beginning of the ori= ginal sentence.=0A= =0A= =0A= [snip] Cheers.= From jmh@joelhalpern.com Thu Nov 7 08:04:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3791421E81C2 for ; Thu, 7 Nov 2013 08:04:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9quyE8GJH9o for ; Thu, 7 Nov 2013 08:03:55 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6A6A521E81C5 for ; Thu, 7 Nov 2013 08:03:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 50AEF1406F7; Thu, 7 Nov 2013 08:03:44 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from dhcp-bcef.meeting.ietf.org (dhcp-bcef.meeting.ietf.org [31.133.188.239]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id EA8A71406F6; Thu, 7 Nov 2013 08:03:43 -0800 (PST) Message-ID: <527BB9DF.4010400@joelhalpern.com> Date: Thu, 07 Nov 2013 11:03:43 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , Andre Beliveau , Melinda Shore , "nsc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Manageability tasks for SFC X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:04:00 -0000 That works for me. Yours, Joel On 11/7/13 9:50 AM, Jim Guichard (jguichar) wrote: > I prefer this wording as what we are really interested in here is what > information needs to be pushed to participating SFC components to realize > a service function chain and associated service function path. > > On 11/6/13 5:31 PM, "Andre Beliveau" wrote: > >> How about this formulation: >> >> "Work on the management and configuration of SFC components related >> to the support of Service Functions Chaining will certainly be needed, >> but first needs to be better understood and scoped." >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Joel M. Halpern >> Sent: November-06-13 2:26 PM >> To: Melinda Shore; nsc@ietf.org >> Subject: Re: [nsc] Manageability tasks for SFC >> >> That still looks like application management. In fact, it looks like the >> exact same application management you want when you are not doing service >> chaining. Which is why I have trouble seeing how it fits in this working >> group. >> >> Yours, >> Joel >> >> On 11/6/13 4:49 PM, Melinda Shore wrote: >>> On 11/06/2013 01:44 PM, Joel M. Halpern wrote: >>>> I find the proposed wording of bullet 5 a little odd. >>>> Service functions are applications. I would hope that application >>>> management is out of scope for this working group. (I can't tell if >>>> I have a problem with the actual milestone, as that depends upon >>>> exactly what the scope of a service function chain component is. >>>> Management of the chaining seems worth discussing. >>> >>> Right, I think it's worth thinking about visibility into and >>> management of each of the service functions, independent of the >>> application they're supporting. Things like status monitoring and >>> reporting, instantiation, etc. >>> >>> Melinda >>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > From kgray@juniper.net Thu Nov 7 13:22:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D2321E80B6 for ; Thu, 7 Nov 2013 13:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.849 X-Spam-Level: X-Spam-Status: No, score=-3.849 tagged_above=-999 required=5 tests=[AWL=-1.251, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Adfcqcm9VGnS for ; Thu, 7 Nov 2013 13:22:30 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 341D721E8092 for ; Thu, 7 Nov 2013 13:22:27 -0800 (PST) Received: from mail49-db8-R.bigfish.com (10.174.8.252) by DB8EHSOBE011.bigfish.com (10.174.4.74) with Microsoft SMTP Server id 14.1.225.22; Thu, 7 Nov 2013 21:22:26 +0000 Received: from mail49-db8 (localhost [127.0.0.1]) by mail49-db8-R.bigfish.com (Postfix) with ESMTP id 123096404C1 for ; Thu, 7 Nov 2013 21:22:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 2 X-BigFish: VPS2(zzc85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz17326ah8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h9a9j1155h) Received-SPF: pass (mail49-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(199002)(189002)(85306002)(47446002)(74876001)(49866001)(47976001)(50986001)(2656002)(31966008)(87266001)(69226001)(4396001)(74502001)(74662001)(16236675002)(81342001)(81542001)(74366001)(74706001)(87936001)(47736001)(76482001)(59766001)(77982001)(56776001)(54316002)(79102001)(63696002)(19580395003)(558084003)(81686001)(81816001)(83322001)(56816003)(76796001)(76176001)(76786001)(66066001)(65816001)(76576001)(80022001)(33646001)(74316001)(15975445006)(15202345003)(54356001)(77096001)(80976001)(83072001)(46102001)(51856001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB084; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail49-db8 (localhost.localdomain [127.0.0.1]) by mail49-db8 (MessageSwitch) id 1383859343786785_2381; Thu, 7 Nov 2013 21:22:23 +0000 (UTC) Received: from DB8EHSMHS020.bigfish.com (unknown [10.174.8.226]) by mail49-db8.bigfish.com (Postfix) with ESMTP id B2975D80049 for ; Thu, 7 Nov 2013 21:22:23 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS020.bigfish.com (10.174.4.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 7 Nov 2013 21:22:23 +0000 Received: from BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 7 Nov 2013 21:22:17 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB084.namprd05.prod.outlook.com (10.255.232.27) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 7 Nov 2013 21:22:11 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.196]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.240]) with mapi id 15.00.0810.005; Thu, 7 Nov 2013 21:22:11 +0000 From: Ken Gray To: "nsc@ietf.org" Thread-Topic: Call for papers for OpenDaylight Summit (nothing to do with the BoF) Thread-Index: AQHO2/DG69AZocPBx0iumJ9eMg7P7g== Date: Thu, 7 Nov 2013 21:22:10 +0000 Message-ID: <687135ba55a643fbb7966e7a87bdf4f0@BL2PR05MB082.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 00235A1EEF Content-Type: multipart/alternative; boundary="_000_687135ba55a643fbb7966e7a87bdf4f0BL2PR05MB082namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [nsc] Call for papers for OpenDaylight Summit (nothing to do with the BoF) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 21:22:36 -0000 --_000_687135ba55a643fbb7966e7a87bdf4f0BL2PR05MB082namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry if you consider this spam, but this is potentially the largest intere= st-pool for such a thing. The OpenDaylight Summit has a rapidly closing wi= ndow for papers. The call for papers is here: http://events.linuxfoundatio= n.org/events/opendaylight-summit/program/cfp Thanks for your patience. --_000_687135ba55a643fbb7966e7a87bdf4f0BL2PR05MB082namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sorry if you consider this spam, but this is potentially the largest intere= st-pool for such a thing.  The OpenDaylight Summit has a rapidly closi= ng window for papers.  The call for papers is here: http://events.linuxfoundation.org/even= ts/opendaylight-summit/program/cfp

Thanks for your patience. 
--_000_687135ba55a643fbb7966e7a87bdf4f0BL2PR05MB082namprd05pro_-- From diego@tid.es Thu Nov 7 16:20:52 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC85F21E8169 for ; Thu, 7 Nov 2013 16:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwHpnBZ3OzIR for ; Thu, 7 Nov 2013 16:20:49 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 53BBA21E8195 for ; Thu, 7 Nov 2013 16:20:45 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MVX003VF4YEHR@tid.hi.inet> for nsc@ietf.org; Fri, 08 Nov 2013 01:20:38 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id DB.61.28420.65E2C725; Fri, 08 Nov 2013 01:20:38 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MVX003VC4YEHR@tid.hi.inet> for nsc@ietf.org; Fri, 08 Nov 2013 01:20:38 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.212]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Fri, 08 Nov 2013 01:20:38 +0100 Date: Fri, 08 Nov 2013 00:20:37 +0000 From: "Diego R. Lopez" X-Originating-IP: [10.95.64.115] To: "nsc@ietf.org" Message-id: <758D5AEC-3424-40F4-ABE7-7E716870433E@tid.es> Content-id: <6B7BAE51D6974D44A41038E32F2BC923@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: The already published NFV documents Thread-index: AQHO3BhZETrOLltJ4EOR1O8Tn78lUw== X-AuditID: 0a5f4e69-b7fe58e000006f04-40-527c2e566cbf X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsXCFe9nqBumVxNk8GSyhcXxffvZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsWbbb7aCFZwV/18mNzB2cHYxcnBICJhI7PtY38XICWSKSVy4 t56ti5GLQ0hgG6PEgnPdrBDON0aJTTN7oJyZjBI/H91hA2lhEVCVODx/EpjNBmQ/av7NDjJV WEBH4ubBKoipChJ/zj1mAQmLCChK7HyTAhLmFbCUWPWojQXEZhYwk1j3q4kNIi4o8WPyPbBy ZgF1iSlTciFKxCWaW29ClStKTFvUwAhiMwrISrybP58VxBYRMJSY9Ow2M4StJ/Fg8k92iAsE JJbsOc8MYYtKvHz8j3UCo+gsJJtnIdk8C2HzLCSbZyHZvICRdRWjWHFSUWZ6RkluYmZOuoGR XkamXmZeaskmRkiUZO5gXL5T5RCjAAejEg9vwYXqICHWxLLiytxDjBIczEoivM8Ua4KEeFMS K6tSi/Lji0pzUosPMTJxcEo1MG6S2lHEZjarU1HzU+OFzWGLbD1v8G6/ab1lgc1aXzYdzrWy U2ukQ5KX5sodmmebfDB367S3U5cWBLL/25JnG8Ye8P/LzZTKTZ3nrqf27Y3In5k45dOi9jzz 3DsfLxTZPdLfP3F3WNumgz/sJ0yJs+Oay3bAdtH3RSWfOiKCj5wVZxM//bGn+7gSS3FGoqEW c1FxIgBj8XtIcAIAAA== Subject: [nsc] The already published NFV documents X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:20:53 -0000 SGksDQoNCkluIG15IHJvbGUgb2YgbGlhaXNvbiwgbGV0IG1lIHBvaW50IHlvdSB0byB0aGVtIGZv ciB5b3VyIGVudGVydGFpbm1lbnQsIHZpZXdpbmcgcGxlYXN1cmUgYW5kIHBvdGVudGlhbCBjb25z aWRlcmF0aW9uIGFzIGEgcmVmZXJlbmNlIGluIHRoZSBjb21pbmcgd29ya3Mgb2YgU0ZDOg0KDQpK dXN0IGdvIHRvIGh0dHA6Ly93d3cuZXRzaS5vcmcvbmZ2IGFuZCBjbGljayBvbiAiU3BlY2lmaWNh dGlvbnMiDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3Rv ciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8v cGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDog ICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3Ug ZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61v IHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRv IG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0 cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMg b2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rp c2NsYWltZXIuYXNweA0K From Ron_Parker@affirmednetworks.com Fri Nov 8 22:14:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F44E21E80DA for ; Fri, 8 Nov 2013 22:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFRLC9Ys-bTG for ; Fri, 8 Nov 2013 22:14:01 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id CD89221E80CE for ; Fri, 8 Nov 2013 22:13:58 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 22:13:58 -0800 From: Ron Parker To: "nsc@ietf.org" Thread-Topic: New SFC posting -- SFC service chain to path reduction Thread-Index: Ac7dEkLU+xWtCFUgSeG/Wv681iuirg== Date: Sat, 9 Nov 2013 06:13:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [209.82.80.116] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A747DF1MBX021W3CA2exch_" MIME-Version: 1.0 Subject: [nsc] New SFC posting -- SFC service chain to path reduction X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 06:14:06 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A747DF1MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear SFC people, Thanks for all of the wonderful questions on the SFC architecture during IE= TF 88 in Vancouver. And thanks to the audience for the resounding vote of= support for our work. In an attempt to resolve some of the questions re= garding the differences between service chains and service paths and how lo= cators are used, I have uploaded a new I-D http://datatracker.ietf.org/doc/= draft-parker-sfc-chain-to-path/. As always, the more spirited the discussion, the better. Thanks. Ron --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A747DF1MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear SFC people,

 

Thanks for all of the wonderful questions on the SFC= architecture during IETF 88 in Vancouver.   And thanks to the au= dience for the resounding vote of support for our work.    I= n an attempt to resolve some of the questions regarding the differences between service chains and service paths and how locators are = used, I have uploaded a new I-D http://datatracker.ietf.org/doc/draft-parker-sfc-chain-to-path/. =  

 

As always, the more spirited the discussion, the bet= ter.

 

Thanks.

 

   Ron

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A747DF1MBX021W3CA2exch_-- From S.Majee@f5.com Mon Nov 11 15:45:56 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E6D11E814B for ; Mon, 11 Nov 2013 15:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsZahVEThH7d for ; Mon, 11 Nov 2013 15:45:44 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id B8B5111E80D9 for ; Mon, 11 Nov 2013 15:45:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,680,1378857600"; d="scan'208";a="87232359" X-IPAS-Result: AqMEAMtrgVLAqArr/2dsb2JhbABZgz9TvxaBU3SCJQEBAQEDAQEBNy0HBBMEAgEIDQQBAwEBCxQJBycLFAMGCAIEAQkJCIgGviETBI4wgQI4BoMagRADlC6KRY5MgWlB Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 11 Nov 2013 23:45:43 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 15:45:42 -0800 From: Sumandra Majee To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQ Date: Mon, 11 Nov 2013 23:45:41 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> In-Reply-To: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 23:45:56 -0000 Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Nov 11 16:36:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE1D11E812A for ; Mon, 11 Nov 2013 16:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qOhxI+PI3mFq for ; Mon, 11 Nov 2013 16:36:18 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id 134F421E80C1 for ; Mon, 11 Nov 2013 16:36:18 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 16:36:11 -0800 From: Ron Parker To: Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhA= Date: Tue, 12 Nov 2013 00:36:11 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 00:36:24 -0000 Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From prvs=80288a6c26=hshah@ciena.com Mon Nov 11 18:26:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9637521E8106 for ; Mon, 11 Nov 2013 18:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtLXPrt+CA35 for ; Mon, 11 Nov 2013 18:26:29 -0800 (PST) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6121E814B for ; Mon, 11 Nov 2013 18:26:19 -0800 (PST) Received: from pps.filterd (m0000419.ppops.net [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id rAC0LC6u015069; Mon, 11 Nov 2013 20:01:56 -0500 Received: from mdwvexchht01.ciena.com ([63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 1g1b8r9caa-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 11 Nov 2013 20:01:56 -0500 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 11 Nov 2013 20:01:55 -0500 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Mon, 11 Nov 2013 20:01:54 -0500 From: "Shah, Himanshu" To: Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Mon, 11 Nov 2013 20:01:53 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAAepQA== Message-ID: <40746B2300A8FC4AB04EE722A593182B6A03BDA9@ONWVEXCHMB04.ciena.com> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20284.003 X-TM-AS-Result: No--30.689000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-11-11_04:2013-11-11, 2013-11-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1311110177 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:26:36 -0000 It appears that within service (chain) header, individual service member wo= uld need either, offset to original packet or total size of the service chain header so that= service delivery component can locate the original packet to perform the service. Alternately, service proxy function (mentioned by you) at the doorstep, perform some push/pop action during entry/exit of the service point. /himanshu -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P= arker Sent: Monday, November 11, 2013 7:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Nov 11 18:35:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7090521E8109 for ; Mon, 11 Nov 2013 18:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLZ9q9LlBCqV for ; Mon, 11 Nov 2013 18:35:27 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 71E2C21E8106 for ; Mon, 11 Nov 2013 18:35:27 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 18:35:25 -0800 From: Ron Parker To: "Shah, Himanshu" , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAAepQIAAGjVg Date: Tue, 12 Nov 2013 02:35:24 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <40746B2300A8FC4AB04EE722A593182B6A03BDA9@ONWVEXCHMB04.ciena.com> In-Reply-To: <40746B2300A8FC4AB04EE722A593182B6A03BDA9@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:35:32 -0000 Himanshu, The service chain header does, indeed, need to be self-descriptive with res= pect to its size in one manner or another.=20 While the service header could be designed as a stack of per-service-functi= on entries, there is sensitivity to packet growth and in particular, unboun= ded packet growth. Most discussion, so far, has been around a single cha= in ID that is commonly understood along the entire service chain (via coord= inated provisioning or an as-yet unspecified control plane protocol). See http://datatracker.ietf.org/doc/draft-quinn-sfc-nsh/ for one proposal o= n design of the service chain header. Ron -----Original Message----- From: Shah, Himanshu [mailto:hshah@ciena.com]=20 Sent: Monday, November 11, 2013 8:02 PM To: Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter It appears that within service (chain) header, individual service member wo= uld need either, offset to original packet or total size of the service cha= in header so that service delivery component can locate the original packet= to perform the service. Alternately, service proxy function (mentioned by you) at the doorstep, per= form some push/pop action during entry/exit of the service point. /himanshu -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P= arker Sent: Monday, November 11, 2013 7:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From S.Majee@f5.com Mon Nov 11 18:56:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AB111E81A5 for ; Mon, 11 Nov 2013 18:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpLlD4RETXOd for ; Mon, 11 Nov 2013 18:55:57 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2411E81A0 for ; Mon, 11 Nov 2013 18:55:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,681,1378857600"; d="scan'208";a="87244832" X-IPAS-Result: AqMEAFSYgVLAqArr/2dsb2JhbABPCoM/U78bgVh0giUBAQEBAwEBATctBwQTBAIBCA0EAQMBAQsUCQcnCxQDBggCBAEJCQiIBr4qEwSOFwQMgQI4BoMagRADlC6KRY5MgWgBQQ Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Nov 2013 02:55:55 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 18:55:54 -0800 From: Sumandra Majee To: Ron Parker , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgACW2YD//5/0sA== Date: Tue, 12 Nov 2013 02:55:53 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@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.16.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:56:02 -0000 Ron, The service header is meant to carry the context which can *also* be derive= d (for example use source ip and vlan to identify chainID and position) or = encapsulated as part of another tunnel header. So this could be optional IM= HO. =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 4:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Nov 11 19:02:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537111E81A0 for ; Mon, 11 Nov 2013 19:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmnG3O55qS3r for ; Mon, 11 Nov 2013 19:01:58 -0800 (PST) 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 DFEEA11E8191 for ; Mon, 11 Nov 2013 19:01:57 -0800 (PST) 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.0158.001; Mon, 11 Nov 2013 19:01:53 -0800 From: Ron Parker To: Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgw Date: Tue, 12 Nov 2013 03:01:53 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:02:02 -0000 Sumandra, The intention of service function chaining is to allow for operation at the= fully qualified flow level, or even finer grained at the transaction level= (this is an implementation matter for the PDP). All flows from the sam= e source IP do not necessarily follow the same chain. Source IP, therefor= e, does not identify the chain ID. Another intention of service functio= n chaining is to operate over any network topology and not be limited to a = single LAN. Thus, while VLAN may be part of the transport, it does not ad= equately identify the service chain, either. Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Monday, November 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Ron, The service header is meant to carry the context which can *also* be derive= d (for example use source ip and vlan to identify chainID and position) or = encapsulated as part of another tunnel header. So this could be optional IM= HO. =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 4:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From S.Majee@f5.com Mon Nov 11 19:09:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D611E81A0 for ; Mon, 11 Nov 2013 19:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7OMkRKRswj9 for ; Mon, 11 Nov 2013 19:09:35 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id B795C11E81A5 for ; Mon, 11 Nov 2013 19:09:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,681,1378857600"; d="scan'208";a="87245521" X-IPAS-Result: AqMEAKmagVLAqArr/2dsb2JhbABPCoM/U78bgVh0giUBAQEBAwEBATctBwQTBAIBCA0EAQMBAQsUCQcnCxQDBggCBAEJCQiIBr4wEwSOFwQMgQI4BoMagRADlC6KRY5MgWgBQQ Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 12 Nov 2013 03:09:35 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 19:09:34 -0800 From: Sumandra Majee To: Ron Parker , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgACW2YD//5/0sIAAiMKA//96YzA= Date: Tue, 12 Nov 2013 03:09:33 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@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.16.236] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:09:40 -0000 Ron, Absolutely, that was an example of one type of derivation. However this cou= ld be augmented with classification result, again one more example.=20 >>All flows from the same source IP do not necessarily follow the same chai= n. =20 Correct. It is also not necessary that all transaction of the same flow fol= low the same chain either. So why stop at flow itself. Again the point here is that do we always need SFC header or Not. Sumandra -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 7:02 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, The intention of service function chaining is to allow for operation at the= fully qualified flow level, or even finer grained at the transaction level= (this is an implementation matter for the PDP). All flows from the sam= e source IP do not necessarily follow the same chain. Source IP, therefor= e, does not identify the chain ID. Another intention of service functio= n chaining is to operate over any network topology and not be limited to a = single LAN. Thus, while VLAN may be part of the transport, it does not ad= equately identify the service chain, either. Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Monday, November 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Ron, The service header is meant to carry the context which can *also* be derive= d (for example use source ip and vlan to identify chainID and position) or = encapsulated as part of another tunnel header. So this could be optional IM= HO. =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 4:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Nov 11 19:16:10 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E918111E81A8 for ; Mon, 11 Nov 2013 19:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bILDTbf4YVHo for ; Mon, 11 Nov 2013 19:15:52 -0800 (PST) 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 F329711E81D1 for ; Mon, 11 Nov 2013 19:15:51 -0800 (PST) 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.0158.001; Mon, 11 Nov 2013 19:15:51 -0800 From: Ron Parker To: Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQA== Date: Tue, 12 Nov 2013 03:15:50 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:16:10 -0000 Sumandra, As was discussed in Vancouver, there are already many existing ways to acco= mplish service chaining. But none of them provide a sufficient combinat= ion of interoperability, flexibility, and resiliency. A single service ch= ain encapsulation will go a long way to ensuring these goals. It may not= be the absolutely most efficient approach for every single network topolog= y and every single use case, but its ubiquitous nature should improve its a= doption.=20 Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Monday, November 11, 2013 10:10 PM To: Ron Parker; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Ron, Absolutely, that was an example of one type of derivation. However this cou= ld be augmented with classification result, again one more example.=20 >>All flows from the same source IP do not necessarily follow the same chai= n. =20 Correct. It is also not necessary that all transaction of the same flow fol= low the same chain either. So why stop at flow itself. Again the point here is that do we always need SFC header or Not. Sumandra -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 7:02 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, The intention of service function chaining is to allow for operation at the= fully qualified flow level, or even finer grained at the transaction level= (this is an implementation matter for the PDP). All flows from the sam= e source IP do not necessarily follow the same chain. Source IP, therefor= e, does not identify the chain ID. Another intention of service functio= n chaining is to operate over any network topology and not be limited to a = single LAN. Thus, while VLAN may be part of the transport, it does not ad= equately identify the service chain, either. Ron -----Original Message----- From: Sumandra Majee [mailto:S.Majee@F5.com]=20 Sent: Monday, November 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Ron, The service header is meant to carry the context which can *also* be derive= d (for example use source ip and vlan to identify chainID and position) or = encapsulated as part of another tunnel header. So this could be optional IM= HO. =20 -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, November 11, 2013 4:36 PM To: Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Sumandra, As I understand it, an SFC packet traversing from PDP to SF or from SF to S= F will look like: +------------------------+ | "transport" | +------------------------+ | service header | +------------------------+ | original IP header | +------------------------+ | | original IP payload | | | +------------------------+ Where service header contains, at a minimum, enough information to allow th= e packet to be propagated along the full length of the chain, and optionall= y, other metadata that enhances the operation of one or more service functi= ons. And where "transport" could conceivably be any of, but not limited to: * Ethernet * Ethernet + LLC2 * Ethernet + MPLS * Ethernet + IP + GRE * Ethernet + IP +UDP Also, "original" in the diagram above is not meant to imply immutability, b= ut rather to specify the packet that is propagated from preceding entity to= succeeding entity, prior to encapsulation. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suman= dra Majee Sent: Monday, November 11, 2013 6:46 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service. [SM] What does it mean by a single service-level encapsulation, a new enca= psulation format or an ability to select one encapsulation format that fits the = need for a given service chain? The ability to select a specific encapsulation would be a manag= ement plane decision. There are quite a few existing encapsulation methods that can pos= sibly be reused to provide context information between service nodes. I have seen mention = of GRE, for HTTP based applications contexts are transferred via headers. =20 =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Wednesday, November 06, 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] Current Proposed SFC charter Hi. Current charter can be found at https://datatracker.ietf.org/doc/charter-ie= tf-sfc/. It contains the revised management text as well as updated milestones. All known issues have been addressed. If there are any remaining issues, pl= ease speak up! Charter charter-ietf-sfc-00-04 Networks, servers, storage technologies, and applications, have all undergo= ne significant change in recent years with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both= a technical and organizational challenge that involves significant modific= ation to the network configuration.=20 Services are typically implemented by the ordered combination of a number o= f service functions that are deployed at different points within the networ= k. Today, a common deployment model has service functions physically insert= ed on the data forwarding path between communicating peers. Going forward, = however, there is a desire to move to a different model, where service func= tions are not required to reside on the default data path and traffic is in= stead steered through services, wherever they are deployed.=20 For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). Since a given service function may be available on more than o= ne node within a network, a Service Function Chain is instantiated via the = selection of specific service function instances and the network nodes on w= hich they are provided, thereby forming a service topology:=20 this is called a Service Function Path. The service functions may be applie= d at a specific layer within the network protocol stack (network layer, app= lication layer, etc.).=20 The Service Function Chaining (SFC) working group will develop new approach= es to service delivery and deployment. It will produce a framework for serv= ice function chaining that includes the necessary protocols or protocol ext= ensions to convey the service path and service path information to nodes th= at implement service functions, as well as mechanisms for steering traffic = through service functions. The working group will also examine what informa= tion needs to be gathered from the network and service functions in support= of service function chaining and how that information may be made availabl= e to nodes that implement the service functions.=20 Specifically, the SFC WG is chartered to deliver the following:=20 1) Problem Statement: This document will provide a summary of the problem space to be addressed by the WG including example high- level use cases. Additionally, the WG will normalize nomenclature and definitions for service function chaining.=20 2) Architecture: This document will provide a description of the architectural building blocks and their relationships including interconnection, placement of capabilities, management, diagnostics, design analysis, and security models, as well as=20 requirements on the protocol mechanisms.=20 3) Generic Service Function Chaining Encapsulation: A document will describe the single service-level data plane encapsulation format for conveying the service function chain and the service function path, and for communicating context information between nodes that implement service functions. It is intended that the encapsulation=20 be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service.=20 4) Control Plane Mechanisms: A set of documents will be developed to describe requirements and protocols necessary to convey information to service function implementation points. Where possible, existing IETF protocols will be used and extended. All protocol extensions work should be carried out in the working groups responsible for the=20 protocols being modified in coordination with this working group, but may be done in this working group after agreement with all the relevant WG chairs and responsible ADs.=20 5) Manageability: Work on the management and configuration of service functions in support of SFC components will certainly be needed, but first needs to be better understood and scoped. =20 Proposed Milestones Apr 2014 Submit to IESG Informational document(s) defining the problem stat= ement and core use cases for Service Function Chaining May 2014 Consult with OPS Area on possible charter modifications for manage= ment and configuration of SFC components Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG requirements for a generic service function chainin= g encapsulation protocol Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Mon Nov 11 19:33:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E193E21E8099 for ; Mon, 11 Nov 2013 19:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOSNMxYa80TX for ; Mon, 11 Nov 2013 19:33:25 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 479C321E8085 for ; Mon, 11 Nov 2013 19:33:25 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8EBA95535E3; Mon, 11 Nov 2013 22:33:24 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CDA9055342A; Mon, 11 Nov 2013 22:33:23 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Mon, 11 Nov 2013 22:33:23 -0500 From: Kevin J Ma To: Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Mon, 11 Nov 2013 22:33:21 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNw Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:33:30 -0000 Hi Ron, I was unable to make the SFC BoF due to a conflict with CDNI, but I had a similar question wrt bullet 11 in section 2 of the problem statemen= t: 11. Per-Service (re)Classification: Classification occurs at each service, independent from previously applied service functions. These unrelated classification events consume resources per service. More importantly, the classification functionality often differs per service function and service function cannot leverage the results from other deployed network or service. as it relates to section 5.2 of the framework document: The SFC Classifier classifies packets based on (some of) the contents of the packet header. Concretely, it classifies packets based on the possible combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and any other information. A packet-based classifier as described in the framework document would seem to be limited in what it can classify? The service function=20 identifier lookup does not seem to be a significant optimization over a packet-based 5-tuple lookup? There seems to be some missing detail wrt how classification information is determined and reused? When thinking about higher level services, e.g., HTTP and TLS encrypted flows, a packet-based classifier seems inadequate? I was also wondering how independent HLS segment requests might be classified and associated? Were these types of use cases discussed in the BoF? thanx. -- Kevin J. Ma > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron > Parker > Sent: Monday, November 11, 2013 10:16 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > As was discussed in Vancouver, there are already many existing ways to > accomplish service chaining. But none of them provide a sufficient > combination of interoperability, flexibility, and resiliency. A single > service chain encapsulation will go a long way to ensuring these goals. > It may not be the absolutely most efficient approach for every single > network topology and every single use case, but its ubiquitous nature > should improve its adoption. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Monday, November 11, 2013 10:10 PM > To: Ron Parker; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Ron, >=20 > Absolutely, that was an example of one type of derivation. However this > could be augmented with classification result, again one more example. >=20 > >>All flows from the same source IP do not necessarily follow the same > chain. > Correct. It is also not necessary that all transaction of the same flow > follow the same chain either. So why stop at flow itself. >=20 > Again the point here is that do we always need SFC header or Not. >=20 > Sumandra >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, November 11, 2013 7:02 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > The intention of service function chaining is to allow for operation at > the fully qualified flow level, or even finer grained at the transaction > level (this is an implementation matter for the PDP). All flows from > the same source IP do not necessarily follow the same chain. Source IP, > therefore, does not identify the chain ID. Another intention of > service function chaining is to operate over any network topology and not > be limited to a single LAN. Thus, while VLAN may be part of the > transport, it does not adequately identify the service chain, either. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Monday, November 11, 2013 9:56 PM > To: Ron Parker; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Ron, >=20 > The service header is meant to carry the context which can *also* be > derived (for example use source ip and vlan to identify chainID and > position) or encapsulated as part of another tunnel header. So this could > be optional IMHO. >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, November 11, 2013 4:36 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > As I understand it, an SFC packet traversing from PDP to SF or from SF to > SF will look like: >=20 > +------------------------+ > | "transport" | > +------------------------+ > | service header | > +------------------------+ > | original IP header | > +------------------------+ > | | original IP payload | > | | > +------------------------+ >=20 > Where service header contains, at a minimum, enough information to allow > the packet to be propagated along the full length of the chain, and > optionally, other metadata that enhances the operation of one or more > service functions. >=20 > And where "transport" could conceivably be any of, but not limited to: >=20 > * Ethernet > * Ethernet + LLC2 > * Ethernet + MPLS > * Ethernet + IP + GRE > * Ethernet + IP +UDP >=20 >=20 > Also, "original" in the diagram above is not meant to imply immutability, > but rather to specify the packet that is propagated from preceding entity > to succeeding entity, prior to encapsulation. >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Sumandra Majee > Sent: Monday, November 11, 2013 6:46 PM > To: Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that > is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. >=20 > [SM] What does it mean by a single service-level encapsulation, a new > encapsulation format > or an ability to select one encapsulation format that fits th= e > need for a given service chain? > The ability to select a specific encapsulation would be a > management plane decision. > There are quite a few existing encapsulation methods that can > possibly be reused to provide > context information between service nodes. I have seen mentio= n > of GRE, for HTTP based > applications contexts are transferred via headers. >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Wednesday, November 06, 2013 11:07 AM > To: nsc@ietf.org > Subject: [nsc] Current Proposed SFC charter >=20 > Hi. >=20 > Current charter can be found at https://datatracker.ietf.org/doc/charter- > ietf-sfc/. >=20 > It contains the revised management text as well as updated milestones. >=20 > All known issues have been addressed. If there are any remaining issues, > please speak up! >=20 > Charter charter-ietf-sfc-00-04 >=20 > Networks, servers, storage technologies, and applications, have all > undergone significant change in recent years with the introduction of > virtualization, network overlays, and orchestration. Service delivery is > currently both a technical and organizational challenge that involves > significant modification to the network configuration. > Services are typically implemented by the ordered combination of a number > of service functions that are deployed at different points within the > network. Today, a common deployment model has service functions physicall= y > inserted on the data forwarding path between communicating peers. Going > forward, however, there is a desire to move to a different model, where > service functions are not required to reside on the default data path and > traffic is instead steered through services, wherever they are deployed. >=20 > For a given service, the abstracted view of the required service function= s > and the order in which they are to be applied is called a Service Functio= n > Chain (SFC). Since a given service function may be available on more than > one node within a network, a Service Function Chain is instantiated via > the selection of specific service function instances and the network node= s > on which they are provided, thereby forming a service topology: > this is called a Service Function Path. The service functions may be > applied at a specific layer within the network protocol stack (network > layer, application layer, etc.). >=20 > The Service Function Chaining (SFC) working group will develop new > approaches to service delivery and deployment. It will produce a framewor= k > for service function chaining that includes the necessary protocols or > protocol extensions to convey the service path and service path > information to nodes that implement service functions, as well as > mechanisms for steering traffic through service functions. The working > group will also examine what information needs to be gathered from the > network and service functions in support of service function chaining and > how that information may be made available to nodes that implement the > service functions. >=20 > Specifically, the SFC WG is chartered to deliver the following: >=20 > 1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high- > level use cases. Additionally, the WG will normalize nomenclature > and definitions for service function chaining. >=20 > 2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. >=20 > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that > is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. >=20 > 4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information > to service function implementation points. Where possible, existing > IETF protocols will be used and extended. All protocol extensions > work should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. >=20 > 5) Manageability: Work on the management and configuration of service > functions in support of SFC components will certainly be needed, > but first needs to be better understood and scoped. >=20 > Proposed Milestones >=20 > Apr 2014 Submit to IESG Informational document(s) defining the problem > statement and core use cases for Service Function Chaining >=20 > May 2014 Consult with OPS Area on possible charter modifications for > management and configuration of SFC components >=20 > Jan 2015 Submit to IESG Informational document defining the architecture > for SFC >=20 > Jan 2015 Submit to IESG requirements for a generic service function > chaining encapsulation protocol >=20 > Aug 2015 Submit to IESG Standards Track document specifying the generic > service function chaining header encapsulation >=20 >=20 >=20 >=20 >=20 > Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Mon Nov 11 19:41:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C75511E81A0 for ; Mon, 11 Nov 2013 19:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCnOhju2z0u7 for ; Mon, 11 Nov 2013 19:40:57 -0800 (PST) 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 B6BFE11E81A5 for ; Mon, 11 Nov 2013 19:40:56 -0800 (PST) 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.0158.001; Mon, 11 Nov 2013 19:40:56 -0800 From: Ron Parker To: Kevin J Ma , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwAAC5a9A= Date: Tue, 12 Nov 2013 03:40:55 +0000 Message-ID: References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:41:03 -0000 Hi, Kevin. I agree that the classifier should not be constrained. While a full speci= fication of the classifier seems beyond scope to me, a discussion of the ov= erall design implications of the classifier supporting the protocols and te= chniques you describe below could make for an interesting I-D :). Ron -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Monday, November 11, 2013 10:33 PM To: Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter Hi Ron, I was unable to make the SFC BoF due to a conflict with CDNI, but I had a similar question wrt bullet 11 in section 2 of the problem statemen= t: 11. Per-Service (re)Classification: Classification occurs at each service, independent from previously applied service functions. These unrelated classification events consume resources per service. More importantly, the classification functionality often differs per service function and service function cannot leverage the results from other deployed network or service. as it relates to section 5.2 of the framework document: The SFC Classifier classifies packets based on (some of) the contents of the packet header. Concretely, it classifies packets based on the possible combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and any other information. A packet-based classifier as described in the framework document would seem to be limited in what it can classify? The service function identifier lookup does not seem to be a significant optimization over a packet-based 5-tuple lookup? There seems to be some missing detail wrt how classification information is determined and reused? When thinking about higher level services, e.g., HTTP and TLS encrypted flows, a packet-based classifier seems inadequate? I was also wondering how independent HLS segment requests might be classified and associated? Were these types of use cases discussed in the BoF? thanx. -- Kevin J. Ma > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Ron Parker > Sent: Monday, November 11, 2013 10:16 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > As was discussed in Vancouver, there are already many existing ways to > accomplish service chaining. But none of them provide a sufficient > combination of interoperability, flexibility, and resiliency. A single > service chain encapsulation will go a long way to ensuring these goals. > It may not be the absolutely most efficient approach for every single=20 > network topology and every single use case, but its ubiquitous nature=20 > should improve its adoption. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Monday, November 11, 2013 10:10 PM > To: Ron Parker; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Ron, >=20 > Absolutely, that was an example of one type of derivation. However=20 > this could be augmented with classification result, again one more exampl= e. >=20 > >>All flows from the same source IP do not necessarily follow the same > chain. > Correct. It is also not necessary that all transaction of the same=20 > flow follow the same chain either. So why stop at flow itself. >=20 > Again the point here is that do we always need SFC header or Not. >=20 > Sumandra >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, November 11, 2013 7:02 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > The intention of service function chaining is to allow for operation=20 > at the fully qualified flow level, or even finer grained at the transacti= on > level (this is an implementation matter for the PDP). All flows from > the same source IP do not necessarily follow the same chain. Source IP, > therefore, does not identify the chain ID. Another intention of > service function chaining is to operate over any network topology and not > be limited to a single LAN. Thus, while VLAN may be part of the > transport, it does not adequately identify the service chain, either. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Sumandra Majee [mailto:S.Majee@F5.com] > Sent: Monday, November 11, 2013 9:56 PM > To: Ron Parker; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Ron, >=20 > The service header is meant to carry the context which can *also* be=20 > derived (for example use source ip and vlan to identify chainID and > position) or encapsulated as part of another tunnel header. So this=20 > could be optional IMHO. >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, November 11, 2013 4:36 PM > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Sumandra, >=20 > As I understand it, an SFC packet traversing from PDP to SF or from SF=20 > to SF will look like: >=20 > +------------------------+ > | "transport" | > +------------------------+ > | service header | > +------------------------+ > | original IP header | > +------------------------+ > | | original IP payload | > | | > +------------------------+ >=20 > Where service header contains, at a minimum, enough information to=20 > allow the packet to be propagated along the full length of the chain,=20 > and optionally, other metadata that enhances the operation of one or=20 > more service functions. >=20 > And where "transport" could conceivably be any of, but not limited to: >=20 > * Ethernet > * Ethernet + LLC2 > * Ethernet + MPLS > * Ethernet + IP + GRE > * Ethernet + IP +UDP >=20 >=20 > Also, "original" in the diagram above is not meant to imply=20 > immutability, but rather to specify the packet that is propagated from=20 > preceding entity to succeeding entity, prior to encapsulation. >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Sumandra Majee > Sent: Monday, November 11, 2013 6:46 PM > To: Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service=20 > that is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. >=20 > [SM] What does it mean by a single service-level encapsulation, a new=20 > encapsulation format > or an ability to select one encapsulation format that fits=20 > the need for a given service chain? > The ability to select a specific encapsulation would be a=20 > management plane decision. > There are quite a few existing encapsulation methods that=20 > can possibly be reused to provide > context information between service nodes. I have seen mentio= n > of GRE, for HTTP based > applications contexts are transferred via headers. >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Thomas Narten > Sent: Wednesday, November 06, 2013 11:07 AM > To: nsc@ietf.org > Subject: [nsc] Current Proposed SFC charter >=20 > Hi. >=20 > Current charter can be found at=20 > https://datatracker.ietf.org/doc/charter- > ietf-sfc/. >=20 > It contains the revised management text as well as updated milestones. >=20 > All known issues have been addressed. If there are any remaining=20 > issues, please speak up! >=20 > Charter charter-ietf-sfc-00-04 >=20 > Networks, servers, storage technologies, and applications, have all=20 > undergone significant change in recent years with the introduction of=20 > virtualization, network overlays, and orchestration. Service delivery=20 > is currently both a technical and organizational challenge that=20 > involves significant modification to the network configuration. > Services are typically implemented by the ordered combination of a=20 > number of service functions that are deployed at different points=20 > within the network. Today, a common deployment model has service=20 > functions physically inserted on the data forwarding path between=20 > communicating peers. Going forward, however, there is a desire to move=20 > to a different model, where service functions are not required to=20 > reside on the default data path and traffic is instead steered through se= rvices, wherever they are deployed. >=20 > For a given service, the abstracted view of the required service=20 > functions and the order in which they are to be applied is called a=20 > Service Function Chain (SFC). Since a given service function may be=20 > available on more than one node within a network, a Service Function=20 > Chain is instantiated via the selection of specific service function=20 > instances and the network nodes on which they are provided, thereby formi= ng a service topology: > this is called a Service Function Path. The service functions may be=20 > applied at a specific layer within the network protocol stack (network=20 > layer, application layer, etc.). >=20 > The Service Function Chaining (SFC) working group will develop new=20 > approaches to service delivery and deployment. It will produce a=20 > framework for service function chaining that includes the necessary=20 > protocols or protocol extensions to convey the service path and=20 > service path information to nodes that implement service functions, as=20 > well as mechanisms for steering traffic through service functions. The=20 > working group will also examine what information needs to be gathered=20 > from the network and service functions in support of service function=20 > chaining and how that information may be made available to nodes that=20 > implement the service functions. >=20 > Specifically, the SFC WG is chartered to deliver the following: >=20 > 1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high- > level use cases. Additionally, the WG will normalize nomenclature > and definitions for service function chaining. >=20 > 2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. >=20 > 3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service=20 > that is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. >=20 > 4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information > to service function implementation points. Where possible, existing > IETF protocols will be used and extended. All protocol extensions > work should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. >=20 > 5) Manageability: Work on the management and configuration of service > functions in support of SFC components will certainly be needed, > but first needs to be better understood and scoped. >=20 > Proposed Milestones >=20 > Apr 2014 Submit to IESG Informational document(s) defining the problem=20 > statement and core use cases for Service Function Chaining >=20 > May 2014 Consult with OPS Area on possible charter modifications for=20 > management and configuration of SFC components >=20 > Jan 2015 Submit to IESG Informational document defining the=20 > architecture for SFC >=20 > Jan 2015 Submit to IESG requirements for a generic service function=20 > chaining encapsulation protocol >=20 > Aug 2015 Submit to IESG Standards Track document specifying the=20 > generic service function chaining header encapsulation >=20 >=20 >=20 >=20 >=20 > Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Mon Nov 11 19:57:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725C611E81A8 for ; Mon, 11 Nov 2013 19:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ9k0hFiGPPj for ; Mon, 11 Nov 2013 19:57:36 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04611E8196 for ; Mon, 11 Nov 2013 19:57:23 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C892A41685D; Mon, 11 Nov 2013 22:57:22 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DCF3141682B; Mon, 11 Nov 2013 22:57:21 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Mon, 11 Nov 2013 22:54:09 -0500 From: Kevin J Ma To: Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Mon, 11 Nov 2013 22:57:19 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwAAC5a9AAAEuYEA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028025F77@MAILR002.mail.lan> References: <201311061907.rA6J7RLT029096@cichlid.raleigh.ibm.com> <0BF7E0211CA62B42AE3FD4020E416098849135D6@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:57:40 -0000 > the overall design implications of the classifier supporting the protocol= s > and techniques you describe below could make for an interesting I-D :). I agree, but I guess I'll take that as a no, on whether it was discussed? It's hard to evaluate the utility of the service function identifier withou= t a better understanding of how the classification works, how the servicce ch= ains are defined, and what the overhead is in doing lookups based on the service function identifier, as opposed to reuseable classification info, especiall= y where TCP/HTTP/TLS level termination is involved. Note: I did not see any minutes posted yet from the BoF? Were hums taken? I'd be interested in knowing the outcome before thinking about I-Ds. = ;-P thanx. -- Kevin J. Ma > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, November 11, 2013 10:41 PM > To: Kevin J Ma; Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter > > Hi, Kevin. > > I agree that the classifier should not be constrained. While a full > specification of the classifier seems beyond scope to me, a discussion of > the overall design implications of the classifier supporting the protocol= s > and techniques you describe below could make for an interesting I-D :). > > Ron > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Monday, November 11, 2013 10:33 PM > To: Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: RE: [nsc] Current Proposed SFC charter > > Hi Ron, > > I was unable to make the SFC BoF due to a conflict with CDNI, but I > had a similar question wrt bullet 11 in section 2 of the problem > statement: > > 11. Per-Service (re)Classification: Classification occurs at each > service, independent from previously applied service functions. > These unrelated classification events consume resources per > service. More importantly, the classification functionality > often differs per service function and service function cannot > leverage the results from other deployed network or service. > > as it relates to section 5.2 of the framework document: > > The SFC Classifier classifies packets based on (some of) the contents > of the packet header. Concretely, it classifies packets based on the > possible combination of one or more header fields, such as source > address, destination address, DS field, protocol ID, source port and > destination port numbers, and any other information. > > A packet-based classifier as described in the framework document would > seem to be limited in what it can classify? The service function > identifier lookup does not seem to be a significant optimization over > a packet-based 5-tuple lookup? There seems to be some missing detail > wrt how classification information is determined and reused? > > When thinking about higher level services, e.g., HTTP and TLS encrypted > flows, a packet-based classifier seems inadequate? I was also wonderin= g > how independent HLS segment requests might be classified and associated= ? > Were these types of use cases discussed in the BoF? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Ron Parker > > Sent: Monday, November 11, 2013 10:16 PM > > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Sumandra, > > > > As was discussed in Vancouver, there are already many existing ways to > > accomplish service chaining. But none of them provide a sufficient > > combination of interoperability, flexibility, and resiliency. A singl= e > > service chain encapsulation will go a long way to ensuring these goals. > > It may not be the absolutely most efficient approach for every single > > network topology and every single use case, but its ubiquitous nature > > should improve its adoption. > > > > Ron > > > > > > -----Original Message----- > > From: Sumandra Majee [mailto:S.Majee@F5.com] > > Sent: Monday, November 11, 2013 10:10 PM > > To: Ron Parker; Thomas Narten; nsc@ietf.org > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > Absolutely, that was an example of one type of derivation. However > > this could be augmented with classification result, again one more > example. > > > > >>All flows from the same source IP do not necessarily follow the same > > chain. > > Correct. It is also not necessary that all transaction of the same > > flow follow the same chain either. So why stop at flow itself. > > > > Again the point here is that do we always need SFC header or Not. > > > > Sumandra > > > > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Monday, November 11, 2013 7:02 PM > > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Sumandra, > > > > The intention of service function chaining is to allow for operation > > at the fully qualified flow level, or even finer grained at the > transaction > > level (this is an implementation matter for the PDP). All flows fro= m > > the same source IP do not necessarily follow the same chain. Source > IP, > > therefore, does not identify the chain ID. Another intention of > > service function chaining is to operate over any network topology and > not > > be limited to a single LAN. Thus, while VLAN may be part of the > > transport, it does not adequately identify the service chain, either. > > > > Ron > > > > > > -----Original Message----- > > From: Sumandra Majee [mailto:S.Majee@F5.com] > > Sent: Monday, November 11, 2013 9:56 PM > > To: Ron Parker; Thomas Narten; nsc@ietf.org > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > The service header is meant to carry the context which can *also* be > > derived (for example use source ip and vlan to identify chainID and > > position) or encapsulated as part of another tunnel header. So this > > could be optional IMHO. > > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Monday, November 11, 2013 4:36 PM > > To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Sumandra, > > > > As I understand it, an SFC packet traversing from PDP to SF or from SF > > to SF will look like: > > > > +------------------------+ > > | "transport" | > > +------------------------+ > > | service header | > > +------------------------+ > > | original IP header | > > +------------------------+ > > | | original IP payload | > > | | > > +------------------------+ > > > > Where service header contains, at a minimum, enough information to > > allow the packet to be propagated along the full length of the chain, > > and optionally, other metadata that enhances the operation of one or > > more service functions. > > > > And where "transport" could conceivably be any of, but not limited to: > > > > * Ethernet > > * Ethernet + LLC2 > > * Ethernet + MPLS > > * Ethernet + IP + GRE > > * Ethernet + IP +UDP > > > > > > Also, "original" in the diagram above is not meant to imply > > immutability, but rather to specify the packet that is propagated from > > preceding entity to succeeding entity, prior to encapsulation. > > > > Ron > > > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Sumandra Majee > > Sent: Monday, November 11, 2013 6:46 PM > > To: Thomas Narten; nsc@ietf.org > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Generic Service Function Chaining Encapsulation: A document will > > describe the single service-level data plane encapsulation format > for > > conveying the service function chain and the service function path, > > and for communicating context information between nodes that > > implement service functions. It is intended that the encapsulation > > be agnostic to the layer at which it is applied and the service > > that is > > being constructed. That is, the same encapsulation may be used on > > a service function path realized at the network layer or at any > other > > layer, and the same encapsulation will apply for the construction o= f > > service function paths regardless of the actual service. > > > > [SM] What does it mean by a single service-level encapsulation, a new > > encapsulation format > > or an ability to select one encapsulation format that fits > > the need for a given service chain? > > The ability to select a specific encapsulation would be a > > management plane decision. > > There are quite a few existing encapsulation methods that > > can possibly be reused to provide > > context information between service nodes. I have seen > mention > > of GRE, for HTTP based > > applications contexts are transferred via headers. > > > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Thomas Narten > > Sent: Wednesday, November 06, 2013 11:07 AM > > To: nsc@ietf.org > > Subject: [nsc] Current Proposed SFC charter > > > > Hi. > > > > Current charter can be found at > > https://datatracker.ietf.org/doc/charter- > > ietf-sfc/. > > > > It contains the revised management text as well as updated milestones. > > > > All known issues have been addressed. If there are any remaining > > issues, please speak up! > > > > Charter charter-ietf-sfc-00-04 > > > > Networks, servers, storage technologies, and applications, have all > > undergone significant change in recent years with the introduction of > > virtualization, network overlays, and orchestration. Service delivery > > is currently both a technical and organizational challenge that > > involves significant modification to the network configuration. > > Services are typically implemented by the ordered combination of a > > number of service functions that are deployed at different points > > within the network. Today, a common deployment model has service > > functions physically inserted on the data forwarding path between > > communicating peers. Going forward, however, there is a desire to move > > to a different model, where service functions are not required to > > reside on the default data path and traffic is instead steered through > services, wherever they are deployed. > > > > For a given service, the abstracted view of the required service > > functions and the order in which they are to be applied is called a > > Service Function Chain (SFC). Since a given service function may be > > available on more than one node within a network, a Service Function > > Chain is instantiated via the selection of specific service function > > instances and the network nodes on which they are provided, thereby > forming a service topology: > > this is called a Service Function Path. The service functions may be > > applied at a specific layer within the network protocol stack (network > > layer, application layer, etc.). > > > > The Service Function Chaining (SFC) working group will develop new > > approaches to service delivery and deployment. It will produce a > > framework for service function chaining that includes the necessary > > protocols or protocol extensions to convey the service path and > > service path information to nodes that implement service functions, as > > well as mechanisms for steering traffic through service functions. The > > working group will also examine what information needs to be gathered > > from the network and service functions in support of service function > > chaining and how that information may be made available to nodes that > > implement the service functions. > > > > Specifically, the SFC WG is chartered to deliver the following: > > > > 1) Problem Statement: This document will provide a summary of the > > problem space to be addressed by the WG including example high- > > level use cases. Additionally, the WG will normalize nomenclature > > and definitions for service function chaining. > > > > 2) Architecture: This document will provide a description of the > > architectural building blocks and their relationships including > > interconnection, placement of capabilities, management, > > diagnostics, design analysis, and security models, as well as > > requirements on the protocol mechanisms. > > > > 3) Generic Service Function Chaining Encapsulation: A document will > > describe the single service-level data plane encapsulation format > for > > conveying the service function chain and the service function path, > > and for communicating context information between nodes that > > implement service functions. It is intended that the encapsulation > > be agnostic to the layer at which it is applied and the service > > that is > > being constructed. That is, the same encapsulation may be used on > > a service function path realized at the network layer or at any > other > > layer, and the same encapsulation will apply for the construction o= f > > service function paths regardless of the actual service. > > > > 4) Control Plane Mechanisms: A set of documents will be developed to > > describe requirements and protocols necessary to convey information > > to service function implementation points. Where possible, existing > > IETF protocols will be used and extended. All protocol extensions > > work should be carried out in the working groups responsible for th= e > > protocols being modified in coordination with this working group, > but > > may be done in this working group after agreement with all the > > relevant WG chairs and responsible ADs. > > > > 5) Manageability: Work on the management and configuration of service > > functions in support of SFC components will certainly be needed, > > but first needs to be better understood and scoped. > > > > Proposed Milestones > > > > Apr 2014 Submit to IESG Informational document(s) defining the problem > > statement and core use cases for Service Function Chaining > > > > May 2014 Consult with OPS Area on possible charter modifications for > > management and configuration of SFC components > > > > Jan 2015 Submit to IESG Informational document defining the > > architecture for SFC > > > > Jan 2015 Submit to IESG requirements for a generic service function > > chaining encapsulation protocol > > > > Aug 2015 Submit to IESG Standards Track document specifying the > > generic service function chaining header encapsulation > > > > > > > > > > > > Thomas > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Mon Nov 11 21:08:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CA921E8114 for ; Mon, 11 Nov 2013 21:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Sucaz1C1b4H for ; Mon, 11 Nov 2013 21:08:46 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF621E80F1 for ; Mon, 11 Nov 2013 21:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14850; q=dns/txt; s=iport; t=1384232920; x=1385442520; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+JcdAPk7eEdzFMBRw/9ykmFvqP2FbMQbkXFckdFb+jo=; b=fLFl2Nu+liFGY2arBScDIRQ31gcodbOwZgqU9NOJ4SiJN0GKVMA7Ss1+ gH1O1/q5nEaFuSBvXbLQRiEktKs9hramBqNEsYhCcd0g1VciDuSJkgMTD 0cVIwitRKYdnlmO238KfmWHymtl1tHZqUFpjkqu7WmJU1YPNm94DS/aDJ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMy2gVKtJXG//2dsb2JhbABPCoMHOFO/G4FEFnSCJQEBAQQBAQE3LQcEEwYBCBEBAwEBHwkuCxQDBggCBAEJCYgBDb4pBI4XBAyBOgaEKgOULoNhkgqDJoFoAR8i X-IronPort-AV: E=Sophos;i="4.93,682,1378857600"; d="scan'208";a="283534482" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2013 05:08:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAC58RfH030426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 05:08:27 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 23:08:27 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdIA= Date: Tue, 12 Nov 2013 05:08:27 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.89.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:08:51 -0000 Kevin, Classification mechanism is outside the scope of SFC. It can be based on the packet or information not in the packet(environmental attributes for instance) or a combination thereof. What is important is that such classification aids in traffic selection and service path identification. It is no different from a policy in this regard except that the policy now specifies the service path. Further, classification is not limited to the network elements but the service functions as well. Some of this is described in the architecture drafts as well - "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". Surendra. On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >Hi Ron, > > I was unable to make the SFC BoF due to a conflict with CDNI, but I > had a similar question wrt bullet 11 in section 2 of the problem >statement: > > 11. Per-Service (re)Classification: Classification occurs at each > service, independent from previously applied service functions. > These unrelated classification events consume resources per > service. More importantly, the classification functionality > often differs per service function and service function cannot > leverage the results from other deployed network or service. > > as it relates to section 5.2 of the framework document: > > The SFC Classifier classifies packets based on (some of) the contents > of the packet header. Concretely, it classifies packets based on the > possible combination of one or more header fields, such as source > address, destination address, DS field, protocol ID, source port and > destination port numbers, and any other information. > > A packet-based classifier as described in the framework document would > seem to be limited in what it can classify? The service function > identifier lookup does not seem to be a significant optimization over > a packet-based 5-tuple lookup? There seems to be some missing detail > wrt how classification information is determined and reused? > > When thinking about higher level services, e.g., HTTP and TLS encrypted > flows, a packet-based classifier seems inadequate? I was also wondering > how independent HLS segment requests might be classified and associated? > Were these types of use cases discussed in the BoF? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>Ron >> Parker >> Sent: Monday, November 11, 2013 10:16 PM >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Sumandra, >>=20 >> As was discussed in Vancouver, there are already many existing ways to >> accomplish service chaining. But none of them provide a sufficient >> combination of interoperability, flexibility, and resiliency. A single >> service chain encapsulation will go a long way to ensuring these goals. >> It may not be the absolutely most efficient approach for every single >> network topology and every single use case, but its ubiquitous nature >> should improve its adoption. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Monday, November 11, 2013 10:10 PM >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >>=20 >> Ron, >>=20 >> Absolutely, that was an example of one type of derivation. However this >> could be augmented with classification result, again one more example. >>=20 >> >>All flows from the same source IP do not necessarily follow the same >> chain. >> Correct. It is also not necessary that all transaction of the same flow >> follow the same chain either. So why stop at flow itself. >>=20 >> Again the point here is that do we always need SFC header or Not. >>=20 >> Sumandra >>=20 >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, November 11, 2013 7:02 PM >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >>=20 >> Sumandra, >>=20 >> The intention of service function chaining is to allow for operation at >> the fully qualified flow level, or even finer grained at the transaction >> level (this is an implementation matter for the PDP). All flows from >> the same source IP do not necessarily follow the same chain. Source >>IP, >> therefore, does not identify the chain ID. Another intention of >> service function chaining is to operate over any network topology and >>not >> be limited to a single LAN. Thus, while VLAN may be part of the >> transport, it does not adequately identify the service chain, either. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> Sent: Monday, November 11, 2013 9:56 PM >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >>=20 >> Ron, >>=20 >> The service header is meant to carry the context which can *also* be >> derived (for example use source ip and vlan to identify chainID and >> position) or encapsulated as part of another tunnel header. So this >>could >> be optional IMHO. >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, November 11, 2013 4:36 PM >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >>=20 >> Sumandra, >>=20 >> As I understand it, an SFC packet traversing from PDP to SF or from SF >>to >> SF will look like: >>=20 >> +------------------------+ >> | "transport" | >> +------------------------+ >> | service header | >> +------------------------+ >> | original IP header | >> +------------------------+ >> | | original IP payload | >> | | >> +------------------------+ >>=20 >> Where service header contains, at a minimum, enough information to allow >> the packet to be propagated along the full length of the chain, and >> optionally, other metadata that enhances the operation of one or more >> service functions. >>=20 >> And where "transport" could conceivably be any of, but not limited to: >>=20 >> * Ethernet >> * Ethernet + LLC2 >> * Ethernet + MPLS >> * Ethernet + IP + GRE >> * Ethernet + IP +UDP >>=20 >>=20 >> Also, "original" in the diagram above is not meant to imply >>immutability, >> but rather to specify the packet that is propagated from preceding >>entity >> to succeeding entity, prior to encapsulation. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Sumandra Majee >> Sent: Monday, November 11, 2013 6:46 PM >> To: Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Generic Service Function Chaining Encapsulation: A document will >> describe the single service-level data plane encapsulation format >>for >> conveying the service function chain and the service function path, >> and for communicating context information between nodes that >> implement service functions. It is intended that the encapsulation >> be agnostic to the layer at which it is applied and the service that >> is >> being constructed. That is, the same encapsulation may be used on >> a service function path realized at the network layer or at any >>other >> layer, and the same encapsulation will apply for the construction of >> service function paths regardless of the actual service. >>=20 >> [SM] What does it mean by a single service-level encapsulation, a new >> encapsulation format >> or an ability to select one encapsulation format that fits >>the >> need for a given service chain? >> The ability to select a specific encapsulation would be a >> management plane decision. >> There are quite a few existing encapsulation methods that can >> possibly be reused to provide >> context information between service nodes. I have seen >>mention >> of GRE, for HTTP based >> applications contexts are transferred via headers. >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Wednesday, November 06, 2013 11:07 AM >> To: nsc@ietf.org >> Subject: [nsc] Current Proposed SFC charter >>=20 >> Hi. >>=20 >> Current charter can be found at >>https://datatracker.ietf.org/doc/charter- >> ietf-sfc/. >>=20 >> It contains the revised management text as well as updated milestones. >>=20 >> All known issues have been addressed. If there are any remaining issues, >> please speak up! >>=20 >> Charter charter-ietf-sfc-00-04 >>=20 >> Networks, servers, storage technologies, and applications, have all >> undergone significant change in recent years with the introduction of >> virtualization, network overlays, and orchestration. Service delivery is >> currently both a technical and organizational challenge that involves >> significant modification to the network configuration. >> Services are typically implemented by the ordered combination of a >>number >> of service functions that are deployed at different points within the >> network. Today, a common deployment model has service functions >>physically >> inserted on the data forwarding path between communicating peers. Going >> forward, however, there is a desire to move to a different model, where >> service functions are not required to reside on the default data path >>and >> traffic is instead steered through services, wherever they are deployed. >>=20 >> For a given service, the abstracted view of the required service >>functions >> and the order in which they are to be applied is called a Service >>Function >> Chain (SFC). Since a given service function may be available on more >>than >> one node within a network, a Service Function Chain is instantiated via >> the selection of specific service function instances and the network >>nodes >> on which they are provided, thereby forming a service topology: >> this is called a Service Function Path. The service functions may be >> applied at a specific layer within the network protocol stack (network >> layer, application layer, etc.). >>=20 >> The Service Function Chaining (SFC) working group will develop new >> approaches to service delivery and deployment. It will produce a >>framework >> for service function chaining that includes the necessary protocols or >> protocol extensions to convey the service path and service path >> information to nodes that implement service functions, as well as >> mechanisms for steering traffic through service functions. The working >> group will also examine what information needs to be gathered from the >> network and service functions in support of service function chaining >>and >> how that information may be made available to nodes that implement the >> service functions. >>=20 >> Specifically, the SFC WG is chartered to deliver the following: >>=20 >> 1) Problem Statement: This document will provide a summary of the >> problem space to be addressed by the WG including example high- >> level use cases. Additionally, the WG will normalize nomenclature >> and definitions for service function chaining. >>=20 >> 2) Architecture: This document will provide a description of the >> architectural building blocks and their relationships including >> interconnection, placement of capabilities, management, >> diagnostics, design analysis, and security models, as well as >> requirements on the protocol mechanisms. >>=20 >> 3) Generic Service Function Chaining Encapsulation: A document will >> describe the single service-level data plane encapsulation format >>for >> conveying the service function chain and the service function path, >> and for communicating context information between nodes that >> implement service functions. It is intended that the encapsulation >> be agnostic to the layer at which it is applied and the service that >> is >> being constructed. That is, the same encapsulation may be used on >> a service function path realized at the network layer or at any >>other >> layer, and the same encapsulation will apply for the construction of >> service function paths regardless of the actual service. >>=20 >> 4) Control Plane Mechanisms: A set of documents will be developed to >> describe requirements and protocols necessary to convey information >> to service function implementation points. Where possible, existing >> IETF protocols will be used and extended. All protocol extensions >> work should be carried out in the working groups responsible for the >> protocols being modified in coordination with this working group, >>but >> may be done in this working group after agreement with all the >> relevant WG chairs and responsible ADs. >>=20 >> 5) Manageability: Work on the management and configuration of service >> functions in support of SFC components will certainly be needed, >> but first needs to be better understood and scoped. >>=20 >> Proposed Milestones >>=20 >> Apr 2014 Submit to IESG Informational document(s) defining the problem >> statement and core use cases for Service Function Chaining >>=20 >> May 2014 Consult with OPS Area on possible charter modifications for >> management and configuration of SFC components >>=20 >> Jan 2015 Submit to IESG Informational document defining the architecture >> for SFC >>=20 >> Jan 2015 Submit to IESG requirements for a generic service function >> chaining encapsulation protocol >>=20 >> Aug 2015 Submit to IESG Standards Track document specifying the generic >> service function chaining header encapsulation >>=20 >>=20 >>=20 >>=20 >>=20 >> Thomas >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Mon Nov 11 21:29:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33D321E8115 for ; Mon, 11 Nov 2013 21:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxMGKfWVs2V8 for ; Mon, 11 Nov 2013 21:29:13 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 529EE21E8108 for ; Mon, 11 Nov 2013 21:29:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9902; q=dns/txt; s=iport; t=1384234153; x=1385443753; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=+FVhVl94q6V3oqeb2hP99PT10R3SmfBqLWO/xHzPDbY=; b=IKBANBTPiyp9XDQ1Avx1kPuOVs3t6MJs48mqts/PouZYHtVvO5HiViKk EBfj+5KIJXA9gpZbTUXSx5/3vRSc6MOyQXv28exYgcVU1iUoI0/+CIExQ NPL+FHpaoHwWVt7fdFBfS+AsaRuKg6vacKkajAikSTmmb+GyRxSPkebne o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAD67gVKtJV2Z/2dsb2JhbABPCoMHOFO/G4FEFnSCJQEBAQQBAQE3LQcEEwYBCA4DAQMBAR8JLgsUAwYIAgQBCQmIAQ2+KwSOFwQMgQgyAgSEKgOULoNhkgqDJoFoAR8i X-IronPort-AV: E=Sophos;i="4.93,682,1378857600"; d="scan'208";a="283610658" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 12 Nov 2013 05:29:12 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAC5TCIx014036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 05:29:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 23:29:11 -0600 From: "Surendra Kumar (smkumar)" To: Sumandra Majee , Ron Parker , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgP//pLeA Date: Tue, 12 Nov 2013 05:29:11 +0000 Message-ID: In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884914047@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.89.79] Content-Type: text/plain; charset="us-ascii" Content-ID: <239892BFEF57D44A9F845A8947556661@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:29:18 -0000 Sumandra, There is need for two kinds of information. a) that identifies the forwarding path the traffic (packets) requiring service(s) must be forwarded along - the service path b) that is produced at one point on the service path for consumption at one or more points down the service path (b) may or may not be derivable at the point it is being consumed. (b) may help (a) or (b) may be a pre-requisite for service delivery at one or more points along the service path. Given that a variety of hardware/software entities have to implement/parse such a service header, it would be reasonable to impose constraints on such a service header, including whether it should be optional or not; primarily to ease implementation and enable interoperability. Surendra. On 11/11/13 6:55 PM, "Sumandra Majee" wrote: >Ron, > >The service header is meant to carry the context which can *also* be >derived (for example use source ip and vlan to identify chainID and >position) or encapsulated as part of another tunnel header. So this could >be optional IMHO.=20 > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Monday, November 11, 2013 4:36 PM >To: Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: RE: [nsc] Current Proposed SFC charter > >Sumandra, > >As I understand it, an SFC packet traversing from PDP to SF or from SF to >SF will look like: > >+------------------------+ >| "transport" | >+------------------------+ >| service header | >+------------------------+ >| original IP header | >+------------------------+ >| | original IP payload | >| | >+------------------------+ > >Where service header contains, at a minimum, enough information to allow >the packet to be propagated along the full length of the chain, and >optionally, other metadata that enhances the operation of one or more >service functions. > > And where "transport" could conceivably be any of, but not limited to: > >* Ethernet >* Ethernet + LLC2 >* Ethernet + MPLS >* Ethernet + IP + GRE >* Ethernet + IP +UDP > > >Also, "original" in the diagram above is not meant to imply immutability, >but rather to specify the packet that is propagated from preceding entity >to succeeding entity, prior to encapsulation. > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Sumandra Majee >Sent: Monday, November 11, 2013 6:46 PM >To: Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >[SM] What does it mean by a single service-level encapsulation, a new >encapsulation format > or an ability to select one encapsulation format that fits >the need for a given service chain? > The ability to select a specific encapsulation would be a >management plane decision. > There are quite a few existing encapsulation methods that can >possibly be reused to provide > context information between service nodes. I have seen >mention of GRE, for HTTP based > applications contexts are transferred via headers. > =20 > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Thomas Narten >Sent: Wednesday, November 06, 2013 11:07 AM >To: nsc@ietf.org >Subject: [nsc] Current Proposed SFC charter > >Hi. > >Current charter can be found at >https://datatracker.ietf.org/doc/charter-ietf-sfc/. > >It contains the revised management text as well as updated milestones. > >All known issues have been addressed. If there are any remaining issues, >please speak up! > >Charter charter-ietf-sfc-00-04 > >Networks, servers, storage technologies, and applications, have all >undergone significant change in recent years with the introduction of >virtualization, network overlays, and orchestration. Service delivery is >currently both a technical and organizational challenge that involves >significant modification to the network configuration. >Services are typically implemented by the ordered combination of a number >of service functions that are deployed at different points within the >network. Today, a common deployment model has service functions >physically inserted on the data forwarding path between communicating >peers. Going forward, however, there is a desire to move to a different >model, where service functions are not required to reside on the default >data path and traffic is instead steered through services, wherever they >are deployed.=20 > >For a given service, the abstracted view of the required service >functions and the order in which they are to be applied is called a >Service Function Chain (SFC). Since a given service function may be >available on more than one node within a network, a Service Function >Chain is instantiated via the selection of specific service function >instances and the network nodes on which they are provided, thereby >forming a service topology: >this is called a Service Function Path. The service functions may be >applied at a specific layer within the network protocol stack (network >layer, application layer, etc.). > >The Service Function Chaining (SFC) working group will develop new >approaches to service delivery and deployment. It will produce a >framework for service function chaining that includes the necessary >protocols or protocol extensions to convey the service path and service >path information to nodes that implement service functions, as well as >mechanisms for steering traffic through service functions. The working >group will also examine what information needs to be gathered from the >network and service functions in support of service function chaining and >how that information may be made available to nodes that implement the >service functions. > >Specifically, the SFC WG is chartered to deliver the following: > >1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high- > level use cases. Additionally, the WG will normalize nomenclature > and definitions for service function chaining. > >2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. > >3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information > to service function implementation points. Where possible, existing > IETF protocols will be used and extended. All protocol extensions > work should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. > >5) Manageability: Work on the management and configuration of service > functions in support of SFC components will certainly be needed, > but first needs to be better understood and scoped. > =20 >Proposed Milestones > >Apr 2014 Submit to IESG Informational document(s) defining the problem >statement and core use cases for Service Function Chaining > >May 2014 Consult with OPS Area on possible charter modifications for >management and configuration of SFC components > >Jan 2015 Submit to IESG Informational document defining the architecture >for SFC > >Jan 2015 Submit to IESG requirements for a generic service function >chaining encapsulation protocol > >Aug 2015 Submit to IESG Standards Track document specifying the generic >service function chaining header encapsulation > > > > > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Mon Nov 11 21:46:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0668E21F9948 for ; Mon, 11 Nov 2013 21:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9id26YSeTKB4 for ; Mon, 11 Nov 2013 21:46:40 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 677F511E819A for ; Mon, 11 Nov 2013 21:46:32 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4509F416A20; Tue, 12 Nov 2013 00:46:28 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1FA4341682B; Tue, 12 Nov 2013 00:46:24 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 12 Nov 2013 00:46:23 -0500 From: Kevin J Ma To: "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Tue, 12 Nov 2013 00:46:21 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6B028025F6E@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:46:48 -0000 Hi Surendra, Classification may be out of scope, but the level of service that is applicable is dependent upon the level of classification that can be performed. An assumption of packet level encapsulation has implications on the level of classification being performed? If the stated goals are for firewall and load balancer functionality, then the application level nature of those functions needs to be taken into account? If, on the other hand, the service function scope is limited due to limitations in classification, that would be and important piece of information? Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork points of the service paths seem like re-classification points? Is that the interpretation from the architecture perspective? Or is the service function chain classification exclusive of DPI functionality? thanx. -- Kevin J. Ma > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Tuesday, November 12, 2013 12:08 AM > To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter > > Kevin, > > Classification mechanism is outside the scope of SFC. It can be based on > the packet or information not in the packet(environmental attributes for > instance) or a combination thereof. What is important is that such > classification aids in traffic selection and service path identification. > It is no different from a policy in this regard except that the policy no= w > specifies the service path. > Further, classification is not limited to the network elements but the > service functions as well. Some of this is described in the architecture > drafts as well - "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/"= . > > Surendra. > > On 11/11/13 7:33 PM, "Kevin J Ma" wrote: > > >Hi Ron, > > > > I was unable to make the SFC BoF due to a conflict with CDNI, but I > > had a similar question wrt bullet 11 in section 2 of the problem > >statement: > > > > 11. Per-Service (re)Classification: Classification occurs at each > > service, independent from previously applied service functions. > > These unrelated classification events consume resources per > > service. More importantly, the classification functionality > > often differs per service function and service function cannot > > leverage the results from other deployed network or service. > > > > as it relates to section 5.2 of the framework document: > > > > The SFC Classifier classifies packets based on (some of) the content= s > > of the packet header. Concretely, it classifies packets based on th= e > > possible combination of one or more header fields, such as source > > address, destination address, DS field, protocol ID, source port and > > destination port numbers, and any other information. > > > > A packet-based classifier as described in the framework document would > > seem to be limited in what it can classify? The service function > > identifier lookup does not seem to be a significant optimization over > > a packet-based 5-tuple lookup? There seems to be some missing detail > > wrt how classification information is determined and reused? > > > > When thinking about higher level services, e.g., HTTP and TLS encrypte= d > > flows, a packet-based classifier seems inadequate? I was also > wondering > > how independent HLS segment requests might be classified and > associated? > > Were these types of use cases discussed in the BoF? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > >>Ron > >> Parker > >> Sent: Monday, November 11, 2013 10:16 PM > >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> Sumandra, > >> > >> As was discussed in Vancouver, there are already many existing ways to > >> accomplish service chaining. But none of them provide a sufficient > >> combination of interoperability, flexibility, and resiliency. A > single > >> service chain encapsulation will go a long way to ensuring these goals= . > >> It may not be the absolutely most efficient approach for every single > >> network topology and every single use case, but its ubiquitous nature > >> should improve its adoption. > >> > >> Ron > >> > >> > >> -----Original Message----- > >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> Sent: Monday, November 11, 2013 10:10 PM > >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Ron, > >> > >> Absolutely, that was an example of one type of derivation. However thi= s > >> could be augmented with classification result, again one more example. > >> > >> >>All flows from the same source IP do not necessarily follow the same > >> chain. > >> Correct. It is also not necessary that all transaction of the same flo= w > >> follow the same chain either. So why stop at flow itself. > >> > >> Again the point here is that do we always need SFC header or Not. > >> > >> Sumandra > >> > >> > >> -----Original Message----- > >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> Sent: Monday, November 11, 2013 7:02 PM > >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Sumandra, > >> > >> The intention of service function chaining is to allow for operation a= t > >> the fully qualified flow level, or even finer grained at the > transaction > >> level (this is an implementation matter for the PDP). All flows > from > >> the same source IP do not necessarily follow the same chain. Source > >>IP, > >> therefore, does not identify the chain ID. Another intention of > >> service function chaining is to operate over any network topology and > >>not > >> be limited to a single LAN. Thus, while VLAN may be part of the > >> transport, it does not adequately identify the service chain, either. > >> > >> Ron > >> > >> > >> -----Original Message----- > >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> Sent: Monday, November 11, 2013 9:56 PM > >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Ron, > >> > >> The service header is meant to carry the context which can *also* be > >> derived (for example use source ip and vlan to identify chainID and > >> position) or encapsulated as part of another tunnel header. So this > >>could > >> be optional IMHO. > >> > >> -----Original Message----- > >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> Sent: Monday, November 11, 2013 4:36 PM > >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Sumandra, > >> > >> As I understand it, an SFC packet traversing from PDP to SF or from SF > >>to > >> SF will look like: > >> > >> +------------------------+ > >> | "transport" | > >> +------------------------+ > >> | service header | > >> +------------------------+ > >> | original IP header | > >> +------------------------+ > >> | | original IP payload | > >> | | > >> +------------------------+ > >> > >> Where service header contains, at a minimum, enough information to > allow > >> the packet to be propagated along the full length of the chain, and > >> optionally, other metadata that enhances the operation of one or more > >> service functions. > >> > >> And where "transport" could conceivably be any of, but not limited to= : > >> > >> * Ethernet > >> * Ethernet + LLC2 > >> * Ethernet + MPLS > >> * Ethernet + IP + GRE > >> * Ethernet + IP +UDP > >> > >> > >> Also, "original" in the diagram above is not meant to imply > >>immutability, > >> but rather to specify the packet that is propagated from preceding > >>entity > >> to succeeding entity, prior to encapsulation. > >> > >> Ron > >> > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > >> Sumandra Majee > >> Sent: Monday, November 11, 2013 6:46 PM > >> To: Thomas Narten; nsc@ietf.org > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> Generic Service Function Chaining Encapsulation: A document will > >> describe the single service-level data plane encapsulation format > >>for > >> conveying the service function chain and the service function path= , > >> and for communicating context information between nodes that > >> implement service functions. It is intended that the encapsulation > >> be agnostic to the layer at which it is applied and the service > that > >> is > >> being constructed. That is, the same encapsulation may be used on > >> a service function path realized at the network layer or at any > >>other > >> layer, and the same encapsulation will apply for the construction > of > >> service function paths regardless of the actual service. > >> > >> [SM] What does it mean by a single service-level encapsulation, a new > >> encapsulation format > >> or an ability to select one encapsulation format that fits > >>the > >> need for a given service chain? > >> The ability to select a specific encapsulation would be a > >> management plane decision. > >> There are quite a few existing encapsulation methods that ca= n > >> possibly be reused to provide > >> context information between service nodes. I have seen > >>mention > >> of GRE, for HTTP based > >> applications contexts are transferred via headers. > >> > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > >> Thomas Narten > >> Sent: Wednesday, November 06, 2013 11:07 AM > >> To: nsc@ietf.org > >> Subject: [nsc] Current Proposed SFC charter > >> > >> Hi. > >> > >> Current charter can be found at > >>https://datatracker.ietf.org/doc/charter- > >> ietf-sfc/. > >> > >> It contains the revised management text as well as updated milestones. > >> > >> All known issues have been addressed. If there are any remaining > issues, > >> please speak up! > >> > >> Charter charter-ietf-sfc-00-04 > >> > >> Networks, servers, storage technologies, and applications, have all > >> undergone significant change in recent years with the introduction of > >> virtualization, network overlays, and orchestration. Service delivery > is > >> currently both a technical and organizational challenge that involves > >> significant modification to the network configuration. > >> Services are typically implemented by the ordered combination of a > >>number > >> of service functions that are deployed at different points within the > >> network. Today, a common deployment model has service functions > >>physically > >> inserted on the data forwarding path between communicating peers. Goin= g > >> forward, however, there is a desire to move to a different model, wher= e > >> service functions are not required to reside on the default data path > >>and > >> traffic is instead steered through services, wherever they are > deployed. > >> > >> For a given service, the abstracted view of the required service > >>functions > >> and the order in which they are to be applied is called a Service > >>Function > >> Chain (SFC). Since a given service function may be available on more > >>than > >> one node within a network, a Service Function Chain is instantiated vi= a > >> the selection of specific service function instances and the network > >>nodes > >> on which they are provided, thereby forming a service topology: > >> this is called a Service Function Path. The service functions may be > >> applied at a specific layer within the network protocol stack (network > >> layer, application layer, etc.). > >> > >> The Service Function Chaining (SFC) working group will develop new > >> approaches to service delivery and deployment. It will produce a > >>framework > >> for service function chaining that includes the necessary protocols or > >> protocol extensions to convey the service path and service path > >> information to nodes that implement service functions, as well as > >> mechanisms for steering traffic through service functions. The working > >> group will also examine what information needs to be gathered from the > >> network and service functions in support of service function chaining > >>and > >> how that information may be made available to nodes that implement the > >> service functions. > >> > >> Specifically, the SFC WG is chartered to deliver the following: > >> > >> 1) Problem Statement: This document will provide a summary of the > >> problem space to be addressed by the WG including example high- > >> level use cases. Additionally, the WG will normalize nomenclature > >> and definitions for service function chaining. > >> > >> 2) Architecture: This document will provide a description of the > >> architectural building blocks and their relationships including > >> interconnection, placement of capabilities, management, > >> diagnostics, design analysis, and security models, as well as > >> requirements on the protocol mechanisms. > >> > >> 3) Generic Service Function Chaining Encapsulation: A document will > >> describe the single service-level data plane encapsulation format > >>for > >> conveying the service function chain and the service function path= , > >> and for communicating context information between nodes that > >> implement service functions. It is intended that the encapsulation > >> be agnostic to the layer at which it is applied and the service > that > >> is > >> being constructed. That is, the same encapsulation may be used on > >> a service function path realized at the network layer or at any > >>other > >> layer, and the same encapsulation will apply for the construction > of > >> service function paths regardless of the actual service. > >> > >> 4) Control Plane Mechanisms: A set of documents will be developed to > >> describe requirements and protocols necessary to convey informatio= n > >> to service function implementation points. Where possible, existin= g > >> IETF protocols will be used and extended. All protocol extensions > >> work should be carried out in the working groups responsible for > the > >> protocols being modified in coordination with this working group, > >>but > >> may be done in this working group after agreement with all the > >> relevant WG chairs and responsible ADs. > >> > >> 5) Manageability: Work on the management and configuration of service > >> functions in support of SFC components will certainly be needed, > >> but first needs to be better understood and scoped. > >> > >> Proposed Milestones > >> > >> Apr 2014 Submit to IESG Informational document(s) defining the problem > >> statement and core use cases for Service Function Chaining > >> > >> May 2014 Consult with OPS Area on possible charter modifications for > >> management and configuration of SFC components > >> > >> Jan 2015 Submit to IESG Informational document defining the > architecture > >> for SFC > >> > >> Jan 2015 Submit to IESG requirements for a generic service function > >> chaining encapsulation protocol > >> > >> Aug 2015 Submit to IESG Standards Track document specifying the generi= c > >> service function chaining header encapsulation > >> > >> > >> > >> > >> > >> Thomas > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Mon Nov 11 22:01:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1BA21E80AE for ; Mon, 11 Nov 2013 22:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdBsyibXZGNm for ; Mon, 11 Nov 2013 22:00:57 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7769521E8088 for ; Mon, 11 Nov 2013 22:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17504; q=dns/txt; s=iport; t=1384236057; x=1385445657; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Jpb0ZhA1s0H4JM1hdcrbqW+7FbCW+SfBZqkGCfOuxcY=; b=QM6y5pDw94UTR9aq8C6MG0j536kqD3Ph4VvDEkXlMlt9puGxhivPmLbn H61COASE24uT9BYr/tIZr8LHb5xZAIE/1QiaTff5NVVK4cNKaZkFqt48R C4WDrqax3R3zSPTLSCXh2OZfuXjESnS6AbmDXBSxg5rzwjWV5kAXWgFrq A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FALXDgVKtJV2c/2dsb2JhbABPCoMHOFO/G4FBFnSCJQEBAQQBAQE3KwIHBBMGAQgRAQMBAQEVCQkuCxQDBggCBAEJCYgBDb4oBI4XBAyBCDICBASEJgOULoNhkgqDJoFoAR8i X-IronPort-AV: E=Sophos;i="4.93,682,1378857600"; d="scan'208";a="283501083" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2013 06:00:36 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAC60aUN023247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 06:00:36 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 00:00:36 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6A Date: Tue, 12 Nov 2013 06:00:35 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.89.79] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 06:01:03 -0000 On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >Hi Surendra, > > Classification may be out of scope, but the level of service that is > applicable is dependent upon the level of classification that can be > performed. An assumption of packet level encapsulation has implications > on the level of classification being performed? If the stated goals are > for firewall and load balancer functionality, then the application level > nature of those functions needs to be taken into account? If, on the > other hand, the service function scope is limited due to limitations in > classification, that would be and important piece of information? > > Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork points > of the service paths seem like re-classification points? Is that the > interpretation from the architecture perspective? Or is the service > function chain classification exclusive of DPI functionality? I have not fully read that draft yet. But in general, as described in the arch draft, the collection of services form a graph, segments of which are service paths. Yes, reclassification can change the service path and re-classification may happen at any node along a service path. Surendra. > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> Sent: Tuesday, November 12, 2013 12:08 AM >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Kevin, >> >> Classification mechanism is outside the scope of SFC. It can be based on >> the packet or information not in the packet(environmental attributes for >> instance) or a combination thereof. What is important is that such >> classification aids in traffic selection and service path >>identification. >> It is no different from a policy in this regard except that the policy >>now >> specifies the service path. >> Further, classification is not limited to the network elements but the >> service functions as well. Some of this is described in the architecture >> drafts as well - >>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> Surendra. >> >> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >> >> >Hi Ron, >> > >> > I was unable to make the SFC BoF due to a conflict with CDNI, but I >> > had a similar question wrt bullet 11 in section 2 of the problem >> >statement: >> > >> > 11. Per-Service (re)Classification: Classification occurs at each >> > service, independent from previously applied service >>functions. >> > These unrelated classification events consume resources per >> > service. More importantly, the classification functionality >> > often differs per service function and service function cannot >> > leverage the results from other deployed network or service. >> > >> > as it relates to section 5.2 of the framework document: >> > >> > The SFC Classifier classifies packets based on (some of) the >>contents >> > of the packet header. Concretely, it classifies packets based on >>the >> > possible combination of one or more header fields, such as source >> > address, destination address, DS field, protocol ID, source port >>and >> > destination port numbers, and any other information. >> > >> > A packet-based classifier as described in the framework document >>would >> > seem to be limited in what it can classify? The service function >> > identifier lookup does not seem to be a significant optimization over >> > a packet-based 5-tuple lookup? There seems to be some missing detail >> > wrt how classification information is determined and reused? >> > >> > When thinking about higher level services, e.g., HTTP and TLS >>encrypted >> > flows, a packet-based classifier seems inadequate? I was also >> wondering >> > how independent HLS segment requests might be classified and >> associated? >> > Were these types of use cases discussed in the BoF? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> >>Ron >> >> Parker >> >> Sent: Monday, November 11, 2013 10:16 PM >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> Sumandra, >> >> >> >> As was discussed in Vancouver, there are already many existing ways >>to >> >> accomplish service chaining. But none of them provide a >>sufficient >> >> combination of interoperability, flexibility, and resiliency. A >> single >> >> service chain encapsulation will go a long way to ensuring these >>goals. >> >> It may not be the absolutely most efficient approach for every >>single >> >> network topology and every single use case, but its ubiquitous nature >> >> should improve its adoption. >> >> >> >> Ron >> >> >> >> >> >> -----Original Message----- >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> Sent: Monday, November 11, 2013 10:10 PM >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> Absolutely, that was an example of one type of derivation. However >>this >> >> could be augmented with classification result, again one more >>example. >> >> >> >> >>All flows from the same source IP do not necessarily follow the >>same >> >> chain. >> >> Correct. It is also not necessary that all transaction of the same >>flow >> >> follow the same chain either. So why stop at flow itself. >> >> >> >> Again the point here is that do we always need SFC header or Not. >> >> >> >> Sumandra >> >> >> >> >> >> -----Original Message----- >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> Sent: Monday, November 11, 2013 7:02 PM >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Sumandra, >> >> >> >> The intention of service function chaining is to allow for operation >>at >> >> the fully qualified flow level, or even finer grained at the >> transaction >> >> level (this is an implementation matter for the PDP). All flows >> from >> >> the same source IP do not necessarily follow the same chain. Source >> >>IP, >> >> therefore, does not identify the chain ID. Another intention of >> >> service function chaining is to operate over any network topology and >> >>not >> >> be limited to a single LAN. Thus, while VLAN may be part of the >> >> transport, it does not adequately identify the service chain, either. >> >> >> >> Ron >> >> >> >> >> >> -----Original Message----- >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> Sent: Monday, November 11, 2013 9:56 PM >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> The service header is meant to carry the context which can *also* be >> >> derived (for example use source ip and vlan to identify chainID and >> >> position) or encapsulated as part of another tunnel header. So this >> >>could >> >> be optional IMHO. >> >> >> >> -----Original Message----- >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> Sent: Monday, November 11, 2013 4:36 PM >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Sumandra, >> >> >> >> As I understand it, an SFC packet traversing from PDP to SF or from >>SF >> >>to >> >> SF will look like: >> >> >> >> +------------------------+ >> >> | "transport" | >> >> +------------------------+ >> >> | service header | >> >> +------------------------+ >> >> | original IP header | >> >> +------------------------+ >> >> | | original IP payload | >> >> | | >> >> +------------------------+ >> >> >> >> Where service header contains, at a minimum, enough information to >> allow >> >> the packet to be propagated along the full length of the chain, and >> >> optionally, other metadata that enhances the operation of one or more >> >> service functions. >> >> >> >> And where "transport" could conceivably be any of, but not limited >>to: >> >> >> >> * Ethernet >> >> * Ethernet + LLC2 >> >> * Ethernet + MPLS >> >> * Ethernet + IP + GRE >> >> * Ethernet + IP +UDP >> >> >> >> >> >> Also, "original" in the diagram above is not meant to imply >> >>immutability, >> >> but rather to specify the packet that is propagated from preceding >> >>entity >> >> to succeeding entity, prior to encapsulation. >> >> >> >> Ron >> >> >> >> >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> >> Sumandra Majee >> >> Sent: Monday, November 11, 2013 6:46 PM >> >> To: Thomas Narten; nsc@ietf.org >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> Generic Service Function Chaining Encapsulation: A document will >> >> describe the single service-level data plane encapsulation format >> >>for >> >> conveying the service function chain and the service function >>path, >> >> and for communicating context information between nodes that >> >> implement service functions. It is intended that the >>encapsulation >> >> be agnostic to the layer at which it is applied and the service >> that >> >> is >> >> being constructed. That is, the same encapsulation may be used on >> >> a service function path realized at the network layer or at any >> >>other >> >> layer, and the same encapsulation will apply for the construction >> of >> >> service function paths regardless of the actual service. >> >> >> >> [SM] What does it mean by a single service-level encapsulation, a >>new >> >> encapsulation format >> >> or an ability to select one encapsulation format that >>fits >> >>the >> >> need for a given service chain? >> >> The ability to select a specific encapsulation would be a >> >> management plane decision. >> >> There are quite a few existing encapsulation methods that >>can >> >> possibly be reused to provide >> >> context information between service nodes. I have seen >> >>mention >> >> of GRE, for HTTP based >> >> applications contexts are transferred via headers. >> >> >> >> >> >> -----Original Message----- >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> >> Thomas Narten >> >> Sent: Wednesday, November 06, 2013 11:07 AM >> >> To: nsc@ietf.org >> >> Subject: [nsc] Current Proposed SFC charter >> >> >> >> Hi. >> >> >> >> Current charter can be found at >> >>https://datatracker.ietf.org/doc/charter- >> >> ietf-sfc/. >> >> >> >> It contains the revised management text as well as updated >>milestones. >> >> >> >> All known issues have been addressed. If there are any remaining >> issues, >> >> please speak up! >> >> >> >> Charter charter-ietf-sfc-00-04 >> >> >> >> Networks, servers, storage technologies, and applications, have all >> >> undergone significant change in recent years with the introduction of >> >> virtualization, network overlays, and orchestration. Service delivery >> is >> >> currently both a technical and organizational challenge that involves >> >> significant modification to the network configuration. >> >> Services are typically implemented by the ordered combination of a >> >>number >> >> of service functions that are deployed at different points within the >> >> network. Today, a common deployment model has service functions >> >>physically >> >> inserted on the data forwarding path between communicating peers. >>Going >> >> forward, however, there is a desire to move to a different model, >>where >> >> service functions are not required to reside on the default data path >> >>and >> >> traffic is instead steered through services, wherever they are >> deployed. >> >> >> >> For a given service, the abstracted view of the required service >> >>functions >> >> and the order in which they are to be applied is called a Service >> >>Function >> >> Chain (SFC). Since a given service function may be available on more >> >>than >> >> one node within a network, a Service Function Chain is instantiated >>via >> >> the selection of specific service function instances and the network >> >>nodes >> >> on which they are provided, thereby forming a service topology: >> >> this is called a Service Function Path. The service functions may be >> >> applied at a specific layer within the network protocol stack >>(network >> >> layer, application layer, etc.). >> >> >> >> The Service Function Chaining (SFC) working group will develop new >> >> approaches to service delivery and deployment. It will produce a >> >>framework >> >> for service function chaining that includes the necessary protocols >>or >> >> protocol extensions to convey the service path and service path >> >> information to nodes that implement service functions, as well as >> >> mechanisms for steering traffic through service functions. The >>working >> >> group will also examine what information needs to be gathered from >>the >> >> network and service functions in support of service function chaining >> >>and >> >> how that information may be made available to nodes that implement >>the >> >> service functions. >> >> >> >> Specifically, the SFC WG is chartered to deliver the following: >> >> >> >> 1) Problem Statement: This document will provide a summary of the >> >> problem space to be addressed by the WG including example high- >> >> level use cases. Additionally, the WG will normalize nomenclature >> >> and definitions for service function chaining. >> >> >> >> 2) Architecture: This document will provide a description of the >> >> architectural building blocks and their relationships including >> >> interconnection, placement of capabilities, management, >> >> diagnostics, design analysis, and security models, as well as >> >> requirements on the protocol mechanisms. >> >> >> >> 3) Generic Service Function Chaining Encapsulation: A document will >> >> describe the single service-level data plane encapsulation format >> >>for >> >> conveying the service function chain and the service function >>path, >> >> and for communicating context information between nodes that >> >> implement service functions. It is intended that the >>encapsulation >> >> be agnostic to the layer at which it is applied and the service >> that >> >> is >> >> being constructed. That is, the same encapsulation may be used on >> >> a service function path realized at the network layer or at any >> >>other >> >> layer, and the same encapsulation will apply for the construction >> of >> >> service function paths regardless of the actual service. >> >> >> >> 4) Control Plane Mechanisms: A set of documents will be developed to >> >> describe requirements and protocols necessary to convey >>information >> >> to service function implementation points. Where possible, >>existing >> >> IETF protocols will be used and extended. All protocol extensions >> >> work should be carried out in the working groups responsible for >> the >> >> protocols being modified in coordination with this working group, >> >>but >> >> may be done in this working group after agreement with all the >> >> relevant WG chairs and responsible ADs. >> >> >> >> 5) Manageability: Work on the management and configuration of service >> >> functions in support of SFC components will certainly be needed, >> >> but first needs to be better understood and scoped. >> >> >> >> Proposed Milestones >> >> >> >> Apr 2014 Submit to IESG Informational document(s) defining the >>problem >> >> statement and core use cases for Service Function Chaining >> >> >> >> May 2014 Consult with OPS Area on possible charter modifications for >> >> management and configuration of SFC components >> >> >> >> Jan 2015 Submit to IESG Informational document defining the >> architecture >> >> for SFC >> >> >> >> Jan 2015 Submit to IESG requirements for a generic service function >> >> chaining encapsulation protocol >> >> >> >> Aug 2015 Submit to IESG Standards Track document specifying the >>generic >> >> service function chaining header encapsulation >> >> >> >> >> >> >> >> >> >> >> >> Thomas >> >> >> >> _______________________________________________ >> >> nsc mailing list >> >> nsc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> >> nsc mailing list >> >> nsc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> >> nsc mailing list >> >> nsc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >> >nsc mailing list >> >nsc@ietf.org >> >https://www.ietf.org/mailman/listinfo/nsc > From kevin.ma@azukisystems.com Mon Nov 11 22:52:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DCA21E80DE for ; Mon, 11 Nov 2013 22:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yaahtg-6APNd for ; Mon, 11 Nov 2013 22:52:34 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C079F21E80DB for ; Mon, 11 Nov 2013 22:52:33 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 70E1D416A38; Tue, 12 Nov 2013 01:52:33 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 75509416A2D; Tue, 12 Nov 2013 01:52:32 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 12 Nov 2013 01:52:32 -0500 From: Kevin J Ma To: "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Tue, 12 Nov 2013 01:52:29 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVEA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 06:52:38 -0000 > Yes, reclassification can change the service path and > re-classification may happen at any node along a service path. Just to expand on that, going back to the original question about service header encapsulation, is it intended that a chain that is re-classified will get a new chain ID which fully describes a chain that is a superset of the original chain ID, prior to DPI-based re-classification? (assuming the goal is "a single chain ID that is commonly understood along the entire service chain" http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) And the applicable subset of the permutative list of service paths would be configured at each appropriate service node? e.g., ID 1: NAT + firewall + DPI ID 2: NAT + firewall + DPI + AV ID 3: NAT + firewall + DPI + AV + NAT ID 4: NAT + firewall + DPI + NAT ID 5: NAT + firewall + DPI + AV + LB ID 6: NAT + firewall + DPI + LB ID 7: NAT + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI + CACHE ID 9: NAT + firewall + DPI + optimizer + LB ID 10: NAT + firewall + DPI + optimizer + LB + CACHE ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow then be initially classified as ID 1, but eventually get re-classified to ID 2-11, after the DPI phase? thanx. -- Kevin J. Ma > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Tuesday, November 12, 2013 1:01 AM > To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter > > > > On 11/11/13 9:46 PM, "Kevin J Ma" wrote: > > >Hi Surendra, > > > > Classification may be out of scope, but the level of service that is > > applicable is dependent upon the level of classification that can be > > performed. An assumption of packet level encapsulation has > implications > > on the level of classification being performed? If the stated goals > are > > for firewall and load balancer functionality, then the application > level > > nature of those functions needs to be taken into account? If, on the > > other hand, the service function scope is limited due to limitations i= n > > classification, that would be and important piece of information? > > > > Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork point= s > > of the service paths seem like re-classification points? Is that the > > interpretation from the architecture perspective? Or is the service > > function chain classification exclusive of DPI functionality? > I have not fully read that draft yet. But in general, as described i= n > the arch draft, the collection of services form a graph, segments of whic= h > are service paths. Yes, reclassification can change the service path and > re-classification may happen at any node along a service path. > > Surendra. > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> Sent: Tuesday, November 12, 2013 12:08 AM > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.or= g > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> Kevin, > >> > >> Classification mechanism is outside the scope of SFC. It can be based > on > >> the packet or information not in the packet(environmental attributes > for > >> instance) or a combination thereof. What is important is that such > >> classification aids in traffic selection and service path > >>identification. > >> It is no different from a policy in this regard except that the policy > >>now > >> specifies the service path. > >> Further, classification is not limited to the network elements but the > >> service functions as well. Some of this is described in the > architecture > >> drafts as well - > >>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >> > >> Surendra. > >> > >> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: > >> > >> >Hi Ron, > >> > > >> > I was unable to make the SFC BoF due to a conflict with CDNI, but I > >> > had a similar question wrt bullet 11 in section 2 of the problem > >> >statement: > >> > > >> > 11. Per-Service (re)Classification: Classification occurs at eac= h > >> > service, independent from previously applied service > >>functions. > >> > These unrelated classification events consume resources per > >> > service. More importantly, the classification functionality > >> > often differs per service function and service function > cannot > >> > leverage the results from other deployed network or service. > >> > > >> > as it relates to section 5.2 of the framework document: > >> > > >> > The SFC Classifier classifies packets based on (some of) the > >>contents > >> > of the packet header. Concretely, it classifies packets based on > >>the > >> > possible combination of one or more header fields, such as source > >> > address, destination address, DS field, protocol ID, source port > >>and > >> > destination port numbers, and any other information. > >> > > >> > A packet-based classifier as described in the framework document > >>would > >> > seem to be limited in what it can classify? The service function > >> > identifier lookup does not seem to be a significant optimization > over > >> > a packet-based 5-tuple lookup? There seems to be some missing > detail > >> > wrt how classification information is determined and reused? > >> > > >> > When thinking about higher level services, e.g., HTTP and TLS > >>encrypted > >> > flows, a packet-based classifier seems inadequate? I was also > >> wondering > >> > how independent HLS segment requests might be classified and > >> associated? > >> > Were these types of use cases discussed in the BoF? > >> > > >> >thanx. > >> > > >> >-- Kevin J. Ma > >> > > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> >>Ron > >> >> Parker > >> >> Sent: Monday, November 11, 2013 10:16 PM > >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> Subject: Re: [nsc] Current Proposed SFC charter > >> >> > >> >> Sumandra, > >> >> > >> >> As was discussed in Vancouver, there are already many existing ways > >>to > >> >> accomplish service chaining. But none of them provide a > >>sufficient > >> >> combination of interoperability, flexibility, and resiliency. A > >> single > >> >> service chain encapsulation will go a long way to ensuring these > >>goals. > >> >> It may not be the absolutely most efficient approach for every > >>single > >> >> network topology and every single use case, but its ubiquitous > nature > >> >> should improve its adoption. > >> >> > >> >> Ron > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> >> Sent: Monday, November 11, 2013 10:10 PM > >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> > >> >> Ron, > >> >> > >> >> Absolutely, that was an example of one type of derivation. However > >>this > >> >> could be augmented with classification result, again one more > >>example. > >> >> > >> >> >>All flows from the same source IP do not necessarily follow the > >>same > >> >> chain. > >> >> Correct. It is also not necessary that all transaction of the same > >>flow > >> >> follow the same chain either. So why stop at flow itself. > >> >> > >> >> Again the point here is that do we always need SFC header or Not. > >> >> > >> >> Sumandra > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> Sent: Monday, November 11, 2013 7:02 PM > >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> > >> >> Sumandra, > >> >> > >> >> The intention of service function chaining is to allow for operatio= n > >>at > >> >> the fully qualified flow level, or even finer grained at the > >> transaction > >> >> level (this is an implementation matter for the PDP). All flows > >> from > >> >> the same source IP do not necessarily follow the same chain. > Source > >> >>IP, > >> >> therefore, does not identify the chain ID. Another intention of > >> >> service function chaining is to operate over any network topology > and > >> >>not > >> >> be limited to a single LAN. Thus, while VLAN may be part of the > >> >> transport, it does not adequately identify the service chain, > either. > >> >> > >> >> Ron > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> >> Sent: Monday, November 11, 2013 9:56 PM > >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> > >> >> Ron, > >> >> > >> >> The service header is meant to carry the context which can *also* b= e > >> >> derived (for example use source ip and vlan to identify chainID and > >> >> position) or encapsulated as part of another tunnel header. So this > >> >>could > >> >> be optional IMHO. > >> >> > >> >> -----Original Message----- > >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> Sent: Monday, November 11, 2013 4:36 PM > >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> > >> >> Sumandra, > >> >> > >> >> As I understand it, an SFC packet traversing from PDP to SF or from > >>SF > >> >>to > >> >> SF will look like: > >> >> > >> >> +------------------------+ > >> >> | "transport" | > >> >> +------------------------+ > >> >> | service header | > >> >> +------------------------+ > >> >> | original IP header | > >> >> +------------------------+ > >> >> | | original IP payload | > >> >> | | > >> >> +------------------------+ > >> >> > >> >> Where service header contains, at a minimum, enough information to > >> allow > >> >> the packet to be propagated along the full length of the chain, and > >> >> optionally, other metadata that enhances the operation of one or > more > >> >> service functions. > >> >> > >> >> And where "transport" could conceivably be any of, but not limited > >>to: > >> >> > >> >> * Ethernet > >> >> * Ethernet + LLC2 > >> >> * Ethernet + MPLS > >> >> * Ethernet + IP + GRE > >> >> * Ethernet + IP +UDP > >> >> > >> >> > >> >> Also, "original" in the diagram above is not meant to imply > >> >>immutability, > >> >> but rather to specify the packet that is propagated from preceding > >> >>entity > >> >> to succeeding entity, prior to encapsulation. > >> >> > >> >> Ron > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> >> Sumandra Majee > >> >> Sent: Monday, November 11, 2013 6:46 PM > >> >> To: Thomas Narten; nsc@ietf.org > >> >> Subject: Re: [nsc] Current Proposed SFC charter > >> >> > >> >> Generic Service Function Chaining Encapsulation: A document will > >> >> describe the single service-level data plane encapsulation > format > >> >>for > >> >> conveying the service function chain and the service function > >>path, > >> >> and for communicating context information between nodes that > >> >> implement service functions. It is intended that the > >>encapsulation > >> >> be agnostic to the layer at which it is applied and the service > >> that > >> >> is > >> >> being constructed. That is, the same encapsulation may be used > on > >> >> a service function path realized at the network layer or at any > >> >>other > >> >> layer, and the same encapsulation will apply for the > construction > >> of > >> >> service function paths regardless of the actual service. > >> >> > >> >> [SM] What does it mean by a single service-level encapsulation, a > >>new > >> >> encapsulation format > >> >> or an ability to select one encapsulation format that > >>fits > >> >>the > >> >> need for a given service chain? > >> >> The ability to select a specific encapsulation would be > a > >> >> management plane decision. > >> >> There are quite a few existing encapsulation methods that > >>can > >> >> possibly be reused to provide > >> >> context information between service nodes. I have seen > >> >>mention > >> >> of GRE, for HTTP based > >> >> applications contexts are transferred via headers. > >> >> > >> >> > >> >> -----Original Message----- > >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> >> Thomas Narten > >> >> Sent: Wednesday, November 06, 2013 11:07 AM > >> >> To: nsc@ietf.org > >> >> Subject: [nsc] Current Proposed SFC charter > >> >> > >> >> Hi. > >> >> > >> >> Current charter can be found at > >> >>https://datatracker.ietf.org/doc/charter- > >> >> ietf-sfc/. > >> >> > >> >> It contains the revised management text as well as updated > >>milestones. > >> >> > >> >> All known issues have been addressed. If there are any remaining > >> issues, > >> >> please speak up! > >> >> > >> >> Charter charter-ietf-sfc-00-04 > >> >> > >> >> Networks, servers, storage technologies, and applications, have all > >> >> undergone significant change in recent years with the introduction > of > >> >> virtualization, network overlays, and orchestration. Service > delivery > >> is > >> >> currently both a technical and organizational challenge that > involves > >> >> significant modification to the network configuration. > >> >> Services are typically implemented by the ordered combination of a > >> >>number > >> >> of service functions that are deployed at different points within > the > >> >> network. Today, a common deployment model has service functions > >> >>physically > >> >> inserted on the data forwarding path between communicating peers. > >>Going > >> >> forward, however, there is a desire to move to a different model, > >>where > >> >> service functions are not required to reside on the default data > path > >> >>and > >> >> traffic is instead steered through services, wherever they are > >> deployed. > >> >> > >> >> For a given service, the abstracted view of the required service > >> >>functions > >> >> and the order in which they are to be applied is called a Service > >> >>Function > >> >> Chain (SFC). Since a given service function may be available on mor= e > >> >>than > >> >> one node within a network, a Service Function Chain is instantiated > >>via > >> >> the selection of specific service function instances and the networ= k > >> >>nodes > >> >> on which they are provided, thereby forming a service topology: > >> >> this is called a Service Function Path. The service functions may b= e > >> >> applied at a specific layer within the network protocol stack > >>(network > >> >> layer, application layer, etc.). > >> >> > >> >> The Service Function Chaining (SFC) working group will develop new > >> >> approaches to service delivery and deployment. It will produce a > >> >>framework > >> >> for service function chaining that includes the necessary protocols > >>or > >> >> protocol extensions to convey the service path and service path > >> >> information to nodes that implement service functions, as well as > >> >> mechanisms for steering traffic through service functions. The > >>working > >> >> group will also examine what information needs to be gathered from > >>the > >> >> network and service functions in support of service function > chaining > >> >>and > >> >> how that information may be made available to nodes that implement > >>the > >> >> service functions. > >> >> > >> >> Specifically, the SFC WG is chartered to deliver the following: > >> >> > >> >> 1) Problem Statement: This document will provide a summary of the > >> >> problem space to be addressed by the WG including example high- > >> >> level use cases. Additionally, the WG will normalize > nomenclature > >> >> and definitions for service function chaining. > >> >> > >> >> 2) Architecture: This document will provide a description of the > >> >> architectural building blocks and their relationships including > >> >> interconnection, placement of capabilities, management, > >> >> diagnostics, design analysis, and security models, as well as > >> >> requirements on the protocol mechanisms. > >> >> > >> >> 3) Generic Service Function Chaining Encapsulation: A document will > >> >> describe the single service-level data plane encapsulation > format > >> >>for > >> >> conveying the service function chain and the service function > >>path, > >> >> and for communicating context information between nodes that > >> >> implement service functions. It is intended that the > >>encapsulation > >> >> be agnostic to the layer at which it is applied and the service > >> that > >> >> is > >> >> being constructed. That is, the same encapsulation may be used > on > >> >> a service function path realized at the network layer or at any > >> >>other > >> >> layer, and the same encapsulation will apply for the > construction > >> of > >> >> service function paths regardless of the actual service. > >> >> > >> >> 4) Control Plane Mechanisms: A set of documents will be developed t= o > >> >> describe requirements and protocols necessary to convey > >>information > >> >> to service function implementation points. Where possible, > >>existing > >> >> IETF protocols will be used and extended. All protocol > extensions > >> >> work should be carried out in the working groups responsible fo= r > >> the > >> >> protocols being modified in coordination with this working > group, > >> >>but > >> >> may be done in this working group after agreement with all the > >> >> relevant WG chairs and responsible ADs. > >> >> > >> >> 5) Manageability: Work on the management and configuration of > service > >> >> functions in support of SFC components will certainly be needed= , > >> >> but first needs to be better understood and scoped. > >> >> > >> >> Proposed Milestones > >> >> > >> >> Apr 2014 Submit to IESG Informational document(s) defining the > >>problem > >> >> statement and core use cases for Service Function Chaining > >> >> > >> >> May 2014 Consult with OPS Area on possible charter modifications fo= r > >> >> management and configuration of SFC components > >> >> > >> >> Jan 2015 Submit to IESG Informational document defining the > >> architecture > >> >> for SFC > >> >> > >> >> Jan 2015 Submit to IESG requirements for a generic service function > >> >> chaining encapsulation protocol > >> >> > >> >> Aug 2015 Submit to IESG Standards Track document specifying the > >>generic > >> >> service function chaining header encapsulation > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Thomas > >> >> > >> >> _______________________________________________ > >> >> nsc mailing list > >> >> nsc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >> _______________________________________________ > >> >> nsc mailing list > >> >> nsc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >> _______________________________________________ > >> >> nsc mailing list > >> >> nsc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >_______________________________________________ > >> >nsc mailing list > >> >nsc@ietf.org > >> >https://www.ietf.org/mailman/listinfo/nsc > > From Ron_Parker@affirmednetworks.com Tue Nov 12 03:44:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375CB21E80BA for ; Tue, 12 Nov 2013 03:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrUbCv1DyD-1 for ; Tue, 12 Nov 2013 03:44:42 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4133821E80AC for ; Tue, 12 Nov 2013 03:44:42 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 03:44:41 -0800 From: Ron Parker To: Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHug== Date: Tue, 12 Nov 2013 11:44:40 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:44:46 -0000 Hi, Kevin You ask a great question about branching the graph. The details around how= to convey the selection of the subtree/subgraph are still to be defined. = Is it one chain id for the whole graph? Does each branch have its own ch= ain id? Some combination? Ron On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" wrote= : >> Yes, reclassification can change the service path and >> re-classification may happen at any node along a service path. >=20 > Just to expand on that, going back to the original question about > service header encapsulation, is it intended that a chain that > is re-classified will get a new chain ID which fully describes > a chain that is a superset of the original chain ID, prior to > DPI-based re-classification? (assuming the goal is "a single > chain ID that is commonly understood along the entire service chain" > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >=20 > And the applicable subset of the permutative list of service > paths would be configured at each appropriate service node? > e.g., ID 1: NAT + firewall + DPI > ID 2: NAT + firewall + DPI + AV > ID 3: NAT + firewall + DPI + AV + NAT > ID 4: NAT + firewall + DPI + NAT > ID 5: NAT + firewall + DPI + AV + LB > ID 6: NAT + firewall + DPI + LB > ID 7: NAT + firewall + DPI + LB + CACHE > ID 8: NAT + firewall + DPI + CACHE > ID 9: NAT + firewall + DPI + optimizer + LB > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > ID 11: NAT + firewall + DPI + optimizer + CACHE > Would every flow then be initially classified as ID 1, but > eventually get re-classified to ID 2-11, after the DPI phase? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> Sent: Tuesday, November 12, 2013 1:01 AM >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >>=20 >>=20 >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>=20 >>> Hi Surendra, >>>=20 >>> Classification may be out of scope, but the level of service that is >>> applicable is dependent upon the level of classification that can be >>> performed. An assumption of packet level encapsulation has >> implications >>> on the level of classification being performed? If the stated goals >> are >>> for firewall and load balancer functionality, then the application >> level >>> nature of those functions needs to be taken into account? If, on the >>> other hand, the service function scope is limited due to limitations in >>> classification, that would be and important piece of information? >>>=20 >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork points >>> of the service paths seem like re-classification points? Is that the >>> interpretation from the architecture perspective? Or is the service >>> function chain classification exclusive of DPI functionality? >> I have not fully read that draft yet. But in general, as described = in >> the arch draft, the collection of services form a graph, segments of whi= ch >> are service paths. Yes, reclassification can change the service path and >> re-classification may happen at any node along a service path. >>=20 >> Surendra. >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>> -----Original Message----- >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.or= g >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> Kevin, >>>>=20 >>>> Classification mechanism is outside the scope of SFC. It can be based >> on >>>> the packet or information not in the packet(environmental attributes >> for >>>> instance) or a combination thereof. What is important is that such >>>> classification aids in traffic selection and service path >>>> identification. >>>> It is no different from a policy in this regard except that the policy >>>> now >>>> specifies the service path. >>>> Further, classification is not limited to the network elements but the >>>> service functions as well. Some of this is described in the >> architecture >>>> drafts as well - >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>=20 >>>> Surendra. >>>>=20 >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>=20 >>>>> Hi Ron, >>>>>=20 >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but I >>>>> had a similar question wrt bullet 11 in section 2 of the problem >>>>> statement: >>>>>=20 >>>>> 11. Per-Service (re)Classification: Classification occurs at each >>>>> service, independent from previously applied service >>>> functions. >>>>> These unrelated classification events consume resources per >>>>> service. More importantly, the classification functionality >>>>> often differs per service function and service function >> cannot >>>>> leverage the results from other deployed network or service. >>>>>=20 >>>>> as it relates to section 5.2 of the framework document: >>>>>=20 >>>>> The SFC Classifier classifies packets based on (some of) the >>>> contents >>>>> of the packet header. Concretely, it classifies packets based on >>>> the >>>>> possible combination of one or more header fields, such as source >>>>> address, destination address, DS field, protocol ID, source port >>>> and >>>>> destination port numbers, and any other information. >>>>>=20 >>>>> A packet-based classifier as described in the framework document >>>> would >>>>> seem to be limited in what it can classify? The service function >>>>> identifier lookup does not seem to be a significant optimization >> over >>>>> a packet-based 5-tuple lookup? There seems to be some missing >> detail >>>>> wrt how classification information is determined and reused? >>>>>=20 >>>>> When thinking about higher level services, e.g., HTTP and TLS >>>> encrypted >>>>> flows, a packet-based classifier seems inadequate? I was also >>>> wondering >>>>> how independent HLS segment requests might be classified and >>>> associated? >>>>> Were these types of use cases discussed in the BoF? >>>>>=20 >>>>> thanx. >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >>>>>> Ron >>>>>> Parker >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> As was discussed in Vancouver, there are already many existing ways >>>> to >>>>>> accomplish service chaining. But none of them provide a >>>> sufficient >>>>>> combination of interoperability, flexibility, and resiliency. A >>>> single >>>>>> service chain encapsulation will go a long way to ensuring these >>>> goals. >>>>>> It may not be the absolutely most efficient approach for every >>>> single >>>>>> network topology and every single use case, but its ubiquitous >> nature >>>>>> should improve its adoption. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Absolutely, that was an example of one type of derivation. However >>>> this >>>>>> could be augmented with classification result, again one more >>>> example. >>>>>>=20 >>>>>>>> All flows from the same source IP do not necessarily follow the >>>> same >>>>>> chain. >>>>>> Correct. It is also not necessary that all transaction of the same >>>> flow >>>>>> follow the same chain either. So why stop at flow itself. >>>>>>=20 >>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>=20 >>>>>> Sumandra >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> The intention of service function chaining is to allow for operation >>>> at >>>>>> the fully qualified flow level, or even finer grained at the >>>> transaction >>>>>> level (this is an implementation matter for the PDP). All flows >>>> from >>>>>> the same source IP do not necessarily follow the same chain. >> Source >>>>>> IP, >>>>>> therefore, does not identify the chain ID. Another intention of >>>>>> service function chaining is to operate over any network topology >> and >>>>>> not >>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>> transport, it does not adequately identify the service chain, >> either. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> The service header is meant to carry the context which can *also* be >>>>>> derived (for example use source ip and vlan to identify chainID and >>>>>> position) or encapsulated as part of another tunnel header. So this >>>>>> could >>>>>> be optional IMHO. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> As I understand it, an SFC packet traversing from PDP to SF or from >>>> SF >>>>>> to >>>>>> SF will look like: >>>>>>=20 >>>>>> +------------------------+ >>>>>> | "transport" | >>>>>> +------------------------+ >>>>>> | service header | >>>>>> +------------------------+ >>>>>> | original IP header | >>>>>> +------------------------+ >>>>>> | | original IP payload | >>>>>> | | >>>>>> +------------------------+ >>>>>>=20 >>>>>> Where service header contains, at a minimum, enough information to >>>> allow >>>>>> the packet to be propagated along the full length of the chain, and >>>>>> optionally, other metadata that enhances the operation of one or >> more >>>>>> service functions. >>>>>>=20 >>>>>> And where "transport" could conceivably be any of, but not limited >>>> to: >>>>>>=20 >>>>>> * Ethernet >>>>>> * Ethernet + LLC2 >>>>>> * Ethernet + MPLS >>>>>> * Ethernet + IP + GRE >>>>>> * Ethernet + IP +UDP >>>>>>=20 >>>>>>=20 >>>>>> Also, "original" in the diagram above is not meant to imply >>>>>> immutability, >>>>>> but rather to specify the packet that is propagated from preceding >>>>>> entity >>>>>> to succeeding entity, prior to encapsulation. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >>>>>> Sumandra Majee >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>> To: Thomas Narten; nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>> describe the single service-level data plane encapsulation >> format >>>>>> for >>>>>> conveying the service function chain and the service function >>>> path, >>>>>> and for communicating context information between nodes that >>>>>> implement service functions. It is intended that the >>>> encapsulation >>>>>> be agnostic to the layer at which it is applied and the service >>>> that >>>>>> is >>>>>> being constructed. That is, the same encapsulation may be used >> on >>>>>> a service function path realized at the network layer or at any >>>>>> other >>>>>> layer, and the same encapsulation will apply for the >> construction >>>> of >>>>>> service function paths regardless of the actual service. >>>>>>=20 >>>>>> [SM] What does it mean by a single service-level encapsulation, a >>>> new >>>>>> encapsulation format >>>>>> or an ability to select one encapsulation format that >>>> fits >>>>>> the >>>>>> need for a given service chain? >>>>>> The ability to select a specific encapsulation would be >> a >>>>>> management plane decision. >>>>>> There are quite a few existing encapsulation methods that >>>> can >>>>>> possibly be reused to provide >>>>>> context information between service nodes. I have seen >>>>>> mention >>>>>> of GRE, for HTTP based >>>>>> applications contexts are transferred via headers. >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >>>>>> Thomas Narten >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>> To: nsc@ietf.org >>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Hi. >>>>>>=20 >>>>>> Current charter can be found at >>>>>> https://datatracker.ietf.org/doc/charter- >>>>>> ietf-sfc/. >>>>>>=20 >>>>>> It contains the revised management text as well as updated >>>> milestones. >>>>>>=20 >>>>>> All known issues have been addressed. If there are any remaining >>>> issues, >>>>>> please speak up! >>>>>>=20 >>>>>> Charter charter-ietf-sfc-00-04 >>>>>>=20 >>>>>> Networks, servers, storage technologies, and applications, have all >>>>>> undergone significant change in recent years with the introduction >> of >>>>>> virtualization, network overlays, and orchestration. Service >> delivery >>>> is >>>>>> currently both a technical and organizational challenge that >> involves >>>>>> significant modification to the network configuration. >>>>>> Services are typically implemented by the ordered combination of a >>>>>> number >>>>>> of service functions that are deployed at different points within >> the >>>>>> network. Today, a common deployment model has service functions >>>>>> physically >>>>>> inserted on the data forwarding path between communicating peers. >>>> Going >>>>>> forward, however, there is a desire to move to a different model, >>>> where >>>>>> service functions are not required to reside on the default data >> path >>>>>> and >>>>>> traffic is instead steered through services, wherever they are >>>> deployed. >>>>>>=20 >>>>>> For a given service, the abstracted view of the required service >>>>>> functions >>>>>> and the order in which they are to be applied is called a Service >>>>>> Function >>>>>> Chain (SFC). Since a given service function may be available on more >>>>>> than >>>>>> one node within a network, a Service Function Chain is instantiated >>>> via >>>>>> the selection of specific service function instances and the network >>>>>> nodes >>>>>> on which they are provided, thereby forming a service topology: >>>>>> this is called a Service Function Path. The service functions may be >>>>>> applied at a specific layer within the network protocol stack >>>> (network >>>>>> layer, application layer, etc.). >>>>>>=20 >>>>>> The Service Function Chaining (SFC) working group will develop new >>>>>> approaches to service delivery and deployment. It will produce a >>>>>> framework >>>>>> for service function chaining that includes the necessary protocols >>>> or >>>>>> protocol extensions to convey the service path and service path >>>>>> information to nodes that implement service functions, as well as >>>>>> mechanisms for steering traffic through service functions. The >>>> working >>>>>> group will also examine what information needs to be gathered from >>>> the >>>>>> network and service functions in support of service function >> chaining >>>>>> and >>>>>> how that information may be made available to nodes that implement >>>> the >>>>>> service functions. >>>>>>=20 >>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>=20 >>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>> problem space to be addressed by the WG including example high- >>>>>> level use cases. Additionally, the WG will normalize >> nomenclature >>>>>> and definitions for service function chaining. >>>>>>=20 >>>>>> 2) Architecture: This document will provide a description of the >>>>>> architectural building blocks and their relationships including >>>>>> interconnection, placement of capabilities, management, >>>>>> diagnostics, design analysis, and security models, as well as >>>>>> requirements on the protocol mechanisms. >>>>>>=20 >>>>>> 3) Generic Service Function Chaining Encapsulation: A document will >>>>>> describe the single service-level data plane encapsulation >> format >>>>>> for >>>>>> conveying the service function chain and the service function >>>> path, >>>>>> and for communicating context information between nodes that >>>>>> implement service functions. It is intended that the >>>> encapsulation >>>>>> be agnostic to the layer at which it is applied and the service >>>> that >>>>>> is >>>>>> being constructed. That is, the same encapsulation may be used >> on >>>>>> a service function path realized at the network layer or at any >>>>>> other >>>>>> layer, and the same encapsulation will apply for the >> construction >>>> of >>>>>> service function paths regardless of the actual service. >>>>>>=20 >>>>>> 4) Control Plane Mechanisms: A set of documents will be developed to >>>>>> describe requirements and protocols necessary to convey >>>> information >>>>>> to service function implementation points. Where possible, >>>> existing >>>>>> IETF protocols will be used and extended. All protocol >> extensions >>>>>> work should be carried out in the working groups responsible for >>>> the >>>>>> protocols being modified in coordination with this working >> group, >>>>>> but >>>>>> may be done in this working group after agreement with all the >>>>>> relevant WG chairs and responsible ADs. >>>>>>=20 >>>>>> 5) Manageability: Work on the management and configuration of >> service >>>>>> functions in support of SFC components will certainly be needed, >>>>>> but first needs to be better understood and scoped. >>>>>>=20 >>>>>> Proposed Milestones >>>>>>=20 >>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>> problem >>>>>> statement and core use cases for Service Function Chaining >>>>>>=20 >>>>>> May 2014 Consult with OPS Area on possible charter modifications for >>>>>> management and configuration of SFC components >>>>>>=20 >>>>>> Jan 2015 Submit to IESG Informational document defining the >>>> architecture >>>>>> for SFC >>>>>>=20 >>>>>> Jan 2015 Submit to IESG requirements for a generic service function >>>>>> chaining encapsulation protocol >>>>>>=20 >>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>> generic >>>>>> service function chaining header encapsulation >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >=20 From hongyu.li@huawei.com Tue Nov 12 03:57:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E709621E80AC for ; Tue, 12 Nov 2013 03:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ec-S61YunTC for ; Tue, 12 Nov 2013 03:57:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E151021E80EB for ; Tue, 12 Nov 2013 03:57:12 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU46732; Tue, 12 Nov 2013 11:57:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 11:56:55 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 11:57:07 +0000 Received: from szxeml560-mbx.china.huawei.com ([169.254.3.84]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 19:57:01 +0800 From: "Hongyu Li (Julio)" To: Ron Parker , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9nE/gbi+9tEGr7VYhI0C+3ZogM9+AgAAOHICAACcIgIAAAa2AgAACJYCAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAiG7Q Date: Tue, 12 Nov 2013 11:57:01 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> 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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 11:57:26 -0000 QnJhbmNoaW5nL2ZvcmtpbmcgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIHRvcGljIG9mIFNGQy4gQWJv dXQgdGhlIHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50LCBwcm9iYWJseSB3ZSBzaGFsbCBub3QgbGlt aXQgaXQgdG8gRFBJLiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgcGFja2V0cyBnbyB0byBkaWZm ZXJlbnQgYnJhbmNoZXMgYWZ0ZXIgYmVlbiBwcm9jZXNzZWQgYnkgYSBjZXJ0YWluIHNlcnZpY2Ug ZnVuY3Rpb24sIGRlY2lzaW9uIG9mIHdoaWNoIGJyYW5jaGVzIHRvIGdvIGlzIG1hZGUgYmFzZWQg b24gdGhlIHJlc3VsdCBvZiBzZXJ2aWNlIGZ1bmN0aW9uJ3MgcHJvY2VzcywgaS5lLiBub3QganVz dCByZS1jbGFzc2lmaWNhdGlvbiBieSBEUEkuDQoNCkhvbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQYXJrZXINClNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDEyLCAyMDEzIDc6NDUgUE0NClRvOiBLZXZpbiBKIE1hDQpDYzogVGhvbWFzIE5hcnRlbjsg bnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFN1bWFuZHJhIE1hamVlDQpT dWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQpIaSwgS2V2 aW4NCg0KWW91IGFzayBhIGdyZWF0IHF1ZXN0aW9uIGFib3V0IGJyYW5jaGluZyB0aGUgZ3JhcGgu ICBUaGUgZGV0YWlscyBhcm91bmQgaG93IHRvIGNvbnZleSB0aGUgc2VsZWN0aW9uIG9mIHRoZSBz dWJ0cmVlL3N1YmdyYXBoIGFyZSBzdGlsbCB0byBiZSBkZWZpbmVkLiAgIElzIGl0IG9uZSBjaGFp biBpZCBmb3IgdGhlIHdob2xlIGdyYXBoPyAgIERvZXMgZWFjaCBicmFuY2ggaGF2ZSBpdHMgb3du IGNoYWluIGlkPyAgIFNvbWUgY29tYmluYXRpb24/DQoNCiAgIFJvbg0KDQpPbiBOb3YgMTIsIDIw MTMsIGF0IDE6NTIgQU0sICJLZXZpbiBKIE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4g d3JvdGU6DQoNCj4+IFllcywgcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRoZSBzZXJ2aWNl IHBhdGggYW5kIA0KPj4gcmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZSBh bG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4gDQo+IEp1c3QgdG8gZXhwYW5kIG9uIHRoYXQsIGdvaW5n IGJhY2sgdG8gdGhlIG9yaWdpbmFsIHF1ZXN0aW9uIGFib3V0IA0KPiBzZXJ2aWNlIGhlYWRlciBl bmNhcHN1bGF0aW9uLCBpcyBpdCBpbnRlbmRlZCB0aGF0IGEgY2hhaW4gdGhhdCBpcyANCj4gcmUt Y2xhc3NpZmllZCB3aWxsIGdldCBhIG5ldyBjaGFpbiBJRCB3aGljaCBmdWxseSBkZXNjcmliZXMg YSBjaGFpbiANCj4gdGhhdCBpcyBhIHN1cGVyc2V0IG9mIHRoZSBvcmlnaW5hbCBjaGFpbiBJRCwg cHJpb3IgdG8gRFBJLWJhc2VkIA0KPiByZS1jbGFzc2lmaWNhdGlvbj8gIChhc3N1bWluZyB0aGUg Z29hbCBpcyAiYSBzaW5nbGUgY2hhaW4gSUQgdGhhdCBpcyANCj4gY29tbW9ubHkgdW5kZXJzdG9v ZCBhbG9uZyB0aGUgZW50aXJlIHNlcnZpY2UgY2hhaW4iDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cwMDYzOC5odG1sKQ0KPiANCj4gQW5kIHRo ZSBhcHBsaWNhYmxlIHN1YnNldCBvZiB0aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlIHBh dGhzIA0KPiB3b3VsZCBiZSBjb25maWd1cmVkIGF0IGVhY2ggYXBwcm9wcmlhdGUgc2VydmljZSBu b2RlPw0KPiBlLmcuLCBJRCAxOiBOQVQgKyBmaXJld2FsbCArIERQSQ0KPiAgICAgIElEIDI6IE5B VCArIGZpcmV3YWxsICsgRFBJICsgQVYNCj4gICAgICBJRCAzOiBOQVQgKyBmaXJld2FsbCArIERQ SSArIEFWICsgTkFUDQo+ICAgICAgSUQgNDogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBOQVQNCj4g ICAgICBJRCA1OiBOQVQgKyBmaXJld2FsbCArIERQSSArIEFWICsgTEINCj4gICAgICBJRCA2OiBO QVQgKyBmaXJld2FsbCArIERQSSArIExCDQo+ICAgICAgSUQgNzogTkFUICsgZmlyZXdhbGwgKyBE UEkgKyBMQiArIENBQ0hFDQo+ICAgICAgSUQgODogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBDQUNI RQ0KPiAgICAgIElEIDk6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgTEINCj4g ICAgICBJRCAxMDogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQiArIENBQ0hF DQo+ICAgICAgSUQgMTE6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgQ0FDSEUg V291bGQgZXZlcnkgZmxvdyANCj4gdGhlbiBiZSBpbml0aWFsbHkgY2xhc3NpZmllZCBhcyBJRCAx LCBidXQgZXZlbnR1YWxseSBnZXQgcmUtY2xhc3NpZmllZCANCj4gdG8gSUQgMi0xMSwgYWZ0ZXIg dGhlIERQSSBwaGFzZT8NCj4gDQo+IHRoYW54Lg0KPiANCj4gLS0gIEtldmluIEouIE1hDQo+IA0K Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFN1cmVuZHJhIEt1bWFyIChz bWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPj4gU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMTIsIDIwMTMgMTowMSBBTQ0KPj4gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1 bWFuZHJhIE1hamVlOyBUaG9tYXMgTmFydGVuOyANCj4+IG5zY0BpZXRmLm9yZw0KPj4gU3ViamVj dDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+IA0KPj4gDQo+PiAN Cj4+PiBPbiAxMS8xMS8xMyA5OjQ2IFBNLCAiS2V2aW4gSiBNYSIgPGtldmluLm1hQGF6dWtpc3lz dGVtcy5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEhpIFN1cmVuZHJhLA0KPj4+IA0KPj4+IENsYXNz aWZpY2F0aW9uIG1heSBiZSBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGUgbGV2ZWwgb2Ygc2VydmljZSB0 aGF0IGlzIA0KPj4+IGFwcGxpY2FibGUgaXMgZGVwZW5kZW50IHVwb24gdGhlIGxldmVsIG9mIGNs YXNzaWZpY2F0aW9uIHRoYXQgY2FuIGJlIA0KPj4+IHBlcmZvcm1lZC4gIEFuIGFzc3VtcHRpb24g b2YgcGFja2V0IGxldmVsIGVuY2Fwc3VsYXRpb24gaGFzDQo+PiBpbXBsaWNhdGlvbnMNCj4+PiBv biB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gYmVpbmcgcGVyZm9ybWVkPyAgSWYgdGhlIHN0 YXRlZCBnb2Fscw0KPj4gYXJlDQo+Pj4gZm9yIGZpcmV3YWxsIGFuZCBsb2FkIGJhbGFuY2VyIGZ1 bmN0aW9uYWxpdHksIHRoZW4gdGhlIGFwcGxpY2F0aW9uDQo+PiBsZXZlbA0KPj4+IG5hdHVyZSBv ZiB0aG9zZSBmdW5jdGlvbnMgbmVlZHMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50PyAgSWYsIG9u IA0KPj4+IHRoZSBvdGhlciBoYW5kLCB0aGUgc2VydmljZSBmdW5jdGlvbiBzY29wZSBpcyBsaW1p dGVkIGR1ZSB0byANCj4+PiBsaW1pdGF0aW9ucyBpbiBjbGFzc2lmaWNhdGlvbiwgdGhhdCB3b3Vs ZCBiZSBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIGluZm9ybWF0aW9uPw0KPj4+IA0KPj4+IFdydCBz ZWN0aW9uIDQuNCBvZiBkcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMgdGhlIGZv cmsgDQo+Pj4gcG9pbnRzIG9mIHRoZSBzZXJ2aWNlIHBhdGhzIHNlZW0gbGlrZSByZS1jbGFzc2lm aWNhdGlvbiBwb2ludHM/ICBJcyANCj4+PiB0aGF0IHRoZSBpbnRlcnByZXRhdGlvbiBmcm9tIHRo ZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmU/ICBPciBpcyANCj4+PiB0aGUgc2VydmljZSBmdW5j dGlvbiBjaGFpbiBjbGFzc2lmaWNhdGlvbiBleGNsdXNpdmUgb2YgRFBJIGZ1bmN0aW9uYWxpdHk/ DQo+PiA8U0s+IEkgaGF2ZSBub3QgZnVsbHkgcmVhZCB0aGF0IGRyYWZ0IHlldC4gQnV0IGluIGdl bmVyYWwsIGFzIA0KPj4gZGVzY3JpYmVkIGluIHRoZSBhcmNoIGRyYWZ0LCB0aGUgY29sbGVjdGlv biBvZiBzZXJ2aWNlcyBmb3JtIGEgZ3JhcGgsIA0KPj4gc2VnbWVudHMgb2Ygd2hpY2ggYXJlIHNl cnZpY2UgcGF0aHMuIFllcywgcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIA0KPj4gdGhlIHNl cnZpY2UgcGF0aCBhbmQgcmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZSBh bG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+IA0KPj4gU3VyZW5kcmEuDQo+Pj4gDQo+Pj4gdGhhbngu DQo+Pj4gDQo+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+IEZyb206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNt a3VtYXJAY2lzY28uY29tXQ0KPj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAx MjowOCBBTQ0KPj4+PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBhcmtlcjsgU3VtYW5kcmEgTWFqZWU7 IFRob21hcyBOYXJ0ZW47IA0KPj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtu c2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4gDQo+Pj4+IEtldmluLA0KPj4+ PiANCj4+Pj4gQ2xhc3NpZmljYXRpb24gbWVjaGFuaXNtIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9m IFNGQy4gSXQgY2FuIGJlIA0KPj4+PiBiYXNlZA0KPj4gb24NCj4+Pj4gdGhlIHBhY2tldCBvciBp bmZvcm1hdGlvbiBub3QgaW4gdGhlIHBhY2tldChlbnZpcm9ubWVudGFsIA0KPj4+PiBhdHRyaWJ1 dGVzDQo+PiBmb3INCj4+Pj4gaW5zdGFuY2UpIG9yIGEgY29tYmluYXRpb24gdGhlcmVvZi4gV2hh dCBpcyBpbXBvcnRhbnQgaXMgdGhhdCBzdWNoIA0KPj4+PiBjbGFzc2lmaWNhdGlvbiBhaWRzIGlu IHRyYWZmaWMgc2VsZWN0aW9uIGFuZCBzZXJ2aWNlIHBhdGggDQo+Pj4+IGlkZW50aWZpY2F0aW9u Lg0KPj4+PiBJdCBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHBvbGljeSBpbiB0aGlzIHJlZ2FyZCBl eGNlcHQgdGhhdCB0aGUgDQo+Pj4+IHBvbGljeSBub3cgc3BlY2lmaWVzIHRoZSBzZXJ2aWNlIHBh dGguDQo+Pj4+IEZ1cnRoZXIsIGNsYXNzaWZpY2F0aW9uIGlzIG5vdCBsaW1pdGVkIHRvIHRoZSBu ZXR3b3JrIGVsZW1lbnRzIGJ1dCANCj4+Pj4gdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwu IFNvbWUgb2YgdGhpcyBpcyBkZXNjcmliZWQgaW4gdGhlDQo+PiBhcmNoaXRlY3R1cmUNCj4+Pj4g ZHJhZnRzIGFzIHdlbGwgLQ0KPj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtcXVpbm4tc2ZjLWFyY2gvIi4NCj4+Pj4gDQo+Pj4+IFN1cmVuZHJhLg0KPj4+PiANCj4+ Pj4+IE9uIDExLzExLzEzIDc6MzMgUE0sICJLZXZpbiBKIE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0 ZW1zLmNvbT4gd3JvdGU6DQo+Pj4+PiANCj4+Pj4+IEhpIFJvbiwNCj4+Pj4+IA0KPj4+Pj4gSSB3 YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNGQyBCb0YgZHVlIHRvIGEgY29uZmxpY3Qgd2l0aCBDRE5J LCBidXQgDQo+Pj4+PiBJIGhhZCBhIHNpbWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxldCAxMSBpbiBz ZWN0aW9uIDIgb2YgdGhlIHByb2JsZW0NCj4+Pj4+IHN0YXRlbWVudDoNCj4+Pj4+IA0KPj4+Pj4g ICAxMS4gIFBlci1TZXJ2aWNlIChyZSlDbGFzc2lmaWNhdGlvbjogQ2xhc3NpZmljYXRpb24gb2Nj dXJzIGF0IGVhY2gNCj4+Pj4+ICAgICAgICBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZp b3VzbHkgYXBwbGllZCBzZXJ2aWNlDQo+Pj4+IGZ1bmN0aW9ucy4NCj4+Pj4+ICAgICAgICBUaGVz ZSB1bnJlbGF0ZWQgY2xhc3NpZmljYXRpb24gZXZlbnRzIGNvbnN1bWUgcmVzb3VyY2VzIHBlcg0K Pj4+Pj4gICAgICAgIHNlcnZpY2UuICBNb3JlIGltcG9ydGFudGx5LCB0aGUgY2xhc3NpZmljYXRp b24gZnVuY3Rpb25hbGl0eQ0KPj4+Pj4gICAgICAgIG9mdGVuIGRpZmZlcnMgcGVyIHNlcnZpY2Ug ZnVuY3Rpb24gYW5kIHNlcnZpY2UgZnVuY3Rpb24NCj4+IGNhbm5vdA0KPj4+Pj4gICAgICAgIGxl dmVyYWdlIHRoZSByZXN1bHRzIGZyb20gb3RoZXIgZGVwbG95ZWQgbmV0d29yayBvciBzZXJ2aWNl Lg0KPj4+Pj4gDQo+Pj4+PiBhcyBpdCByZWxhdGVzIHRvIHNlY3Rpb24gNS4yIG9mIHRoZSBmcmFt ZXdvcmsgZG9jdW1lbnQ6DQo+Pj4+PiANCj4+Pj4+ICAgVGhlIFNGQyBDbGFzc2lmaWVyIGNsYXNz aWZpZXMgcGFja2V0cyBiYXNlZCBvbiAoc29tZSBvZikgdGhlDQo+Pj4+IGNvbnRlbnRzDQo+Pj4+ PiAgIG9mIHRoZSBwYWNrZXQgaGVhZGVyLiAgQ29uY3JldGVseSwgaXQgY2xhc3NpZmllcyBwYWNr ZXRzIGJhc2VkIA0KPj4+Pj4gb24NCj4+Pj4gdGhlDQo+Pj4+PiAgIHBvc3NpYmxlIGNvbWJpbmF0 aW9uIG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsIHN1Y2ggYXMgc291cmNlDQo+Pj4+PiAg IGFkZHJlc3MsIGRlc3RpbmF0aW9uIGFkZHJlc3MsIERTIGZpZWxkLCBwcm90b2NvbCBJRCwgc291 cmNlIHBvcnQNCj4+Pj4gYW5kDQo+Pj4+PiAgIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVycywgYW5k IGFueSBvdGhlciBpbmZvcm1hdGlvbi4NCj4+Pj4+IA0KPj4+Pj4gQSBwYWNrZXQtYmFzZWQgY2xh c3NpZmllciBhcyBkZXNjcmliZWQgaW4gdGhlIGZyYW1ld29yayBkb2N1bWVudA0KPj4+PiB3b3Vs ZA0KPj4+Pj4gc2VlbSB0byBiZSBsaW1pdGVkIGluIHdoYXQgaXQgY2FuIGNsYXNzaWZ5PyAgVGhl IHNlcnZpY2UgZnVuY3Rpb24gDQo+Pj4+PiBpZGVudGlmaWVyIGxvb2t1cCBkb2VzIG5vdCBzZWVt IHRvIGJlIGEgc2lnbmlmaWNhbnQgb3B0aW1pemF0aW9uDQo+PiBvdmVyDQo+Pj4+PiBhIHBhY2tl dC1iYXNlZCA1LXR1cGxlIGxvb2t1cD8gIFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWlzc2luZw0K Pj4gZGV0YWlsDQo+Pj4+PiB3cnQgaG93IGNsYXNzaWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIGRl dGVybWluZWQgYW5kIHJldXNlZD8NCj4+Pj4+IA0KPj4+Pj4gV2hlbiB0aGlua2luZyBhYm91dCBo aWdoZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhUVFAgYW5kIFRMUw0KPj4+PiBlbmNyeXB0ZWQN Cj4+Pj4+IGZsb3dzLCBhIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVyIHNlZW1zIGluYWRlcXVhdGU/ ICBJIHdhcyBhbHNvDQo+Pj4+IHdvbmRlcmluZw0KPj4+Pj4gaG93IGluZGVwZW5kZW50IEhMUyBz ZWdtZW50IHJlcXVlc3RzIG1pZ2h0IGJlIGNsYXNzaWZpZWQgYW5kDQo+Pj4+IGFzc29jaWF0ZWQ/ DQo+Pj4+PiBXZXJlIHRoZXNlIHR5cGVzIG9mIHVzZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJv Rj8NCj4+Pj4+IA0KPj4+Pj4gdGhhbnguDQo+Pj4+PiANCj4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0K Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+ Pj4+PiBCZWhhbGYNCj4+IE9mDQo+Pj4+Pj4gUm9uDQo+Pj4+Pj4gUGFya2VyDQo+Pj4+Pj4gU2Vu dDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyAxMDoxNiBQTQ0KPj4+Pj4+IFRvOiBTdW1hbmRy YSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUmU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+PiANCj4+Pj4+PiBTdW1h bmRyYSwNCj4+Pj4+PiANCj4+Pj4+PiBBcyB3YXMgZGlzY3Vzc2VkIGluIFZhbmNvdXZlciwgdGhl cmUgYXJlIGFscmVhZHkgbWFueSBleGlzdGluZyANCj4+Pj4+PiB3YXlzDQo+Pj4+IHRvDQo+Pj4+ Pj4gYWNjb21wbGlzaCBzZXJ2aWNlIGNoYWluaW5nLiAgICAgQnV0IG5vbmUgb2YgdGhlbSBwcm92 aWRlIGENCj4+Pj4gc3VmZmljaWVudA0KPj4+Pj4+IGNvbWJpbmF0aW9uIG9mIGludGVyb3BlcmFi aWxpdHksIGZsZXhpYmlsaXR5LCBhbmQgcmVzaWxpZW5jeS4gICBBDQo+Pj4+IHNpbmdsZQ0KPj4+ Pj4+IHNlcnZpY2UgY2hhaW4gZW5jYXBzdWxhdGlvbiB3aWxsIGdvIGEgbG9uZyB3YXkgdG8gZW5z dXJpbmcgdGhlc2UNCj4+Pj4gZ29hbHMuDQo+Pj4+Pj4gSXQgIG1heSBub3QgYmUgdGhlIGFic29s dXRlbHkgbW9zdCBlZmZpY2llbnQgYXBwcm9hY2ggZm9yIGV2ZXJ5DQo+Pj4+IHNpbmdsZQ0KPj4+ Pj4+IG5ldHdvcmsgdG9wb2xvZ3kgYW5kIGV2ZXJ5IHNpbmdsZSB1c2UgY2FzZSwgYnV0IGl0cyB1 YmlxdWl0b3VzDQo+PiBuYXR1cmUNCj4+Pj4+PiBzaG91bGQgaW1wcm92ZSBpdHMgYWRvcHRpb24u DQo+Pj4+Pj4gDQo+Pj4+Pj4gICBSb24NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86 Uy5NYWplZUBGNS5jb21dDQo+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyAx MDoxMCBQTQ0KPj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5v cmcNCj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KPj4+Pj4+IA0KPj4+Pj4+IFJvbiwNCj4+Pj4+PiANCj4+Pj4+PiBBYnNvbHV0ZWx5LCB0aGF0 IHdhcyBhbiBleGFtcGxlIG9mIG9uZSB0eXBlIG9mIGRlcml2YXRpb24uIA0KPj4+Pj4+IEhvd2V2 ZXINCj4+Pj4gdGhpcw0KPj4+Pj4+IGNvdWxkIGJlIGF1Z21lbnRlZCB3aXRoIGNsYXNzaWZpY2F0 aW9uIHJlc3VsdCwgYWdhaW4gb25lIG1vcmUNCj4+Pj4gZXhhbXBsZS4NCj4+Pj4+PiANCj4+Pj4+ Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVjZXNzYXJpbHkg Zm9sbG93IHRoZQ0KPj4+PiBzYW1lDQo+Pj4+Pj4gY2hhaW4uDQo+Pj4+Pj4gQ29ycmVjdC4gSXQg aXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQgYWxsIHRyYW5zYWN0aW9uIG9mIHRoZSANCj4+Pj4+ PiBzYW1lDQo+Pj4+IGZsb3cNCj4+Pj4+PiBmb2xsb3cgdGhlIHNhbWUgY2hhaW4gZWl0aGVyLiBT byB3aHkgc3RvcCBhdCBmbG93IGl0c2VsZi4NCj4+Pj4+PiANCj4+Pj4+PiBBZ2FpbiB0aGUgcG9p bnQgaGVyZSBpcyB0aGF0IGRvIHdlIGFsd2F5cyBuZWVkIFNGQyBoZWFkZXIgb3IgTm90Lg0KPj4+ Pj4+IA0KPj4+Pj4+IFN1bWFuZHJhDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVy IDExLCAyMDEzIDc6MDIgUE0NCj4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0 ZW47IG5zY0BpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bv c2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4gDQo+Pj4+Pj4gU3VtYW5kcmEsDQo+Pj4+Pj4gDQo+Pj4+ Pj4gVGhlIGludGVudGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHRvIGFsbG93 IGZvciANCj4+Pj4+PiBvcGVyYXRpb24NCj4+Pj4gYXQNCj4+Pj4+PiB0aGUgZnVsbHkgcXVhbGlm aWVkIGZsb3cgbGV2ZWwsIG9yIGV2ZW4gZmluZXIgZ3JhaW5lZCBhdCB0aGUNCj4+Pj4gdHJhbnNh Y3Rpb24NCj4+Pj4+PiBsZXZlbCAodGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIgZm9y IHRoZSBQRFApLiAgICAgQWxsIGZsb3dzDQo+Pj4+IGZyb20NCj4+Pj4+PiB0aGUgc2FtZSBzb3Vy Y2UgSVAgZG8gbm90IG5lY2Vzc2FyaWx5IGZvbGxvdyB0aGUgc2FtZSBjaGFpbi4NCj4+IFNvdXJj ZQ0KPj4+Pj4+IElQLA0KPj4+Pj4+IHRoZXJlZm9yZSwgIGRvZXMgbm90IGlkZW50aWZ5IHRoZSBj aGFpbiBJRC4gICAgQW5vdGhlciBpbnRlbnRpb24gb2YNCj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29yayB0b3BvbG9neQ0KPj4gYW5k DQo+Pj4+Pj4gbm90DQo+Pj4+Pj4gYmUgbGltaXRlZCB0byBhIHNpbmdsZSBMQU4uICAgVGh1cywg d2hpbGUgVkxBTiBtYXkgYmUgcGFydCBvZiB0aGUNCj4+Pj4+PiB0cmFuc3BvcnQsIGl0IGRvZXMg bm90IGFkZXF1YXRlbHkgaWRlbnRpZnkgdGhlIHNlcnZpY2UgY2hhaW4sDQo+PiBlaXRoZXIuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gICBSb24NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86Uy5N YWplZUBGNS5jb21dDQo+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA5OjU2 IFBNDQo+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ Pj4+Pj4gDQo+Pj4+Pj4gUm9uLA0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBzZXJ2aWNlIGhlYWRlciBp cyBtZWFudCB0byBjYXJyeSB0aGUgY29udGV4dCB3aGljaCBjYW4gKmFsc28qIA0KPj4+Pj4+IGJl IGRlcml2ZWQgKGZvciBleGFtcGxlIHVzZSBzb3VyY2UgaXAgYW5kIHZsYW4gdG8gaWRlbnRpZnkg DQo+Pj4+Pj4gY2hhaW5JRCBhbmQNCj4+Pj4+PiBwb3NpdGlvbikgb3IgZW5jYXBzdWxhdGVkIGFz IHBhcnQgb2YgYW5vdGhlciB0dW5uZWwgaGVhZGVyLiBTbyANCj4+Pj4+PiB0aGlzIGNvdWxkIGJl IG9wdGlvbmFsIElNSE8uDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbV0NCj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDQ6MzYg UE0NCj4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9y Zw0KPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVy DQo+Pj4+Pj4gDQo+Pj4+Pj4gU3VtYW5kcmEsDQo+Pj4+Pj4gDQo+Pj4+Pj4gQXMgSSB1bmRlcnN0 YW5kIGl0LCBhbiBTRkMgcGFja2V0IHRyYXZlcnNpbmcgZnJvbSBQRFAgdG8gU0Ygb3IgDQo+Pj4+ Pj4gZnJvbQ0KPj4+PiBTRg0KPj4+Pj4+IHRvDQo+Pj4+Pj4gU0Ygd2lsbCBsb29rIGxpa2U6DQo+ Pj4+Pj4gDQo+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+PiB8ICAgICAg ICAidHJhbnNwb3J0IiAgICAgICAgIHwNCj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPj4+Pj4+IHwgICAgICBzZXJ2aWNlIGhlYWRlciAgICB8DQo+Pj4+Pj4gKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCj4+Pj4+PiB8ICAgb3JpZ2luYWwgSVAgaGVhZGVyICB8DQo+Pj4+Pj4g Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICBvcmlnaW5hbCBJUCBwYXlsb2FkICB8DQo+Pj4+Pj4gfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+ICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4gDQo+Pj4+Pj4gV2hlcmUgc2VydmljZSBoZWFkZXIg Y29udGFpbnMsIGF0IGEgbWluaW11bSwgZW5vdWdoIGluZm9ybWF0aW9uIA0KPj4+Pj4+IHRvDQo+ Pj4+IGFsbG93DQo+Pj4+Pj4gdGhlIHBhY2tldCB0byBiZSBwcm9wYWdhdGVkIGFsb25nIHRoZSBm dWxsIGxlbmd0aCBvZiB0aGUgY2hhaW4sIA0KPj4+Pj4+IGFuZCBvcHRpb25hbGx5LCBvdGhlciBt ZXRhZGF0YSB0aGF0IGVuaGFuY2VzIHRoZSBvcGVyYXRpb24gb2Ygb25lIA0KPj4+Pj4+IG9yDQo+ PiBtb3JlDQo+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gQW5kIHdo ZXJlICJ0cmFuc3BvcnQiIGNvdWxkIGNvbmNlaXZhYmx5IGJlIGFueSBvZiwgYnV0IG5vdCANCj4+ Pj4+PiBsaW1pdGVkDQo+Pj4+IHRvOg0KPj4+Pj4+IA0KPj4+Pj4+ICogRXRoZXJuZXQNCj4+Pj4+ PiAqIEV0aGVybmV0ICsgTExDMg0KPj4+Pj4+ICogRXRoZXJuZXQgKyBNUExTDQo+Pj4+Pj4gKiBF dGhlcm5ldCArIElQICsgR1JFDQo+Pj4+Pj4gKiBFdGhlcm5ldCArIElQICtVRFANCj4+Pj4+PiAN Cj4+Pj4+PiANCj4+Pj4+PiBBbHNvLCAib3JpZ2luYWwiIGluIHRoZSBkaWFncmFtIGFib3ZlIGlz IG5vdCBtZWFudCB0byBpbXBseSANCj4+Pj4+PiBpbW11dGFiaWxpdHksIGJ1dCByYXRoZXIgdG8g c3BlY2lmeSB0aGUgcGFja2V0IHRoYXQgaXMgcHJvcGFnYXRlZCANCj4+Pj4+PiBmcm9tIHByZWNl ZGluZyBlbnRpdHkgdG8gc3VjY2VlZGluZyBlbnRpdHksIHByaW9yIHRvIA0KPj4+Pj4+IGVuY2Fw c3VsYXRpb24uDQo+Pj4+Pj4gDQo+Pj4+Pj4gICBSb24NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+IEJlaGFsZg0K Pj4gT2YNCj4+Pj4+PiBTdW1hbmRyYSBNYWplZQ0KPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgMTEsIDIwMTMgNjo0NiBQTQ0KPj4+Pj4+IFRvOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5v cmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KPj4+Pj4+IA0KPj4+Pj4+IEdlbmVyaWMgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBFbmNh cHN1bGF0aW9uOiBBIGRvY3VtZW50IHdpbGwNCj4+Pj4+PiAgICBkZXNjcmliZSB0aGUgc2luZ2xl IHNlcnZpY2UtbGV2ZWwgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uDQo+PiBmb3JtYXQNCj4+Pj4+ PiBmb3INCj4+Pj4+PiAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5k IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+IHBhdGgsDQo+Pj4+Pj4gICAgYW5kIGZvciBjb21t dW5pY2F0aW5nIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiBub2RlcyB0aGF0DQo+Pj4+Pj4g ICAgaW1wbGVtZW50IHNlcnZpY2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0K Pj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4gICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0 IHdoaWNoIGl0IGlzIGFwcGxpZWQgYW5kIHRoZSANCj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+IHRoYXQN Cj4+Pj4+PiBpcw0KPj4+Pj4+ICAgIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2Ft ZSBlbmNhcHN1bGF0aW9uIG1heSBiZSB1c2VkDQo+PiBvbg0KPj4+Pj4+ICAgIGEgc2VydmljZSBm dW5jdGlvbiBwYXRoIHJlYWxpemVkIGF0IHRoZSBuZXR3b3JrIGxheWVyIG9yIGF0IA0KPj4+Pj4+ IGFueSBvdGhlcg0KPj4+Pj4+ICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3 aWxsIGFwcGx5IGZvciB0aGUNCj4+IGNvbnN0cnVjdGlvbg0KPj4+PiBvZg0KPj4+Pj4+ICAgIHNl cnZpY2UgZnVuY3Rpb24gcGF0aHMgcmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsIHNlcnZpY2UuDQo+ Pj4+Pj4gDQo+Pj4+Pj4gW1NNXSBXaGF0IGRvZXMgaXQgbWVhbiBieSBhIHNpbmdsZSBzZXJ2aWNl LWxldmVsIGVuY2Fwc3VsYXRpb24sICANCj4+Pj4+PiBhDQo+Pj4+IG5ldw0KPj4+Pj4+IGVuY2Fw c3VsYXRpb24gZm9ybWF0DQo+Pj4+Pj4gICAgICAgICAgICBvciBhbiBhYmlsaXR5IHRvIHNlbGVj dCBvbmUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgdGhhdA0KPj4+PiBmaXRzDQo+Pj4+Pj4gdGhlDQo+ Pj4+Pj4gbmVlZCBmb3IgYSBnaXZlbiBzZXJ2aWNlIGNoYWluPw0KPj4+Pj4+ICAgICAgICAgICBU aGUgYWJpbGl0eSB0byBzZWxlY3QgYSBzcGVjaWZpYyBlbmNhcHN1bGF0aW9uICB3b3VsZCANCj4+ Pj4+PiBiZQ0KPj4gYQ0KPj4+Pj4+IG1hbmFnZW1lbnQgcGxhbmUgZGVjaXNpb24uDQo+Pj4+Pj4g ICAgICAgICAgVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGV4aXN0aW5nIGVuY2Fwc3VsYXRpb24gbWV0 aG9kcyANCj4+Pj4+PiB0aGF0DQo+Pj4+IGNhbg0KPj4+Pj4+IHBvc3NpYmx5IGJlIHJldXNlZCB0 byBwcm92aWRlDQo+Pj4+Pj4gICAgICAgICAgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuICAg c2VydmljZSBub2Rlcy4gSSBoYXZlIHNlZW4NCj4+Pj4+PiBtZW50aW9uDQo+Pj4+Pj4gb2YgR1JF LCBmb3IgSFRUUCBiYXNlZA0KPj4+Pj4+ICAgICAgICAgIGFwcGxpY2F0aW9ucyBjb250ZXh0cyBh cmUgdHJhbnNmZXJyZWQgdmlhIGhlYWRlcnMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+Pj4+PiBCZWhhbGYNCj4+IE9m DQo+Pj4+Pj4gVGhvbWFzIE5hcnRlbg0KPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIg MDYsIDIwMTMgMTE6MDcgQU0NCj4+Pj4+PiBUbzogbnNjQGlldGYub3JnDQo+Pj4+Pj4gU3ViamVj dDogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+IA0KPj4+Pj4+IEhp Lg0KPj4+Pj4+IA0KPj4+Pj4+IEN1cnJlbnQgY2hhcnRlciBjYW4gYmUgZm91bmQgYXQNCj4+Pj4+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLQ0KPj4+Pj4+IGlldGYt c2ZjLy4NCj4+Pj4+PiANCj4+Pj4+PiBJdCBjb250YWlucyB0aGUgcmV2aXNlZCBtYW5hZ2VtZW50 IHRleHQgYXMgd2VsbCBhcyB1cGRhdGVkDQo+Pj4+IG1pbGVzdG9uZXMuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gQWxsIGtub3duIGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBJZiB0aGVyZSBhcmUgYW55 IHJlbWFpbmluZw0KPj4+PiBpc3N1ZXMsDQo+Pj4+Pj4gcGxlYXNlIHNwZWFrIHVwIQ0KPj4+Pj4+ IA0KPj4+Pj4+IENoYXJ0ZXIgY2hhcnRlci1pZXRmLXNmYy0wMC0wNA0KPj4+Pj4+IA0KPj4+Pj4+ IE5ldHdvcmtzLCBzZXJ2ZXJzLCBzdG9yYWdlIHRlY2hub2xvZ2llcywgYW5kIGFwcGxpY2F0aW9u cywgaGF2ZSANCj4+Pj4+PiBhbGwgdW5kZXJnb25lIHNpZ25pZmljYW50IGNoYW5nZSBpbiByZWNl bnQgeWVhcnMgd2l0aCB0aGUgDQo+Pj4+Pj4gaW50cm9kdWN0aW9uDQo+PiBvZg0KPj4+Pj4+IHZp cnR1YWxpemF0aW9uLCBuZXR3b3JrIG92ZXJsYXlzLCBhbmQgb3JjaGVzdHJhdGlvbi4gU2Vydmlj ZQ0KPj4gZGVsaXZlcnkNCj4+Pj4gaXMNCj4+Pj4+PiBjdXJyZW50bHkgYm90aCBhIHRlY2huaWNh bCBhbmQgb3JnYW5pemF0aW9uYWwgY2hhbGxlbmdlIHRoYXQNCj4+IGludm9sdmVzDQo+Pj4+Pj4g c2lnbmlmaWNhbnQgbW9kaWZpY2F0aW9uIHRvIHRoZSBuZXR3b3JrIGNvbmZpZ3VyYXRpb24uDQo+ Pj4+Pj4gU2VydmljZXMgYXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBieSB0aGUgb3JkZXJlZCBj b21iaW5hdGlvbiBvZiANCj4+Pj4+PiBhIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0 IGFyZSBkZXBsb3llZCBhdCBkaWZmZXJlbnQgDQo+Pj4+Pj4gcG9pbnRzIHdpdGhpbg0KPj4gdGhl DQo+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEgY29tbW9uIGRlcGxveW1lbnQgbW9kZWwgaGFzIHNl cnZpY2UgZnVuY3Rpb25zIA0KPj4+Pj4+IHBoeXNpY2FsbHkgaW5zZXJ0ZWQgb24gdGhlIGRhdGEg Zm9yd2FyZGluZyBwYXRoIGJldHdlZW4gDQo+Pj4+Pj4gY29tbXVuaWNhdGluZyBwZWVycy4NCj4+ Pj4gR29pbmcNCj4+Pj4+PiBmb3J3YXJkLCBob3dldmVyLCB0aGVyZSBpcyBhIGRlc2lyZSB0byBt b3ZlIHRvIGEgZGlmZmVyZW50IG1vZGVsLA0KPj4+PiB3aGVyZQ0KPj4+Pj4+IHNlcnZpY2UgZnVu Y3Rpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gcmVzaWRlIG9uIHRoZSBkZWZhdWx0IGRhdGENCj4+ IHBhdGgNCj4+Pj4+PiBhbmQNCj4+Pj4+PiB0cmFmZmljIGlzIGluc3RlYWQgc3RlZXJlZCB0aHJv dWdoIHNlcnZpY2VzLCB3aGVyZXZlciB0aGV5IGFyZQ0KPj4+PiBkZXBsb3llZC4NCj4+Pj4+PiAN Cj4+Pj4+PiBGb3IgYSBnaXZlbiBzZXJ2aWNlLCB0aGUgYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSBy ZXF1aXJlZCBzZXJ2aWNlIA0KPj4+Pj4+IGZ1bmN0aW9ucyBhbmQgdGhlIG9yZGVyIGluIHdoaWNo IHRoZXkgYXJlIHRvIGJlIGFwcGxpZWQgaXMgY2FsbGVkIA0KPj4+Pj4+IGEgU2VydmljZSBGdW5j dGlvbiBDaGFpbiAoU0ZDKS4gU2luY2UgYSBnaXZlbiBzZXJ2aWNlIGZ1bmN0aW9uIA0KPj4+Pj4+ IG1heSBiZSBhdmFpbGFibGUgb24gbW9yZSB0aGFuIG9uZSBub2RlIHdpdGhpbiBhIG5ldHdvcmss IGEgDQo+Pj4+Pj4gU2VydmljZSBGdW5jdGlvbiBDaGFpbiBpcyBpbnN0YW50aWF0ZWQNCj4+Pj4g dmlhDQo+Pj4+Pj4gdGhlIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIGlu c3RhbmNlcyBhbmQgdGhlIA0KPj4+Pj4+IG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhleSBhcmUg cHJvdmlkZWQsIHRoZXJlYnkgZm9ybWluZyBhIA0KPj4+Pj4+IHNlcnZpY2UgdG9wb2xvZ3k6DQo+ Pj4+Pj4gdGhpcyBpcyBjYWxsZWQgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNl IGZ1bmN0aW9ucyBtYXkgDQo+Pj4+Pj4gYmUgYXBwbGllZCBhdCBhIHNwZWNpZmljIGxheWVyIHdp dGhpbiB0aGUgbmV0d29yayBwcm90b2NvbCBzdGFjaw0KPj4+PiAobmV0d29yaw0KPj4+Pj4+IGxh eWVyLCBhcHBsaWNhdGlvbiBsYXllciwgZXRjLikuDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgd29ya2luZyBncm91cCB3aWxsIGRldmVsb3AgDQo+ Pj4+Pj4gbmV3IGFwcHJvYWNoZXMgdG8gc2VydmljZSBkZWxpdmVyeSBhbmQgZGVwbG95bWVudC4g SXQgd2lsbCANCj4+Pj4+PiBwcm9kdWNlIGEgZnJhbWV3b3JrIGZvciBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIHRoYXQgaW5jbHVkZXMgDQo+Pj4+Pj4gdGhlIG5lY2Vzc2FyeSBwcm90b2NvbHMN Cj4+Pj4gb3INCj4+Pj4+PiBwcm90b2NvbCBleHRlbnNpb25zIHRvIGNvbnZleSB0aGUgc2Vydmlj ZSBwYXRoIGFuZCBzZXJ2aWNlIHBhdGggDQo+Pj4+Pj4gaW5mb3JtYXRpb24gdG8gbm9kZXMgdGhh dCBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMsIGFzIHdlbGwgYXMgDQo+Pj4+Pj4gbWVjaGFu aXNtcyBmb3Igc3RlZXJpbmcgdHJhZmZpYyB0aHJvdWdoIHNlcnZpY2UgZnVuY3Rpb25zLiBUaGUN Cj4+Pj4gd29ya2luZw0KPj4+Pj4+IGdyb3VwIHdpbGwgYWxzbyBleGFtaW5lIHdoYXQgaW5mb3Jt YXRpb24gbmVlZHMgdG8gYmUgZ2F0aGVyZWQgDQo+Pj4+Pj4gZnJvbQ0KPj4+PiB0aGUNCj4+Pj4+ PiBuZXR3b3JrIGFuZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIHNlcnZpY2UgZnVu Y3Rpb24NCj4+IGNoYWluaW5nDQo+Pj4+Pj4gYW5kDQo+Pj4+Pj4gaG93IHRoYXQgaW5mb3JtYXRp b24gbWF5IGJlIG1hZGUgYXZhaWxhYmxlIHRvIG5vZGVzIHRoYXQgDQo+Pj4+Pj4gaW1wbGVtZW50 DQo+Pj4+IHRoZQ0KPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+IA0KPj4+Pj4+IFNw ZWNpZmljYWxseSwgdGhlIFNGQyBXRyBpcyBjaGFydGVyZWQgdG8gZGVsaXZlciB0aGUgZm9sbG93 aW5nOg0KPj4+Pj4+IA0KPj4+Pj4+IDEpIFByb2JsZW0gU3RhdGVtZW50OiBUaGlzIGRvY3VtZW50 IHdpbGwgcHJvdmlkZSBhIHN1bW1hcnkgb2YgdGhlDQo+Pj4+Pj4gICAgcHJvYmxlbSBzcGFjZSB0 byBiZSBhZGRyZXNzZWQgYnkgdGhlIFdHIGluY2x1ZGluZyBleGFtcGxlIGhpZ2gtDQo+Pj4+Pj4g ICAgbGV2ZWwgdXNlIGNhc2VzLiBBZGRpdGlvbmFsbHksIHRoZSBXRyB3aWxsIG5vcm1hbGl6ZQ0K Pj4gbm9tZW5jbGF0dXJlDQo+Pj4+Pj4gICAgYW5kIGRlZmluaXRpb25zIGZvciBzZXJ2aWNlIGZ1 bmN0aW9uIGNoYWluaW5nLg0KPj4+Pj4+IA0KPj4+Pj4+IDIpIEFyY2hpdGVjdHVyZTogVGhpcyBk b2N1bWVudCB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGUNCj4+Pj4+PiAgICBhcmNo aXRlY3R1cmFsIGJ1aWxkaW5nIGJsb2NrcyBhbmQgdGhlaXIgcmVsYXRpb25zaGlwcyBpbmNsdWRp bmcNCj4+Pj4+PiAgICBpbnRlcmNvbm5lY3Rpb24sIHBsYWNlbWVudCBvZiBjYXBhYmlsaXRpZXMs IG1hbmFnZW1lbnQsDQo+Pj4+Pj4gICAgZGlhZ25vc3RpY3MsIGRlc2lnbiBhbmFseXNpcywgYW5k IHNlY3VyaXR5IG1vZGVscywgYXMgd2VsbCBhcw0KPj4+Pj4+ICAgIHJlcXVpcmVtZW50cyBvbiB0 aGUgcHJvdG9jb2wgbWVjaGFuaXNtcy4NCj4+Pj4+PiANCj4+Pj4+PiAzKSBHZW5lcmljIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSBkb2N1bWVudCB3aWxsDQo+Pj4+ Pj4gICAgZGVzY3JpYmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgZW5jYXBz dWxhdGlvbg0KPj4gZm9ybWF0DQo+Pj4+Pj4gZm9yDQo+Pj4+Pj4gICAgY29udmV5aW5nIHRoZSBz ZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0aGUgc2VydmljZSBmdW5jdGlvbg0KPj4+PiBwYXRo LA0KPj4+Pj4+ICAgIGFuZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJl dHdlZW4gbm9kZXMgdGhhdA0KPj4+Pj4+ICAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4g SXQgaXMgaW50ZW5kZWQgdGhhdCB0aGUNCj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+ICAgIGJl IGFnbm9zdGljIHRvIHRoZSBsYXllciBhdCB3aGljaCBpdCBpcyBhcHBsaWVkIGFuZCB0aGUgDQo+ Pj4+Pj4gc2VydmljZQ0KPj4+PiB0aGF0DQo+Pj4+Pj4gaXMNCj4+Pj4+PiAgICBiZWluZyBjb25z dHJ1Y3RlZC4gVGhhdCBpcywgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiBtYXkgYmUgdXNlZA0KPj4g b24NCj4+Pj4+PiAgICBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0 d29yayBsYXllciBvciBhdCANCj4+Pj4+PiBhbnkgb3RoZXINCj4+Pj4+PiAgICBsYXllciwgYW5k IHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBmb3IgdGhlDQo+PiBjb25zdHJ1Y3Rp b24NCj4+Pj4gb2YNCj4+Pj4+PiAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mg b2YgdGhlIGFjdHVhbCBzZXJ2aWNlLg0KPj4+Pj4+IA0KPj4+Pj4+IDQpIENvbnRyb2wgUGxhbmUg TWVjaGFuaXNtczogQSBzZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUgZGV2ZWxvcGVkIHRvDQo+Pj4+ Pj4gICAgZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbHMgbmVjZXNzYXJ5IHRvIGNv bnZleQ0KPj4+PiBpbmZvcm1hdGlvbg0KPj4+Pj4+ICAgIHRvIHNlcnZpY2UgZnVuY3Rpb24gaW1w bGVtZW50YXRpb24gcG9pbnRzLiBXaGVyZSBwb3NzaWJsZSwNCj4+Pj4gZXhpc3RpbmcNCj4+Pj4+ PiAgICBJRVRGIHByb3RvY29scyB3aWxsIGJlIHVzZWQgYW5kIGV4dGVuZGVkLiBBbGwgcHJvdG9j b2wNCj4+IGV4dGVuc2lvbnMNCj4+Pj4+PiAgICB3b3JrIHNob3VsZCBiZSBjYXJyaWVkIG91dCBp biB0aGUgd29ya2luZyBncm91cHMgcmVzcG9uc2libGUgDQo+Pj4+Pj4gZm9yDQo+Pj4+IHRoZQ0K Pj4+Pj4+ICAgIHByb3RvY29scyBiZWluZyBtb2RpZmllZCBpbiBjb29yZGluYXRpb24gd2l0aCB0 aGlzIHdvcmtpbmcNCj4+IGdyb3VwLA0KPj4+Pj4+IGJ1dA0KPj4+Pj4+ICAgIG1heSBiZSBkb25l IGluIHRoaXMgd29ya2luZyBncm91cCBhZnRlciBhZ3JlZW1lbnQgd2l0aCBhbGwgdGhlDQo+Pj4+ Pj4gICAgcmVsZXZhbnQgV0cgY2hhaXJzIGFuZCByZXNwb25zaWJsZSBBRHMuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gNSkgTWFuYWdlYWJpbGl0eTogV29yayBvbiB0aGUgbWFuYWdlbWVudCBhbmQgY29uZmln dXJhdGlvbiBvZg0KPj4gc2VydmljZQ0KPj4+Pj4+ICAgIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9m IFNGQyBjb21wb25lbnRzIHdpbGwgY2VydGFpbmx5IGJlIG5lZWRlZCwNCj4+Pj4+PiAgICBidXQg Zmlyc3QgbmVlZHMgdG8gYmUgYmV0dGVyIHVuZGVyc3Rvb2QgYW5kIHNjb3BlZC4NCj4+Pj4+PiAN Cj4+Pj4+PiBQcm9wb3NlZCBNaWxlc3RvbmVzDQo+Pj4+Pj4gDQo+Pj4+Pj4gQXByIDIwMTQgU3Vi bWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudChzKSBkZWZpbmluZyB0aGUNCj4+Pj4g cHJvYmxlbQ0KPj4+Pj4+IHN0YXRlbWVudCBhbmQgY29yZSB1c2UgY2FzZXMgZm9yIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcNCj4+Pj4+PiANCj4+Pj4+PiBNYXkgMjAxNCBDb25zdWx0IHdpdGgg T1BTIEFyZWEgb24gcG9zc2libGUgY2hhcnRlciBtb2RpZmljYXRpb25zIA0KPj4+Pj4+IGZvciBt YW5hZ2VtZW50IGFuZCBjb25maWd1cmF0aW9uIG9mIFNGQyBjb21wb25lbnRzDQo+Pj4+Pj4gDQo+ Pj4+Pj4gSmFuIDIwMTUgU3VibWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZWZp bmluZyB0aGUNCj4+Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+Pj4gZm9yIFNGQw0KPj4+Pj4+IA0KPj4+ Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIHJlcXVpcmVtZW50cyBmb3IgYSBnZW5lcmljIHNl cnZpY2UgDQo+Pj4+Pj4gZnVuY3Rpb24gY2hhaW5pbmcgZW5jYXBzdWxhdGlvbiBwcm90b2NvbA0K Pj4+Pj4+IA0KPj4+Pj4+IEF1ZyAyMDE1IFN1Ym1pdCB0byBJRVNHIFN0YW5kYXJkcyBUcmFjayBk b2N1bWVudCBzcGVjaWZ5aW5nIHRoZQ0KPj4+PiBnZW5lcmljDQo+Pj4+Pj4gc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZyBoZWFkZXIgZW5jYXBzdWxhdGlvbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+ Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IFRob21hcw0KPj4+Pj4+IA0KPj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4gbnNj IG1haWxpbmcgbGlzdA0KPj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+ Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+IG5zYyBt YWlsaW5nIGxpc3QNCj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4gDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K From jguichar@cisco.com Tue Nov 12 05:36:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5262D21E80EC for ; Tue, 12 Nov 2013 05:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBd8dSUT995F for ; Tue, 12 Nov 2013 05:36:53 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD2921E8093 for ; Tue, 12 Nov 2013 05:36:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9798; q=dns/txt; s=iport; t=1384263412; x=1385473012; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=3gCuaAK1vQbvF7qPcgHM2GyIpu8ZjJszeTZy5xDgA6k=; b=XOcGiCQnN2kCbNAERHVJfuMNQ7aUGD+pOvl8eJD4xIRAVTfjhIU9JCJD /Nw5DxO86cDAs7JgUgB51aotuacaamsLEd5rh9gN1by4vdk0ksK3IiRH3 ToEq/WDEx/+NOBcypZRB1rguq70EM2wIalpECFZTsb2G4w7mXDEIkaOQD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAIYuglKtJV2Y/2dsb2JhbABZgwc4U78cgSkWdIIlAQEBBAEBATctBwQTBgEIEQEDAQEfCS4LFAMGCAIEAQkJG4dmDb4pBI4gDIE6BoQrA5Qug2GSCoMmgWgBHyI X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283693965" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2013 13:36:45 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACDajuY011112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 13:36:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 07:36:44 -0600 From: "Jim Guichard (jguichar)" To: "Shah, Himanshu" , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAAAcvgIAAfxMA Date: Tue, 12 Nov 2013 13:36:44 +0000 Message-ID: In-Reply-To: <40746B2300A8FC4AB04EE722A593182B6A03BDA9@ONWVEXCHMB04.ciena.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <93993662DA94F8498C6B81696A6F8265@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 13:36:58 -0000 Hi Himanshu, There are actually two things needed for this encapsulation stack to work: 1. Indication in the transport encapsulation that a service header is present. There are several drafts that provide suggested solutions for this. 2. An understanding of the size of the service header; draft-quinn-sfc-nsh proposes a fixed length header. On 11/11/13 8:01 PM, "Shah, Himanshu" wrote: >It appears that within service (chain) header, individual service member >would need either, >offset to original packet or total size of the service chain header so >that service delivery >component can locate the original packet to perform the service. > >Alternately, service proxy function (mentioned by you) at the doorstep, >perform some push/pop action during entry/exit of the service point. > >/himanshu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron >Parker >Sent: Monday, November 11, 2013 7:36 PM >To: Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Sumandra, > >As I understand it, an SFC packet traversing from PDP to SF or from SF to >SF will look like: > >+------------------------+ >| "transport" | >+------------------------+ >| service header | >+------------------------+ >| original IP header | >+------------------------+ >| | original IP payload | >| | >+------------------------+ > >Where service header contains, at a minimum, enough information to allow >the packet to be propagated along the full length of the chain, and >optionally, other metadata that enhances the operation of one or more >service functions. > > And where "transport" could conceivably be any of, but not limited to: > >* Ethernet >* Ethernet + LLC2 >* Ethernet + MPLS >* Ethernet + IP + GRE >* Ethernet + IP +UDP > > >Also, "original" in the diagram above is not meant to imply immutability, >but rather to specify the packet that is propagated from preceding entity >to succeeding entity, prior to encapsulation. > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Sumandra Majee >Sent: Monday, November 11, 2013 6:46 PM >To: Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >[SM] What does it mean by a single service-level encapsulation, a new >encapsulation format > or an ability to select one encapsulation format that fits >the need for a given service chain? > The ability to select a specific encapsulation would be a >management plane decision. > There are quite a few existing encapsulation methods that can >possibly be reused to provide > context information between service nodes. I have seen >mention of GRE, for HTTP based > applications contexts are transferred via headers. > =20 > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Thomas Narten >Sent: Wednesday, November 06, 2013 11:07 AM >To: nsc@ietf.org >Subject: [nsc] Current Proposed SFC charter > >Hi. > >Current charter can be found at >https://datatracker.ietf.org/doc/charter-ietf-sfc/. > >It contains the revised management text as well as updated milestones. > >All known issues have been addressed. If there are any remaining issues, >please speak up! > >Charter charter-ietf-sfc-00-04 > >Networks, servers, storage technologies, and applications, have all >undergone significant change in recent years with the introduction of >virtualization, network overlays, and orchestration. Service delivery is >currently both a technical and organizational challenge that involves >significant modification to the network configuration. >Services are typically implemented by the ordered combination of a number >of service functions that are deployed at different points within the >network. Today, a common deployment model has service functions >physically inserted on the data forwarding path between communicating >peers. Going forward, however, there is a desire to move to a different >model, where service functions are not required to reside on the default >data path and traffic is instead steered through services, wherever they >are deployed.=20 > >For a given service, the abstracted view of the required service >functions and the order in which they are to be applied is called a >Service Function Chain (SFC). Since a given service function may be >available on more than one node within a network, a Service Function >Chain is instantiated via the selection of specific service function >instances and the network nodes on which they are provided, thereby >forming a service topology: >this is called a Service Function Path. The service functions may be >applied at a specific layer within the network protocol stack (network >layer, application layer, etc.). > >The Service Function Chaining (SFC) working group will develop new >approaches to service delivery and deployment. It will produce a >framework for service function chaining that includes the necessary >protocols or protocol extensions to convey the service path and service >path information to nodes that implement service functions, as well as >mechanisms for steering traffic through service functions. The working >group will also examine what information needs to be gathered from the >network and service functions in support of service function chaining and >how that information may be made available to nodes that implement the >service functions. > >Specifically, the SFC WG is chartered to deliver the following: > >1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high- > level use cases. Additionally, the WG will normalize nomenclature > and definitions for service function chaining. > >2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. > >3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information > to service function implementation points. Where possible, existing > IETF protocols will be used and extended. All protocol extensions > work should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. > >5) Manageability: Work on the management and configuration of service > functions in support of SFC components will certainly be needed, > but first needs to be better understood and scoped. > =20 >Proposed Milestones > >Apr 2014 Submit to IESG Informational document(s) defining the problem >statement and core use cases for Service Function Chaining > >May 2014 Consult with OPS Area on possible charter modifications for >management and configuration of SFC components > >Jan 2015 Submit to IESG Informational document defining the architecture >for SFC > >Jan 2015 Submit to IESG requirements for a generic service function >chaining encapsulation protocol > >Aug 2015 Submit to IESG Standards Track document specifying the generic >service function chaining header encapsulation > > > > > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 05:52:53 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83A411E8143 for ; Tue, 12 Nov 2013 05:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.55 X-Spam-Level: X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E44JW4cHfH0l for ; Tue, 12 Nov 2013 05:52:49 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D4D9C11E8140 for ; Tue, 12 Nov 2013 05:52:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11217; q=dns/txt; s=iport; t=1384264368; x=1385473968; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fnjVTGkaAbWr3LRz9kEdGLZPcmsZ9izYyXbvSPMykO4=; b=DkG7eHUqWFXqYhXWDGyXfoX13/LbLo5u2H1UN/CsbHTiji14cS46ByqS OQY/DypiX9ETvxUiXMU4GNtb4zDCz7sGyOxDsrlH/GJYfoH8m/O56inkf X0hys20T4lgTKBXWIWFrFX3ihFSeH3WIgCbJaOZhxubqzqZOane2A354H c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGExglKtJXHA/2dsb2JhbABPCoMHOFO/G4EnFnSCJQEBAQQBAQFkBwQTBgEIDgMBAwEBKC4LFAMGCAIEAQkJiAENviUEjhwEDIEIMgIEhCsDiQqLJINhkgqDJoFoAR8i X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="280689765" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2013 13:52:47 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACDqlg6019628 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 13:52:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 07:52:47 -0600 From: "Jim Guichard (jguichar)" To: Sumandra Majee , Ron Parker , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAF/iAA== Date: Tue, 12 Nov 2013 13:52:47 +0000 Message-ID: In-Reply-To: <0BF7E0211CA62B42AE3FD4020E41609884914148@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 13:52:54 -0000 Hi Sumandra, On 11/11/13 10:09 PM, "Sumandra Majee" wrote: >Ron, > >Absolutely, that was an example of one type of derivation. However this >could be augmented with classification result, again one more example. > >>>All flows from the same source IP do not necessarily follow the same >>>chain. =20 >Correct. It is also not necessary that all transaction of the same flow >follow the same chain either. So why stop at flow itself. > >Again the point here is that do we always need SFC header or Not. Jim> we are perhaps getting a little ahead of ourselves as part of the WG's job will be to define the SFC header and its applicability to service chaining. As has been pointed out several times there are existing methods for applying service chains and if those satisfy your requirements then that=B9s fine. Having said that, I believe there are many use cases being presented that are either extremely difficult, if not impossible, to realize using existing methods and that is why SFC was spawned to try and address those.=20 > >Sumandra > > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Monday, November 11, 2013 7:02 PM >To: Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: RE: [nsc] Current Proposed SFC charter > >Sumandra, > >The intention of service function chaining is to allow for operation at >the fully qualified flow level, or even finer grained at the transaction >level (this is an implementation matter for the PDP). All flows from >the same source IP do not necessarily follow the same chain. Source IP, >therefore, does not identify the chain ID. Another intention of >service function chaining is to operate over any network topology and not >be limited to a single LAN. Thus, while VLAN may be part of the >transport, it does not adequately identify the service chain, either. > > Ron > > >-----Original Message----- >From: Sumandra Majee [mailto:S.Majee@F5.com] >Sent: Monday, November 11, 2013 9:56 PM >To: Ron Parker; Thomas Narten; nsc@ietf.org >Subject: RE: [nsc] Current Proposed SFC charter > >Ron, > >The service header is meant to carry the context which can *also* be >derived (for example use source ip and vlan to identify chainID and >position) or encapsulated as part of another tunnel header. So this could >be optional IMHO.=20 > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Monday, November 11, 2013 4:36 PM >To: Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: RE: [nsc] Current Proposed SFC charter > >Sumandra, > >As I understand it, an SFC packet traversing from PDP to SF or from SF to >SF will look like: > >+------------------------+ >| "transport" | >+------------------------+ >| service header | >+------------------------+ >| original IP header | >+------------------------+ >| | original IP payload | >| | >+------------------------+ > >Where service header contains, at a minimum, enough information to allow >the packet to be propagated along the full length of the chain, and >optionally, other metadata that enhances the operation of one or more >service functions. > > And where "transport" could conceivably be any of, but not limited to: > >* Ethernet >* Ethernet + LLC2 >* Ethernet + MPLS >* Ethernet + IP + GRE >* Ethernet + IP +UDP > > >Also, "original" in the diagram above is not meant to imply immutability, >but rather to specify the packet that is propagated from preceding entity >to succeeding entity, prior to encapsulation. > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Sumandra Majee >Sent: Monday, November 11, 2013 6:46 PM >To: Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >[SM] What does it mean by a single service-level encapsulation, a new >encapsulation format > or an ability to select one encapsulation format that fits >the need for a given service chain? > The ability to select a specific encapsulation would be a >management plane decision. > There are quite a few existing encapsulation methods that can >possibly be reused to provide > context information between service nodes. I have seen >mention of GRE, for HTTP based > applications contexts are transferred via headers. > =20 > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Thomas Narten >Sent: Wednesday, November 06, 2013 11:07 AM >To: nsc@ietf.org >Subject: [nsc] Current Proposed SFC charter > >Hi. > >Current charter can be found at >https://datatracker.ietf.org/doc/charter-ietf-sfc/. > >It contains the revised management text as well as updated milestones. > >All known issues have been addressed. If there are any remaining issues, >please speak up! > >Charter charter-ietf-sfc-00-04 > >Networks, servers, storage technologies, and applications, have all >undergone significant change in recent years with the introduction of >virtualization, network overlays, and orchestration. Service delivery is >currently both a technical and organizational challenge that involves >significant modification to the network configuration. >Services are typically implemented by the ordered combination of a number >of service functions that are deployed at different points within the >network. Today, a common deployment model has service functions >physically inserted on the data forwarding path between communicating >peers. Going forward, however, there is a desire to move to a different >model, where service functions are not required to reside on the default >data path and traffic is instead steered through services, wherever they >are deployed.=20 > >For a given service, the abstracted view of the required service >functions and the order in which they are to be applied is called a >Service Function Chain (SFC). Since a given service function may be >available on more than one node within a network, a Service Function >Chain is instantiated via the selection of specific service function >instances and the network nodes on which they are provided, thereby >forming a service topology: >this is called a Service Function Path. The service functions may be >applied at a specific layer within the network protocol stack (network >layer, application layer, etc.). > >The Service Function Chaining (SFC) working group will develop new >approaches to service delivery and deployment. It will produce a >framework for service function chaining that includes the necessary >protocols or protocol extensions to convey the service path and service >path information to nodes that implement service functions, as well as >mechanisms for steering traffic through service functions. The working >group will also examine what information needs to be gathered from the >network and service functions in support of service function chaining and >how that information may be made available to nodes that implement the >service functions. > >Specifically, the SFC WG is chartered to deliver the following: > >1) Problem Statement: This document will provide a summary of the > problem space to be addressed by the WG including example high- > level use cases. Additionally, the WG will normalize nomenclature > and definitions for service function chaining. > >2) Architecture: This document will provide a description of the > architectural building blocks and their relationships including > interconnection, placement of capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. > >3) Generic Service Function Chaining Encapsulation: A document will > describe the single service-level data plane encapsulation format for > conveying the service function chain and the service function path, > and for communicating context information between nodes that > implement service functions. It is intended that the encapsulation > be agnostic to the layer at which it is applied and the service that >is > being constructed. That is, the same encapsulation may be used on > a service function path realized at the network layer or at any other > layer, and the same encapsulation will apply for the construction of > service function paths regardless of the actual service. > >4) Control Plane Mechanisms: A set of documents will be developed to > describe requirements and protocols necessary to convey information > to service function implementation points. Where possible, existing > IETF protocols will be used and extended. All protocol extensions > work should be carried out in the working groups responsible for the > protocols being modified in coordination with this working group, but > may be done in this working group after agreement with all the > relevant WG chairs and responsible ADs. > >5) Manageability: Work on the management and configuration of service > functions in support of SFC components will certainly be needed, > but first needs to be better understood and scoped. > =20 >Proposed Milestones > >Apr 2014 Submit to IESG Informational document(s) defining the problem >statement and core use cases for Service Function Chaining > >May 2014 Consult with OPS Area on possible charter modifications for >management and configuration of SFC components > >Jan 2015 Submit to IESG Informational document defining the architecture >for SFC > >Jan 2015 Submit to IESG requirements for a generic service function >chaining encapsulation protocol > >Aug 2015 Submit to IESG Standards Track document specifying the generic >service function chaining header encapsulation > > > > > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 05:58:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48B011E815C for ; Tue, 12 Nov 2013 05:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.554 X-Spam-Level: X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fI5ZXbnbMUTa for ; Tue, 12 Nov 2013 05:57:56 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3C711E8159 for ; Tue, 12 Nov 2013 05:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16584; q=dns/txt; s=iport; t=1384264674; x=1385474274; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=6pmKAYxSpt/LPxwiOtp09GnsvZ5/T/DZ1mvtr8vDA74=; b=E6GvOFEiZgjRvAYcC77eKWch0DrgMrmVgdWFxdom8jzGndTRqXfadYuV 9O145ucQtefBqdO6rzzR5ZdmbML18C0s1nQLXMyhLGexuelsRShFIha27 GgSantBgEfJB9lfQpvJEkla1XSWJbdtYDFzn5vh2V2eAyTYNWfF1ujkio 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAAwzglKtJXHA/2dsb2JhbABPCoMHOFO/G4EnFnSCJQEBAQMBAQEBNy0HBBMGAQgRAQMBAR8JLgsUAwYIAgQBCQmHewYNvh4EjhwEDIE6BoQrA5Qug2GSCoMmgWgBHyI X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283769721" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 12 Nov 2013 13:57:52 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACDvp94026385 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 13:57:51 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 07:57:51 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAACHoCAAASVgIAAU/QA Date: Tue, 12 Nov 2013 13:57:50 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F77@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 13:58:01 -0000 Hi Kevin, Classification was not discussed in detail during the BOF. Minutes were taken and will be posted soon (I am waiting on one of the scribes to send their inputs before correlating into a single set of minutes).=20 On 11/11/13 10:57 PM, "Kevin J Ma" wrote: >> the overall design implications of the classifier supporting the >>protocols >> and techniques you describe below could make for an interesting I-D :). > >I agree, but I guess I'll take that as a no, on whether it was discussed? > >It's hard to evaluate the utility of the service function identifier >without >a better understanding of how the classification works, how the servicce >chains >are defined, and what the overhead is in doing lookups based on the >service >function identifier, as opposed to reuseable classification info, >especially >where TCP/HTTP/TLS level termination is involved. > >Note: I did not see any minutes posted yet from the BoF? Were hums taken? > I'd be interested in knowing the outcome before thinking about >I-Ds. ;-P > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, November 11, 2013 10:41 PM >> To: Kevin J Ma; Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Hi, Kevin. >> >> I agree that the classifier should not be constrained. While a full >> specification of the classifier seems beyond scope to me, a discussion >>of >> the overall design implications of the classifier supporting the >>protocols >> and techniques you describe below could make for an interesting I-D :). >> >> Ron >> >> >> -----Original Message----- >> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> Sent: Monday, November 11, 2013 10:33 PM >> To: Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Hi Ron, >> >> I was unable to make the SFC BoF due to a conflict with CDNI, but I >> had a similar question wrt bullet 11 in section 2 of the problem >> statement: >> >> 11. Per-Service (re)Classification: Classification occurs at each >> service, independent from previously applied service functions. >> These unrelated classification events consume resources per >> service. More importantly, the classification functionality >> often differs per service function and service function cannot >> leverage the results from other deployed network or service. >> >> as it relates to section 5.2 of the framework document: >> >> The SFC Classifier classifies packets based on (some of) the >>contents >> of the packet header. Concretely, it classifies packets based on >>the >> possible combination of one or more header fields, such as source >> address, destination address, DS field, protocol ID, source port and >> destination port numbers, and any other information. >> >> A packet-based classifier as described in the framework document would >> seem to be limited in what it can classify? The service function >> identifier lookup does not seem to be a significant optimization over >> a packet-based 5-tuple lookup? There seems to be some missing detail >> wrt how classification information is determined and reused? >> >> When thinking about higher level services, e.g., HTTP and TLS >>encrypted >> flows, a packet-based classifier seems inadequate? I was also >>wondering >> how independent HLS segment requests might be classified and >>associated? >> Were these types of use cases discussed in the BoF? >> >> thanx. >> >> -- Kevin J. Ma >> >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> > Ron Parker >> > Sent: Monday, November 11, 2013 10:16 PM >> > To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Sumandra, >> > >> > As was discussed in Vancouver, there are already many existing ways to >> > accomplish service chaining. But none of them provide a sufficient >> > combination of interoperability, flexibility, and resiliency. A >>single >> > service chain encapsulation will go a long way to ensuring these >>goals. >> > It may not be the absolutely most efficient approach for every single >> > network topology and every single use case, but its ubiquitous nature >> > should improve its adoption. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: Sumandra Majee [mailto:S.Majee@F5.com] >> > Sent: Monday, November 11, 2013 10:10 PM >> > To: Ron Parker; Thomas Narten; nsc@ietf.org >> > Subject: RE: [nsc] Current Proposed SFC charter >> > >> > Ron, >> > >> > Absolutely, that was an example of one type of derivation. However >> > this could be augmented with classification result, again one more >> example. >> > >> > >>All flows from the same source IP do not necessarily follow the same >> > chain. >> > Correct. It is also not necessary that all transaction of the same >> > flow follow the same chain either. So why stop at flow itself. >> > >> > Again the point here is that do we always need SFC header or Not. >> > >> > Sumandra >> > >> > >> > -----Original Message----- >> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > Sent: Monday, November 11, 2013 7:02 PM >> > To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > Subject: RE: [nsc] Current Proposed SFC charter >> > >> > Sumandra, >> > >> > The intention of service function chaining is to allow for operation >> > at the fully qualified flow level, or even finer grained at the >> transaction >> > level (this is an implementation matter for the PDP). All flows >>from >> > the same source IP do not necessarily follow the same chain. Source >> IP, >> > therefore, does not identify the chain ID. Another intention of >> > service function chaining is to operate over any network topology and >> not >> > be limited to a single LAN. Thus, while VLAN may be part of the >> > transport, it does not adequately identify the service chain, either. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: Sumandra Majee [mailto:S.Majee@F5.com] >> > Sent: Monday, November 11, 2013 9:56 PM >> > To: Ron Parker; Thomas Narten; nsc@ietf.org >> > Subject: RE: [nsc] Current Proposed SFC charter >> > >> > Ron, >> > >> > The service header is meant to carry the context which can *also* be >> > derived (for example use source ip and vlan to identify chainID and >> > position) or encapsulated as part of another tunnel header. So this >> > could be optional IMHO. >> > >> > -----Original Message----- >> > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > Sent: Monday, November 11, 2013 4:36 PM >> > To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > Subject: RE: [nsc] Current Proposed SFC charter >> > >> > Sumandra, >> > >> > As I understand it, an SFC packet traversing from PDP to SF or from SF >> > to SF will look like: >> > >> > +------------------------+ >> > | "transport" | >> > +------------------------+ >> > | service header | >> > +------------------------+ >> > | original IP header | >> > +------------------------+ >> > | | original IP payload | >> > | | >> > +------------------------+ >> > >> > Where service header contains, at a minimum, enough information to >> > allow the packet to be propagated along the full length of the chain, >> > and optionally, other metadata that enhances the operation of one or >> > more service functions. >> > >> > And where "transport" could conceivably be any of, but not limited >>to: >> > >> > * Ethernet >> > * Ethernet + LLC2 >> > * Ethernet + MPLS >> > * Ethernet + IP + GRE >> > * Ethernet + IP +UDP >> > >> > >> > Also, "original" in the diagram above is not meant to imply >> > immutability, but rather to specify the packet that is propagated from >> > preceding entity to succeeding entity, prior to encapsulation. >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> > Sumandra Majee >> > Sent: Monday, November 11, 2013 6:46 PM >> > To: Thomas Narten; nsc@ietf.org >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Generic Service Function Chaining Encapsulation: A document will >> > describe the single service-level data plane encapsulation format >> for >> > conveying the service function chain and the service function >>path, >> > and for communicating context information between nodes that >> > implement service functions. It is intended that the encapsulation >> > be agnostic to the layer at which it is applied and the service >> > that is >> > being constructed. That is, the same encapsulation may be used on >> > a service function path realized at the network layer or at any >> other >> > layer, and the same encapsulation will apply for the construction >>of >> > service function paths regardless of the actual service. >> > >> > [SM] What does it mean by a single service-level encapsulation, a new >> > encapsulation format >> > or an ability to select one encapsulation format that fits >> > the need for a given service chain? >> > The ability to select a specific encapsulation would be a >> > management plane decision. >> > There are quite a few existing encapsulation methods that >> > can possibly be reused to provide >> > context information between service nodes. I have seen >> mention >> > of GRE, for HTTP based >> > applications contexts are transferred via headers. >> > >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> > Thomas Narten >> > Sent: Wednesday, November 06, 2013 11:07 AM >> > To: nsc@ietf.org >> > Subject: [nsc] Current Proposed SFC charter >> > >> > Hi. >> > >> > Current charter can be found at >> > https://datatracker.ietf.org/doc/charter- >> > ietf-sfc/. >> > >> > It contains the revised management text as well as updated milestones. >> > >> > All known issues have been addressed. If there are any remaining >> > issues, please speak up! >> > >> > Charter charter-ietf-sfc-00-04 >> > >> > Networks, servers, storage technologies, and applications, have all >> > undergone significant change in recent years with the introduction of >> > virtualization, network overlays, and orchestration. Service delivery >> > is currently both a technical and organizational challenge that >> > involves significant modification to the network configuration. >> > Services are typically implemented by the ordered combination of a >> > number of service functions that are deployed at different points >> > within the network. Today, a common deployment model has service >> > functions physically inserted on the data forwarding path between >> > communicating peers. Going forward, however, there is a desire to move >> > to a different model, where service functions are not required to >> > reside on the default data path and traffic is instead steered through >> services, wherever they are deployed. >> > >> > For a given service, the abstracted view of the required service >> > functions and the order in which they are to be applied is called a >> > Service Function Chain (SFC). Since a given service function may be >> > available on more than one node within a network, a Service Function >> > Chain is instantiated via the selection of specific service function >> > instances and the network nodes on which they are provided, thereby >> forming a service topology: >> > this is called a Service Function Path. The service functions may be >> > applied at a specific layer within the network protocol stack (network >> > layer, application layer, etc.). >> > >> > The Service Function Chaining (SFC) working group will develop new >> > approaches to service delivery and deployment. It will produce a >> > framework for service function chaining that includes the necessary >> > protocols or protocol extensions to convey the service path and >> > service path information to nodes that implement service functions, as >> > well as mechanisms for steering traffic through service functions. The >> > working group will also examine what information needs to be gathered >> > from the network and service functions in support of service function >> > chaining and how that information may be made available to nodes that >> > implement the service functions. >> > >> > Specifically, the SFC WG is chartered to deliver the following: >> > >> > 1) Problem Statement: This document will provide a summary of the >> > problem space to be addressed by the WG including example high- >> > level use cases. Additionally, the WG will normalize nomenclature >> > and definitions for service function chaining. >> > >> > 2) Architecture: This document will provide a description of the >> > architectural building blocks and their relationships including >> > interconnection, placement of capabilities, management, >> > diagnostics, design analysis, and security models, as well as >> > requirements on the protocol mechanisms. >> > >> > 3) Generic Service Function Chaining Encapsulation: A document will >> > describe the single service-level data plane encapsulation format >> for >> > conveying the service function chain and the service function >>path, >> > and for communicating context information between nodes that >> > implement service functions. It is intended that the encapsulation >> > be agnostic to the layer at which it is applied and the service >> > that is >> > being constructed. That is, the same encapsulation may be used on >> > a service function path realized at the network layer or at any >> other >> > layer, and the same encapsulation will apply for the construction >>of >> > service function paths regardless of the actual service. >> > >> > 4) Control Plane Mechanisms: A set of documents will be developed to >> > describe requirements and protocols necessary to convey >>information >> > to service function implementation points. Where possible, >>existing >> > IETF protocols will be used and extended. All protocol extensions >> > work should be carried out in the working groups responsible for >>the >> > protocols being modified in coordination with this working group, >> but >> > may be done in this working group after agreement with all the >> > relevant WG chairs and responsible ADs. >> > >> > 5) Manageability: Work on the management and configuration of service >> > functions in support of SFC components will certainly be needed, >> > but first needs to be better understood and scoped. >> > >> > Proposed Milestones >> > >> > Apr 2014 Submit to IESG Informational document(s) defining the problem >> > statement and core use cases for Service Function Chaining >> > >> > May 2014 Consult with OPS Area on possible charter modifications for >> > management and configuration of SFC components >> > >> > Jan 2015 Submit to IESG Informational document defining the >> > architecture for SFC >> > >> > Jan 2015 Submit to IESG requirements for a generic service function >> > chaining encapsulation protocol >> > >> > Aug 2015 Submit to IESG Standards Track document specifying the >> > generic service function chaining header encapsulation >> > >> > >> > >> > >> > >> > Thomas >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 06:07:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA89521E8124 for ; Tue, 12 Nov 2013 06:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+gS4oN2Dg5V for ; Tue, 12 Nov 2013 06:07:14 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7AA11E8140 for ; Tue, 12 Nov 2013 06:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21744; q=dns/txt; s=iport; t=1384265231; x=1385474831; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=SaWLXuBkpwEPdFhddfAOJTTqojZM/jyjN95vZf9aaI4=; b=T8CqyWfV9/treN9VlZZ7PeIOvWl4M7epgCqprlcmWqXCiyaMr/xcxOpW elVqvgBOSY0//mRLyTmL86xq4Avl39jN233xkGHo3ql8ue5h+0Jin4pLw nx/RS2VHwqtNz9mgkajrukMd2u1D3w0yZbIS4EQMbCKJfC9Bz+O+MFcwz A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAFk1glKtJV2c/2dsb2JhbABPCoMHOFO/G4EnFnSCJQEBAQMBAQEBFw0TKwIHBBMGAQgRAQMBAQEVCQkuCxQDBggCBAEJCQkSh2AGDb4pjhwEBgaBCC0FAgQEhCcDlC6DYZIKgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283716507" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2013 14:07:09 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACE79d5015745 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 14:07:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 08:07:08 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , "Sumandra Majee" , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAA== Date: Tue, 12 Nov 2013 14:07:08 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <5B14BD668636BE41959160EBB1FD255F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:07:18 -0000 Hi Kevin, Let me try and provide a concrete example to see if this answers your specific question: Use case: P-GW -> PCRF -> services applied to traffic based on applicationID and subscriberID. Instantiated as: SFC1: P-GW -> DPI -> PCRF SFC2: PCRF -> video-optimization -> metering -> FW SFC3: PCRF -> parental-control -> metering -> FW In this case DPI is performed on SFC1 and identifies applicationID. The applicationID is carried in the service encapsulation to PCRF. PCRF uses solution specific logic (identifies subscriber, applies policies, etc) and uses the result along with the applicationID received from DPI to select an outbound service chain, SFC2 or SFC3. Note that in this case branching occurs from SFC1 to either SFC2 or SFC3. On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >> Yes, reclassification can change the service path and >> re-classification may happen at any node along a service path. > >Just to expand on that, going back to the original question about >service header encapsulation, is it intended that a chain that >is re-classified will get a new chain ID which fully describes >a chain that is a superset of the original chain ID, prior to >DPI-based re-classification? (assuming the goal is "a single >chain ID that is commonly understood along the entire service chain" >http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >And the applicable subset of the permutative list of service >paths would be configured at each appropriate service node? >e.g., ID 1: NAT + firewall + DPI > ID 2: NAT + firewall + DPI + AV > ID 3: NAT + firewall + DPI + AV + NAT > ID 4: NAT + firewall + DPI + NAT > ID 5: NAT + firewall + DPI + AV + LB > ID 6: NAT + firewall + DPI + LB > ID 7: NAT + firewall + DPI + LB + CACHE > ID 8: NAT + firewall + DPI + CACHE > ID 9: NAT + firewall + DPI + optimizer + LB > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > ID 11: NAT + firewall + DPI + optimizer + CACHE >Would every flow then be initially classified as ID 1, but >eventually get re-classified to ID 2-11, after the DPI phase? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> Sent: Tuesday, November 12, 2013 1:01 AM >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >> >> >Hi Surendra, >> > >> > Classification may be out of scope, but the level of service that is >> > applicable is dependent upon the level of classification that can be >> > performed. An assumption of packet level encapsulation has >> implications >> > on the level of classification being performed? If the stated goals >> are >> > for firewall and load balancer functionality, then the application >> level >> > nature of those functions needs to be taken into account? If, on the >> > other hand, the service function scope is limited due to limitations >>in >> > classification, that would be and important piece of information? >> > >> > Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>points >> > of the service paths seem like re-classification points? Is that the >> > interpretation from the architecture perspective? Or is the service >> > function chain classification exclusive of DPI functionality? >> I have not fully read that draft yet. But in general, as described >>in >> the arch draft, the collection of services form a graph, segments of >>which >> are service paths. Yes, reclassification can change the service path and >> re-classification may happen at any node along a service path. >> >> Surendra. >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> Sent: Tuesday, November 12, 2013 12:08 AM >> >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>nsc@ietf.org >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> Kevin, >> >> >> >> Classification mechanism is outside the scope of SFC. It can be based >> on >> >> the packet or information not in the packet(environmental attributes >> for >> >> instance) or a combination thereof. What is important is that such >> >> classification aids in traffic selection and service path >> >>identification. >> >> It is no different from a policy in this regard except that the >>policy >> >>now >> >> specifies the service path. >> >> Further, classification is not limited to the network elements but >>the >> >> service functions as well. Some of this is described in the >> architecture >> >> drafts as well - >> >>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> >> >> Surendra. >> >> >> >> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >> >> >> >> >Hi Ron, >> >> > >> >> > I was unable to make the SFC BoF due to a conflict with CDNI, but >>I >> >> > had a similar question wrt bullet 11 in section 2 of the problem >> >> >statement: >> >> > >> >> > 11. Per-Service (re)Classification: Classification occurs at >>each >> >> > service, independent from previously applied service >> >>functions. >> >> > These unrelated classification events consume resources per >> >> > service. More importantly, the classification >>functionality >> >> > often differs per service function and service function >> cannot >> >> > leverage the results from other deployed network or >>service. >> >> > >> >> > as it relates to section 5.2 of the framework document: >> >> > >> >> > The SFC Classifier classifies packets based on (some of) the >> >>contents >> >> > of the packet header. Concretely, it classifies packets based >>on >> >>the >> >> > possible combination of one or more header fields, such as >>source >> >> > address, destination address, DS field, protocol ID, source port >> >>and >> >> > destination port numbers, and any other information. >> >> > >> >> > A packet-based classifier as described in the framework document >> >>would >> >> > seem to be limited in what it can classify? The service function >> >> > identifier lookup does not seem to be a significant optimization >> over >> >> > a packet-based 5-tuple lookup? There seems to be some missing >> detail >> >> > wrt how classification information is determined and reused? >> >> > >> >> > When thinking about higher level services, e.g., HTTP and TLS >> >>encrypted >> >> > flows, a packet-based classifier seems inadequate? I was also >> >> wondering >> >> > how independent HLS segment requests might be classified and >> >> associated? >> >> > Were these types of use cases discussed in the BoF? >> >> > >> >> >thanx. >> >> > >> >> >-- Kevin J. Ma >> >> > >> >> >> -----Original Message----- >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> >>Ron >> >> >> Parker >> >> >> Sent: Monday, November 11, 2013 10:16 PM >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> As was discussed in Vancouver, there are already many existing >>ways >> >>to >> >> >> accomplish service chaining. But none of them provide a >> >>sufficient >> >> >> combination of interoperability, flexibility, and resiliency. A >> >> single >> >> >> service chain encapsulation will go a long way to ensuring these >> >>goals. >> >> >> It may not be the absolutely most efficient approach for every >> >>single >> >> >> network topology and every single use case, but its ubiquitous >> nature >> >> >> should improve its adoption. >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> >> Sent: Monday, November 11, 2013 10:10 PM >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Ron, >> >> >> >> >> >> Absolutely, that was an example of one type of derivation. However >> >>this >> >> >> could be augmented with classification result, again one more >> >>example. >> >> >> >> >> >> >>All flows from the same source IP do not necessarily follow the >> >>same >> >> >> chain. >> >> >> Correct. It is also not necessary that all transaction of the same >> >>flow >> >> >> follow the same chain either. So why stop at flow itself. >> >> >> >> >> >> Again the point here is that do we always need SFC header or Not. >> >> >> >> >> >> Sumandra >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> >> Sent: Monday, November 11, 2013 7:02 PM >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> The intention of service function chaining is to allow for >>operation >> >>at >> >> >> the fully qualified flow level, or even finer grained at the >> >> transaction >> >> >> level (this is an implementation matter for the PDP). All >>flows >> >> from >> >> >> the same source IP do not necessarily follow the same chain. >> Source >> >> >>IP, >> >> >> therefore, does not identify the chain ID. Another intention >>of >> >> >> service function chaining is to operate over any network topology >> and >> >> >>not >> >> >> be limited to a single LAN. Thus, while VLAN may be part of the >> >> >> transport, it does not adequately identify the service chain, >> either. >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> >> Sent: Monday, November 11, 2013 9:56 PM >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Ron, >> >> >> >> >> >> The service header is meant to carry the context which can *also* >>be >> >> >> derived (for example use source ip and vlan to identify chainID >>and >> >> >> position) or encapsulated as part of another tunnel header. So >>this >> >> >>could >> >> >> be optional IMHO. >> >> >> >> >> >> -----Original Message----- >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> >> Sent: Monday, November 11, 2013 4:36 PM >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> As I understand it, an SFC packet traversing from PDP to SF or >>from >> >>SF >> >> >>to >> >> >> SF will look like: >> >> >> >> >> >> +------------------------+ >> >> >> | "transport" | >> >> >> +------------------------+ >> >> >> | service header | >> >> >> +------------------------+ >> >> >> | original IP header | >> >> >> +------------------------+ >> >> >> | | original IP payload >>| >> >> >> | | >> >> >> +------------------------+ >> >> >> >> >> >> Where service header contains, at a minimum, enough information to >> >> allow >> >> >> the packet to be propagated along the full length of the chain, >>and >> >> >> optionally, other metadata that enhances the operation of one or >> more >> >> >> service functions. >> >> >> >> >> >> And where "transport" could conceivably be any of, but not >>limited >> >>to: >> >> >> >> >> >> * Ethernet >> >> >> * Ethernet + LLC2 >> >> >> * Ethernet + MPLS >> >> >> * Ethernet + IP + GRE >> >> >> * Ethernet + IP +UDP >> >> >> >> >> >> >> >> >> Also, "original" in the diagram above is not meant to imply >> >> >>immutability, >> >> >> but rather to specify the packet that is propagated from preceding >> >> >>entity >> >> >> to succeeding entity, prior to encapsulation. >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> >> Sumandra Majee >> >> >> Sent: Monday, November 11, 2013 6:46 PM >> >> >> To: Thomas Narten; nsc@ietf.org >> >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Generic Service Function Chaining Encapsulation: A document will >> >> >> describe the single service-level data plane encapsulation >> format >> >> >>for >> >> >> conveying the service function chain and the service function >> >>path, >> >> >> and for communicating context information between nodes that >> >> >> implement service functions. It is intended that the >> >>encapsulation >> >> >> be agnostic to the layer at which it is applied and the >>service >> >> that >> >> >> is >> >> >> being constructed. That is, the same encapsulation may be used >> on >> >> >> a service function path realized at the network layer or at >>any >> >> >>other >> >> >> layer, and the same encapsulation will apply for the >> construction >> >> of >> >> >> service function paths regardless of the actual service. >> >> >> >> >> >> [SM] What does it mean by a single service-level encapsulation, a >> >>new >> >> >> encapsulation format >> >> >> or an ability to select one encapsulation format that >> >>fits >> >> >>the >> >> >> need for a given service chain? >> >> >> The ability to select a specific encapsulation would >>be >> a >> >> >> management plane decision. >> >> >> There are quite a few existing encapsulation methods >>that >> >>can >> >> >> possibly be reused to provide >> >> >> context information between service nodes. I have seen >> >> >>mention >> >> >> of GRE, for HTTP based >> >> >> applications contexts are transferred via headers. >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> >> >> Thomas Narten >> >> >> Sent: Wednesday, November 06, 2013 11:07 AM >> >> >> To: nsc@ietf.org >> >> >> Subject: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Hi. >> >> >> >> >> >> Current charter can be found at >> >> >>https://datatracker.ietf.org/doc/charter- >> >> >> ietf-sfc/. >> >> >> >> >> >> It contains the revised management text as well as updated >> >>milestones. >> >> >> >> >> >> All known issues have been addressed. If there are any remaining >> >> issues, >> >> >> please speak up! >> >> >> >> >> >> Charter charter-ietf-sfc-00-04 >> >> >> >> >> >> Networks, servers, storage technologies, and applications, have >>all >> >> >> undergone significant change in recent years with the introduction >> of >> >> >> virtualization, network overlays, and orchestration. Service >> delivery >> >> is >> >> >> currently both a technical and organizational challenge that >> involves >> >> >> significant modification to the network configuration. >> >> >> Services are typically implemented by the ordered combination of a >> >> >>number >> >> >> of service functions that are deployed at different points within >> the >> >> >> network. Today, a common deployment model has service functions >> >> >>physically >> >> >> inserted on the data forwarding path between communicating peers. >> >>Going >> >> >> forward, however, there is a desire to move to a different model, >> >>where >> >> >> service functions are not required to reside on the default data >> path >> >> >>and >> >> >> traffic is instead steered through services, wherever they are >> >> deployed. >> >> >> >> >> >> For a given service, the abstracted view of the required service >> >> >>functions >> >> >> and the order in which they are to be applied is called a Service >> >> >>Function >> >> >> Chain (SFC). Since a given service function may be available on >>more >> >> >>than >> >> >> one node within a network, a Service Function Chain is >>instantiated >> >>via >> >> >> the selection of specific service function instances and the >>network >> >> >>nodes >> >> >> on which they are provided, thereby forming a service topology: >> >> >> this is called a Service Function Path. The service functions may >>be >> >> >> applied at a specific layer within the network protocol stack >> >>(network >> >> >> layer, application layer, etc.). >> >> >> >> >> >> The Service Function Chaining (SFC) working group will develop new >> >> >> approaches to service delivery and deployment. It will produce a >> >> >>framework >> >> >> for service function chaining that includes the necessary >>protocols >> >>or >> >> >> protocol extensions to convey the service path and service path >> >> >> information to nodes that implement service functions, as well as >> >> >> mechanisms for steering traffic through service functions. The >> >>working >> >> >> group will also examine what information needs to be gathered from >> >>the >> >> >> network and service functions in support of service function >> chaining >> >> >>and >> >> >> how that information may be made available to nodes that implement >> >>the >> >> >> service functions. >> >> >> >> >> >> Specifically, the SFC WG is chartered to deliver the following: >> >> >> >> >> >> 1) Problem Statement: This document will provide a summary of the >> >> >> problem space to be addressed by the WG including example >>high- >> >> >> level use cases. Additionally, the WG will normalize >> nomenclature >> >> >> and definitions for service function chaining. >> >> >> >> >> >> 2) Architecture: This document will provide a description of the >> >> >> architectural building blocks and their relationships >>including >> >> >> interconnection, placement of capabilities, management, >> >> >> diagnostics, design analysis, and security models, as well as >> >> >> requirements on the protocol mechanisms. >> >> >> >> >> >> 3) Generic Service Function Chaining Encapsulation: A document >>will >> >> >> describe the single service-level data plane encapsulation >> format >> >> >>for >> >> >> conveying the service function chain and the service function >> >>path, >> >> >> and for communicating context information between nodes that >> >> >> implement service functions. It is intended that the >> >>encapsulation >> >> >> be agnostic to the layer at which it is applied and the >>service >> >> that >> >> >> is >> >> >> being constructed. That is, the same encapsulation may be used >> on >> >> >> a service function path realized at the network layer or at >>any >> >> >>other >> >> >> layer, and the same encapsulation will apply for the >> construction >> >> of >> >> >> service function paths regardless of the actual service. >> >> >> >> >> >> 4) Control Plane Mechanisms: A set of documents will be developed >>to >> >> >> describe requirements and protocols necessary to convey >> >>information >> >> >> to service function implementation points. Where possible, >> >>existing >> >> >> IETF protocols will be used and extended. All protocol >> extensions >> >> >> work should be carried out in the working groups responsible >>for >> >> the >> >> >> protocols being modified in coordination with this working >> group, >> >> >>but >> >> >> may be done in this working group after agreement with all the >> >> >> relevant WG chairs and responsible ADs. >> >> >> >> >> >> 5) Manageability: Work on the management and configuration of >> service >> >> >> functions in support of SFC components will certainly be >>needed, >> >> >> but first needs to be better understood and scoped. >> >> >> >> >> >> Proposed Milestones >> >> >> >> >> >> Apr 2014 Submit to IESG Informational document(s) defining the >> >>problem >> >> >> statement and core use cases for Service Function Chaining >> >> >> >> >> >> May 2014 Consult with OPS Area on possible charter modifications >>for >> >> >> management and configuration of SFC components >> >> >> >> >> >> Jan 2015 Submit to IESG Informational document defining the >> >> architecture >> >> >> for SFC >> >> >> >> >> >> Jan 2015 Submit to IESG requirements for a generic service >>function >> >> >> chaining encapsulation protocol >> >> >> >> >> >> Aug 2015 Submit to IESG Standards Track document specifying the >> >>generic >> >> >> service function chaining header encapsulation >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thomas >> >> >> >> >> >> _______________________________________________ >> >> >> nsc mailing list >> >> >> nsc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> _______________________________________________ >> >> >> nsc mailing list >> >> >> nsc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> _______________________________________________ >> >> >> nsc mailing list >> >> >> nsc@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >_______________________________________________ >> >> >nsc mailing list >> >> >nsc@ietf.org >> >> >https://www.ietf.org/mailman/listinfo/nsc >> > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 06:08:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF5A21E8113 for ; Tue, 12 Nov 2013 06:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th45NS9PVXQs for ; Tue, 12 Nov 2013 06:08:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 04F7B11E8140 for ; Tue, 12 Nov 2013 06:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22299; q=dns/txt; s=iport; t=1384265296; x=1385474896; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/9xa0JySIv0J6qrTW3e7EwNfvK92EdBP0kK7KbPoEFU=; b=gTYXvpaed+SOC2U3NmdHz18dHFxCVu+NWjzVFCq/HxC+Me5GD5Bk6ct3 dqrFFaj7HGo3kkpZhpjtf1umiwqYz+1I5p+PKggTtslV5wslfOod5x4PR aESi9liwsjrEaSQ/h1MowkwBGztji0IqDyXSaz9Z2MSXGPgKcyPdpoX70 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOE0glKtJXG9/2dsb2JhbABPCoMHOFO/G4EnFnSCJQEBAQQBAQEXICsCBwQHDAYBCBEBAwEBARUJCS4LFAMGCAIEAQkEBQmHeA2+Lo4cBAEFBoEIKwIFAgQEhCcDlC6DYZIKgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="280698446" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2013 14:08:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACE8EqW010872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 14:08:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 08:08:14 -0600 From: "Jim Guichard (jguichar)" To: "Hongyu Li (Julio)" , Ron Parker , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OA///Q0wA= Date: Tue, 12 Nov 2013 14:08:13 +0000 Message-ID: In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-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.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <4D086355F1958A45A5861F194CA24BC0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:08:20 -0000 Yes, completely agree Hongyu. On 11/12/13 6:57 AM, "Hongyu Li (Julio)" wrote: >Branching/forking is a very interesting topic of SFC. About the >re-classification point, probably we shall not limit it to DPI. It is >also possible that packets go to different branches after been processed >by a certain service function, decision of which branches to go is made >based on the result of service function's process, i.e. not just >re-classification by DPI. > >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron >Parker >Sent: Tuesday, November 12, 2013 7:45 PM >To: Kevin J Ma >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Hi, Kevin > >You ask a great question about branching the graph. The details around >how to convey the selection of the subtree/subgraph are still to be >defined. Is it one chain id for the whole graph? Does each branch >have its own chain id? Some combination? > > Ron > >On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >wrote: > >>> Yes, reclassification can change the service path and >>> re-classification may happen at any node along a service path. >>=20 >> Just to expand on that, going back to the original question about >> service header encapsulation, is it intended that a chain that is >> re-classified will get a new chain ID which fully describes a chain >> that is a superset of the original chain ID, prior to DPI-based >> re-classification? (assuming the goal is "a single chain ID that is >> commonly understood along the entire service chain" >> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>=20 >> And the applicable subset of the permutative list of service paths >> would be configured at each appropriate service node? >> e.g., ID 1: NAT + firewall + DPI >> ID 2: NAT + firewall + DPI + AV >> ID 3: NAT + firewall + DPI + AV + NAT >> ID 4: NAT + firewall + DPI + NAT >> ID 5: NAT + firewall + DPI + AV + LB >> ID 6: NAT + firewall + DPI + LB >> ID 7: NAT + firewall + DPI + LB + CACHE >> ID 8: NAT + firewall + DPI + CACHE >> ID 9: NAT + firewall + DPI + optimizer + LB >> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow >> then be initially classified as ID 1, but eventually get re-classified >> to ID 2-11, after the DPI phase? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >>> -----Original Message----- >>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:01 AM >>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> nsc@ietf.org >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>>=20 >>>=20 >>>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>>=20 >>>> Hi Surendra, >>>>=20 >>>> Classification may be out of scope, but the level of service that is >>>> applicable is dependent upon the level of classification that can be >>>> performed. An assumption of packet level encapsulation has >>> implications >>>> on the level of classification being performed? If the stated goals >>> are >>>> for firewall and load balancer functionality, then the application >>> level >>>> nature of those functions needs to be taken into account? If, on >>>> the other hand, the service function scope is limited due to >>>> limitations in classification, that would be and important piece of >>>>information? >>>>=20 >>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>> points of the service paths seem like re-classification points? Is >>>> that the interpretation from the architecture perspective? Or is >>>> the service function chain classification exclusive of DPI >>>>functionality? >>> I have not fully read that draft yet. But in general, as >>> described in the arch draft, the collection of services form a graph, >>> segments of which are service paths. Yes, reclassification can change >>> the service path and re-classification may happen at any node along a >>>service path. >>>=20 >>> Surendra. >>>>=20 >>>> thanx. >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>> nsc@ietf.org >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>=20 >>>>> Kevin, >>>>>=20 >>>>> Classification mechanism is outside the scope of SFC. It can be >>>>> based >>> on >>>>> the packet or information not in the packet(environmental >>>>> attributes >>> for >>>>> instance) or a combination thereof. What is important is that such >>>>> classification aids in traffic selection and service path >>>>> identification. >>>>> It is no different from a policy in this regard except that the >>>>> policy now specifies the service path. >>>>> Further, classification is not limited to the network elements but >>>>> the service functions as well. Some of this is described in the >>> architecture >>>>> drafts as well - >>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>=20 >>>>> Surendra. >>>>>=20 >>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>>=20 >>>>>> Hi Ron, >>>>>>=20 >>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but >>>>>> I had a similar question wrt bullet 11 in section 2 of the problem >>>>>> statement: >>>>>>=20 >>>>>> 11. Per-Service (re)Classification: Classification occurs at each >>>>>> service, independent from previously applied service >>>>> functions. >>>>>> These unrelated classification events consume resources per >>>>>> service. More importantly, the classification functionality >>>>>> often differs per service function and service function >>> cannot >>>>>> leverage the results from other deployed network or service. >>>>>>=20 >>>>>> as it relates to section 5.2 of the framework document: >>>>>>=20 >>>>>> The SFC Classifier classifies packets based on (some of) the >>>>> contents >>>>>> of the packet header. Concretely, it classifies packets based >>>>>> on >>>>> the >>>>>> possible combination of one or more header fields, such as source >>>>>> address, destination address, DS field, protocol ID, source port >>>>> and >>>>>> destination port numbers, and any other information. >>>>>>=20 >>>>>> A packet-based classifier as described in the framework document >>>>> would >>>>>> seem to be limited in what it can classify? The service function >>>>>> identifier lookup does not seem to be a significant optimization >>> over >>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>> detail >>>>>> wrt how classification information is determined and reused? >>>>>>=20 >>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>> encrypted >>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>> wondering >>>>>> how independent HLS segment requests might be classified and >>>>> associated? >>>>>> Were these types of use cases discussed in the BoF? >>>>>>=20 >>>>>> thanx. >>>>>>=20 >>>>>> -- Kevin J. Ma >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Ron >>>>>>> Parker >>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Sumandra, >>>>>>>=20 >>>>>>> As was discussed in Vancouver, there are already many existing >>>>>>> ways >>>>> to >>>>>>> accomplish service chaining. But none of them provide a >>>>> sufficient >>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>> single >>>>>>> service chain encapsulation will go a long way to ensuring these >>>>> goals. >>>>>>> It may not be the absolutely most efficient approach for every >>>>> single >>>>>>> network topology and every single use case, but its ubiquitous >>> nature >>>>>>> should improve its adoption. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Ron, >>>>>>>=20 >>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>> However >>>>> this >>>>>>> could be augmented with classification result, again one more >>>>> example. >>>>>>>=20 >>>>>>>>> All flows from the same source IP do not necessarily follow the >>>>> same >>>>>>> chain. >>>>>>> Correct. It is also not necessary that all transaction of the >>>>>>> same >>>>> flow >>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>=20 >>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>>=20 >>>>>>> Sumandra >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Sumandra, >>>>>>>=20 >>>>>>> The intention of service function chaining is to allow for >>>>>>> operation >>>>> at >>>>>>> the fully qualified flow level, or even finer grained at the >>>>> transaction >>>>>>> level (this is an implementation matter for the PDP). All flows >>>>> from >>>>>>> the same source IP do not necessarily follow the same chain. >>> Source >>>>>>> IP, >>>>>>> therefore, does not identify the chain ID. Another intention of >>>>>>> service function chaining is to operate over any network topology >>> and >>>>>>> not >>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>> transport, it does not adequately identify the service chain, >>> either. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Ron, >>>>>>>=20 >>>>>>> The service header is meant to carry the context which can *also* >>>>>>> be derived (for example use source ip and vlan to identify >>>>>>> chainID and >>>>>>> position) or encapsulated as part of another tunnel header. So >>>>>>> this could be optional IMHO. >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Sumandra, >>>>>>>=20 >>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>>>>> from >>>>> SF >>>>>>> to >>>>>>> SF will look like: >>>>>>>=20 >>>>>>> +------------------------+ >>>>>>> | "transport" | >>>>>>> +------------------------+ >>>>>>> | service header | >>>>>>> +------------------------+ >>>>>>> | original IP header | >>>>>>> +------------------------+ >>>>>>> | | original IP payload | >>>>>>> | | >>>>>>> +------------------------+ >>>>>>>=20 >>>>>>> Where service header contains, at a minimum, enough information >>>>>>> to >>>>> allow >>>>>>> the packet to be propagated along the full length of the chain, >>>>>>> and optionally, other metadata that enhances the operation of one >>>>>>> or >>> more >>>>>>> service functions. >>>>>>>=20 >>>>>>> And where "transport" could conceivably be any of, but not >>>>>>> limited >>>>> to: >>>>>>>=20 >>>>>>> * Ethernet >>>>>>> * Ethernet + LLC2 >>>>>>> * Ethernet + MPLS >>>>>>> * Ethernet + IP + GRE >>>>>>> * Ethernet + IP +UDP >>>>>>>=20 >>>>>>>=20 >>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>> immutability, but rather to specify the packet that is propagated >>>>>>> from preceding entity to succeeding entity, prior to >>>>>>> encapsulation. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Sumandra Majee >>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be used >>> on >>>>>>> a service function path realized at the network layer or at >>>>>>> any other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>>=20 >>>>>>> [SM] What does it mean by a single service-level encapsulation, >>>>>>> a >>>>> new >>>>>>> encapsulation format >>>>>>> or an ability to select one encapsulation format that >>>>> fits >>>>>>> the >>>>>>> need for a given service chain? >>>>>>> The ability to select a specific encapsulation would >>>>>>> be >>> a >>>>>>> management plane decision. >>>>>>> There are quite a few existing encapsulation methods >>>>>>> that >>>>> can >>>>>>> possibly be reused to provide >>>>>>> context information between service nodes. I have seen >>>>>>> mention >>>>>>> of GRE, for HTTP based >>>>>>> applications contexts are transferred via headers. >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Thomas Narten >>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>> To: nsc@ietf.org >>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Hi. >>>>>>>=20 >>>>>>> Current charter can be found at >>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>> ietf-sfc/. >>>>>>>=20 >>>>>>> It contains the revised management text as well as updated >>>>> milestones. >>>>>>>=20 >>>>>>> All known issues have been addressed. If there are any remaining >>>>> issues, >>>>>>> please speak up! >>>>>>>=20 >>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>=20 >>>>>>> Networks, servers, storage technologies, and applications, have >>>>>>> all undergone significant change in recent years with the >>>>>>> introduction >>> of >>>>>>> virtualization, network overlays, and orchestration. Service >>> delivery >>>>> is >>>>>>> currently both a technical and organizational challenge that >>> involves >>>>>>> significant modification to the network configuration. >>>>>>> Services are typically implemented by the ordered combination of >>>>>>> a number of service functions that are deployed at different >>>>>>> points within >>> the >>>>>>> network. Today, a common deployment model has service functions >>>>>>> physically inserted on the data forwarding path between >>>>>>> communicating peers. >>>>> Going >>>>>>> forward, however, there is a desire to move to a different model, >>>>> where >>>>>>> service functions are not required to reside on the default data >>> path >>>>>>> and >>>>>>> traffic is instead steered through services, wherever they are >>>>> deployed. >>>>>>>=20 >>>>>>> For a given service, the abstracted view of the required service >>>>>>> functions and the order in which they are to be applied is called >>>>>>> a Service Function Chain (SFC). Since a given service function >>>>>>> may be available on more than one node within a network, a >>>>>>> Service Function Chain is instantiated >>>>> via >>>>>>> the selection of specific service function instances and the >>>>>>> network nodes on which they are provided, thereby forming a >>>>>>> service topology: >>>>>>> this is called a Service Function Path. The service functions may >>>>>>> be applied at a specific layer within the network protocol stack >>>>> (network >>>>>>> layer, application layer, etc.). >>>>>>>=20 >>>>>>> The Service Function Chaining (SFC) working group will develop >>>>>>> new approaches to service delivery and deployment. It will >>>>>>> produce a framework for service function chaining that includes >>>>>>> the necessary protocols >>>>> or >>>>>>> protocol extensions to convey the service path and service path >>>>>>> information to nodes that implement service functions, as well as >>>>>>> mechanisms for steering traffic through service functions. The >>>>> working >>>>>>> group will also examine what information needs to be gathered >>>>>>> from >>>>> the >>>>>>> network and service functions in support of service function >>> chaining >>>>>>> and >>>>>>> how that information may be made available to nodes that >>>>>>> implement >>>>> the >>>>>>> service functions. >>>>>>>=20 >>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>>=20 >>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>> problem space to be addressed by the WG including example high- >>>>>>> level use cases. Additionally, the WG will normalize >>> nomenclature >>>>>>> and definitions for service function chaining. >>>>>>>=20 >>>>>>> 2) Architecture: This document will provide a description of the >>>>>>> architectural building blocks and their relationships including >>>>>>> interconnection, placement of capabilities, management, >>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>> requirements on the protocol mechanisms. >>>>>>>=20 >>>>>>> 3) Generic Service Function Chaining Encapsulation: A document will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be used >>> on >>>>>>> a service function path realized at the network layer or at >>>>>>> any other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>>=20 >>>>>>> 4) Control Plane Mechanisms: A set of documents will be developed >>>>>>>to >>>>>>> describe requirements and protocols necessary to convey >>>>> information >>>>>>> to service function implementation points. Where possible, >>>>> existing >>>>>>> IETF protocols will be used and extended. All protocol >>> extensions >>>>>>> work should be carried out in the working groups responsible >>>>>>> for >>>>> the >>>>>>> protocols being modified in coordination with this working >>> group, >>>>>>> but >>>>>>> may be done in this working group after agreement with all the >>>>>>> relevant WG chairs and responsible ADs. >>>>>>>=20 >>>>>>> 5) Manageability: Work on the management and configuration of >>> service >>>>>>> functions in support of SFC components will certainly be needed, >>>>>>> but first needs to be better understood and scoped. >>>>>>>=20 >>>>>>> Proposed Milestones >>>>>>>=20 >>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>> problem >>>>>>> statement and core use cases for Service Function Chaining >>>>>>>=20 >>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>>>>>> for management and configuration of SFC components >>>>>>>=20 >>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>> architecture >>>>>>> for SFC >>>>>>>=20 >>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>>>>> function chaining encapsulation protocol >>>>>>>=20 >>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>> generic >>>>>>> service function chaining header encapsulation >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> Thomas >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Tue Nov 12 06:16:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7967811E8170 for ; Tue, 12 Nov 2013 06:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+yw53EohH5H for ; Tue, 12 Nov 2013 06:16:01 -0800 (PST) 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 3EB3111E8143 for ; Tue, 12 Nov 2013 06:16:01 -0800 (PST) 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.0158.001; Tue, 12 Nov 2013 06:15:57 -0800 From: Ron Parker To: "Hongyu Li (Julio)" , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMA= Date: Tue, 12 Nov 2013 14:15:57 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-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 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:16:06 -0000 Hongyu,=20 I agree completely that re-classification is not limited to DPI. And also, that an area for us to explore as a group is how to represent the= service graph. Do we want to represent it as a proper graph with an adja= cency list or other representational model? Or, do we want to represent i= t as a set of linear segments and if so, how are the segments connected int= o a graph? Other ideas? Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Hongy= u Li (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron Parker; Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Branching/forking is a very interesting topic of SFC. About the re-classifi= cation point, probably we shall not limit it to DPI. It is also possible th= at packets go to different branches after been processed by a certain servi= ce function, decision of which branches to go is made based on the result o= f service function's process, i.e. not just re-classification by DPI. Hongyu -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ron P= arker Sent: Tuesday, November 12, 2013 7:45 PM To: Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Hi, Kevin You ask a great question about branching the graph. The details around how= to convey the selection of the subtree/subgraph are still to be defined. = Is it one chain id for the whole graph? Does each branch have its own ch= ain id? Some combination? Ron On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" wrote= : >> Yes, reclassification can change the service path and=20 >> re-classification may happen at any node along a service path. >=20 > Just to expand on that, going back to the original question about=20 > service header encapsulation, is it intended that a chain that is=20 > re-classified will get a new chain ID which fully describes a chain=20 > that is a superset of the original chain ID, prior to DPI-based=20 > re-classification? (assuming the goal is "a single chain ID that is=20 > commonly understood along the entire service chain" > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >=20 > And the applicable subset of the permutative list of service paths=20 > would be configured at each appropriate service node? > e.g., ID 1: NAT + firewall + DPI > ID 2: NAT + firewall + DPI + AV > ID 3: NAT + firewall + DPI + AV + NAT > ID 4: NAT + firewall + DPI + NAT > ID 5: NAT + firewall + DPI + AV + LB > ID 6: NAT + firewall + DPI + LB > ID 7: NAT + firewall + DPI + LB + CACHE > ID 8: NAT + firewall + DPI + CACHE > ID 9: NAT + firewall + DPI + optimizer + LB > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow=20 > then be initially classified as ID 1, but eventually get re-classified=20 > to ID 2-11, after the DPI phase? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> Sent: Tuesday, November 12, 2013 1:01 AM >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >>=20 >>=20 >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>=20 >>> Hi Surendra, >>>=20 >>> Classification may be out of scope, but the level of service that is=20 >>> applicable is dependent upon the level of classification that can be=20 >>> performed. An assumption of packet level encapsulation has >> implications >>> on the level of classification being performed? If the stated goals >> are >>> for firewall and load balancer functionality, then the application >> level >>> nature of those functions needs to be taken into account? If, on=20 >>> the other hand, the service function scope is limited due to=20 >>> limitations in classification, that would be and important piece of inf= ormation? >>>=20 >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork=20 >>> points of the service paths seem like re-classification points? Is=20 >>> that the interpretation from the architecture perspective? Or is=20 >>> the service function chain classification exclusive of DPI functionalit= y? >> I have not fully read that draft yet. But in general, as=20 >> described in the arch draft, the collection of services form a graph,=20 >> segments of which are service paths. Yes, reclassification can change=20 >> the service path and re-classification may happen at any node along a se= rvice path. >>=20 >> Surendra. >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>> -----Original Message----- >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>> nsc@ietf.org >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> Kevin, >>>>=20 >>>> Classification mechanism is outside the scope of SFC. It can be=20 >>>> based >> on >>>> the packet or information not in the packet(environmental=20 >>>> attributes >> for >>>> instance) or a combination thereof. What is important is that such=20 >>>> classification aids in traffic selection and service path=20 >>>> identification. >>>> It is no different from a policy in this regard except that the=20 >>>> policy now specifies the service path. >>>> Further, classification is not limited to the network elements but=20 >>>> the service functions as well. Some of this is described in the >> architecture >>>> drafts as well - >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>=20 >>>> Surendra. >>>>=20 >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>=20 >>>>> Hi Ron, >>>>>=20 >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but=20 >>>>> I had a similar question wrt bullet 11 in section 2 of the problem >>>>> statement: >>>>>=20 >>>>> 11. Per-Service (re)Classification: Classification occurs at each >>>>> service, independent from previously applied service >>>> functions. >>>>> These unrelated classification events consume resources per >>>>> service. More importantly, the classification functionality >>>>> often differs per service function and service function >> cannot >>>>> leverage the results from other deployed network or service. >>>>>=20 >>>>> as it relates to section 5.2 of the framework document: >>>>>=20 >>>>> The SFC Classifier classifies packets based on (some of) the >>>> contents >>>>> of the packet header. Concretely, it classifies packets based=20 >>>>> on >>>> the >>>>> possible combination of one or more header fields, such as source >>>>> address, destination address, DS field, protocol ID, source port >>>> and >>>>> destination port numbers, and any other information. >>>>>=20 >>>>> A packet-based classifier as described in the framework document >>>> would >>>>> seem to be limited in what it can classify? The service function=20 >>>>> identifier lookup does not seem to be a significant optimization >> over >>>>> a packet-based 5-tuple lookup? There seems to be some missing >> detail >>>>> wrt how classification information is determined and reused? >>>>>=20 >>>>> When thinking about higher level services, e.g., HTTP and TLS >>>> encrypted >>>>> flows, a packet-based classifier seems inadequate? I was also >>>> wondering >>>>> how independent HLS segment requests might be classified and >>>> associated? >>>>> Were these types of use cases discussed in the BoF? >>>>>=20 >>>>> thanx. >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>> Behalf >> Of >>>>>> Ron >>>>>> Parker >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> As was discussed in Vancouver, there are already many existing=20 >>>>>> ways >>>> to >>>>>> accomplish service chaining. But none of them provide a >>>> sufficient >>>>>> combination of interoperability, flexibility, and resiliency. A >>>> single >>>>>> service chain encapsulation will go a long way to ensuring these >>>> goals. >>>>>> It may not be the absolutely most efficient approach for every >>>> single >>>>>> network topology and every single use case, but its ubiquitous >> nature >>>>>> should improve its adoption. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Absolutely, that was an example of one type of derivation.=20 >>>>>> However >>>> this >>>>>> could be augmented with classification result, again one more >>>> example. >>>>>>=20 >>>>>>>> All flows from the same source IP do not necessarily follow the >>>> same >>>>>> chain. >>>>>> Correct. It is also not necessary that all transaction of the=20 >>>>>> same >>>> flow >>>>>> follow the same chain either. So why stop at flow itself. >>>>>>=20 >>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>=20 >>>>>> Sumandra >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> The intention of service function chaining is to allow for=20 >>>>>> operation >>>> at >>>>>> the fully qualified flow level, or even finer grained at the >>>> transaction >>>>>> level (this is an implementation matter for the PDP). All flows >>>> from >>>>>> the same source IP do not necessarily follow the same chain. >> Source >>>>>> IP, >>>>>> therefore, does not identify the chain ID. Another intention of >>>>>> service function chaining is to operate over any network topology >> and >>>>>> not >>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>> transport, it does not adequately identify the service chain, >> either. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> The service header is meant to carry the context which can *also*=20 >>>>>> be derived (for example use source ip and vlan to identify=20 >>>>>> chainID and >>>>>> position) or encapsulated as part of another tunnel header. So=20 >>>>>> this could be optional IMHO. >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Sumandra, >>>>>>=20 >>>>>> As I understand it, an SFC packet traversing from PDP to SF or=20 >>>>>> from >>>> SF >>>>>> to >>>>>> SF will look like: >>>>>>=20 >>>>>> +------------------------+ >>>>>> | "transport" | >>>>>> +------------------------+ >>>>>> | service header | >>>>>> +------------------------+ >>>>>> | original IP header | >>>>>> +------------------------+ >>>>>> | | original IP payload | >>>>>> | | >>>>>> +------------------------+ >>>>>>=20 >>>>>> Where service header contains, at a minimum, enough information=20 >>>>>> to >>>> allow >>>>>> the packet to be propagated along the full length of the chain,=20 >>>>>> and optionally, other metadata that enhances the operation of one=20 >>>>>> or >> more >>>>>> service functions. >>>>>>=20 >>>>>> And where "transport" could conceivably be any of, but not=20 >>>>>> limited >>>> to: >>>>>>=20 >>>>>> * Ethernet >>>>>> * Ethernet + LLC2 >>>>>> * Ethernet + MPLS >>>>>> * Ethernet + IP + GRE >>>>>> * Ethernet + IP +UDP >>>>>>=20 >>>>>>=20 >>>>>> Also, "original" in the diagram above is not meant to imply=20 >>>>>> immutability, but rather to specify the packet that is propagated=20 >>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>> encapsulation. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>> Behalf >> Of >>>>>> Sumandra Majee >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>> To: Thomas Narten; nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>> describe the single service-level data plane encapsulation >> format >>>>>> for >>>>>> conveying the service function chain and the service function >>>> path, >>>>>> and for communicating context information between nodes that >>>>>> implement service functions. It is intended that the >>>> encapsulation >>>>>> be agnostic to the layer at which it is applied and the=20 >>>>>> service >>>> that >>>>>> is >>>>>> being constructed. That is, the same encapsulation may be used >> on >>>>>> a service function path realized at the network layer or at=20 >>>>>> any other >>>>>> layer, and the same encapsulation will apply for the >> construction >>>> of >>>>>> service function paths regardless of the actual service. >>>>>>=20 >>>>>> [SM] What does it mean by a single service-level encapsulation, a >>>> new >>>>>> encapsulation format >>>>>> or an ability to select one encapsulation format that >>>> fits >>>>>> the >>>>>> need for a given service chain? >>>>>> The ability to select a specific encapsulation would=20 >>>>>> be >> a >>>>>> management plane decision. >>>>>> There are quite a few existing encapsulation methods=20 >>>>>> that >>>> can >>>>>> possibly be reused to provide >>>>>> context information between service nodes. I have seen >>>>>> mention >>>>>> of GRE, for HTTP based >>>>>> applications contexts are transferred via headers. >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>> Behalf >> Of >>>>>> Thomas Narten >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>> To: nsc@ietf.org >>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Hi. >>>>>>=20 >>>>>> Current charter can be found at >>>>>> https://datatracker.ietf.org/doc/charter- >>>>>> ietf-sfc/. >>>>>>=20 >>>>>> It contains the revised management text as well as updated >>>> milestones. >>>>>>=20 >>>>>> All known issues have been addressed. If there are any remaining >>>> issues, >>>>>> please speak up! >>>>>>=20 >>>>>> Charter charter-ietf-sfc-00-04 >>>>>>=20 >>>>>> Networks, servers, storage technologies, and applications, have=20 >>>>>> all undergone significant change in recent years with the=20 >>>>>> introduction >> of >>>>>> virtualization, network overlays, and orchestration. Service >> delivery >>>> is >>>>>> currently both a technical and organizational challenge that >> involves >>>>>> significant modification to the network configuration. >>>>>> Services are typically implemented by the ordered combination of=20 >>>>>> a number of service functions that are deployed at different=20 >>>>>> points within >> the >>>>>> network. Today, a common deployment model has service functions=20 >>>>>> physically inserted on the data forwarding path between=20 >>>>>> communicating peers. >>>> Going >>>>>> forward, however, there is a desire to move to a different model, >>>> where >>>>>> service functions are not required to reside on the default data >> path >>>>>> and >>>>>> traffic is instead steered through services, wherever they are >>>> deployed. >>>>>>=20 >>>>>> For a given service, the abstracted view of the required service=20 >>>>>> functions and the order in which they are to be applied is called=20 >>>>>> a Service Function Chain (SFC). Since a given service function=20 >>>>>> may be available on more than one node within a network, a=20 >>>>>> Service Function Chain is instantiated >>>> via >>>>>> the selection of specific service function instances and the=20 >>>>>> network nodes on which they are provided, thereby forming a=20 >>>>>> service topology: >>>>>> this is called a Service Function Path. The service functions may=20 >>>>>> be applied at a specific layer within the network protocol stack >>>> (network >>>>>> layer, application layer, etc.). >>>>>>=20 >>>>>> The Service Function Chaining (SFC) working group will develop=20 >>>>>> new approaches to service delivery and deployment. It will=20 >>>>>> produce a framework for service function chaining that includes=20 >>>>>> the necessary protocols >>>> or >>>>>> protocol extensions to convey the service path and service path=20 >>>>>> information to nodes that implement service functions, as well as=20 >>>>>> mechanisms for steering traffic through service functions. The >>>> working >>>>>> group will also examine what information needs to be gathered=20 >>>>>> from >>>> the >>>>>> network and service functions in support of service function >> chaining >>>>>> and >>>>>> how that information may be made available to nodes that=20 >>>>>> implement >>>> the >>>>>> service functions. >>>>>>=20 >>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>=20 >>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>> problem space to be addressed by the WG including example high- >>>>>> level use cases. Additionally, the WG will normalize >> nomenclature >>>>>> and definitions for service function chaining. >>>>>>=20 >>>>>> 2) Architecture: This document will provide a description of the >>>>>> architectural building blocks and their relationships including >>>>>> interconnection, placement of capabilities, management, >>>>>> diagnostics, design analysis, and security models, as well as >>>>>> requirements on the protocol mechanisms. >>>>>>=20 >>>>>> 3) Generic Service Function Chaining Encapsulation: A document will >>>>>> describe the single service-level data plane encapsulation >> format >>>>>> for >>>>>> conveying the service function chain and the service function >>>> path, >>>>>> and for communicating context information between nodes that >>>>>> implement service functions. It is intended that the >>>> encapsulation >>>>>> be agnostic to the layer at which it is applied and the=20 >>>>>> service >>>> that >>>>>> is >>>>>> being constructed. That is, the same encapsulation may be used >> on >>>>>> a service function path realized at the network layer or at=20 >>>>>> any other >>>>>> layer, and the same encapsulation will apply for the >> construction >>>> of >>>>>> service function paths regardless of the actual service. >>>>>>=20 >>>>>> 4) Control Plane Mechanisms: A set of documents will be developed to >>>>>> describe requirements and protocols necessary to convey >>>> information >>>>>> to service function implementation points. Where possible, >>>> existing >>>>>> IETF protocols will be used and extended. All protocol >> extensions >>>>>> work should be carried out in the working groups responsible=20 >>>>>> for >>>> the >>>>>> protocols being modified in coordination with this working >> group, >>>>>> but >>>>>> may be done in this working group after agreement with all the >>>>>> relevant WG chairs and responsible ADs. >>>>>>=20 >>>>>> 5) Manageability: Work on the management and configuration of >> service >>>>>> functions in support of SFC components will certainly be needed, >>>>>> but first needs to be better understood and scoped. >>>>>>=20 >>>>>> Proposed Milestones >>>>>>=20 >>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>> problem >>>>>> statement and core use cases for Service Function Chaining >>>>>>=20 >>>>>> May 2014 Consult with OPS Area on possible charter modifications=20 >>>>>> for management and configuration of SFC components >>>>>>=20 >>>>>> Jan 2015 Submit to IESG Informational document defining the >>>> architecture >>>>>> for SFC >>>>>>=20 >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 >>>>>> function chaining encapsulation protocol >>>>>>=20 >>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>> generic >>>>>> service function chaining header encapsulation >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Tue Nov 12 06:41:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE4B21E80C7 for ; Tue, 12 Nov 2013 06:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS7EJYY6C9nG for ; Tue, 12 Nov 2013 06:40:59 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 851E021E812B for ; Tue, 12 Nov 2013 06:40:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 6803F1BD4879; Tue, 12 Nov 2013 06:40:59 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D25571BD4875; Tue, 12 Nov 2013 06:40:56 -0800 (PST) Message-ID: <52823DF6.5050306@joelhalpern.com> Date: Tue, 12 Nov 2013 09:40:54 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:41:04 -0000 Jim, thank you for a concrete example. I would suggest that in the usual cases, there is a better way to handle this than branching and rewriting at the PCRF. If the DPI engine or PCRF logic (whichever makes the decision) notifies the control logic about the decision for the flow, then the ingress can direct subsequent packets to the correct place, avoiding needless processing of further packets in the DPI and PCRF logic. Further, the needed control information can be passed to the optimization or parental control so that it does not matter where the first packet is sent, avoiding the need for the PCRF to understand how to direct packets to service paths. Yours, Joel On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: > Hi Kevin, > > Let me try and provide a concrete example to see if this answers your > specific question: > > Use case: P-GW -> PCRF -> services applied to traffic based on > applicationID and subscriberID. > > Instantiated as: > > SFC1: P-GW -> DPI -> PCRF > SFC2: PCRF -> video-optimization -> metering -> FW > SFC3: PCRF -> parental-control -> metering -> FW > > In this case DPI is performed on SFC1 and identifies applicationID. The > applicationID is carried in the service encapsulation to PCRF. PCRF uses > solution specific logic (identifies subscriber, applies policies, etc) and > uses the result along with the applicationID received from DPI to select > an outbound service chain, SFC2 or SFC3. Note that in this case branching > occurs from SFC1 to either SFC2 or SFC3. > > > > > On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > >>> Yes, reclassification can change the service path and >>> re-classification may happen at any node along a service path. >> >> Just to expand on that, going back to the original question about >> service header encapsulation, is it intended that a chain that >> is re-classified will get a new chain ID which fully describes >> a chain that is a superset of the original chain ID, prior to >> DPI-based re-classification? (assuming the goal is "a single >> chain ID that is commonly understood along the entire service chain" >> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> >> And the applicable subset of the permutative list of service >> paths would be configured at each appropriate service node? >> e.g., ID 1: NAT + firewall + DPI >> ID 2: NAT + firewall + DPI + AV >> ID 3: NAT + firewall + DPI + AV + NAT >> ID 4: NAT + firewall + DPI + NAT >> ID 5: NAT + firewall + DPI + AV + LB >> ID 6: NAT + firewall + DPI + LB >> ID 7: NAT + firewall + DPI + LB + CACHE >> ID 8: NAT + firewall + DPI + CACHE >> ID 9: NAT + firewall + DPI + optimizer + LB >> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> ID 11: NAT + firewall + DPI + optimizer + CACHE >> Would every flow then be initially classified as ID 1, but >> eventually get re-classified to ID 2-11, after the DPI phase? >> >> thanx. >> >> -- Kevin J. Ma >> >>> -----Original Message----- >>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:01 AM >>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> >>> >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>> >>>> Hi Surendra, >>>> >>>> Classification may be out of scope, but the level of service that is >>>> applicable is dependent upon the level of classification that can be >>>> performed. An assumption of packet level encapsulation has >>> implications >>>> on the level of classification being performed? If the stated goals >>> are >>>> for firewall and load balancer functionality, then the application >>> level >>>> nature of those functions needs to be taken into account? If, on the >>>> other hand, the service function scope is limited due to limitations >>> in >>>> classification, that would be and important piece of information? >>>> >>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>> points >>>> of the service paths seem like re-classification points? Is that the >>>> interpretation from the architecture perspective? Or is the service >>>> function chain classification exclusive of DPI functionality? >>> I have not fully read that draft yet. But in general, as described >>> in >>> the arch draft, the collection of services form a graph, segments of >>> which >>> are service paths. Yes, reclassification can change the service path and >>> re-classification may happen at any node along a service path. >>> >>> Surendra. >>>> >>>> thanx. >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- >>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> nsc@ietf.org >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>> >>>>> Kevin, >>>>> >>>>> Classification mechanism is outside the scope of SFC. It can be based >>> on >>>>> the packet or information not in the packet(environmental attributes >>> for >>>>> instance) or a combination thereof. What is important is that such >>>>> classification aids in traffic selection and service path >>>>> identification. >>>>> It is no different from a policy in this regard except that the >>> policy >>>>> now >>>>> specifies the service path. >>>>> Further, classification is not limited to the network elements but >>> the >>>>> service functions as well. Some of this is described in the >>> architecture >>>>> drafts as well - >>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>> >>>>> Surendra. >>>>> >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>> >>>>>> Hi Ron, >>>>>> >>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but >>> I >>>>>> had a similar question wrt bullet 11 in section 2 of the problem >>>>>> statement: >>>>>> >>>>>> 11. Per-Service (re)Classification: Classification occurs at >>> each >>>>>> service, independent from previously applied service >>>>> functions. >>>>>> These unrelated classification events consume resources per >>>>>> service. More importantly, the classification >>> functionality >>>>>> often differs per service function and service function >>> cannot >>>>>> leverage the results from other deployed network or >>> service. >>>>>> >>>>>> as it relates to section 5.2 of the framework document: >>>>>> >>>>>> The SFC Classifier classifies packets based on (some of) the >>>>> contents >>>>>> of the packet header. Concretely, it classifies packets based >>> on >>>>> the >>>>>> possible combination of one or more header fields, such as >>> source >>>>>> address, destination address, DS field, protocol ID, source port >>>>> and >>>>>> destination port numbers, and any other information. >>>>>> >>>>>> A packet-based classifier as described in the framework document >>>>> would >>>>>> seem to be limited in what it can classify? The service function >>>>>> identifier lookup does not seem to be a significant optimization >>> over >>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>> detail >>>>>> wrt how classification information is determined and reused? >>>>>> >>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>> encrypted >>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>> wondering >>>>>> how independent HLS segment requests might be classified and >>>>> associated? >>>>>> Were these types of use cases discussed in the BoF? >>>>>> >>>>>> thanx. >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>>>> Ron >>>>>>> Parker >>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As was discussed in Vancouver, there are already many existing >>> ways >>>>> to >>>>>>> accomplish service chaining. But none of them provide a >>>>> sufficient >>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>> single >>>>>>> service chain encapsulation will go a long way to ensuring these >>>>> goals. >>>>>>> It may not be the absolutely most efficient approach for every >>>>> single >>>>>>> network topology and every single use case, but its ubiquitous >>> nature >>>>>>> should improve its adoption. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> Absolutely, that was an example of one type of derivation. However >>>>> this >>>>>>> could be augmented with classification result, again one more >>>>> example. >>>>>>> >>>>>>>>> All flows from the same source IP do not necessarily follow the >>>>> same >>>>>>> chain. >>>>>>> Correct. It is also not necessary that all transaction of the same >>>>> flow >>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>> >>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>> >>>>>>> Sumandra >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> The intention of service function chaining is to allow for >>> operation >>>>> at >>>>>>> the fully qualified flow level, or even finer grained at the >>>>> transaction >>>>>>> level (this is an implementation matter for the PDP). All >>> flows >>>>> from >>>>>>> the same source IP do not necessarily follow the same chain. >>> Source >>>>>>> IP, >>>>>>> therefore, does not identify the chain ID. Another intention >>> of >>>>>>> service function chaining is to operate over any network topology >>> and >>>>>>> not >>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>> transport, it does not adequately identify the service chain, >>> either. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> The service header is meant to carry the context which can *also* >>> be >>>>>>> derived (for example use source ip and vlan to identify chainID >>> and >>>>>>> position) or encapsulated as part of another tunnel header. So >>> this >>>>>>> could >>>>>>> be optional IMHO. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>> from >>>>> SF >>>>>>> to >>>>>>> SF will look like: >>>>>>> >>>>>>> +------------------------+ >>>>>>> | "transport" | >>>>>>> +------------------------+ >>>>>>> | service header | >>>>>>> +------------------------+ >>>>>>> | original IP header | >>>>>>> +------------------------+ >>>>>>> | | original IP payload >>> | >>>>>>> | | >>>>>>> +------------------------+ >>>>>>> >>>>>>> Where service header contains, at a minimum, enough information to >>>>> allow >>>>>>> the packet to be propagated along the full length of the chain, >>> and >>>>>>> optionally, other metadata that enhances the operation of one or >>> more >>>>>>> service functions. >>>>>>> >>>>>>> And where "transport" could conceivably be any of, but not >>> limited >>>>> to: >>>>>>> >>>>>>> * Ethernet >>>>>>> * Ethernet + LLC2 >>>>>>> * Ethernet + MPLS >>>>>>> * Ethernet + IP + GRE >>>>>>> * Ethernet + IP +UDP >>>>>>> >>>>>>> >>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>> immutability, >>>>>>> but rather to specify the packet that is propagated from preceding >>>>>>> entity >>>>>>> to succeeding entity, prior to encapsulation. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>>>> Sumandra Majee >>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> [SM] What does it mean by a single service-level encapsulation, a >>>>> new >>>>>>> encapsulation format >>>>>>> or an ability to select one encapsulation format that >>>>> fits >>>>>>> the >>>>>>> need for a given service chain? >>>>>>> The ability to select a specific encapsulation would >>> be >>> a >>>>>>> management plane decision. >>>>>>> There are quite a few existing encapsulation methods >>> that >>>>> can >>>>>>> possibly be reused to provide >>>>>>> context information between service nodes. I have seen >>>>>>> mention >>>>>>> of GRE, for HTTP based >>>>>>> applications contexts are transferred via headers. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of >>>>>>> Thomas Narten >>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>> To: nsc@ietf.org >>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Current charter can be found at >>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>> ietf-sfc/. >>>>>>> >>>>>>> It contains the revised management text as well as updated >>>>> milestones. >>>>>>> >>>>>>> All known issues have been addressed. If there are any remaining >>>>> issues, >>>>>>> please speak up! >>>>>>> >>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>> >>>>>>> Networks, servers, storage technologies, and applications, have >>> all >>>>>>> undergone significant change in recent years with the introduction >>> of >>>>>>> virtualization, network overlays, and orchestration. Service >>> delivery >>>>> is >>>>>>> currently both a technical and organizational challenge that >>> involves >>>>>>> significant modification to the network configuration. >>>>>>> Services are typically implemented by the ordered combination of a >>>>>>> number >>>>>>> of service functions that are deployed at different points within >>> the >>>>>>> network. Today, a common deployment model has service functions >>>>>>> physically >>>>>>> inserted on the data forwarding path between communicating peers. >>>>> Going >>>>>>> forward, however, there is a desire to move to a different model, >>>>> where >>>>>>> service functions are not required to reside on the default data >>> path >>>>>>> and >>>>>>> traffic is instead steered through services, wherever they are >>>>> deployed. >>>>>>> >>>>>>> For a given service, the abstracted view of the required service >>>>>>> functions >>>>>>> and the order in which they are to be applied is called a Service >>>>>>> Function >>>>>>> Chain (SFC). Since a given service function may be available on >>> more >>>>>>> than >>>>>>> one node within a network, a Service Function Chain is >>> instantiated >>>>> via >>>>>>> the selection of specific service function instances and the >>> network >>>>>>> nodes >>>>>>> on which they are provided, thereby forming a service topology: >>>>>>> this is called a Service Function Path. The service functions may >>> be >>>>>>> applied at a specific layer within the network protocol stack >>>>> (network >>>>>>> layer, application layer, etc.). >>>>>>> >>>>>>> The Service Function Chaining (SFC) working group will develop new >>>>>>> approaches to service delivery and deployment. It will produce a >>>>>>> framework >>>>>>> for service function chaining that includes the necessary >>> protocols >>>>> or >>>>>>> protocol extensions to convey the service path and service path >>>>>>> information to nodes that implement service functions, as well as >>>>>>> mechanisms for steering traffic through service functions. The >>>>> working >>>>>>> group will also examine what information needs to be gathered from >>>>> the >>>>>>> network and service functions in support of service function >>> chaining >>>>>>> and >>>>>>> how that information may be made available to nodes that implement >>>>> the >>>>>>> service functions. >>>>>>> >>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>> >>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>> problem space to be addressed by the WG including example >>> high- >>>>>>> level use cases. Additionally, the WG will normalize >>> nomenclature >>>>>>> and definitions for service function chaining. >>>>>>> >>>>>>> 2) Architecture: This document will provide a description of the >>>>>>> architectural building blocks and their relationships >>> including >>>>>>> interconnection, placement of capabilities, management, >>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>> requirements on the protocol mechanisms. >>>>>>> >>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>> will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> 4) Control Plane Mechanisms: A set of documents will be developed >>> to >>>>>>> describe requirements and protocols necessary to convey >>>>> information >>>>>>> to service function implementation points. Where possible, >>>>> existing >>>>>>> IETF protocols will be used and extended. All protocol >>> extensions >>>>>>> work should be carried out in the working groups responsible >>> for >>>>> the >>>>>>> protocols being modified in coordination with this working >>> group, >>>>>>> but >>>>>>> may be done in this working group after agreement with all the >>>>>>> relevant WG chairs and responsible ADs. >>>>>>> >>>>>>> 5) Manageability: Work on the management and configuration of >>> service >>>>>>> functions in support of SFC components will certainly be >>> needed, >>>>>>> but first needs to be better understood and scoped. >>>>>>> >>>>>>> Proposed Milestones >>>>>>> >>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>> problem >>>>>>> statement and core use cases for Service Function Chaining >>>>>>> >>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>> for >>>>>>> management and configuration of SFC components >>>>>>> >>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>> architecture >>>>>>> for SFC >>>>>>> >>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>> function >>>>>>> chaining encapsulation protocol >>>>>>> >>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>> generic >>>>>>> service function chaining header encapsulation >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Tue Nov 12 06:53:07 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9FB21E8104 for ; Tue, 12 Nov 2013 06:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.48 X-Spam-Level: X-Spam-Status: No, score=-10.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qhs6lbVqC3IO for ; Tue, 12 Nov 2013 06:53:02 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 179FA11E8143 for ; Tue, 12 Nov 2013 06:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23971; q=dns/txt; s=iport; t=1384267982; x=1385477582; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=zWp7uWBd4nvRUuGGacXQmhw1CQZtRUEjAKN+fJeofpM=; b=PgMMQu5w9mORvtRc9eFdCmn3bjYx5hHhzowFw8Kw0Zb++cl7/XK8EkY7 a3h3yODdqsB5Vtkc/I5z40daIjf1mx7/L6n/J/P7k2pkZE5ZSr7HL5SfV 3rVgU4gx3JV0q/NkbllcA4aJb6o5CbYd9T9GjgQrzcq/vN1Tcik7qspIU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAOs/glKtJV2c/2dsb2JhbABPCoMHOFO/HIEnFnSCJQEBAQQBAQEXDRMrAgcEEwYBCBEBAwEBARUJCS4LFAMGCAIEAQkJCRKHZg2+KI4cBAYGgQgtBQIEBIQnA5Qug2GSCoMmgWgBCBci X-IronPort-AV: E=Sophos;i="4.93,685,1378857600"; d="scan'208";a="283676926" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2013 14:52:53 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACEqrYf007759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 14:52:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 08:52:52 -0600 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAIAAXUUA//+vg4A= Date: Tue, 12 Nov 2013 14:52:51 +0000 Message-ID: In-Reply-To: <52823DF6.5050306@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <57DEA47E9DD5484FA1B283C9A2F529FD@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 14:53:07 -0000 Yes optimization can certainly be built into this but I wanted to show an example of the types of things we mean when we talk about branching. Once the concept is better understood I think we will see some more exciting examples. Note also that the control logic could also utilize the service encapsulation as a mechanism to push notifications back up the original chain to inform the ingress to bypass the original chain for all subsequent packets for this flow. On 11/12/13 9:40 AM, "Joel M. Halpern" wrote: >Jim, thank you for a concrete example. >I would suggest that in the usual cases, there is a better way to handle >this than branching and rewriting at the PCRF. > >If the DPI engine or PCRF logic (whichever makes the decision) notifies >the control logic about the decision for the flow, then the ingress can >direct subsequent packets to the correct place, avoiding needless >processing of further packets in the DPI and PCRF logic. >Further, the needed control information can be passed to the >optimization or parental control so that it does not matter where the >first packet is sent, avoiding the need for the PCRF to understand how >to direct packets to service paths. > >Yours, >Joel > >On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >> Hi Kevin, >> >> Let me try and provide a concrete example to see if this answers your >> specific question: >> >> Use case: P-GW -> PCRF -> services applied to traffic based on >> applicationID and subscriberID. >> >> Instantiated as: >> >> SFC1: P-GW -> DPI -> PCRF >> SFC2: PCRF -> video-optimization -> metering -> FW >> SFC3: PCRF -> parental-control -> metering -> FW >> >> In this case DPI is performed on SFC1 and identifies applicationID. The >> applicationID is carried in the service encapsulation to PCRF. PCRF uses >> solution specific logic (identifies subscriber, applies policies, etc) >>and >> uses the result along with the applicationID received from DPI to select >> an outbound service chain, SFC2 or SFC3. Note that in this case >>branching >> occurs from SFC1 to either SFC2 or SFC3. >> >> >> >> >> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >> >>>> Yes, reclassification can change the service path and >>>> re-classification may happen at any node along a service path. >>> >>> Just to expand on that, going back to the original question about >>> service header encapsulation, is it intended that a chain that >>> is re-classified will get a new chain ID which fully describes >>> a chain that is a superset of the original chain ID, prior to >>> DPI-based re-classification? (assuming the goal is "a single >>> chain ID that is commonly understood along the entire service chain" >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>> >>> And the applicable subset of the permutative list of service >>> paths would be configured at each appropriate service node? >>> e.g., ID 1: NAT + firewall + DPI >>> ID 2: NAT + firewall + DPI + AV >>> ID 3: NAT + firewall + DPI + AV + NAT >>> ID 4: NAT + firewall + DPI + NAT >>> ID 5: NAT + firewall + DPI + AV + LB >>> ID 6: NAT + firewall + DPI + LB >>> ID 7: NAT + firewall + DPI + LB + CACHE >>> ID 8: NAT + firewall + DPI + CACHE >>> ID 9: NAT + firewall + DPI + optimizer + LB >>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> ID 11: NAT + firewall + DPI + optimizer + CACHE >>> Would every flow then be initially classified as ID 1, but >>> eventually get re-classified to ID 2-11, after the DPI phase? >>> >>> thanx. >>> >>> -- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>nsc@ietf.org >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >>>> >>>> >>>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>> >>>>> Hi Surendra, >>>>> >>>>> Classification may be out of scope, but the level of service that >>>>>is >>>>> applicable is dependent upon the level of classification that can >>>>>be >>>>> performed. An assumption of packet level encapsulation has >>>> implications >>>>> on the level of classification being performed? If the stated >>>>>goals >>>> are >>>>> for firewall and load balancer functionality, then the application >>>> level >>>>> nature of those functions needs to be taken into account? If, on >>>>>the >>>>> other hand, the service function scope is limited due to >>>>>limitations >>>> in >>>>> classification, that would be and important piece of information? >>>>> >>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>> points >>>>> of the service paths seem like re-classification points? Is that >>>>>the >>>>> interpretation from the architecture perspective? Or is the >>>>>service >>>>> function chain classification exclusive of DPI functionality? >>>> I have not fully read that draft yet. But in general, as >>>>described >>>> in >>>> the arch draft, the collection of services form a graph, segments of >>>> which >>>> are service paths. Yes, reclassification can change the service path >>>>and >>>> re-classification may happen at any node along a service path. >>>> >>>> Surendra. >>>>> >>>>> thanx. >>>>> >>>>> -- Kevin J. Ma >>>>> >>>>>> -----Original Message----- >>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>> >>>>>> Kevin, >>>>>> >>>>>> Classification mechanism is outside the scope of SFC. It can be >>>>>>based >>>> on >>>>>> the packet or information not in the packet(environmental attributes >>>> for >>>>>> instance) or a combination thereof. What is important is that such >>>>>> classification aids in traffic selection and service path >>>>>> identification. >>>>>> It is no different from a policy in this regard except that the >>>> policy >>>>>> now >>>>>> specifies the service path. >>>>>> Further, classification is not limited to the network elements but >>>> the >>>>>> service functions as well. Some of this is described in the >>>> architecture >>>>>> drafts as well - >>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>> >>>>>> Surendra. >>>>>> >>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>> >>>>>>> Hi Ron, >>>>>>> >>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but >>>> I >>>>>>> had a similar question wrt bullet 11 in section 2 of the problem >>>>>>> statement: >>>>>>> >>>>>>> 11. Per-Service (re)Classification: Classification occurs at >>>> each >>>>>>> service, independent from previously applied service >>>>>> functions. >>>>>>> These unrelated classification events consume resources >>>>>>>per >>>>>>> service. More importantly, the classification >>>> functionality >>>>>>> often differs per service function and service function >>>> cannot >>>>>>> leverage the results from other deployed network or >>>> service. >>>>>>> >>>>>>> as it relates to section 5.2 of the framework document: >>>>>>> >>>>>>> The SFC Classifier classifies packets based on (some of) the >>>>>> contents >>>>>>> of the packet header. Concretely, it classifies packets based >>>> on >>>>>> the >>>>>>> possible combination of one or more header fields, such as >>>> source >>>>>>> address, destination address, DS field, protocol ID, source >>>>>>>port >>>>>> and >>>>>>> destination port numbers, and any other information. >>>>>>> >>>>>>> A packet-based classifier as described in the framework document >>>>>> would >>>>>>> seem to be limited in what it can classify? The service function >>>>>>> identifier lookup does not seem to be a significant optimization >>>> over >>>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>>> detail >>>>>>> wrt how classification information is determined and reused? >>>>>>> >>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>> encrypted >>>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>>> wondering >>>>>>> how independent HLS segment requests might be classified and >>>>>> associated? >>>>>>> Were these types of use cases discussed in the BoF? >>>>>>> >>>>>>> thanx. >>>>>>> >>>>>>> -- Kevin J. Ma >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of >>>>>>>> Ron >>>>>>>> Parker >>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As was discussed in Vancouver, there are already many existing >>>> ways >>>>>> to >>>>>>>> accomplish service chaining. But none of them provide a >>>>>> sufficient >>>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>>> single >>>>>>>> service chain encapsulation will go a long way to ensuring these >>>>>> goals. >>>>>>>> It may not be the absolutely most efficient approach for every >>>>>> single >>>>>>>> network topology and every single use case, but its ubiquitous >>>> nature >>>>>>>> should improve its adoption. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> Absolutely, that was an example of one type of derivation. However >>>>>> this >>>>>>>> could be augmented with classification result, again one more >>>>>> example. >>>>>>>> >>>>>>>>>> All flows from the same source IP do not necessarily follow the >>>>>> same >>>>>>>> chain. >>>>>>>> Correct. It is also not necessary that all transaction of the same >>>>>> flow >>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>> >>>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>>> >>>>>>>> Sumandra >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> The intention of service function chaining is to allow for >>>> operation >>>>>> at >>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>> transaction >>>>>>>> level (this is an implementation matter for the PDP). All >>>> flows >>>>>> from >>>>>>>> the same source IP do not necessarily follow the same chain. >>>> Source >>>>>>>> IP, >>>>>>>> therefore, does not identify the chain ID. Another intention >>>> of >>>>>>>> service function chaining is to operate over any network topology >>>> and >>>>>>>> not >>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>>> transport, it does not adequately identify the service chain, >>>> either. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> The service header is meant to carry the context which can *also* >>>> be >>>>>>>> derived (for example use source ip and vlan to identify chainID >>>> and >>>>>>>> position) or encapsulated as part of another tunnel header. So >>>> this >>>>>>>> could >>>>>>>> be optional IMHO. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>> from >>>>>> SF >>>>>>>> to >>>>>>>> SF will look like: >>>>>>>> >>>>>>>> +------------------------+ >>>>>>>> | "transport" | >>>>>>>> +------------------------+ >>>>>>>> | service header | >>>>>>>> +------------------------+ >>>>>>>> | original IP header | >>>>>>>> +------------------------+ >>>>>>>> | | original IP payload >>>> | >>>>>>>> | | >>>>>>>> +------------------------+ >>>>>>>> >>>>>>>> Where service header contains, at a minimum, enough information to >>>>>> allow >>>>>>>> the packet to be propagated along the full length of the chain, >>>> and >>>>>>>> optionally, other metadata that enhances the operation of one or >>>> more >>>>>>>> service functions. >>>>>>>> >>>>>>>> And where "transport" could conceivably be any of, but not >>>> limited >>>>>> to: >>>>>>>> >>>>>>>> * Ethernet >>>>>>>> * Ethernet + LLC2 >>>>>>>> * Ethernet + MPLS >>>>>>>> * Ethernet + IP + GRE >>>>>>>> * Ethernet + IP +UDP >>>>>>>> >>>>>>>> >>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>> immutability, >>>>>>>> but rather to specify the packet that is propagated from preceding >>>>>>>> entity >>>>>>>> to succeeding entity, prior to encapsulation. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of >>>>>>>> Sumandra Majee >>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> [SM] What does it mean by a single service-level encapsulation, a >>>>>> new >>>>>>>> encapsulation format >>>>>>>> or an ability to select one encapsulation format that >>>>>> fits >>>>>>>> the >>>>>>>> need for a given service chain? >>>>>>>> The ability to select a specific encapsulation would >>>> be >>>> a >>>>>>>> management plane decision. >>>>>>>> There are quite a few existing encapsulation methods >>>> that >>>>>> can >>>>>>>> possibly be reused to provide >>>>>>>> context information between service nodes. I have >>>>>>>>seen >>>>>>>> mention >>>>>>>> of GRE, for HTTP based >>>>>>>> applications contexts are transferred via headers. >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of >>>>>>>> Thomas Narten >>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>> To: nsc@ietf.org >>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Hi. >>>>>>>> >>>>>>>> Current charter can be found at >>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>> ietf-sfc/. >>>>>>>> >>>>>>>> It contains the revised management text as well as updated >>>>>> milestones. >>>>>>>> >>>>>>>> All known issues have been addressed. If there are any remaining >>>>>> issues, >>>>>>>> please speak up! >>>>>>>> >>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>> >>>>>>>> Networks, servers, storage technologies, and applications, have >>>> all >>>>>>>> undergone significant change in recent years with the introduction >>>> of >>>>>>>> virtualization, network overlays, and orchestration. Service >>>> delivery >>>>>> is >>>>>>>> currently both a technical and organizational challenge that >>>> involves >>>>>>>> significant modification to the network configuration. >>>>>>>> Services are typically implemented by the ordered combination of a >>>>>>>> number >>>>>>>> of service functions that are deployed at different points within >>>> the >>>>>>>> network. Today, a common deployment model has service functions >>>>>>>> physically >>>>>>>> inserted on the data forwarding path between communicating peers. >>>>>> Going >>>>>>>> forward, however, there is a desire to move to a different model, >>>>>> where >>>>>>>> service functions are not required to reside on the default data >>>> path >>>>>>>> and >>>>>>>> traffic is instead steered through services, wherever they are >>>>>> deployed. >>>>>>>> >>>>>>>> For a given service, the abstracted view of the required service >>>>>>>> functions >>>>>>>> and the order in which they are to be applied is called a Service >>>>>>>> Function >>>>>>>> Chain (SFC). Since a given service function may be available on >>>> more >>>>>>>> than >>>>>>>> one node within a network, a Service Function Chain is >>>> instantiated >>>>>> via >>>>>>>> the selection of specific service function instances and the >>>> network >>>>>>>> nodes >>>>>>>> on which they are provided, thereby forming a service topology: >>>>>>>> this is called a Service Function Path. The service functions may >>>> be >>>>>>>> applied at a specific layer within the network protocol stack >>>>>> (network >>>>>>>> layer, application layer, etc.). >>>>>>>> >>>>>>>> The Service Function Chaining (SFC) working group will develop new >>>>>>>> approaches to service delivery and deployment. It will produce a >>>>>>>> framework >>>>>>>> for service function chaining that includes the necessary >>>> protocols >>>>>> or >>>>>>>> protocol extensions to convey the service path and service path >>>>>>>> information to nodes that implement service functions, as well as >>>>>>>> mechanisms for steering traffic through service functions. The >>>>>> working >>>>>>>> group will also examine what information needs to be gathered from >>>>>> the >>>>>>>> network and service functions in support of service function >>>> chaining >>>>>>>> and >>>>>>>> how that information may be made available to nodes that implement >>>>>> the >>>>>>>> service functions. >>>>>>>> >>>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>>> >>>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>>> problem space to be addressed by the WG including example >>>> high- >>>>>>>> level use cases. Additionally, the WG will normalize >>>> nomenclature >>>>>>>> and definitions for service function chaining. >>>>>>>> >>>>>>>> 2) Architecture: This document will provide a description of the >>>>>>>> architectural building blocks and their relationships >>>> including >>>>>>>> interconnection, placement of capabilities, management, >>>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>>> requirements on the protocol mechanisms. >>>>>>>> >>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>>> will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> 4) Control Plane Mechanisms: A set of documents will be developed >>>> to >>>>>>>> describe requirements and protocols necessary to convey >>>>>> information >>>>>>>> to service function implementation points. Where possible, >>>>>> existing >>>>>>>> IETF protocols will be used and extended. All protocol >>>> extensions >>>>>>>> work should be carried out in the working groups responsible >>>> for >>>>>> the >>>>>>>> protocols being modified in coordination with this working >>>> group, >>>>>>>> but >>>>>>>> may be done in this working group after agreement with all >>>>>>>>the >>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>> >>>>>>>> 5) Manageability: Work on the management and configuration of >>>> service >>>>>>>> functions in support of SFC components will certainly be >>>> needed, >>>>>>>> but first needs to be better understood and scoped. >>>>>>>> >>>>>>>> Proposed Milestones >>>>>>>> >>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>>> problem >>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>> >>>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>>> for >>>>>>>> management and configuration of SFC components >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>> architecture >>>>>>>> for SFC >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>> function >>>>>>>> chaining encapsulation protocol >>>>>>>> >>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>>> generic >>>>>>>> service function chaining header encapsulation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> From jmoisand@juniper.net Tue Nov 12 07:09:59 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6099511E8169 for ; Tue, 12 Nov 2013 07:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGvB9ZHT8pGl for ; Tue, 12 Nov 2013 07:09:54 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAAE11E8170 for ; Tue, 12 Nov 2013 07:09:44 -0800 (PST) Received: from mail145-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE015.bigfish.com (10.236.130.78) with Microsoft SMTP Server id 14.1.225.22; Tue, 12 Nov 2013 15:09:43 +0000 Received: from mail145-co9 (localhost [127.0.0.1]) by mail145-co9-R.bigfish.com (Postfix) with ESMTP id DBE433804AC; Tue, 12 Nov 2013 15:09:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail145-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(377454003)(479174003)(13464003)(74316001)(33646001)(4396001)(15975445006)(76786001)(76796001)(15202345003)(54356001)(76576001)(81686001)(49866001)(81816001)(31966008)(77096001)(56816003)(74876001)(63696002)(81342001)(46102001)(2656002)(74706001)(69226001)(51856001)(74366001)(77982001)(59766001)(80976001)(47446002)(83072001)(551934002)(74502001)(74662001)(87936001)(79102001)(81542001)(76482001)(47976001)(50986001)(47736001)(54316002)(56776001)(65816001)(66066001)(85306002)(19580405001)(53806001)(83322001)(87266001)(19580395003)(80022001)(24736002)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB249; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail145-co9 (localhost.localdomain [127.0.0.1]) by mail145-co9 (MessageSwitch) id 1384268981404137_1758; Tue, 12 Nov 2013 15:09:41 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.232]) by mail145-co9.bigfish.com (Postfix) with ESMTP id 5CB95360202; Tue, 12 Nov 2013 15:09:41 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 12 Nov 2013 15:09:40 +0000 Received: from BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Tue, 12 Nov 2013 15:09:38 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) with Microsoft SMTP Server (TLS) id 15.0.810.5; Tue, 12 Nov 2013 15:09:25 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.83]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.180]) with mapi id 15.00.0815.000; Tue, 12 Nov 2013 15:09:25 +0000 From: Jerome Moisand To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgAAQvYCAACcIgIAAAa2AgAACJYCAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAHlxAIAACW8AgAAHVVA= Date: Tue, 12 Nov 2013 15:09:24 +0000 Message-ID: <06825c9329714f04ac0ce09ae995f7ed@BN1PR05MB251.namprd05.prod.outlook.com> References: <52823DF6.5050306@joelhalpern.com> In-Reply-To: <52823DF6.5050306@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.11] x-forefront-prvs: 00286C0CA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:09:59 -0000 No clue what you guys are discussing.=20 PCRF (when relevant for a given type of domain, e.g. mobile broadband) has = a role to play in service chaining for sure, but... A PCRF is a control pla= ne element, not a data plane element. It is not part of a service chain, it= would control (part of) it. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: Tuesday, November 12, 2013 9:41 AM To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Park= er; Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Jim, thank you for a concrete example. I would suggest that in the usual cases, there is a better way to handle th= is than branching and rewriting at the PCRF. If the DPI engine or PCRF logic (whichever makes the decision) notifies the= control logic about the decision for the flow, then the ingress can direct= subsequent packets to the correct place, avoiding needless processing of f= urther packets in the DPI and PCRF logic. Further, the needed control information can be passed to the optimization o= r parental control so that it does not matter where the first packet is sen= t, avoiding the need for the PCRF to understand how to direct packets to se= rvice paths. Yours, Joel On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: > Hi Kevin, > > Let me try and provide a concrete example to see if this answers your=20 > specific question: > > Use case: P-GW -> PCRF -> services applied to traffic based on=20 > applicationID and subscriberID. > > Instantiated as: > > SFC1: P-GW -> DPI -> PCRF > SFC2: PCRF -> video-optimization -> metering -> FW > SFC3: PCRF -> parental-control -> metering -> FW > > In this case DPI is performed on SFC1 and identifies applicationID.=20 > The applicationID is carried in the service encapsulation to PCRF.=20 > PCRF uses solution specific logic (identifies subscriber, applies=20 > policies, etc) and uses the result along with the applicationID=20 > received from DPI to select an outbound service chain, SFC2 or SFC3.=20 > Note that in this case branching occurs from SFC1 to either SFC2 or SFC3. > > > > > On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > >>> Yes, reclassification can change the service path and=20 >>> re-classification may happen at any node along a service path. >> >> Just to expand on that, going back to the original question about=20 >> service header encapsulation, is it intended that a chain that is=20 >> re-classified will get a new chain ID which fully describes a chain=20 >> that is a superset of the original chain ID, prior to DPI-based=20 >> re-classification? (assuming the goal is "a single chain ID that is=20 >> commonly understood along the entire service chain" >> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> >> And the applicable subset of the permutative list of service paths=20 >> would be configured at each appropriate service node? >> e.g., ID 1: NAT + firewall + DPI >> ID 2: NAT + firewall + DPI + AV >> ID 3: NAT + firewall + DPI + AV + NAT >> ID 4: NAT + firewall + DPI + NAT >> ID 5: NAT + firewall + DPI + AV + LB >> ID 6: NAT + firewall + DPI + LB >> ID 7: NAT + firewall + DPI + LB + CACHE >> ID 8: NAT + firewall + DPI + CACHE >> ID 9: NAT + firewall + DPI + optimizer + LB >> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every=20 >> flow then be initially classified as ID 1, but eventually get=20 >> re-classified to ID 2-11, after the DPI phase? >> >> thanx. >> >> -- Kevin J. Ma >> >>> -----Original Message----- >>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:01 AM >>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> nsc@ietf.org >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> >>> >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>> >>>> Hi Surendra, >>>> >>>> Classification may be out of scope, but the level of service that is >>>> applicable is dependent upon the level of classification that can be >>>> performed. An assumption of packet level encapsulation has >>> implications >>>> on the level of classification being performed? If the stated=20 >>>> goals >>> are >>>> for firewall and load balancer functionality, then the=20 >>>> application >>> level >>>> nature of those functions needs to be taken into account? If, on th= e >>>> other hand, the service function scope is limited due to=20 >>>> limitations >>> in >>>> classification, that would be and important piece of information? >>>> >>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>> points >>>> of the service paths seem like re-classification points? Is that th= e >>>> interpretation from the architecture perspective? Or is the service >>>> function chain classification exclusive of DPI functionality? >>> I have not fully read that draft yet. But in general, as=20 >>> described in the arch draft, the collection of services form a=20 >>> graph, segments of which are service paths. Yes, reclassification=20 >>> can change the service path and re-classification may happen at any=20 >>> node along a service path. >>> >>> Surendra. >>>> >>>> thanx. >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- >>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> nsc@ietf.org >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>> >>>>> Kevin, >>>>> >>>>> Classification mechanism is outside the scope of SFC. It can be=20 >>>>> based >>> on >>>>> the packet or information not in the packet(environmental=20 >>>>> attributes >>> for >>>>> instance) or a combination thereof. What is important is that such=20 >>>>> classification aids in traffic selection and service path=20 >>>>> identification. >>>>> It is no different from a policy in this regard except that the >>> policy >>>>> now >>>>> specifies the service path. >>>>> Further, classification is not limited to the network elements but >>> the >>>>> service functions as well. Some of this is described in the >>> architecture >>>>> drafts as well - >>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>> >>>>> Surendra. >>>>> >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>> >>>>>> Hi Ron, >>>>>> >>>>>> I was unable to make the SFC BoF due to a conflict with CDNI,=20 >>>>>> but >>> I >>>>>> had a similar question wrt bullet 11 in section 2 of the=20 >>>>>> problem >>>>>> statement: >>>>>> >>>>>> 11. Per-Service (re)Classification: Classification occurs at >>> each >>>>>> service, independent from previously applied service >>>>> functions. >>>>>> These unrelated classification events consume resources per >>>>>> service. More importantly, the classification >>> functionality >>>>>> often differs per service function and service function >>> cannot >>>>>> leverage the results from other deployed network or >>> service. >>>>>> >>>>>> as it relates to section 5.2 of the framework document: >>>>>> >>>>>> The SFC Classifier classifies packets based on (some of) the >>>>> contents >>>>>> of the packet header. Concretely, it classifies packets=20 >>>>>> based >>> on >>>>> the >>>>>> possible combination of one or more header fields, such as >>> source >>>>>> address, destination address, DS field, protocol ID, source=20 >>>>>> port >>>>> and >>>>>> destination port numbers, and any other information. >>>>>> >>>>>> A packet-based classifier as described in the framework=20 >>>>>> document >>>>> would >>>>>> seem to be limited in what it can classify? The service function >>>>>> identifier lookup does not seem to be a significant=20 >>>>>> optimization >>> over >>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>> detail >>>>>> wrt how classification information is determined and reused? >>>>>> >>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>> encrypted >>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>> wondering >>>>>> how independent HLS segment requests might be classified and >>>>> associated? >>>>>> Were these types of use cases discussed in the BoF? >>>>>> >>>>>> thanx. >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>> Behalf >>> Of >>>>>>> Ron >>>>>>> Parker >>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As was discussed in Vancouver, there are already many existing >>> ways >>>>> to >>>>>>> accomplish service chaining. But none of them provide a >>>>> sufficient >>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>> single >>>>>>> service chain encapsulation will go a long way to ensuring these >>>>> goals. >>>>>>> It may not be the absolutely most efficient approach for every >>>>> single >>>>>>> network topology and every single use case, but its ubiquitous >>> nature >>>>>>> should improve its adoption. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> Absolutely, that was an example of one type of derivation.=20 >>>>>>> However >>>>> this >>>>>>> could be augmented with classification result, again one more >>>>> example. >>>>>>> >>>>>>>>> All flows from the same source IP do not necessarily follow=20 >>>>>>>>> the >>>>> same >>>>>>> chain. >>>>>>> Correct. It is also not necessary that all transaction of the=20 >>>>>>> same >>>>> flow >>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>> >>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>> >>>>>>> Sumandra >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> The intention of service function chaining is to allow for >>> operation >>>>> at >>>>>>> the fully qualified flow level, or even finer grained at the >>>>> transaction >>>>>>> level (this is an implementation matter for the PDP). All >>> flows >>>>> from >>>>>>> the same source IP do not necessarily follow the same chain. >>> Source >>>>>>> IP, >>>>>>> therefore, does not identify the chain ID. Another intention >>> of >>>>>>> service function chaining is to operate over any network=20 >>>>>>> topology >>> and >>>>>>> not >>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>> transport, it does not adequately identify the service chain, >>> either. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> The service header is meant to carry the context which can=20 >>>>>>> *also* >>> be >>>>>>> derived (for example use source ip and vlan to identify chainID >>> and >>>>>>> position) or encapsulated as part of another tunnel header. So >>> this >>>>>>> could >>>>>>> be optional IMHO. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>> from >>>>> SF >>>>>>> to >>>>>>> SF will look like: >>>>>>> >>>>>>> +------------------------+ >>>>>>> | "transport" | >>>>>>> +------------------------+ >>>>>>> | service header | >>>>>>> +------------------------+ >>>>>>> | original IP header | >>>>>>> +------------------------+ >>>>>>> | | original IP payload >>> | >>>>>>> | | >>>>>>> +------------------------+ >>>>>>> >>>>>>> Where service header contains, at a minimum, enough information=20 >>>>>>> to >>>>> allow >>>>>>> the packet to be propagated along the full length of the chain, >>> and >>>>>>> optionally, other metadata that enhances the operation of one or >>> more >>>>>>> service functions. >>>>>>> >>>>>>> And where "transport" could conceivably be any of, but not >>> limited >>>>> to: >>>>>>> >>>>>>> * Ethernet >>>>>>> * Ethernet + LLC2 >>>>>>> * Ethernet + MPLS >>>>>>> * Ethernet + IP + GRE >>>>>>> * Ethernet + IP +UDP >>>>>>> >>>>>>> >>>>>>> Also, "original" in the diagram above is not meant to imply=20 >>>>>>> immutability, but rather to specify the packet that is=20 >>>>>>> propagated from preceding entity to succeeding entity, prior to=20 >>>>>>> encapsulation. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>> Behalf >>> Of >>>>>>> Sumandra Majee >>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service=20 >>>>>>> function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be=20 >>>>>>> used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> [SM] What does it mean by a single service-level encapsulation, =20 >>>>>>> a >>>>> new >>>>>>> encapsulation format >>>>>>> or an ability to select one encapsulation format=20 >>>>>>> that >>>>> fits >>>>>>> the >>>>>>> need for a given service chain? >>>>>>> The ability to select a specific encapsulation =20 >>>>>>> would >>> be >>> a >>>>>>> management plane decision. >>>>>>> There are quite a few existing encapsulation methods >>> that >>>>> can >>>>>>> possibly be reused to provide >>>>>>> context information between service nodes. I have seen >>>>>>> mention >>>>>>> of GRE, for HTTP based >>>>>>> applications contexts are transferred via headers. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>> Behalf >>> Of >>>>>>> Thomas Narten >>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>> To: nsc@ietf.org >>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Current charter can be found at >>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>> ietf-sfc/. >>>>>>> >>>>>>> It contains the revised management text as well as updated >>>>> milestones. >>>>>>> >>>>>>> All known issues have been addressed. If there are any remaining >>>>> issues, >>>>>>> please speak up! >>>>>>> >>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>> >>>>>>> Networks, servers, storage technologies, and applications, have >>> all >>>>>>> undergone significant change in recent years with the=20 >>>>>>> introduction >>> of >>>>>>> virtualization, network overlays, and orchestration. Service >>> delivery >>>>> is >>>>>>> currently both a technical and organizational challenge that >>> involves >>>>>>> significant modification to the network configuration. >>>>>>> Services are typically implemented by the ordered combination of=20 >>>>>>> a number of service functions that are deployed at different=20 >>>>>>> points within >>> the >>>>>>> network. Today, a common deployment model has service functions=20 >>>>>>> physically inserted on the data forwarding path between=20 >>>>>>> communicating peers. >>>>> Going >>>>>>> forward, however, there is a desire to move to a different=20 >>>>>>> model, >>>>> where >>>>>>> service functions are not required to reside on the default data >>> path >>>>>>> and >>>>>>> traffic is instead steered through services, wherever they are >>>>> deployed. >>>>>>> >>>>>>> For a given service, the abstracted view of the required service=20 >>>>>>> functions and the order in which they are to be applied is=20 >>>>>>> called a Service Function Chain (SFC). Since a given service=20 >>>>>>> function may be available on >>> more >>>>>>> than >>>>>>> one node within a network, a Service Function Chain is >>> instantiated >>>>> via >>>>>>> the selection of specific service function instances and the >>> network >>>>>>> nodes >>>>>>> on which they are provided, thereby forming a service topology: >>>>>>> this is called a Service Function Path. The service functions=20 >>>>>>> may >>> be >>>>>>> applied at a specific layer within the network protocol stack >>>>> (network >>>>>>> layer, application layer, etc.). >>>>>>> >>>>>>> The Service Function Chaining (SFC) working group will develop=20 >>>>>>> new approaches to service delivery and deployment. It will=20 >>>>>>> produce a framework for service function chaining that includes=20 >>>>>>> the necessary >>> protocols >>>>> or >>>>>>> protocol extensions to convey the service path and service path=20 >>>>>>> information to nodes that implement service functions, as well=20 >>>>>>> as mechanisms for steering traffic through service functions.=20 >>>>>>> The >>>>> working >>>>>>> group will also examine what information needs to be gathered=20 >>>>>>> from >>>>> the >>>>>>> network and service functions in support of service function >>> chaining >>>>>>> and >>>>>>> how that information may be made available to nodes that=20 >>>>>>> implement >>>>> the >>>>>>> service functions. >>>>>>> >>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>> >>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>> problem space to be addressed by the WG including example >>> high- >>>>>>> level use cases. Additionally, the WG will normalize >>> nomenclature >>>>>>> and definitions for service function chaining. >>>>>>> >>>>>>> 2) Architecture: This document will provide a description of the >>>>>>> architectural building blocks and their relationships >>> including >>>>>>> interconnection, placement of capabilities, management, >>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>> requirements on the protocol mechanisms. >>>>>>> >>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>> will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service=20 >>>>>>> function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be=20 >>>>>>> used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> 4) Control Plane Mechanisms: A set of documents will be=20 >>>>>>> developed >>> to >>>>>>> describe requirements and protocols necessary to convey >>>>> information >>>>>>> to service function implementation points. Where possible, >>>>> existing >>>>>>> IETF protocols will be used and extended. All protocol >>> extensions >>>>>>> work should be carried out in the working groups=20 >>>>>>> responsible >>> for >>>>> the >>>>>>> protocols being modified in coordination with this working >>> group, >>>>>>> but >>>>>>> may be done in this working group after agreement with all the >>>>>>> relevant WG chairs and responsible ADs. >>>>>>> >>>>>>> 5) Manageability: Work on the management and configuration of >>> service >>>>>>> functions in support of SFC components will certainly be >>> needed, >>>>>>> but first needs to be better understood and scoped. >>>>>>> >>>>>>> Proposed Milestones >>>>>>> >>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>> problem >>>>>>> statement and core use cases for Service Function Chaining >>>>>>> >>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>> for >>>>>>> management and configuration of SFC components >>>>>>> >>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>> architecture >>>>>>> for SFC >>>>>>> >>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>> function >>>>>>> chaining encapsulation protocol >>>>>>> >>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>> generic >>>>>>> service function chaining header encapsulation >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Tue Nov 12 07:28:21 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9903B21E8170 for ; Tue, 12 Nov 2013 07:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a24wg+6eJiDz for ; Tue, 12 Nov 2013 07:28:17 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 744F811E8149 for ; Tue, 12 Nov 2013 07:28:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU65882; Tue, 12 Nov 2013 15:28:14 +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, 12 Nov 2013 15:28:00 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 15:28:14 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 07:28:07 -0800 From: Linda Dunbar To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN+0+4iz5RRxkOCS0vXxMG0/5ohQBeAgAAOHICAACcJgIAAAa2AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAHlxAIAACW8AgAADV4D//4NRMA== Date: Tue, 12 Nov 2013 15:28:07 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C05373@dfweml509-mbx.china.huawei.com> References: <52823DF6.5050306@joelhalpern.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:28:22 -0000 Maybe a better example for branching is at the DPI service function. Depend= ing on the content, the flow can to go to video optimization function or we= b optimization function.=20 Linda=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jim Guichard (jguichar) > Sent: Tuesday, November 12, 2013 8:53 AM > To: Joel M. Halpern; Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; > Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Yes optimization can certainly be built into this but I wanted to show > an > example of the types of things we mean when we talk about branching. > Once > the concept is better understood I think we will see some more exciting > examples. Note also that the control logic could also utilize the > service > encapsulation as a mechanism to push notifications back up the original > chain to inform the ingress to bypass the original chain for all > subsequent packets for this flow. >=20 > On 11/12/13 9:40 AM, "Joel M. Halpern" wrote: >=20 > >Jim, thank you for a concrete example. > >I would suggest that in the usual cases, there is a better way to > handle > >this than branching and rewriting at the PCRF. > > > >If the DPI engine or PCRF logic (whichever makes the decision) > notifies > >the control logic about the decision for the flow, then the ingress > can > >direct subsequent packets to the correct place, avoiding needless > >processing of further packets in the DPI and PCRF logic. > >Further, the needed control information can be passed to the > >optimization or parental control so that it does not matter where the > >first packet is sent, avoiding the need for the PCRF to understand how > >to direct packets to service paths. > > > >Yours, > >Joel > > > >On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: > >> Hi Kevin, > >> > >> Let me try and provide a concrete example to see if this answers > your > >> specific question: > >> > >> Use case: P-GW -> PCRF -> services applied to traffic based on > >> applicationID and subscriberID. > >> > >> Instantiated as: > >> > >> SFC1: P-GW -> DPI -> PCRF > >> SFC2: PCRF -> video-optimization -> metering -> FW > >> SFC3: PCRF -> parental-control -> metering -> FW > >> > >> In this case DPI is performed on SFC1 and identifies applicationID. > The > >> applicationID is carried in the service encapsulation to PCRF. PCRF > uses > >> solution specific logic (identifies subscriber, applies policies, > etc) > >>and > >> uses the result along with the applicationID received from DPI to > select > >> an outbound service chain, SFC2 or SFC3. Note that in this case > >>branching > >> occurs from SFC1 to either SFC2 or SFC3. > >> > >> > >> > >> > >> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > >> > >>>> Yes, reclassification can change the service path and > >>>> re-classification may happen at any node along a service path. > >>> > >>> Just to expand on that, going back to the original question about > >>> service header encapsulation, is it intended that a chain that > >>> is re-classified will get a new chain ID which fully describes > >>> a chain that is a superset of the original chain ID, prior to > >>> DPI-based re-classification? (assuming the goal is "a single > >>> chain ID that is commonly understood along the entire service > chain" > >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >>> > >>> And the applicable subset of the permutative list of service > >>> paths would be configured at each appropriate service node? > >>> e.g., ID 1: NAT + firewall + DPI > >>> ID 2: NAT + firewall + DPI + AV > >>> ID 3: NAT + firewall + DPI + AV + NAT > >>> ID 4: NAT + firewall + DPI + NAT > >>> ID 5: NAT + firewall + DPI + AV + LB > >>> ID 6: NAT + firewall + DPI + LB > >>> ID 7: NAT + firewall + DPI + LB + CACHE > >>> ID 8: NAT + firewall + DPI + CACHE > >>> ID 9: NAT + firewall + DPI + optimizer + LB > >>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > >>> ID 11: NAT + firewall + DPI + optimizer + CACHE > >>> Would every flow then be initially classified as ID 1, but > >>> eventually get re-classified to ID 2-11, after the DPI phase? > >>> > >>> thanx. > >>> > >>> -- Kevin J. Ma > >>> > >>>> -----Original Message----- > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >>>> Sent: Tuesday, November 12, 2013 1:01 AM > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>>>nsc@ietf.org > >>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>> > >>>> > >>>> > >>>> On 11/11/13 9:46 PM, "Kevin J Ma" > wrote: > >>>> > >>>>> Hi Surendra, > >>>>> > >>>>> Classification may be out of scope, but the level of service > that > >>>>>is > >>>>> applicable is dependent upon the level of classification that > can > >>>>>be > >>>>> performed. An assumption of packet level encapsulation has > >>>> implications > >>>>> on the level of classification being performed? If the stated > >>>>>goals > >>>> are > >>>>> for firewall and load balancer functionality, then the > application > >>>> level > >>>>> nature of those functions needs to be taken into account? If, > on > >>>>>the > >>>>> other hand, the service function scope is limited due to > >>>>>limitations > >>>> in > >>>>> classification, that would be and important piece of > information? > >>>>> > >>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the > fork > >>>> points > >>>>> of the service paths seem like re-classification points? Is > that > >>>>>the > >>>>> interpretation from the architecture perspective? Or is the > >>>>>service > >>>>> function chain classification exclusive of DPI functionality? > >>>> I have not fully read that draft yet. But in general, as > >>>>described > >>>> in > >>>> the arch draft, the collection of services form a graph, segments > of > >>>> which > >>>> are service paths. Yes, reclassification can change the service > path > >>>>and > >>>> re-classification may happen at any node along a service path. > >>>> > >>>> Surendra. > >>>>> > >>>>> thanx. > >>>>> > >>>>> -- Kevin J. Ma > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >>>>>> Sent: Tuesday, November 12, 2013 12:08 AM > >>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>>> nsc@ietf.org > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Kevin, > >>>>>> > >>>>>> Classification mechanism is outside the scope of SFC. It can be > >>>>>>based > >>>> on > >>>>>> the packet or information not in the packet(environmental > attributes > >>>> for > >>>>>> instance) or a combination thereof. What is important is that > such > >>>>>> classification aids in traffic selection and service path > >>>>>> identification. > >>>>>> It is no different from a policy in this regard except that the > >>>> policy > >>>>>> now > >>>>>> specifies the service path. > >>>>>> Further, classification is not limited to the network elements > but > >>>> the > >>>>>> service functions as well. Some of this is described in the > >>>> architecture > >>>>>> drafts as well - > >>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >>>>>> > >>>>>> Surendra. > >>>>>> > >>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > wrote: > >>>>>> > >>>>>>> Hi Ron, > >>>>>>> > >>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > but > >>>> I > >>>>>>> had a similar question wrt bullet 11 in section 2 of the > problem > >>>>>>> statement: > >>>>>>> > >>>>>>> 11. Per-Service (re)Classification: Classification occurs > at > >>>> each > >>>>>>> service, independent from previously applied service > >>>>>> functions. > >>>>>>> These unrelated classification events consume > resources > >>>>>>>per > >>>>>>> service. More importantly, the classification > >>>> functionality > >>>>>>> often differs per service function and service > function > >>>> cannot > >>>>>>> leverage the results from other deployed network or > >>>> service. > >>>>>>> > >>>>>>> as it relates to section 5.2 of the framework document: > >>>>>>> > >>>>>>> The SFC Classifier classifies packets based on (some of) > the > >>>>>> contents > >>>>>>> of the packet header. Concretely, it classifies packets > based > >>>> on > >>>>>> the > >>>>>>> possible combination of one or more header fields, such as > >>>> source > >>>>>>> address, destination address, DS field, protocol ID, source > >>>>>>>port > >>>>>> and > >>>>>>> destination port numbers, and any other information. > >>>>>>> > >>>>>>> A packet-based classifier as described in the framework > document > >>>>>> would > >>>>>>> seem to be limited in what it can classify? The service > function > >>>>>>> identifier lookup does not seem to be a significant > optimization > >>>> over > >>>>>>> a packet-based 5-tuple lookup? There seems to be some > missing > >>>> detail > >>>>>>> wrt how classification information is determined and reused? > >>>>>>> > >>>>>>> When thinking about higher level services, e.g., HTTP and TLS > >>>>>> encrypted > >>>>>>> flows, a packet-based classifier seems inadequate? I was > also > >>>>>> wondering > >>>>>>> how independent HLS segment requests might be classified and > >>>>>> associated? > >>>>>>> Were these types of use cases discussed in the BoF? > >>>>>>> > >>>>>>> thanx. > >>>>>>> > >>>>>>> -- Kevin J. Ma > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>>>> Ron > >>>>>>>> Parker > >>>>>>>> Sent: Monday, November 11, 2013 10:16 PM > >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Sumandra, > >>>>>>>> > >>>>>>>> As was discussed in Vancouver, there are already many existing > >>>> ways > >>>>>> to > >>>>>>>> accomplish service chaining. But none of them provide a > >>>>>> sufficient > >>>>>>>> combination of interoperability, flexibility, and resiliency. > A > >>>>>> single > >>>>>>>> service chain encapsulation will go a long way to ensuring > these > >>>>>> goals. > >>>>>>>> It may not be the absolutely most efficient approach for > every > >>>>>> single > >>>>>>>> network topology and every single use case, but its ubiquitous > >>>> nature > >>>>>>>> should improve its adoption. > >>>>>>>> > >>>>>>>> Ron > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>>>> Sent: Monday, November 11, 2013 10:10 PM > >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Ron, > >>>>>>>> > >>>>>>>> Absolutely, that was an example of one type of derivation. > However > >>>>>> this > >>>>>>>> could be augmented with classification result, again one more > >>>>>> example. > >>>>>>>> > >>>>>>>>>> All flows from the same source IP do not necessarily follow > the > >>>>>> same > >>>>>>>> chain. > >>>>>>>> Correct. It is also not necessary that all transaction of the > same > >>>>>> flow > >>>>>>>> follow the same chain either. So why stop at flow itself. > >>>>>>>> > >>>>>>>> Again the point here is that do we always need SFC header or > Not. > >>>>>>>> > >>>>>>>> Sumandra > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>>>> Sent: Monday, November 11, 2013 7:02 PM > >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Sumandra, > >>>>>>>> > >>>>>>>> The intention of service function chaining is to allow for > >>>> operation > >>>>>> at > >>>>>>>> the fully qualified flow level, or even finer grained at the > >>>>>> transaction > >>>>>>>> level (this is an implementation matter for the PDP). All > >>>> flows > >>>>>> from > >>>>>>>> the same source IP do not necessarily follow the same chain. > >>>> Source > >>>>>>>> IP, > >>>>>>>> therefore, does not identify the chain ID. Another > intention > >>>> of > >>>>>>>> service function chaining is to operate over any network > topology > >>>> and > >>>>>>>> not > >>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of > the > >>>>>>>> transport, it does not adequately identify the service chain, > >>>> either. > >>>>>>>> > >>>>>>>> Ron > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>>>> Sent: Monday, November 11, 2013 9:56 PM > >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Ron, > >>>>>>>> > >>>>>>>> The service header is meant to carry the context which can > *also* > >>>> be > >>>>>>>> derived (for example use source ip and vlan to identify > chainID > >>>> and > >>>>>>>> position) or encapsulated as part of another tunnel header. So > >>>> this > >>>>>>>> could > >>>>>>>> be optional IMHO. > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>>>> Sent: Monday, November 11, 2013 4:36 PM > >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Sumandra, > >>>>>>>> > >>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or > >>>> from > >>>>>> SF > >>>>>>>> to > >>>>>>>> SF will look like: > >>>>>>>> > >>>>>>>> +------------------------+ > >>>>>>>> | "transport" | > >>>>>>>> +------------------------+ > >>>>>>>> | service header | > >>>>>>>> +------------------------+ > >>>>>>>> | original IP header | > >>>>>>>> +------------------------+ > >>>>>>>> | | original IP > payload > >>>> | > >>>>>>>> | | > >>>>>>>> +------------------------+ > >>>>>>>> > >>>>>>>> Where service header contains, at a minimum, enough > information to > >>>>>> allow > >>>>>>>> the packet to be propagated along the full length of the chain, > >>>> and > >>>>>>>> optionally, other metadata that enhances the operation of one > or > >>>> more > >>>>>>>> service functions. > >>>>>>>> > >>>>>>>> And where "transport" could conceivably be any of, but not > >>>> limited > >>>>>> to: > >>>>>>>> > >>>>>>>> * Ethernet > >>>>>>>> * Ethernet + LLC2 > >>>>>>>> * Ethernet + MPLS > >>>>>>>> * Ethernet + IP + GRE > >>>>>>>> * Ethernet + IP +UDP > >>>>>>>> > >>>>>>>> > >>>>>>>> Also, "original" in the diagram above is not meant to imply > >>>>>>>> immutability, > >>>>>>>> but rather to specify the packet that is propagated from > preceding > >>>>>>>> entity > >>>>>>>> to succeeding entity, prior to encapsulation. > >>>>>>>> > >>>>>>>> Ron > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>>>> Sumandra Majee > >>>>>>>> Sent: Monday, November 11, 2013 6:46 PM > >>>>>>>> To: Thomas Narten; nsc@ietf.org > >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Generic Service Function Chaining Encapsulation: A document > will > >>>>>>>> describe the single service-level data plane > encapsulation > >>>> format > >>>>>>>> for > >>>>>>>> conveying the service function chain and the service > function > >>>>>> path, > >>>>>>>> and for communicating context information between nodes > that > >>>>>>>> implement service functions. It is intended that the > >>>>>> encapsulation > >>>>>>>> be agnostic to the layer at which it is applied and the > >>>> service > >>>>>> that > >>>>>>>> is > >>>>>>>> being constructed. That is, the same encapsulation may be > >>>>>>>>used > >>>> on > >>>>>>>> a service function path realized at the network layer or > at > >>>> any > >>>>>>>> other > >>>>>>>> layer, and the same encapsulation will apply for the > >>>> construction > >>>>>> of > >>>>>>>> service function paths regardless of the actual service. > >>>>>>>> > >>>>>>>> [SM] What does it mean by a single service-level encapsulation, > a > >>>>>> new > >>>>>>>> encapsulation format > >>>>>>>> or an ability to select one encapsulation format > that > >>>>>> fits > >>>>>>>> the > >>>>>>>> need for a given service chain? > >>>>>>>> The ability to select a specific encapsulation > would > >>>> be > >>>> a > >>>>>>>> management plane decision. > >>>>>>>> There are quite a few existing encapsulation > methods > >>>> that > >>>>>> can > >>>>>>>> possibly be reused to provide > >>>>>>>> context information between service nodes. I have > >>>>>>>>seen > >>>>>>>> mention > >>>>>>>> of GRE, for HTTP based > >>>>>>>> applications contexts are transferred via headers. > >>>>>>>> > >>>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >>>> Of > >>>>>>>> Thomas Narten > >>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >>>>>>>> To: nsc@ietf.org > >>>>>>>> Subject: [nsc] Current Proposed SFC charter > >>>>>>>> > >>>>>>>> Hi. > >>>>>>>> > >>>>>>>> Current charter can be found at > >>>>>>>> https://datatracker.ietf.org/doc/charter- > >>>>>>>> ietf-sfc/. > >>>>>>>> > >>>>>>>> It contains the revised management text as well as updated > >>>>>> milestones. > >>>>>>>> > >>>>>>>> All known issues have been addressed. If there are any > remaining > >>>>>> issues, > >>>>>>>> please speak up! > >>>>>>>> > >>>>>>>> Charter charter-ietf-sfc-00-04 > >>>>>>>> > >>>>>>>> Networks, servers, storage technologies, and applications, > have > >>>> all > >>>>>>>> undergone significant change in recent years with the > introduction > >>>> of > >>>>>>>> virtualization, network overlays, and orchestration. Service > >>>> delivery > >>>>>> is > >>>>>>>> currently both a technical and organizational challenge that > >>>> involves > >>>>>>>> significant modification to the network configuration. > >>>>>>>> Services are typically implemented by the ordered combination > of a > >>>>>>>> number > >>>>>>>> of service functions that are deployed at different points > within > >>>> the > >>>>>>>> network. Today, a common deployment model has service > functions > >>>>>>>> physically > >>>>>>>> inserted on the data forwarding path between communicating > peers. > >>>>>> Going > >>>>>>>> forward, however, there is a desire to move to a different > model, > >>>>>> where > >>>>>>>> service functions are not required to reside on the default > data > >>>> path > >>>>>>>> and > >>>>>>>> traffic is instead steered through services, wherever they are > >>>>>> deployed. > >>>>>>>> > >>>>>>>> For a given service, the abstracted view of the required > service > >>>>>>>> functions > >>>>>>>> and the order in which they are to be applied is called a > Service > >>>>>>>> Function > >>>>>>>> Chain (SFC). Since a given service function may be available > on > >>>> more > >>>>>>>> than > >>>>>>>> one node within a network, a Service Function Chain is > >>>> instantiated > >>>>>> via > >>>>>>>> the selection of specific service function instances and the > >>>> network > >>>>>>>> nodes > >>>>>>>> on which they are provided, thereby forming a service topology: > >>>>>>>> this is called a Service Function Path. The service functions > may > >>>> be > >>>>>>>> applied at a specific layer within the network protocol stack > >>>>>> (network > >>>>>>>> layer, application layer, etc.). > >>>>>>>> > >>>>>>>> The Service Function Chaining (SFC) working group will develop > new > >>>>>>>> approaches to service delivery and deployment. It will produce > a > >>>>>>>> framework > >>>>>>>> for service function chaining that includes the necessary > >>>> protocols > >>>>>> or > >>>>>>>> protocol extensions to convey the service path and service > path > >>>>>>>> information to nodes that implement service functions, as well > as > >>>>>>>> mechanisms for steering traffic through service functions. The > >>>>>> working > >>>>>>>> group will also examine what information needs to be gathered > from > >>>>>> the > >>>>>>>> network and service functions in support of service function > >>>> chaining > >>>>>>>> and > >>>>>>>> how that information may be made available to nodes that > implement > >>>>>> the > >>>>>>>> service functions. > >>>>>>>> > >>>>>>>> Specifically, the SFC WG is chartered to deliver the following: > >>>>>>>> > >>>>>>>> 1) Problem Statement: This document will provide a summary of > the > >>>>>>>> problem space to be addressed by the WG including example > >>>> high- > >>>>>>>> level use cases. Additionally, the WG will normalize > >>>> nomenclature > >>>>>>>> and definitions for service function chaining. > >>>>>>>> > >>>>>>>> 2) Architecture: This document will provide a description of > the > >>>>>>>> architectural building blocks and their relationships > >>>> including > >>>>>>>> interconnection, placement of capabilities, management, > >>>>>>>> diagnostics, design analysis, and security models, as > well as > >>>>>>>> requirements on the protocol mechanisms. > >>>>>>>> > >>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document > >>>> will > >>>>>>>> describe the single service-level data plane > encapsulation > >>>> format > >>>>>>>> for > >>>>>>>> conveying the service function chain and the service > function > >>>>>> path, > >>>>>>>> and for communicating context information between nodes > that > >>>>>>>> implement service functions. It is intended that the > >>>>>> encapsulation > >>>>>>>> be agnostic to the layer at which it is applied and the > >>>> service > >>>>>> that > >>>>>>>> is > >>>>>>>> being constructed. That is, the same encapsulation may be > >>>>>>>>used > >>>> on > >>>>>>>> a service function path realized at the network layer or > at > >>>> any > >>>>>>>> other > >>>>>>>> layer, and the same encapsulation will apply for the > >>>> construction > >>>>>> of > >>>>>>>> service function paths regardless of the actual service. > >>>>>>>> > >>>>>>>> 4) Control Plane Mechanisms: A set of documents will be > developed > >>>> to > >>>>>>>> describe requirements and protocols necessary to convey > >>>>>> information > >>>>>>>> to service function implementation points. Where possible, > >>>>>> existing > >>>>>>>> IETF protocols will be used and extended. All protocol > >>>> extensions > >>>>>>>> work should be carried out in the working groups > responsible > >>>> for > >>>>>> the > >>>>>>>> protocols being modified in coordination with this > working > >>>> group, > >>>>>>>> but > >>>>>>>> may be done in this working group after agreement with > all > >>>>>>>>the > >>>>>>>> relevant WG chairs and responsible ADs. > >>>>>>>> > >>>>>>>> 5) Manageability: Work on the management and configuration of > >>>> service > >>>>>>>> functions in support of SFC components will certainly be > >>>> needed, > >>>>>>>> but first needs to be better understood and scoped. > >>>>>>>> > >>>>>>>> Proposed Milestones > >>>>>>>> > >>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the > >>>>>> problem > >>>>>>>> statement and core use cases for Service Function Chaining > >>>>>>>> > >>>>>>>> May 2014 Consult with OPS Area on possible charter > modifications > >>>> for > >>>>>>>> management and configuration of SFC components > >>>>>>>> > >>>>>>>> Jan 2015 Submit to IESG Informational document defining the > >>>>>> architecture > >>>>>>>> for SFC > >>>>>>>> > >>>>>>>> Jan 2015 Submit to IESG requirements for a generic service > >>>> function > >>>>>>>> chaining encapsulation protocol > >>>>>>>> > >>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying > the > >>>>>> generic > >>>>>>>> service function chaining header encapsulation > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Thomas > >>>>>>>> > >>>>>>>> _______________________________________________ > >>>>>>>> nsc mailing list > >>>>>>>> nsc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>>>> _______________________________________________ > >>>>>>>> nsc mailing list > >>>>>>>> nsc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>>>> _______________________________________________ > >>>>>>>> nsc mailing list > >>>>>>>> nsc@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>>> _______________________________________________ > >>>>>>> nsc mailing list > >>>>>>> nsc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>> > >>> > >>> _______________________________________________ > >>> nsc mailing list > >>> nsc@ietf.org > >>> https://www.ietf.org/mailman/listinfo/nsc > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >> >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Tue Nov 12 07:34:25 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8284421E81C0 for ; Tue, 12 Nov 2013 07:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.472 X-Spam-Level: X-Spam-Status: No, score=-6.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHCUuNy1OPFh for ; Tue, 12 Nov 2013 07:34:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA4F21E8091 for ; Tue, 12 Nov 2013 07:33:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE57045; Tue, 12 Nov 2013 15:33:58 +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; Tue, 12 Nov 2013 15:33:01 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 15:33:57 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 07:33:48 -0800 From: Linda Dunbar To: Ron Parker , "Hongyu Li (Julio)" , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN+0+4iz5RRxkOCS0vXxMG0/5ohQBeAgAAOHICAACcJgIAAAa2AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oD//46zEA== Date: Tue, 12 Nov 2013 15:33:48 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:34:25 -0000 Ron,=20 First, want to make it clear that "branching" !=3D reclassification, agree? Second, the representation of branching (or service graph) can be in a form= of logic on a service function. Some service functions, especially L7 base= d, can use value in a Database to determine what is the next service functi= on.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Ron Parker > Sent: Tuesday, November 12, 2013 8:16 AM > To: Hongyu Li (Julio); Kevin J Ma > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Hongyu, >=20 > I agree completely that re-classification is not limited to DPI. >=20 > And also, that an area for us to explore as a group is how to represent > the service graph. Do we want to represent it as a proper graph with > an adjacency list or other representational model? Or, do we want to > represent it as a set of linear segments and if so, how are the > segments connected into a graph? Other ideas? >=20 > Ron >=20 >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Hongyu Li (Julio) > Sent: Tuesday, November 12, 2013 6:57 AM > To: Ron Parker; Kevin J Ma > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Branching/forking is a very interesting topic of SFC. About the re- > classification point, probably we shall not limit it to DPI. It is also > possible that packets go to different branches after been processed by > a certain service function, decision of which branches to go is made > based on the result of service function's process, i.e. not just re- > classification by DPI. >=20 > Hongyu >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Ron Parker > Sent: Tuesday, November 12, 2013 7:45 PM > To: Kevin J Ma > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Hi, Kevin >=20 > You ask a great question about branching the graph. The details around > how to convey the selection of the subtree/subgraph are still to be > defined. Is it one chain id for the whole graph? Does each branch > have its own chain id? Some combination? >=20 > Ron >=20 > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > wrote: >=20 > >> Yes, reclassification can change the service path and > >> re-classification may happen at any node along a service path. > > > > Just to expand on that, going back to the original question about > > service header encapsulation, is it intended that a chain that is > > re-classified will get a new chain ID which fully describes a chain > > that is a superset of the original chain ID, prior to DPI-based > > re-classification? (assuming the goal is "a single chain ID that is > > commonly understood along the entire service chain" > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > And the applicable subset of the permutative list of service paths > > would be configured at each appropriate service node? > > e.g., ID 1: NAT + firewall + DPI > > ID 2: NAT + firewall + DPI + AV > > ID 3: NAT + firewall + DPI + AV + NAT > > ID 4: NAT + firewall + DPI + NAT > > ID 5: NAT + firewall + DPI + AV + LB > > ID 6: NAT + firewall + DPI + LB > > ID 7: NAT + firewall + DPI + LB + CACHE > > ID 8: NAT + firewall + DPI + CACHE > > ID 9: NAT + firewall + DPI + optimizer + LB > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow > > then be initially classified as ID 1, but eventually get re- > classified > > to ID 2-11, after the DPI phase? > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> Sent: Tuesday, November 12, 2013 1:01 AM > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >> nsc@ietf.org > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> > >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: > >>> > >>> Hi Surendra, > >>> > >>> Classification may be out of scope, but the level of service that > is > >>> applicable is dependent upon the level of classification that can > be > >>> performed. An assumption of packet level encapsulation has > >> implications > >>> on the level of classification being performed? If the stated > goals > >> are > >>> for firewall and load balancer functionality, then the application > >> level > >>> nature of those functions needs to be taken into account? If, on > >>> the other hand, the service function scope is limited due to > >>> limitations in classification, that would be and important piece of > information? > >>> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > >>> points of the service paths seem like re-classification points? Is > >>> that the interpretation from the architecture perspective? Or is > >>> the service function chain classification exclusive of DPI > functionality? > >> I have not fully read that draft yet. But in general, as > >> described in the arch draft, the collection of services form a graph, > >> segments of which are service paths. Yes, reclassification can > change > >> the service path and re-classification may happen at any node along > a service path. > >> > >> Surendra. > >>> > >>> thanx. > >>> > >>> -- Kevin J. Ma > >>> > >>>> -----Original Message----- > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>>> nsc@ietf.org > >>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>> > >>>> Kevin, > >>>> > >>>> Classification mechanism is outside the scope of SFC. It can be > >>>> based > >> on > >>>> the packet or information not in the packet(environmental > >>>> attributes > >> for > >>>> instance) or a combination thereof. What is important is that such > >>>> classification aids in traffic selection and service path > >>>> identification. > >>>> It is no different from a policy in this regard except that the > >>>> policy now specifies the service path. > >>>> Further, classification is not limited to the network elements but > >>>> the service functions as well. Some of this is described in the > >> architecture > >>>> drafts as well - > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >>>> > >>>> Surendra. > >>>> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > wrote: > >>>>> > >>>>> Hi Ron, > >>>>> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but > >>>>> I had a similar question wrt bullet 11 in section 2 of the > problem > >>>>> statement: > >>>>> > >>>>> 11. Per-Service (re)Classification: Classification occurs at > each > >>>>> service, independent from previously applied service > >>>> functions. > >>>>> These unrelated classification events consume resources > per > >>>>> service. More importantly, the classification > functionality > >>>>> often differs per service function and service function > >> cannot > >>>>> leverage the results from other deployed network or > service. > >>>>> > >>>>> as it relates to section 5.2 of the framework document: > >>>>> > >>>>> The SFC Classifier classifies packets based on (some of) the > >>>> contents > >>>>> of the packet header. Concretely, it classifies packets based > >>>>> on > >>>> the > >>>>> possible combination of one or more header fields, such as > source > >>>>> address, destination address, DS field, protocol ID, source > port > >>>> and > >>>>> destination port numbers, and any other information. > >>>>> > >>>>> A packet-based classifier as described in the framework document > >>>> would > >>>>> seem to be limited in what it can classify? The service function > >>>>> identifier lookup does not seem to be a significant optimization > >> over > >>>>> a packet-based 5-tuple lookup? There seems to be some missing > >> detail > >>>>> wrt how classification information is determined and reused? > >>>>> > >>>>> When thinking about higher level services, e.g., HTTP and TLS > >>>> encrypted > >>>>> flows, a packet-based classifier seems inadequate? I was also > >>>> wondering > >>>>> how independent HLS segment requests might be classified and > >>>> associated? > >>>>> Were these types of use cases discussed in the BoF? > >>>>> > >>>>> thanx. > >>>>> > >>>>> -- Kevin J. Ma > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>> Behalf > >> Of > >>>>>> Ron > >>>>>> Parker > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Sumandra, > >>>>>> > >>>>>> As was discussed in Vancouver, there are already many existing > >>>>>> ways > >>>> to > >>>>>> accomplish service chaining. But none of them provide a > >>>> sufficient > >>>>>> combination of interoperability, flexibility, and resiliency. > A > >>>> single > >>>>>> service chain encapsulation will go a long way to ensuring these > >>>> goals. > >>>>>> It may not be the absolutely most efficient approach for every > >>>> single > >>>>>> network topology and every single use case, but its ubiquitous > >> nature > >>>>>> should improve its adoption. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Ron, > >>>>>> > >>>>>> Absolutely, that was an example of one type of derivation. > >>>>>> However > >>>> this > >>>>>> could be augmented with classification result, again one more > >>>> example. > >>>>>> > >>>>>>>> All flows from the same source IP do not necessarily follow > the > >>>> same > >>>>>> chain. > >>>>>> Correct. It is also not necessary that all transaction of the > >>>>>> same > >>>> flow > >>>>>> follow the same chain either. So why stop at flow itself. > >>>>>> > >>>>>> Again the point here is that do we always need SFC header or Not. > >>>>>> > >>>>>> Sumandra > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Sumandra, > >>>>>> > >>>>>> The intention of service function chaining is to allow for > >>>>>> operation > >>>> at > >>>>>> the fully qualified flow level, or even finer grained at the > >>>> transaction > >>>>>> level (this is an implementation matter for the PDP). All > flows > >>>> from > >>>>>> the same source IP do not necessarily follow the same chain. > >> Source > >>>>>> IP, > >>>>>> therefore, does not identify the chain ID. Another intention > of > >>>>>> service function chaining is to operate over any network > topology > >> and > >>>>>> not > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > the > >>>>>> transport, it does not adequately identify the service chain, > >> either. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Ron, > >>>>>> > >>>>>> The service header is meant to carry the context which can > *also* > >>>>>> be derived (for example use source ip and vlan to identify > >>>>>> chainID and > >>>>>> position) or encapsulated as part of another tunnel header. So > >>>>>> this could be optional IMHO. > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Sumandra, > >>>>>> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF or > >>>>>> from > >>>> SF > >>>>>> to > >>>>>> SF will look like: > >>>>>> > >>>>>> +------------------------+ > >>>>>> | "transport" | > >>>>>> +------------------------+ > >>>>>> | service header | > >>>>>> +------------------------+ > >>>>>> | original IP header | > >>>>>> +------------------------+ > >>>>>> | | original IP payload > | > >>>>>> | | > >>>>>> +------------------------+ > >>>>>> > >>>>>> Where service header contains, at a minimum, enough information > >>>>>> to > >>>> allow > >>>>>> the packet to be propagated along the full length of the chain, > >>>>>> and optionally, other metadata that enhances the operation of > one > >>>>>> or > >> more > >>>>>> service functions. > >>>>>> > >>>>>> And where "transport" could conceivably be any of, but not > >>>>>> limited > >>>> to: > >>>>>> > >>>>>> * Ethernet > >>>>>> * Ethernet + LLC2 > >>>>>> * Ethernet + MPLS > >>>>>> * Ethernet + IP + GRE > >>>>>> * Ethernet + IP +UDP > >>>>>> > >>>>>> > >>>>>> Also, "original" in the diagram above is not meant to imply > >>>>>> immutability, but rather to specify the packet that is > propagated > >>>>>> from preceding entity to succeeding entity, prior to > >>>>>> encapsulation. > >>>>>> > >>>>>> Ron > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>> Behalf > >> Of > >>>>>> Sumandra Majee > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > >>>>>> To: Thomas Narten; nsc@ietf.org > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Generic Service Function Chaining Encapsulation: A document will > >>>>>> describe the single service-level data plane encapsulation > >> format > >>>>>> for > >>>>>> conveying the service function chain and the service function > >>>> path, > >>>>>> and for communicating context information between nodes that > >>>>>> implement service functions. It is intended that the > >>>> encapsulation > >>>>>> be agnostic to the layer at which it is applied and the > >>>>>> service > >>>> that > >>>>>> is > >>>>>> being constructed. That is, the same encapsulation may be > used > >> on > >>>>>> a service function path realized at the network layer or at > >>>>>> any other > >>>>>> layer, and the same encapsulation will apply for the > >> construction > >>>> of > >>>>>> service function paths regardless of the actual service. > >>>>>> > >>>>>> [SM] What does it mean by a single service-level encapsulation, > a > >>>> new > >>>>>> encapsulation format > >>>>>> or an ability to select one encapsulation format that > >>>> fits > >>>>>> the > >>>>>> need for a given service chain? > >>>>>> The ability to select a specific encapsulation would > >>>>>> be > >> a > >>>>>> management plane decision. > >>>>>> There are quite a few existing encapsulation methods > >>>>>> that > >>>> can > >>>>>> possibly be reused to provide > >>>>>> context information between service nodes. I have > seen > >>>>>> mention > >>>>>> of GRE, for HTTP based > >>>>>> applications contexts are transferred via headers. > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>> Behalf > >> Of > >>>>>> Thomas Narten > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >>>>>> To: nsc@ietf.org > >>>>>> Subject: [nsc] Current Proposed SFC charter > >>>>>> > >>>>>> Hi. > >>>>>> > >>>>>> Current charter can be found at > >>>>>> https://datatracker.ietf.org/doc/charter- > >>>>>> ietf-sfc/. > >>>>>> > >>>>>> It contains the revised management text as well as updated > >>>> milestones. > >>>>>> > >>>>>> All known issues have been addressed. If there are any remaining > >>>> issues, > >>>>>> please speak up! > >>>>>> > >>>>>> Charter charter-ietf-sfc-00-04 > >>>>>> > >>>>>> Networks, servers, storage technologies, and applications, have > >>>>>> all undergone significant change in recent years with the > >>>>>> introduction > >> of > >>>>>> virtualization, network overlays, and orchestration. Service > >> delivery > >>>> is > >>>>>> currently both a technical and organizational challenge that > >> involves > >>>>>> significant modification to the network configuration. > >>>>>> Services are typically implemented by the ordered combination of > >>>>>> a number of service functions that are deployed at different > >>>>>> points within > >> the > >>>>>> network. Today, a common deployment model has service functions > >>>>>> physically inserted on the data forwarding path between > >>>>>> communicating peers. > >>>> Going > >>>>>> forward, however, there is a desire to move to a different model, > >>>> where > >>>>>> service functions are not required to reside on the default data > >> path > >>>>>> and > >>>>>> traffic is instead steered through services, wherever they are > >>>> deployed. > >>>>>> > >>>>>> For a given service, the abstracted view of the required service > >>>>>> functions and the order in which they are to be applied is > called > >>>>>> a Service Function Chain (SFC). Since a given service function > >>>>>> may be available on more than one node within a network, a > >>>>>> Service Function Chain is instantiated > >>>> via > >>>>>> the selection of specific service function instances and the > >>>>>> network nodes on which they are provided, thereby forming a > >>>>>> service topology: > >>>>>> this is called a Service Function Path. The service functions > may > >>>>>> be applied at a specific layer within the network protocol stack > >>>> (network > >>>>>> layer, application layer, etc.). > >>>>>> > >>>>>> The Service Function Chaining (SFC) working group will develop > >>>>>> new approaches to service delivery and deployment. It will > >>>>>> produce a framework for service function chaining that includes > >>>>>> the necessary protocols > >>>> or > >>>>>> protocol extensions to convey the service path and service path > >>>>>> information to nodes that implement service functions, as well > as > >>>>>> mechanisms for steering traffic through service functions. The > >>>> working > >>>>>> group will also examine what information needs to be gathered > >>>>>> from > >>>> the > >>>>>> network and service functions in support of service function > >> chaining > >>>>>> and > >>>>>> how that information may be made available to nodes that > >>>>>> implement > >>>> the > >>>>>> service functions. > >>>>>> > >>>>>> Specifically, the SFC WG is chartered to deliver the following: > >>>>>> > >>>>>> 1) Problem Statement: This document will provide a summary of > the > >>>>>> problem space to be addressed by the WG including example > high- > >>>>>> level use cases. Additionally, the WG will normalize > >> nomenclature > >>>>>> and definitions for service function chaining. > >>>>>> > >>>>>> 2) Architecture: This document will provide a description of the > >>>>>> architectural building blocks and their relationships > including > >>>>>> interconnection, placement of capabilities, management, > >>>>>> diagnostics, design analysis, and security models, as well as > >>>>>> requirements on the protocol mechanisms. > >>>>>> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A document > will > >>>>>> describe the single service-level data plane encapsulation > >> format > >>>>>> for > >>>>>> conveying the service function chain and the service function > >>>> path, > >>>>>> and for communicating context information between nodes that > >>>>>> implement service functions. It is intended that the > >>>> encapsulation > >>>>>> be agnostic to the layer at which it is applied and the > >>>>>> service > >>>> that > >>>>>> is > >>>>>> being constructed. That is, the same encapsulation may be > used > >> on > >>>>>> a service function path realized at the network layer or at > >>>>>> any other > >>>>>> layer, and the same encapsulation will apply for the > >> construction > >>>> of > >>>>>> service function paths regardless of the actual service. > >>>>>> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > developed to > >>>>>> describe requirements and protocols necessary to convey > >>>> information > >>>>>> to service function implementation points. Where possible, > >>>> existing > >>>>>> IETF protocols will be used and extended. All protocol > >> extensions > >>>>>> work should be carried out in the working groups responsible > >>>>>> for > >>>> the > >>>>>> protocols being modified in coordination with this working > >> group, > >>>>>> but > >>>>>> may be done in this working group after agreement with all > the > >>>>>> relevant WG chairs and responsible ADs. > >>>>>> > >>>>>> 5) Manageability: Work on the management and configuration of > >> service > >>>>>> functions in support of SFC components will certainly be > needed, > >>>>>> but first needs to be better understood and scoped. > >>>>>> > >>>>>> Proposed Milestones > >>>>>> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining the > >>>> problem > >>>>>> statement and core use cases for Service Function Chaining > >>>>>> > >>>>>> May 2014 Consult with OPS Area on possible charter modifications > >>>>>> for management and configuration of SFC components > >>>>>> > >>>>>> Jan 2015 Submit to IESG Informational document defining the > >>>> architecture > >>>>>> for SFC > >>>>>> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > >>>>>> function chaining encapsulation protocol > >>>>>> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying the > >>>> generic > >>>>>> service function chaining header encapsulation > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Thomas > >>>>>> > >>>>>> _______________________________________________ > >>>>>> nsc mailing list > >>>>>> nsc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>> _______________________________________________ > >>>>>> nsc mailing list > >>>>>> nsc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>> _______________________________________________ > >>>>>> nsc mailing list > >>>>>> nsc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>> _______________________________________________ > >>>>> nsc mailing list > >>>>> nsc@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From diego@tid.es Tue Nov 12 07:47:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A81021E8213 for ; Tue, 12 Nov 2013 07:47:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEMLM1pdpwyf for ; Tue, 12 Nov 2013 07:47:14 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF3221E823D for ; Tue, 12 Nov 2013 07:46:14 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MW5007MDQGY6I@tid.hi.inet> for nsc@ietf.org; Tue, 12 Nov 2013 16:46:12 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 8F.DC.28420.44D42825; Tue, 12 Nov 2013 16:46:12 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MW5001HKQH0SM@tid.hi.inet> for nsc@ietf.org; Tue, 12 Nov 2013 16:46:12 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.212]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 16:46:12 +0100 Date: Tue, 12 Nov 2013 15:46:11 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Jim Guichard (jguichar)" Message-id: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> Content-id: <37F95BFCEF59C349A9EAA3E1132C4315@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: [nsc] Current Proposed SFC charter Thread-index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAP//5+wAgAADV4CAAA7jAA== X-AuditID: 0a5f4e69-b7fe58e000006f04-1a-52824d4494d4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42Lhivcz1HXxbQoyeNRnYHF83342B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBl9N55zVSwaCJTxb2lvWwNjAu6mLoYOTkkBEwkmvseMkLYYhIX 7q1n62Lk4hAS2MYosWDzbEYI5xujxK8dN6EyMxkllp5oYQFpYRFQlTg6/y+YzQZkP2r+zQ5i CwvoSxyee5IVxOYUMJCYOO8GK8QKBYk/5x6D1YsIGEl0X3rPCjKUWWAOk8Thhg6wO3gFLCUe 3GpnA7GZBcwkJn1sYoGIC0r8mHwPyOYAiqtLTJmSC1EiLtHcepMFwlaUmLaoAWwMo4CsxLv5 81khdhlIPPu8B+wbEYEpjBKvln+G+llAYsme88wQtqjEy8f/wBqEgB64OGE58wRGiVlIzpiF 5IxZCGfMQnLGLCRnLGBkXcUoVpxUlJmeUZKbmJmTbmCkl5Gpl5mXWrKJERJ9mTsYl+9UOcQo wMGoxMN7QLAxSIg1say4MvcQowQHs5II7ybPpiAh3pTEyqrUovz4otKc1OJDjEwcnFJA87X0 mbk3NW/yiGafX/DiSeOpXvf3/xPskupfL7we8eaA31+G1hq+XV7qc89cj330/Ov8AsFz8Uwp 2y6f6vju16eyIcGyMPzwfONT89PMrZ/JKt/Q6Np2d1P/ivD1nA3NrC9at7vbudftWe1r7buN 2bf8OoNrkLKudD5fqEfXkklT1YxzquuVWIozEg21mIuKEwHhmilunAIAAA== References: Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee , Kevin J Ma , Ron Parker , "Joel M. Halpern" , "Surendra Kumar \(smkumar\)" Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:47:18 -0000 TGV0IG1lIGFkZCBmb3IgdGhlIHJlY29yZCB0aGF0IHRoaXMgaXMgdGhlIGtpbmQgb2YgbWFuYWdl bWVudCBhc3BlY3RzIEkgaGFkIGluIG1pbmQgd2hlbiB3ZSB3ZXJlIHRhbGtpbmcgYWJvdXQgc2Vy dmljZSBtZXRhZGF0YSBhbmQgaG93IHRvIGV4Y2hhbmdlIHRoZW0uLi4NCg0KQmUgZ29vZGUsDQoN Ck9uIDEyIE5vdiAyMDEzLCBhdCAxNTo1MiAsIEppbSBHdWljaGFyZCAoamd1aWNoYXIpIHdyb3Rl Og0KDQo+IFllcyBvcHRpbWl6YXRpb24gY2FuIGNlcnRhaW5seSBiZSBidWlsdCBpbnRvIHRoaXMg YnV0IEkgd2FudGVkIHRvIHNob3cgYW4NCj4gZXhhbXBsZSBvZiB0aGUgdHlwZXMgb2YgdGhpbmdz IHdlIG1lYW4gd2hlbiB3ZSB0YWxrIGFib3V0IGJyYW5jaGluZy4gT25jZQ0KPiB0aGUgY29uY2Vw dCBpcyBiZXR0ZXIgdW5kZXJzdG9vZCBJIHRoaW5rIHdlIHdpbGwgc2VlIHNvbWUgbW9yZSBleGNp dGluZw0KPiBleGFtcGxlcy4gTm90ZSBhbHNvIHRoYXQgdGhlIGNvbnRyb2wgbG9naWMgY291bGQg YWxzbyB1dGlsaXplIHRoZSBzZXJ2aWNlDQo+IGVuY2Fwc3VsYXRpb24gYXMgYSBtZWNoYW5pc20g dG8gcHVzaCBub3RpZmljYXRpb25zIGJhY2sgdXAgdGhlIG9yaWdpbmFsDQo+IGNoYWluIHRvIGlu Zm9ybSB0aGUgaW5ncmVzcyB0byBieXBhc3MgdGhlIG9yaWdpbmFsIGNoYWluIGZvciBhbGwNCj4g c3Vic2VxdWVudCBwYWNrZXRzIGZvciB0aGlzIGZsb3cuDQo+DQo+IE9uIDExLzEyLzEzIDk6NDAg QU0sICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4uY29tPiB3cm90ZToNCj4NCj4+ IEppbSwgdGhhbmsgeW91IGZvciBhIGNvbmNyZXRlIGV4YW1wbGUuDQo+PiBJIHdvdWxkIHN1Z2dl c3QgdGhhdCBpbiB0aGUgdXN1YWwgY2FzZXMsIHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBoYW5k bGUNCj4+IHRoaXMgdGhhbiBicmFuY2hpbmcgYW5kIHJld3JpdGluZyBhdCB0aGUgUENSRi4NCj4+ DQo+PiBJZiB0aGUgRFBJIGVuZ2luZSBvciBQQ1JGIGxvZ2ljICh3aGljaGV2ZXIgbWFrZXMgdGhl IGRlY2lzaW9uKSBub3RpZmllcw0KPj4gdGhlIGNvbnRyb2wgbG9naWMgYWJvdXQgdGhlIGRlY2lz aW9uIGZvciB0aGUgZmxvdywgdGhlbiB0aGUgaW5ncmVzcyBjYW4NCj4+IGRpcmVjdCBzdWJzZXF1 ZW50IHBhY2tldHMgdG8gdGhlIGNvcnJlY3QgcGxhY2UsIGF2b2lkaW5nIG5lZWRsZXNzDQo+PiBw cm9jZXNzaW5nIG9mIGZ1cnRoZXIgcGFja2V0cyBpbiB0aGUgRFBJIGFuZCBQQ1JGIGxvZ2ljLg0K Pj4gRnVydGhlciwgdGhlIG5lZWRlZCBjb250cm9sIGluZm9ybWF0aW9uIGNhbiBiZSBwYXNzZWQg dG8gdGhlDQo+PiBvcHRpbWl6YXRpb24gb3IgcGFyZW50YWwgY29udHJvbCBzbyB0aGF0IGl0IGRv ZXMgbm90IG1hdHRlciB3aGVyZSB0aGUNCj4+IGZpcnN0IHBhY2tldCBpcyBzZW50LCBhdm9pZGlu ZyB0aGUgbmVlZCBmb3IgdGhlIFBDUkYgdG8gdW5kZXJzdGFuZCBob3cNCj4+IHRvIGRpcmVjdCBw YWNrZXRzIHRvIHNlcnZpY2UgcGF0aHMuDQo+Pg0KPj4gWW91cnMsDQo+PiBKb2VsDQo+Pg0KPj4g T24gMTEvMTIvMTMgOTowNyBBTSwgSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6DQo+Pj4g SGkgS2V2aW4sDQo+Pj4NCj4+PiBMZXQgbWUgdHJ5IGFuZCBwcm92aWRlIGEgY29uY3JldGUgZXhh bXBsZSB0byBzZWUgaWYgdGhpcyBhbnN3ZXJzIHlvdXINCj4+PiBzcGVjaWZpYyBxdWVzdGlvbjoN Cj4+Pg0KPj4+IFVzZSBjYXNlOiBQLUdXIC0+IFBDUkYgLT4gc2VydmljZXMgYXBwbGllZCB0byB0 cmFmZmljIGJhc2VkIG9uDQo+Pj4gYXBwbGljYXRpb25JRCBhbmQgc3Vic2NyaWJlcklELg0KPj4+ DQo+Pj4gSW5zdGFudGlhdGVkIGFzOg0KPj4+DQo+Pj4gU0ZDMTogUC1HVyAtPiBEUEkgLT4gUENS Rg0KPj4+IFNGQzI6IFBDUkYgLT4gdmlkZW8tb3B0aW1pemF0aW9uIC0+IG1ldGVyaW5nIC0+IEZX DQo+Pj4gU0ZDMzogUENSRiAtPiBwYXJlbnRhbC1jb250cm9sIC0+IG1ldGVyaW5nIC0+IEZXDQo+ Pj4NCj4+PiBJbiB0aGlzIGNhc2UgRFBJIGlzIHBlcmZvcm1lZCBvbiBTRkMxIGFuZCBpZGVudGlm aWVzIGFwcGxpY2F0aW9uSUQuIFRoZQ0KPj4+IGFwcGxpY2F0aW9uSUQgaXMgY2FycmllZCBpbiB0 aGUgc2VydmljZSBlbmNhcHN1bGF0aW9uIHRvIFBDUkYuIFBDUkYgdXNlcw0KPj4+IHNvbHV0aW9u IHNwZWNpZmljIGxvZ2ljIChpZGVudGlmaWVzIHN1YnNjcmliZXIsIGFwcGxpZXMgcG9saWNpZXMs IGV0YykNCj4+PiBhbmQNCj4+PiB1c2VzIHRoZSByZXN1bHQgYWxvbmcgd2l0aCB0aGUgYXBwbGlj YXRpb25JRCByZWNlaXZlZCBmcm9tIERQSSB0byBzZWxlY3QNCj4+PiBhbiBvdXRib3VuZCBzZXJ2 aWNlIGNoYWluLCBTRkMyIG9yIFNGQzMuIE5vdGUgdGhhdCBpbiB0aGlzIGNhc2UNCj4+PiBicmFu Y2hpbmcNCj4+PiBvY2N1cnMgZnJvbSBTRkMxIHRvIGVpdGhlciBTRkMyIG9yIFNGQzMuDQo+Pj4N Cj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiAxMS8xMi8xMyAxOjUyIEFNLCAiS2V2aW4gSiBNYSIgPGtl dmluLm1hQGF6dWtpc3lzdGVtcy5jb20+IHdyb3RlOg0KPj4+DQo+Pj4+PiBZZXMsIHJlY2xhc3Np ZmljYXRpb24gY2FuIGNoYW5nZSB0aGUgc2VydmljZSBwYXRoIGFuZA0KPj4+Pj4gcmUtY2xhc3Np ZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZSBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+ Pj4NCj4+Pj4gSnVzdCB0byBleHBhbmQgb24gdGhhdCwgZ29pbmcgYmFjayB0byB0aGUgb3JpZ2lu YWwgcXVlc3Rpb24gYWJvdXQNCj4+Pj4gc2VydmljZSBoZWFkZXIgZW5jYXBzdWxhdGlvbiwgaXMg aXQgaW50ZW5kZWQgdGhhdCBhIGNoYWluIHRoYXQNCj4+Pj4gaXMgcmUtY2xhc3NpZmllZCB3aWxs IGdldCBhIG5ldyBjaGFpbiBJRCB3aGljaCBmdWxseSBkZXNjcmliZXMNCj4+Pj4gYSBjaGFpbiB0 aGF0IGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFsIGNoYWluIElELCBwcmlvciB0bw0KPj4+ PiBEUEktYmFzZWQgcmUtY2xhc3NpZmljYXRpb24/ICAoYXNzdW1pbmcgdGhlIGdvYWwgaXMgImEg c2luZ2xlDQo+Pj4+IGNoYWluIElEIHRoYXQgaXMgY29tbW9ubHkgdW5kZXJzdG9vZCBhbG9uZyB0 aGUgZW50aXJlIHNlcnZpY2UgY2hhaW4iDQo+Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h cmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cwMDYzOC5odG1sKQ0KPj4+Pg0KPj4+PiBBbmQgdGhl IGFwcGxpY2FibGUgc3Vic2V0IG9mIHRoZSBwZXJtdXRhdGl2ZSBsaXN0IG9mIHNlcnZpY2UNCj4+ Pj4gcGF0aHMgd291bGQgYmUgY29uZmlndXJlZCBhdCBlYWNoIGFwcHJvcHJpYXRlIHNlcnZpY2Ug bm9kZT8NCj4+Pj4gZS5nLiwgSUQgMTogTkFUICsgZmlyZXdhbGwgKyBEUEkNCj4+Pj4gICAgICBJ RCAyOiBOQVQgKyBmaXJld2FsbCArIERQSSArIEFWDQo+Pj4+ICAgICAgSUQgMzogTkFUICsgZmly ZXdhbGwgKyBEUEkgKyBBViArIE5BVA0KPj4+PiAgICAgIElEIDQ6IE5BVCArIGZpcmV3YWxsICsg RFBJICsgTkFUDQo+Pj4+ICAgICAgSUQgNTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViArIExC DQo+Pj4+ICAgICAgSUQgNjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBMQg0KPj4+PiAgICAgIElE IDc6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTEIgKyBDQUNIRQ0KPj4+PiAgICAgIElEIDg6IE5B VCArIGZpcmV3YWxsICsgRFBJICsgQ0FDSEUNCj4+Pj4gICAgICBJRCA5OiBOQVQgKyBmaXJld2Fs bCArIERQSSArIG9wdGltaXplciArIExCDQo+Pj4+ICAgICAgSUQgMTA6IE5BVCArIGZpcmV3YWxs ICsgRFBJICsgb3B0aW1pemVyICsgTEIgKyBDQUNIRQ0KPj4+PiAgICAgIElEIDExOiBOQVQgKyBm aXJld2FsbCArIERQSSArIG9wdGltaXplciArIENBQ0hFDQo+Pj4+IFdvdWxkIGV2ZXJ5IGZsb3cg dGhlbiBiZSBpbml0aWFsbHkgY2xhc3NpZmllZCBhcyBJRCAxLCBidXQNCj4+Pj4gZXZlbnR1YWxs eSBnZXQgcmUtY2xhc3NpZmllZCB0byBJRCAyLTExLCBhZnRlciB0aGUgRFBJIHBoYXNlPw0KPj4+ Pg0KPj4+PiB0aGFueC4NCj4+Pj4NCj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+DQo+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogU3VyZW5kcmEgS3VtYXIgKHNt a3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBO b3ZlbWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+Pj4+PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBhcmtl cjsgU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47DQo+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+ Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBPbiAxMS8xMS8xMyA5OjQ2IFBNLCAiS2V2aW4gSiBNYSIg PGtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+PiBIaSBTdXJl bmRyYSwNCj4+Pj4+Pg0KPj4+Pj4+ICBDbGFzc2lmaWNhdGlvbiBtYXkgYmUgb3V0IG9mIHNjb3Bl LCBidXQgdGhlIGxldmVsIG9mIHNlcnZpY2UgdGhhdA0KPj4+Pj4+IGlzDQo+Pj4+Pj4gIGFwcGxp Y2FibGUgaXMgZGVwZW5kZW50IHVwb24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIHRoYXQg Y2FuDQo+Pj4+Pj4gYmUNCj4+Pj4+PiAgcGVyZm9ybWVkLiAgQW4gYXNzdW1wdGlvbiBvZiBwYWNr ZXQgbGV2ZWwgZW5jYXBzdWxhdGlvbiBoYXMNCj4+Pj4+IGltcGxpY2F0aW9ucw0KPj4+Pj4+ICBv biB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gYmVpbmcgcGVyZm9ybWVkPyAgSWYgdGhlIHN0 YXRlZA0KPj4+Pj4+IGdvYWxzDQo+Pj4+PiBhcmUNCj4+Pj4+PiAgZm9yIGZpcmV3YWxsIGFuZCBs b2FkIGJhbGFuY2VyIGZ1bmN0aW9uYWxpdHksIHRoZW4gdGhlIGFwcGxpY2F0aW9uDQo+Pj4+PiBs ZXZlbA0KPj4+Pj4+ICBuYXR1cmUgb2YgdGhvc2UgZnVuY3Rpb25zIG5lZWRzIHRvIGJlIHRha2Vu IGludG8gYWNjb3VudD8gIElmLCBvbg0KPj4+Pj4+IHRoZQ0KPj4+Pj4+ICBvdGhlciBoYW5kLCB0 aGUgc2VydmljZSBmdW5jdGlvbiBzY29wZSBpcyBsaW1pdGVkIGR1ZSB0bw0KPj4+Pj4+IGxpbWl0 YXRpb25zDQo+Pj4+PiBpbg0KPj4+Pj4+ICBjbGFzc2lmaWNhdGlvbiwgdGhhdCB3b3VsZCBiZSBh bmQgaW1wb3J0YW50IHBpZWNlIG9mIGluZm9ybWF0aW9uPw0KPj4+Pj4+DQo+Pj4+Pj4gIFdydCBz ZWN0aW9uIDQuNCBvZiBkcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMgdGhlIGZv cmsNCj4+Pj4+IHBvaW50cw0KPj4+Pj4+ICBvZiB0aGUgc2VydmljZSBwYXRocyBzZWVtIGxpa2Ug cmUtY2xhc3NpZmljYXRpb24gcG9pbnRzPyAgSXMgdGhhdA0KPj4+Pj4+IHRoZQ0KPj4+Pj4+ICBp bnRlcnByZXRhdGlvbiBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmU/ICBPciBpcyB0 aGUNCj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4gIGZ1bmN0aW9uIGNoYWluIGNsYXNzaWZpY2F0aW9u IGV4Y2x1c2l2ZSBvZiBEUEkgZnVuY3Rpb25hbGl0eT8NCj4+Pj4+IDxTSz4gSSBoYXZlIG5vdCBm dWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwgYXMNCj4+Pj4+IGRlc2Ny aWJlZA0KPj4+Pj4gaW4NCj4+Pj4+IHRoZSBhcmNoIGRyYWZ0LCB0aGUgY29sbGVjdGlvbiBvZiBz ZXJ2aWNlcyBmb3JtIGEgZ3JhcGgsIHNlZ21lbnRzIG9mDQo+Pj4+PiB3aGljaA0KPj4+Pj4gYXJl IHNlcnZpY2UgcGF0aHMuIFllcywgcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRoZSBzZXJ2 aWNlIHBhdGgNCj4+Pj4+IGFuZA0KPj4+Pj4gcmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBh dCBhbnkgbm9kZSBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+Pj4+DQo+Pj4+PiBTdXJlbmRyYS4N Cj4+Pj4+Pg0KPj4+Pj4+IHRoYW54Lg0KPj4+Pj4+DQo+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+ Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTog U3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+Pj4+ Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEyOjA4IEFNDQo+Pj4+Pj4+IFRv OiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsN Cj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pg0KPj4+Pj4+PiBLZXZpbiwNCj4+Pj4+Pj4NCj4+ Pj4+Pj4gQ2xhc3NpZmljYXRpb24gbWVjaGFuaXNtIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNG Qy4gSXQgY2FuIGJlDQo+Pj4+Pj4+IGJhc2VkDQo+Pj4+PiBvbg0KPj4+Pj4+PiB0aGUgcGFja2V0 IG9yIGluZm9ybWF0aW9uIG5vdCBpbiB0aGUgcGFja2V0KGVudmlyb25tZW50YWwgYXR0cmlidXRl cw0KPj4+Pj4gZm9yDQo+Pj4+Pj4+IGluc3RhbmNlKSBvciBhIGNvbWJpbmF0aW9uIHRoZXJlb2Yu IFdoYXQgaXMgaW1wb3J0YW50IGlzIHRoYXQgc3VjaA0KPj4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBh aWRzIGluIHRyYWZmaWMgc2VsZWN0aW9uIGFuZCBzZXJ2aWNlIHBhdGgNCj4+Pj4+Pj4gaWRlbnRp ZmljYXRpb24uDQo+Pj4+Pj4+IEl0IGlzIG5vIGRpZmZlcmVudCBmcm9tIGEgcG9saWN5IGluIHRo aXMgcmVnYXJkIGV4Y2VwdCB0aGF0IHRoZQ0KPj4+Pj4gcG9saWN5DQo+Pj4+Pj4+IG5vdw0KPj4+ Pj4+PiBzcGVjaWZpZXMgdGhlIHNlcnZpY2UgcGF0aC4NCj4+Pj4+Pj4gRnVydGhlciwgY2xhc3Np ZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gdGhlIG5ldHdvcmsgZWxlbWVudHMgYnV0DQo+Pj4+ PiB0aGUNCj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgYXMgd2VsbC4gU29tZSBvZiB0aGlzIGlz IGRlc2NyaWJlZCBpbiB0aGUNCj4+Pj4+IGFyY2hpdGVjdHVyZQ0KPj4+Pj4+PiBkcmFmdHMgYXMg d2VsbCAtDQo+Pj4+Pj4+ICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1x dWlubi1zZmMtYXJjaC8iLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTdXJlbmRyYS4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4gT24gMTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiIDxrZXZpbi5tYUBhenVraXN5 c3RlbXMuY29tPiB3cm90ZToNCj4+Pj4+Pj4NCj4+Pj4+Pj4+IEhpIFJvbiwNCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiAgSSB3YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNGQyBCb0YgZHVlIHRvIGEgY29uZmxp Y3Qgd2l0aCBDRE5JLCBidXQNCj4+Pj4+IEkNCj4+Pj4+Pj4+ICBoYWQgYSBzaW1pbGFyIHF1ZXN0 aW9uIHdydCBidWxsZXQgMTEgaW4gc2VjdGlvbiAyIG9mIHRoZSBwcm9ibGVtDQo+Pj4+Pj4+PiBz dGF0ZW1lbnQ6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgMTEuICBQZXItU2VydmljZSAocmUpQ2xh c3NpZmljYXRpb246IENsYXNzaWZpY2F0aW9uIG9jY3VycyBhdA0KPj4+Pj4gZWFjaA0KPj4+Pj4+ Pj4gICAgICAgICBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZpb3VzbHkgYXBwbGllZCBz ZXJ2aWNlDQo+Pj4+Pj4+IGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+ICAgICAgICAgVGhlc2UgdW5yZWxh dGVkIGNsYXNzaWZpY2F0aW9uIGV2ZW50cyBjb25zdW1lIHJlc291cmNlcw0KPj4+Pj4+Pj4gcGVy DQo+Pj4+Pj4+PiAgICAgICAgIHNlcnZpY2UuICBNb3JlIGltcG9ydGFudGx5LCB0aGUgY2xhc3Np ZmljYXRpb24NCj4+Pj4+IGZ1bmN0aW9uYWxpdHkNCj4+Pj4+Pj4+ICAgICAgICAgb2Z0ZW4gZGlm ZmVycyBwZXIgc2VydmljZSBmdW5jdGlvbiBhbmQgc2VydmljZSBmdW5jdGlvbg0KPj4+Pj4gY2Fu bm90DQo+Pj4+Pj4+PiAgICAgICAgIGxldmVyYWdlIHRoZSByZXN1bHRzIGZyb20gb3RoZXIgZGVw bG95ZWQgbmV0d29yayBvcg0KPj4+Pj4gc2VydmljZS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgYXMg aXQgcmVsYXRlcyB0byBzZWN0aW9uIDUuMiBvZiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Og0KPj4+ Pj4+Pj4NCj4+Pj4+Pj4+ICAgIFRoZSBTRkMgQ2xhc3NpZmllciBjbGFzc2lmaWVzIHBhY2tldHMg YmFzZWQgb24gKHNvbWUgb2YpIHRoZQ0KPj4+Pj4+PiBjb250ZW50cw0KPj4+Pj4+Pj4gICAgb2Yg dGhlIHBhY2tldCBoZWFkZXIuICBDb25jcmV0ZWx5LCBpdCBjbGFzc2lmaWVzIHBhY2tldHMgYmFz ZWQNCj4+Pj4+IG9uDQo+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4gICAgcG9zc2libGUgY29tYmluYXRp b24gb2Ygb25lIG9yIG1vcmUgaGVhZGVyIGZpZWxkcywgc3VjaCBhcw0KPj4+Pj4gc291cmNlDQo+ Pj4+Pj4+PiAgICBhZGRyZXNzLCBkZXN0aW5hdGlvbiBhZGRyZXNzLCBEUyBmaWVsZCwgcHJvdG9j b2wgSUQsIHNvdXJjZQ0KPj4+Pj4+Pj4gcG9ydA0KPj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+ICAgIGRl c3RpbmF0aW9uIHBvcnQgbnVtYmVycywgYW5kIGFueSBvdGhlciBpbmZvcm1hdGlvbi4NCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiAgQSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBhcyBkZXNjcmliZWQgaW4g dGhlIGZyYW1ld29yayBkb2N1bWVudA0KPj4+Pj4+PiB3b3VsZA0KPj4+Pj4+Pj4gIHNlZW0gdG8g YmUgbGltaXRlZCBpbiB3aGF0IGl0IGNhbiBjbGFzc2lmeT8gIFRoZSBzZXJ2aWNlIGZ1bmN0aW9u DQo+Pj4+Pj4+PiAgaWRlbnRpZmllciBsb29rdXAgZG9lcyBub3Qgc2VlbSB0byBiZSBhIHNpZ25p ZmljYW50IG9wdGltaXphdGlvbg0KPj4+Pj4gb3Zlcg0KPj4+Pj4+Pj4gIGEgcGFja2V0LWJhc2Vk IDUtdHVwbGUgbG9va3VwPyAgVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBtaXNzaW5nDQo+Pj4+PiBk ZXRhaWwNCj4+Pj4+Pj4+ICB3cnQgaG93IGNsYXNzaWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIGRl dGVybWluZWQgYW5kIHJldXNlZD8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgV2hlbiB0aGlua2luZyBh Ym91dCBoaWdoZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhUVFAgYW5kIFRMUw0KPj4+Pj4+PiBl bmNyeXB0ZWQNCj4+Pj4+Pj4+ICBmbG93cywgYSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBzZWVt cyBpbmFkZXF1YXRlPyAgSSB3YXMgYWxzbw0KPj4+Pj4+PiB3b25kZXJpbmcNCj4+Pj4+Pj4+ICBo b3cgaW5kZXBlbmRlbnQgSExTIHNlZ21lbnQgcmVxdWVzdHMgbWlnaHQgYmUgY2xhc3NpZmllZCBh bmQNCj4+Pj4+Pj4gYXNzb2NpYXRlZD8NCj4+Pj4+Pj4+ICBXZXJlIHRoZXNlIHR5cGVzIG9mIHVz ZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJvRj8NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiB0aGFueC4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+IE9m DQo+Pj4+Pj4+Pj4gUm9uDQo+Pj4+Pj4+Pj4gUGFya2VyDQo+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAxMSwgMjAxMyAxMDoxNiBQTQ0KPj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWpl ZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtu c2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFN1 bWFuZHJhLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQXMgd2FzIGRpc2N1c3NlZCBpbiBWYW5jb3V2 ZXIsIHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgZXhpc3RpbmcNCj4+Pj4+IHdheXMNCj4+Pj4+Pj4g dG8NCj4+Pj4+Pj4+PiBhY2NvbXBsaXNoIHNlcnZpY2UgY2hhaW5pbmcuICAgICBCdXQgbm9uZSBv ZiB0aGVtIHByb3ZpZGUgYQ0KPj4+Pj4+PiBzdWZmaWNpZW50DQo+Pj4+Pj4+Pj4gY29tYmluYXRp b24gb2YgaW50ZXJvcGVyYWJpbGl0eSwgZmxleGliaWxpdHksIGFuZCByZXNpbGllbmN5LiAgIEEN Cj4+Pj4+Pj4gc2luZ2xlDQo+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdp bGwgZ28gYSBsb25nIHdheSB0byBlbnN1cmluZyB0aGVzZQ0KPj4+Pj4+PiBnb2Fscy4NCj4+Pj4+ Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBtb3N0IGVmZmljaWVudCBhcHByb2Fj aCBmb3IgZXZlcnkNCj4+Pj4+Pj4gc2luZ2xlDQo+Pj4+Pj4+Pj4gbmV0d29yayB0b3BvbG9neSBh bmQgZXZlcnkgc2luZ2xlIHVzZSBjYXNlLCBidXQgaXRzIHViaXF1aXRvdXMNCj4+Pj4+IG5hdHVy ZQ0KPj4+Pj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+ICAgIFJvbg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IFN1bWFuZHJhIE1hamVlIFttYWlsdG86 Uy5NYWplZUBGNS5jb21dDQo+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAx MyAxMDoxMCBQTQ0KPj4+Pj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NA aWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBT RkMgY2hhcnRlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gUm9uLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gQWJzb2x1dGVseSwgdGhhdCB3YXMgYW4gZXhhbXBsZSBvZiBvbmUgdHlwZSBvZiBkZXJpdmF0 aW9uLiBIb3dldmVyDQo+Pj4+Pj4+IHRoaXMNCj4+Pj4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQg d2l0aCBjbGFzc2lmaWNhdGlvbiByZXN1bHQsIGFnYWluIG9uZSBtb3JlDQo+Pj4+Pj4+IGV4YW1w bGUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJj ZSBJUCBkbyBub3QgbmVjZXNzYXJpbHkgZm9sbG93IHRoZQ0KPj4+Pj4+PiBzYW1lDQo+Pj4+Pj4+ Pj4gY2hhaW4uDQo+Pj4+Pj4+Pj4gQ29ycmVjdC4gSXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRo YXQgYWxsIHRyYW5zYWN0aW9uIG9mIHRoZSBzYW1lDQo+Pj4+Pj4+IGZsb3cNCj4+Pj4+Pj4+PiBm b2xsb3cgdGhlIHNhbWUgY2hhaW4gZWl0aGVyLiBTbyB3aHkgc3RvcCBhdCBmbG93IGl0c2VsZi4N Cj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFnYWluIHRoZSBwb2ludCBoZXJlIGlzIHRoYXQgZG8gd2Ug YWx3YXlzIG5lZWQgU0ZDIGhlYWRlciBvciBOb3QuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBTdW1h bmRyYQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEs IDIwMTMgNzowMiBQTQ0KPj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRl bjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFN1bWFuZHJhLA0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gVGhlIGludGVudGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5n IGlzIHRvIGFsbG93IGZvcg0KPj4+Pj4gb3BlcmF0aW9uDQo+Pj4+Pj4+IGF0DQo+Pj4+Pj4+Pj4g dGhlIGZ1bGx5IHF1YWxpZmllZCBmbG93IGxldmVsLCBvciBldmVuIGZpbmVyIGdyYWluZWQgYXQg dGhlDQo+Pj4+Pj4+IHRyYW5zYWN0aW9uDQo+Pj4+Pj4+Pj4gbGV2ZWwgKHRoaXMgaXMgYW4gaW1w bGVtZW50YXRpb24gbWF0dGVyIGZvciB0aGUgUERQKS4gICAgIEFsbA0KPj4+Pj4gZmxvd3MNCj4+ Pj4+Pj4gZnJvbQ0KPj4+Pj4+Pj4+IHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVjZXNzYXJp bHkgZm9sbG93IHRoZSBzYW1lIGNoYWluLg0KPj4+Pj4gU291cmNlDQo+Pj4+Pj4+Pj4gSVAsDQo+ Pj4+Pj4+Pj4gdGhlcmVmb3JlLCAgZG9lcyBub3QgaWRlbnRpZnkgdGhlIGNoYWluIElELiAgICBB bm90aGVyIGludGVudGlvbg0KPj4+Pj4gb2YNCj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNo YWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29yayB0b3BvbG9neQ0KPj4+Pj4gYW5k DQo+Pj4+Pj4+Pj4gbm90DQo+Pj4+Pj4+Pj4gYmUgbGltaXRlZCB0byBhIHNpbmdsZSBMQU4uICAg VGh1cywgd2hpbGUgVkxBTiBtYXkgYmUgcGFydCBvZiB0aGUNCj4+Pj4+Pj4+PiB0cmFuc3BvcnQs IGl0IGRvZXMgbm90IGFkZXF1YXRlbHkgaWRlbnRpZnkgdGhlIHNlcnZpY2UgY2hhaW4sDQo+Pj4+ PiBlaXRoZXIuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgICBSb24NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9t OiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29tXQ0KPj4+Pj4+Pj4+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgOTo1NiBQTQ0KPj4+Pj4+Pj4+IFRvOiBSb24gUGFy a2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g Um9uLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhlIHNlcnZpY2UgaGVhZGVyIGlzIG1lYW50IHRv IGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoIGNhbiAqYWxzbyoNCj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4g ZGVyaXZlZCAoZm9yIGV4YW1wbGUgdXNlIHNvdXJjZSBpcCBhbmQgdmxhbiB0byBpZGVudGlmeSBj aGFpbklEDQo+Pj4+PiBhbmQNCj4+Pj4+Pj4+PiBwb3NpdGlvbikgb3IgZW5jYXBzdWxhdGVkIGFz IHBhcnQgb2YgYW5vdGhlciB0dW5uZWwgaGVhZGVyLiBTbw0KPj4+Pj4gdGhpcw0KPj4+Pj4+Pj4+ IGNvdWxkDQo+Pj4+Pj4+Pj4gYmUgb3B0aW9uYWwgSU1ITy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogUm9uIFBhcmtlciBb bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+Pj4+Pj4+Pj4gU2VudDog TW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA0OjM2IFBNDQo+Pj4+Pj4+Pj4gVG86IFN1bWFuZHJh IE1hamVlOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBS RTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gU3VtYW5kcmEsDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQsIGFu IFNGQyBwYWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0byBTRiBvcg0KPj4+Pj4gZnJvbQ0KPj4+ Pj4+PiBTRg0KPj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4gU0Ygd2lsbCBsb29rIGxpa2U6DQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4+IHwg ICAgICAgICJ0cmFuc3BvcnQiICAgICAgICAgfA0KPj4+Pj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQo+Pj4+Pj4+Pj4gfCAgICAgIHNlcnZpY2UgaGVhZGVyICAgIHwNCj4+Pj4+Pj4+ PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4+IHwgICBvcmlnaW5hbCBJUCBo ZWFkZXIgIHwNCj4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4+ IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIG9yaWdpbmFsIElQ IHBheWxvYWQNCj4+Pj4+IHwNCj4+Pj4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFdoZXJlIHNlcnZpY2UgaGVhZGVyIGNvbnRhaW5zLCBhdCBhIG1p bmltdW0sIGVub3VnaCBpbmZvcm1hdGlvbiB0bw0KPj4+Pj4+PiBhbGxvdw0KPj4+Pj4+Pj4+IHRo ZSBwYWNrZXQgdG8gYmUgcHJvcGFnYXRlZCBhbG9uZyB0aGUgZnVsbCBsZW5ndGggb2YgdGhlIGNo YWluLA0KPj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4gb3B0aW9uYWxseSwgb3RoZXIgbWV0YWRhdGEgdGhh dCBlbmhhbmNlcyB0aGUgb3BlcmF0aW9uIG9mIG9uZSBvcg0KPj4+Pj4gbW9yZQ0KPj4+Pj4+Pj4+ IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gIEFuZCB3aGVyZSAidHJh bnNwb3J0IiBjb3VsZCBjb25jZWl2YWJseSBiZSBhbnkgb2YsIGJ1dCBub3QNCj4+Pj4+IGxpbWl0 ZWQNCj4+Pj4+Pj4gdG86DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAqIEV0aGVybmV0DQo+Pj4+Pj4+ Pj4gKiBFdGhlcm5ldCArIExMQzINCj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgTVBMUw0KPj4+Pj4+ Pj4+ICogRXRoZXJuZXQgKyBJUCArIEdSRQ0KPj4+Pj4+Pj4+ICogRXRoZXJuZXQgKyBJUCArVURQ DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhl IGRpYWdyYW0gYWJvdmUgaXMgbm90IG1lYW50IHRvIGltcGx5DQo+Pj4+Pj4+Pj4gaW1tdXRhYmls aXR5LA0KPj4+Pj4+Pj4+IGJ1dCByYXRoZXIgdG8gc3BlY2lmeSB0aGUgcGFja2V0IHRoYXQgaXMg cHJvcGFnYXRlZCBmcm9tIHByZWNlZGluZw0KPj4+Pj4+Pj4+IGVudGl0eQ0KPj4+Pj4+Pj4+IHRv IHN1Y2NlZWRpbmcgZW50aXR5LCBwcmlvciB0byBlbmNhcHN1bGF0aW9uLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gICAgUm9uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+PiBPZg0KPj4+Pj4+ Pj4+IFN1bWFuZHJhIE1hamVlDQo+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwg MjAxMyA2OjQ2IFBNDQo+Pj4+Pj4+Pj4gVG86IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVy DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcg RW5jYXBzdWxhdGlvbjogQSBkb2N1bWVudCB3aWxsDQo+Pj4+Pj4+Pj4gICAgIGRlc2NyaWJlIHRo ZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24NCj4+Pj4+IGZv cm1hdA0KPj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4+ICAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+Pj4+IHBhdGgsDQo+ Pj4+Pj4+Pj4gICAgIGFuZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJl dHdlZW4gbm9kZXMgdGhhdA0KPj4+Pj4+Pj4+ICAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlv bnMuIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlDQo+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+Pj4+ Pj4+PiAgICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQg YW5kIHRoZQ0KPj4+Pj4gc2VydmljZQ0KPj4+Pj4+PiB0aGF0DQo+Pj4+Pj4+Pj4gaXMNCj4+Pj4+ Pj4+PiAgICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1lIGVuY2Fwc3VsYXRp b24gbWF5IGJlDQo+Pj4+Pj4+Pj4gdXNlZA0KPj4+Pj4gb24NCj4+Pj4+Pj4+PiAgICAgYSBzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgb3IgYXQNCj4+ Pj4+IGFueQ0KPj4+Pj4+Pj4+IG90aGVyDQo+Pj4+Pj4+Pj4gICAgIGxheWVyLCBhbmQgdGhlIHNh bWUgZW5jYXBzdWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUNCj4+Pj4+IGNvbnN0cnVjdGlvbg0K Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+ICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxl c3Mgb2YgdGhlIGFjdHVhbCBzZXJ2aWNlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gW1NNXSBXaGF0 IGRvZXMgaXQgbWVhbiBieSBhIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGVuY2Fwc3VsYXRpb24sICBh DQo+Pj4+Pj4+IG5ldw0KPj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gZm9ybWF0DQo+Pj4+Pj4+Pj4g ICAgICAgICAgICAgb3IgYW4gYWJpbGl0eSB0byBzZWxlY3Qgb25lIGVuY2Fwc3VsYXRpb24gZm9y bWF0IHRoYXQNCj4+Pj4+Pj4gZml0cw0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+IG5lZWQgZm9y IGEgZ2l2ZW4gc2VydmljZSBjaGFpbj8NCj4+Pj4+Pj4+PiAgICAgICAgICAgIFRoZSBhYmlsaXR5 IHRvIHNlbGVjdCBhIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gIHdvdWxkDQo+Pj4+PiBiZQ0KPj4+ Pj4gYQ0KPj4+Pj4+Pj4+IG1hbmFnZW1lbnQgcGxhbmUgZGVjaXNpb24uDQo+Pj4+Pj4+Pj4gICAg ICAgICAgIFRoZXJlIGFyZSBxdWl0ZSBhIGZldyBleGlzdGluZyBlbmNhcHN1bGF0aW9uIG1ldGhv ZHMNCj4+Pj4+IHRoYXQNCj4+Pj4+Pj4gY2FuDQo+Pj4+Pj4+Pj4gcG9zc2libHkgYmUgcmV1c2Vk IHRvIHByb3ZpZGUNCj4+Pj4+Pj4+PiAgICAgICAgICAgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3 ZWVuICAgc2VydmljZSBub2Rlcy4gSSBoYXZlDQo+Pj4+Pj4+Pj4gc2Vlbg0KPj4+Pj4+Pj4+IG1l bnRpb24NCj4+Pj4+Pj4+PiBvZiBHUkUsIGZvciBIVFRQIGJhc2VkDQo+Pj4+Pj4+Pj4gICAgICAg ICAgIGFwcGxpY2F0aW9ucyBjb250ZXh0cyBhcmUgdHJhbnNmZXJyZWQgdmlhIGhlYWRlcnMuDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+Pj4+PiBPZg0KPj4+Pj4+Pj4+IFRob21hcyBOYXJ0ZW4N Cj4+Pj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA2LCAyMDEzIDExOjA3IEFNDQo+ Pj4+Pj4+Pj4gVG86IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFtuc2NdIEN1cnJl bnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEhpLg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gQ3VycmVudCBjaGFydGVyIGNhbiBiZSBmb3VuZCBhdA0KPj4+Pj4+Pj4+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItDQo+Pj4+Pj4+Pj4gaWV0 Zi1zZmMvLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSXQgY29udGFpbnMgdGhlIHJldmlzZWQgbWFu YWdlbWVudCB0ZXh0IGFzIHdlbGwgYXMgdXBkYXRlZA0KPj4+Pj4+PiBtaWxlc3RvbmVzLg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQWxsIGtub3duIGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBJ ZiB0aGVyZSBhcmUgYW55IHJlbWFpbmluZw0KPj4+Pj4+PiBpc3N1ZXMsDQo+Pj4+Pj4+Pj4gcGxl YXNlIHNwZWFrIHVwIQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2hhcnRlciBjaGFydGVyLWlldGYt c2ZjLTAwLTA0DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBOZXR3b3Jrcywgc2VydmVycywgc3RvcmFn ZSB0ZWNobm9sb2dpZXMsIGFuZCBhcHBsaWNhdGlvbnMsIGhhdmUNCj4+Pj4+IGFsbA0KPj4+Pj4+ Pj4+IHVuZGVyZ29uZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gcmVjZW50IHllYXJzIHdpdGggdGhl IGludHJvZHVjdGlvbg0KPj4+Pj4gb2YNCj4+Pj4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0d29y ayBvdmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24uIFNlcnZpY2UNCj4+Pj4+IGRlbGl2ZXJ5DQo+ Pj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2Fu aXphdGlvbmFsIGNoYWxsZW5nZSB0aGF0DQo+Pj4+PiBpbnZvbHZlcw0KPj4+Pj4+Pj4+IHNpZ25p ZmljYW50IG1vZGlmaWNhdGlvbiB0byB0aGUgbmV0d29yayBjb25maWd1cmF0aW9uLg0KPj4+Pj4+ Pj4+IFNlcnZpY2VzIGFyZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQgY29t YmluYXRpb24gb2YgYQ0KPj4+Pj4+Pj4+IG51bWJlcg0KPj4+Pj4+Pj4+IG9mIHNlcnZpY2UgZnVu Y3Rpb25zIHRoYXQgYXJlIGRlcGxveWVkIGF0IGRpZmZlcmVudCBwb2ludHMgd2l0aGluDQo+Pj4+ PiB0aGUNCj4+Pj4+Pj4+PiBuZXR3b3JrLiBUb2RheSwgYSBjb21tb24gZGVwbG95bWVudCBtb2Rl bCBoYXMgc2VydmljZSBmdW5jdGlvbnMNCj4+Pj4+Pj4+PiBwaHlzaWNhbGx5DQo+Pj4+Pj4+Pj4g aW5zZXJ0ZWQgb24gdGhlIGRhdGEgZm9yd2FyZGluZyBwYXRoIGJldHdlZW4gY29tbXVuaWNhdGlu ZyBwZWVycy4NCj4+Pj4+Pj4gR29pbmcNCj4+Pj4+Pj4+PiBmb3J3YXJkLCBob3dldmVyLCB0aGVy ZSBpcyBhIGRlc2lyZSB0byBtb3ZlIHRvIGEgZGlmZmVyZW50IG1vZGVsLA0KPj4+Pj4+PiB3aGVy ZQ0KPj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gcmVzaWRl IG9uIHRoZSBkZWZhdWx0IGRhdGENCj4+Pj4+IHBhdGgNCj4+Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+ PiB0cmFmZmljIGlzIGluc3RlYWQgc3RlZXJlZCB0aHJvdWdoIHNlcnZpY2VzLCB3aGVyZXZlciB0 aGV5IGFyZQ0KPj4+Pj4+PiBkZXBsb3llZC4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEZvciBhIGdp dmVuIHNlcnZpY2UsIHRoZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlIHJlcXVpcmVkIHNlcnZpY2UN Cj4+Pj4+Pj4+PiBmdW5jdGlvbnMNCj4+Pj4+Pj4+PiBhbmQgdGhlIG9yZGVyIGluIHdoaWNoIHRo ZXkgYXJlIHRvIGJlIGFwcGxpZWQgaXMgY2FsbGVkIGEgU2VydmljZQ0KPj4+Pj4+Pj4+IEZ1bmN0 aW9uDQo+Pj4+Pj4+Pj4gQ2hhaW4gKFNGQykuIFNpbmNlIGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlv biBtYXkgYmUgYXZhaWxhYmxlIG9uDQo+Pj4+PiBtb3JlDQo+Pj4+Pj4+Pj4gdGhhbg0KPj4+Pj4+ Pj4+IG9uZSBub2RlIHdpdGhpbiBhIG5ldHdvcmssIGEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBp cw0KPj4+Pj4gaW5zdGFudGlhdGVkDQo+Pj4+Pj4+IHZpYQ0KPj4+Pj4+Pj4+IHRoZSBzZWxlY3Rp b24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgYW5kIHRoZQ0KPj4+Pj4g bmV0d29yaw0KPj4+Pj4+Pj4+IG5vZGVzDQo+Pj4+Pj4+Pj4gb24gd2hpY2ggdGhleSBhcmUgcHJv dmlkZWQsIHRoZXJlYnkgZm9ybWluZyBhIHNlcnZpY2UgdG9wb2xvZ3k6DQo+Pj4+Pj4+Pj4gdGhp cyBpcyBjYWxsZWQgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNlIGZ1bmN0aW9u cyBtYXkNCj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4gYXBwbGllZCBhdCBhIHNwZWNpZmljIGxheWVyIHdp dGhpbiB0aGUgbmV0d29yayBwcm90b2NvbCBzdGFjaw0KPj4+Pj4+PiAobmV0d29yaw0KPj4+Pj4+ Pj4+IGxheWVyLCBhcHBsaWNhdGlvbiBsYXllciwgZXRjLikuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSB3b3JraW5nIGdyb3VwIHdpbGwg ZGV2ZWxvcCBuZXcNCj4+Pj4+Pj4+PiBhcHByb2FjaGVzIHRvIHNlcnZpY2UgZGVsaXZlcnkgYW5k IGRlcGxveW1lbnQuIEl0IHdpbGwgcHJvZHVjZSBhDQo+Pj4+Pj4+Pj4gZnJhbWV3b3JrDQo+Pj4+ Pj4+Pj4gZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgdGhhdCBpbmNsdWRlcyB0aGUgbmVj ZXNzYXJ5DQo+Pj4+PiBwcm90b2NvbHMNCj4+Pj4+Pj4gb3INCj4+Pj4+Pj4+PiBwcm90b2NvbCBl eHRlbnNpb25zIHRvIGNvbnZleSB0aGUgc2VydmljZSBwYXRoIGFuZCBzZXJ2aWNlIHBhdGgNCj4+ Pj4+Pj4+PiBpbmZvcm1hdGlvbiB0byBub2RlcyB0aGF0IGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0 aW9ucywgYXMgd2VsbCBhcw0KPj4+Pj4+Pj4+IG1lY2hhbmlzbXMgZm9yIHN0ZWVyaW5nIHRyYWZm aWMgdGhyb3VnaCBzZXJ2aWNlIGZ1bmN0aW9ucy4gVGhlDQo+Pj4+Pj4+IHdvcmtpbmcNCj4+Pj4+ Pj4+PiBncm91cCB3aWxsIGFsc28gZXhhbWluZSB3aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJl IGdhdGhlcmVkIGZyb20NCj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4gbmV0d29yayBhbmQgc2Vydmlj ZSBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+PiBjaGFpbmlu Zw0KPj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+IGhvdyB0aGF0IGluZm9ybWF0aW9uIG1heSBiZSBt YWRlIGF2YWlsYWJsZSB0byBub2RlcyB0aGF0IGltcGxlbWVudA0KPj4+Pj4+PiB0aGUNCj4+Pj4+ Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFNwZWNpZmljYWxs eSwgdGhlIFNGQyBXRyBpcyBjaGFydGVyZWQgdG8gZGVsaXZlciB0aGUgZm9sbG93aW5nOg0KPj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4gMSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IFRoaXMgZG9jdW1lbnQgd2ls bCBwcm92aWRlIGEgc3VtbWFyeSBvZiB0aGUNCj4+Pj4+Pj4+PiAgICAgcHJvYmxlbSBzcGFjZSB0 byBiZSBhZGRyZXNzZWQgYnkgdGhlIFdHIGluY2x1ZGluZyBleGFtcGxlDQo+Pj4+PiBoaWdoLQ0K Pj4+Pj4+Pj4+ICAgICBsZXZlbCB1c2UgY2FzZXMuIEFkZGl0aW9uYWxseSwgdGhlIFdHIHdpbGwg bm9ybWFsaXplDQo+Pj4+PiBub21lbmNsYXR1cmUNCj4+Pj4+Pj4+PiAgICAgYW5kIGRlZmluaXRp b25zIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g MikgQXJjaGl0ZWN0dXJlOiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZSBhIGRlc2NyaXB0aW9u IG9mIHRoZQ0KPj4+Pj4+Pj4+ICAgICBhcmNoaXRlY3R1cmFsIGJ1aWxkaW5nIGJsb2NrcyBhbmQg dGhlaXIgcmVsYXRpb25zaGlwcw0KPj4+Pj4gaW5jbHVkaW5nDQo+Pj4+Pj4+Pj4gICAgIGludGVy Y29ubmVjdGlvbiwgcGxhY2VtZW50IG9mIGNhcGFiaWxpdGllcywgbWFuYWdlbWVudCwNCj4+Pj4+ Pj4+PiAgICAgZGlhZ25vc3RpY3MsIGRlc2lnbiBhbmFseXNpcywgYW5kIHNlY3VyaXR5IG1vZGVs cywgYXMgd2VsbCBhcw0KPj4+Pj4+Pj4+ICAgICByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29s IG1lY2hhbmlzbXMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAzKSBHZW5lcmljIFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSBkb2N1bWVudA0KPj4+Pj4gd2lsbA0KPj4+ Pj4+Pj4+ICAgICBkZXNjcmliZSB0aGUgc2luZ2xlIHNlcnZpY2UtbGV2ZWwgZGF0YSBwbGFuZSBl bmNhcHN1bGF0aW9uDQo+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+PiBmb3INCj4+Pj4+Pj4+PiAgICAg Y29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0aGUgc2VydmljZSBmdW5j dGlvbg0KPj4+Pj4+PiBwYXRoLA0KPj4+Pj4+Pj4+ICAgICBhbmQgZm9yIGNvbW11bmljYXRpbmcg Y29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQNCj4+Pj4+Pj4+PiAgICAgaW1w bGVtZW50IHNlcnZpY2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0KPj4+Pj4+ PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4gICAgIGJlIGFnbm9zdGljIHRvIHRoZSBsYXllciBh dCB3aGljaCBpdCBpcyBhcHBsaWVkIGFuZCB0aGUNCj4+Pj4+IHNlcnZpY2UNCj4+Pj4+Pj4gdGhh dA0KPj4+Pj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4gICAgIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlz LCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1heSBiZQ0KPj4+Pj4+Pj4+IHVzZWQNCj4+Pj4+IG9u DQo+Pj4+Pj4+Pj4gICAgIGEgc2VydmljZSBmdW5jdGlvbiBwYXRoIHJlYWxpemVkIGF0IHRoZSBu ZXR3b3JrIGxheWVyIG9yIGF0DQo+Pj4+PiBhbnkNCj4+Pj4+Pj4+PiBvdGhlcg0KPj4+Pj4+Pj4+ ICAgICBsYXllciwgYW5kIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBmb3IgdGhl DQo+Pj4+PiBjb25zdHJ1Y3Rpb24NCj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+PiAgICAgc2VydmljZSBm dW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IDQpIENvbnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBzZXQgb2YgZG9jdW1l bnRzIHdpbGwgYmUgZGV2ZWxvcGVkDQo+Pj4+PiB0bw0KPj4+Pj4+Pj4+ICAgICBkZXNjcmliZSBy ZXF1aXJlbWVudHMgYW5kIHByb3RvY29scyBuZWNlc3NhcnkgdG8gY29udmV5DQo+Pj4+Pj4+IGlu Zm9ybWF0aW9uDQo+Pj4+Pj4+Pj4gICAgIHRvIHNlcnZpY2UgZnVuY3Rpb24gaW1wbGVtZW50YXRp b24gcG9pbnRzLiBXaGVyZSBwb3NzaWJsZSwNCj4+Pj4+Pj4gZXhpc3RpbmcNCj4+Pj4+Pj4+PiAg ICAgSUVURiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIGFuZCBleHRlbmRlZC4gQWxsIHByb3RvY29s DQo+Pj4+PiBleHRlbnNpb25zDQo+Pj4+Pj4+Pj4gICAgIHdvcmsgc2hvdWxkIGJlIGNhcnJpZWQg b3V0IGluIHRoZSB3b3JraW5nIGdyb3VwcyByZXNwb25zaWJsZQ0KPj4+Pj4gZm9yDQo+Pj4+Pj4+ IHRoZQ0KPj4+Pj4+Pj4+ICAgICBwcm90b2NvbHMgYmVpbmcgbW9kaWZpZWQgaW4gY29vcmRpbmF0 aW9uIHdpdGggdGhpcyB3b3JraW5nDQo+Pj4+PiBncm91cCwNCj4+Pj4+Pj4+PiBidXQNCj4+Pj4+ Pj4+PiAgICAgbWF5IGJlIGRvbmUgaW4gdGhpcyB3b3JraW5nIGdyb3VwIGFmdGVyIGFncmVlbWVu dCB3aXRoIGFsbA0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+ICAgICByZWxldmFudCBXRyBjaGFp cnMgYW5kIHJlc3BvbnNpYmxlIEFEcy4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IDUpIE1hbmFnZWFi aWxpdHk6IFdvcmsgb24gdGhlIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YNCj4+Pj4+ IHNlcnZpY2UNCj4+Pj4+Pj4+PiAgICAgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2YgU0ZDIGNvbXBv bmVudHMgd2lsbCBjZXJ0YWlubHkgYmUNCj4+Pj4+IG5lZWRlZCwNCj4+Pj4+Pj4+PiAgICAgYnV0 IGZpcnN0IG5lZWRzIHRvIGJlIGJldHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+PiBQcm9wb3NlZCBNaWxlc3RvbmVzDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBB cHIgMjAxNCBTdWJtaXQgdG8gSUVTRyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50KHMpIGRlZmluaW5n IHRoZQ0KPj4+Pj4+PiBwcm9ibGVtDQo+Pj4+Pj4+Pj4gc3RhdGVtZW50IGFuZCBjb3JlIHVzZSBj YXNlcyBmb3IgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4g TWF5IDIwMTQgQ29uc3VsdCB3aXRoIE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNoYXJ0ZXIgbW9kaWZp Y2F0aW9ucw0KPj4+Pj4gZm9yDQo+Pj4+Pj4+Pj4gbWFuYWdlbWVudCBhbmQgY29uZmlndXJhdGlv biBvZiBTRkMgY29tcG9uZW50cw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSmFuIDIwMTUgU3VibWl0 IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZWZpbmluZyB0aGUNCj4+Pj4+Pj4gYXJj aGl0ZWN0dXJlDQo+Pj4+Pj4+Pj4gZm9yIFNGQw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSmFuIDIw MTUgU3VibWl0IHRvIElFU0cgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVyaWMgc2VydmljZQ0KPj4+ Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+PiBjaGFpbmluZyBlbmNhcHN1bGF0aW9uIHByb3RvY29sDQo+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBBdWcgMjAxNSBTdWJtaXQgdG8gSUVTRyBTdGFuZGFyZHMgVHJh Y2sgZG9jdW1lbnQgc3BlY2lmeWluZyB0aGUNCj4+Pj4+Pj4gZ2VuZXJpYw0KPj4+Pj4+Pj4+IHNl cnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaGVhZGVyIGVuY2Fwc3VsYXRpb24NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gVGhv bWFzDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+PiBu c2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zYw0KPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IG5zY0BpZXRm Lm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNj DQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+ Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+ Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4NCj4+Pj4NCj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4g bnNjIG1haWxpbmcgbGlzdA0KPj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+IG5z Y0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNj DQo+Pj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gbnNjIG1haWxpbmcgbGlzdA0KPiBuc2NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVt b3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStE DQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQu ZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1l bnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2Eg ZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFj ZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZl bHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0 aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9Q QUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From kevin.ma@azukisystems.com Tue Nov 12 07:49:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B9221E817D for ; Tue, 12 Nov 2013 07:49:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COFIgapvHhUC for ; Tue, 12 Nov 2013 07:48:53 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9FFF621F9D46 for ; Tue, 12 Nov 2013 07:48:38 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 010A57AE9B5; Tue, 12 Nov 2013 10:48:38 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7DC3A7AE8C9; Tue, 12 Nov 2013 10:48:36 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Tue, 12 Nov 2013 10:45:24 -0500 From: Kevin J Ma To: Linda Dunbar , Ron Parker , "Hongyu Li (Julio)" Date: Tue, 12 Nov 2013 10:48:34 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN+0+4iz5RRxkOCS0vXxMG0/5ohQBeAgAAOHICAACcJgIAAAa2AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oD//46zEIAAAodQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:49:05 -0000 Hi Linda, Are you saying that a branching point is "never" a reclassification point, or are you saying that a branching point "does not have to be" a reclassification point? I think this is an important distinction that needs to be clarified. If branching is never reclassification, then the meaning of a chain is different than I originally inferred. If the chain is a tree with other "branching" points in it, then that limits the scope of the problem statement goals. While this could be a degenerate case, and any implementation could define bad service chains, is it the intent of SFC to only look at the simpler packet-level classification cases, or is it the intent to consider the case where a branching point is viewed as a re-classification point? thanx. -- Kevin J. Ma > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Tuesday, November 12, 2013 10:34 AM > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Ron, > > First, want to make it clear that "branching" !=3D reclassification, agre= e? > > Second, the representation of branching (or service graph) can be in a > form of logic on a service function. Some service functions, especially L= 7 > based, can use value in a Database to determine what is the next service > function. > > Linda > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Ron Parker > > Sent: Tuesday, November 12, 2013 8:16 AM > > To: Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Hongyu, > > > > I agree completely that re-classification is not limited to DPI. > > > > And also, that an area for us to explore as a group is how to represent > > the service graph. Do we want to represent it as a proper graph with > > an adjacency list or other representational model? Or, do we want to > > represent it as a set of linear segments and if so, how are the > > segments connected into a graph? Other ideas? > > > > Ron > > > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Hongyu Li (Julio) > > Sent: Tuesday, November 12, 2013 6:57 AM > > To: Ron Parker; Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Branching/forking is a very interesting topic of SFC. About the re- > > classification point, probably we shall not limit it to DPI. It is also > > possible that packets go to different branches after been processed by > > a certain service function, decision of which branches to go is made > > based on the result of service function's process, i.e. not just re- > > classification by DPI. > > > > Hongyu > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > > Ron Parker > > Sent: Tuesday, November 12, 2013 7:45 PM > > To: Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Hi, Kevin > > > > You ask a great question about branching the graph. The details around > > how to convey the selection of the subtree/subgraph are still to be > > defined. Is it one chain id for the whole graph? Does each branch > > have its own chain id? Some combination? > > > > Ron > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > > wrote: > > > > >> Yes, reclassification can change the service path and > > >> re-classification may happen at any node along a service path. > > > > > > Just to expand on that, going back to the original question about > > > service header encapsulation, is it intended that a chain that is > > > re-classified will get a new chain ID which fully describes a chain > > > that is a superset of the original chain ID, prior to DPI-based > > > re-classification? (assuming the goal is "a single chain ID that is > > > commonly understood along the entire service chain" > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > And the applicable subset of the permutative list of service paths > > > would be configured at each appropriate service node? > > > e.g., ID 1: NAT + firewall + DPI > > > ID 2: NAT + firewall + DPI + AV > > > ID 3: NAT + firewall + DPI + AV + NAT > > > ID 4: NAT + firewall + DPI + NAT > > > ID 5: NAT + firewall + DPI + AV + LB > > > ID 6: NAT + firewall + DPI + LB > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > ID 8: NAT + firewall + DPI + CACHE > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow > > > then be initially classified as ID 1, but eventually get re- > > classified > > > to ID 2-11, after the DPI phase? > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > >> -----Original Message----- > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > >> nsc@ietf.org > > >> Subject: Re: [nsc] Current Proposed SFC charter > > >> > > >> > > >> > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote= : > > >>> > > >>> Hi Surendra, > > >>> > > >>> Classification may be out of scope, but the level of service that > > is > > >>> applicable is dependent upon the level of classification that can > > be > > >>> performed. An assumption of packet level encapsulation has > > >> implications > > >>> on the level of classification being performed? If the stated > > goals > > >> are > > >>> for firewall and load balancer functionality, then the application > > >> level > > >>> nature of those functions needs to be taken into account? If, on > > >>> the other hand, the service function scope is limited due to > > >>> limitations in classification, that would be and important piece of > > information? > > >>> > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > > >>> points of the service paths seem like re-classification points? Is > > >>> that the interpretation from the architecture perspective? Or is > > >>> the service function chain classification exclusive of DPI > > functionality? > > >> I have not fully read that draft yet. But in general, as > > >> described in the arch draft, the collection of services form a graph= , > > >> segments of which are service paths. Yes, reclassification can > > change > > >> the service path and re-classification may happen at any node along > > a service path. > > >> > > >> Surendra. > > >>> > > >>> thanx. > > >>> > > >>> -- Kevin J. Ma > > >>> > > >>>> -----Original Message----- > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > >>>> nsc@ietf.org > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>> > > >>>> Kevin, > > >>>> > > >>>> Classification mechanism is outside the scope of SFC. It can be > > >>>> based > > >> on > > >>>> the packet or information not in the packet(environmental > > >>>> attributes > > >> for > > >>>> instance) or a combination thereof. What is important is that such > > >>>> classification aids in traffic selection and service path > > >>>> identification. > > >>>> It is no different from a policy in this regard except that the > > >>>> policy now specifies the service path. > > >>>> Further, classification is not limited to the network elements but > > >>>> the service functions as well. Some of this is described in the > > >> architecture > > >>>> drafts as well - > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > >>>> > > >>>> Surendra. > > >>>> > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > > wrote: > > >>>>> > > >>>>> Hi Ron, > > >>>>> > > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but > > >>>>> I had a similar question wrt bullet 11 in section 2 of the > > problem > > >>>>> statement: > > >>>>> > > >>>>> 11. Per-Service (re)Classification: Classification occurs at > > each > > >>>>> service, independent from previously applied service > > >>>> functions. > > >>>>> These unrelated classification events consume resources > > per > > >>>>> service. More importantly, the classification > > functionality > > >>>>> often differs per service function and service function > > >> cannot > > >>>>> leverage the results from other deployed network or > > service. > > >>>>> > > >>>>> as it relates to section 5.2 of the framework document: > > >>>>> > > >>>>> The SFC Classifier classifies packets based on (some of) the > > >>>> contents > > >>>>> of the packet header. Concretely, it classifies packets based > > >>>>> on > > >>>> the > > >>>>> possible combination of one or more header fields, such as > > source > > >>>>> address, destination address, DS field, protocol ID, source > > port > > >>>> and > > >>>>> destination port numbers, and any other information. > > >>>>> > > >>>>> A packet-based classifier as described in the framework document > > >>>> would > > >>>>> seem to be limited in what it can classify? The service function > > >>>>> identifier lookup does not seem to be a significant optimization > > >> over > > >>>>> a packet-based 5-tuple lookup? There seems to be some missing > > >> detail > > >>>>> wrt how classification information is determined and reused? > > >>>>> > > >>>>> When thinking about higher level services, e.g., HTTP and TLS > > >>>> encrypted > > >>>>> flows, a packet-based classifier seems inadequate? I was also > > >>>> wondering > > >>>>> how independent HLS segment requests might be classified and > > >>>> associated? > > >>>>> Were these types of use cases discussed in the BoF? > > >>>>> > > >>>>> thanx. > > >>>>> > > >>>>> -- Kevin J. Ma > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > >>>>>> Behalf > > >> Of > > >>>>>> Ron > > >>>>>> Parker > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> As was discussed in Vancouver, there are already many existing > > >>>>>> ways > > >>>> to > > >>>>>> accomplish service chaining. But none of them provide a > > >>>> sufficient > > >>>>>> combination of interoperability, flexibility, and resiliency. > > A > > >>>> single > > >>>>>> service chain encapsulation will go a long way to ensuring these > > >>>> goals. > > >>>>>> It may not be the absolutely most efficient approach for every > > >>>> single > > >>>>>> network topology and every single use case, but its ubiquitous > > >> nature > > >>>>>> should improve its adoption. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Ron, > > >>>>>> > > >>>>>> Absolutely, that was an example of one type of derivation. > > >>>>>> However > > >>>> this > > >>>>>> could be augmented with classification result, again one more > > >>>> example. > > >>>>>> > > >>>>>>>> All flows from the same source IP do not necessarily follow > > the > > >>>> same > > >>>>>> chain. > > >>>>>> Correct. It is also not necessary that all transaction of the > > >>>>>> same > > >>>> flow > > >>>>>> follow the same chain either. So why stop at flow itself. > > >>>>>> > > >>>>>> Again the point here is that do we always need SFC header or Not= . > > >>>>>> > > >>>>>> Sumandra > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> The intention of service function chaining is to allow for > > >>>>>> operation > > >>>> at > > >>>>>> the fully qualified flow level, or even finer grained at the > > >>>> transaction > > >>>>>> level (this is an implementation matter for the PDP). All > > flows > > >>>> from > > >>>>>> the same source IP do not necessarily follow the same chain. > > >> Source > > >>>>>> IP, > > >>>>>> therefore, does not identify the chain ID. Another intention > > of > > >>>>>> service function chaining is to operate over any network > > topology > > >> and > > >>>>>> not > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > > the > > >>>>>> transport, it does not adequately identify the service chain, > > >> either. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Ron, > > >>>>>> > > >>>>>> The service header is meant to carry the context which can > > *also* > > >>>>>> be derived (for example use source ip and vlan to identify > > >>>>>> chainID and > > >>>>>> position) or encapsulated as part of another tunnel header. So > > >>>>>> this could be optional IMHO. > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF or > > >>>>>> from > > >>>> SF > > >>>>>> to > > >>>>>> SF will look like: > > >>>>>> > > >>>>>> +------------------------+ > > >>>>>> | "transport" | > > >>>>>> +------------------------+ > > >>>>>> | service header | > > >>>>>> +------------------------+ > > >>>>>> | original IP header | > > >>>>>> +------------------------+ > > >>>>>> | | original IP payload > > | > > >>>>>> | | > > >>>>>> +------------------------+ > > >>>>>> > > >>>>>> Where service header contains, at a minimum, enough information > > >>>>>> to > > >>>> allow > > >>>>>> the packet to be propagated along the full length of the chain, > > >>>>>> and optionally, other metadata that enhances the operation of > > one > > >>>>>> or > > >> more > > >>>>>> service functions. > > >>>>>> > > >>>>>> And where "transport" could conceivably be any of, but not > > >>>>>> limited > > >>>> to: > > >>>>>> > > >>>>>> * Ethernet > > >>>>>> * Ethernet + LLC2 > > >>>>>> * Ethernet + MPLS > > >>>>>> * Ethernet + IP + GRE > > >>>>>> * Ethernet + IP +UDP > > >>>>>> > > >>>>>> > > >>>>>> Also, "original" in the diagram above is not meant to imply > > >>>>>> immutability, but rather to specify the packet that is > > propagated > > >>>>>> from preceding entity to succeeding entity, prior to > > >>>>>> encapsulation. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > >>>>>> Behalf > > >> Of > > >>>>>> Sumandra Majee > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > >>>>>> To: Thomas Narten; nsc@ietf.org > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Generic Service Function Chaining Encapsulation: A document will > > >>>>>> describe the single service-level data plane encapsulation > > >> format > > >>>>>> for > > >>>>>> conveying the service function chain and the service function > > >>>> path, > > >>>>>> and for communicating context information between nodes that > > >>>>>> implement service functions. It is intended that the > > >>>> encapsulation > > >>>>>> be agnostic to the layer at which it is applied and the > > >>>>>> service > > >>>> that > > >>>>>> is > > >>>>>> being constructed. That is, the same encapsulation may be > > used > > >> on > > >>>>>> a service function path realized at the network layer or at > > >>>>>> any other > > >>>>>> layer, and the same encapsulation will apply for the > > >> construction > > >>>> of > > >>>>>> service function paths regardless of the actual service. > > >>>>>> > > >>>>>> [SM] What does it mean by a single service-level encapsulation, > > a > > >>>> new > > >>>>>> encapsulation format > > >>>>>> or an ability to select one encapsulation format that > > >>>> fits > > >>>>>> the > > >>>>>> need for a given service chain? > > >>>>>> The ability to select a specific encapsulation would > > >>>>>> be > > >> a > > >>>>>> management plane decision. > > >>>>>> There are quite a few existing encapsulation methods > > >>>>>> that > > >>>> can > > >>>>>> possibly be reused to provide > > >>>>>> context information between service nodes. I have > > seen > > >>>>>> mention > > >>>>>> of GRE, for HTTP based > > >>>>>> applications contexts are transferred via headers. > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > >>>>>> Behalf > > >> Of > > >>>>>> Thomas Narten > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > >>>>>> To: nsc@ietf.org > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Hi. > > >>>>>> > > >>>>>> Current charter can be found at > > >>>>>> https://datatracker.ietf.org/doc/charter- > > >>>>>> ietf-sfc/. > > >>>>>> > > >>>>>> It contains the revised management text as well as updated > > >>>> milestones. > > >>>>>> > > >>>>>> All known issues have been addressed. If there are any remaining > > >>>> issues, > > >>>>>> please speak up! > > >>>>>> > > >>>>>> Charter charter-ietf-sfc-00-04 > > >>>>>> > > >>>>>> Networks, servers, storage technologies, and applications, have > > >>>>>> all undergone significant change in recent years with the > > >>>>>> introduction > > >> of > > >>>>>> virtualization, network overlays, and orchestration. Service > > >> delivery > > >>>> is > > >>>>>> currently both a technical and organizational challenge that > > >> involves > > >>>>>> significant modification to the network configuration. > > >>>>>> Services are typically implemented by the ordered combination of > > >>>>>> a number of service functions that are deployed at different > > >>>>>> points within > > >> the > > >>>>>> network. Today, a common deployment model has service functions > > >>>>>> physically inserted on the data forwarding path between > > >>>>>> communicating peers. > > >>>> Going > > >>>>>> forward, however, there is a desire to move to a different model= , > > >>>> where > > >>>>>> service functions are not required to reside on the default data > > >> path > > >>>>>> and > > >>>>>> traffic is instead steered through services, wherever they are > > >>>> deployed. > > >>>>>> > > >>>>>> For a given service, the abstracted view of the required service > > >>>>>> functions and the order in which they are to be applied is > > called > > >>>>>> a Service Function Chain (SFC). Since a given service function > > >>>>>> may be available on more than one node within a network, a > > >>>>>> Service Function Chain is instantiated > > >>>> via > > >>>>>> the selection of specific service function instances and the > > >>>>>> network nodes on which they are provided, thereby forming a > > >>>>>> service topology: > > >>>>>> this is called a Service Function Path. The service functions > > may > > >>>>>> be applied at a specific layer within the network protocol stack > > >>>> (network > > >>>>>> layer, application layer, etc.). > > >>>>>> > > >>>>>> The Service Function Chaining (SFC) working group will develop > > >>>>>> new approaches to service delivery and deployment. It will > > >>>>>> produce a framework for service function chaining that includes > > >>>>>> the necessary protocols > > >>>> or > > >>>>>> protocol extensions to convey the service path and service path > > >>>>>> information to nodes that implement service functions, as well > > as > > >>>>>> mechanisms for steering traffic through service functions. The > > >>>> working > > >>>>>> group will also examine what information needs to be gathered > > >>>>>> from > > >>>> the > > >>>>>> network and service functions in support of service function > > >> chaining > > >>>>>> and > > >>>>>> how that information may be made available to nodes that > > >>>>>> implement > > >>>> the > > >>>>>> service functions. > > >>>>>> > > >>>>>> Specifically, the SFC WG is chartered to deliver the following: > > >>>>>> > > >>>>>> 1) Problem Statement: This document will provide a summary of > > the > > >>>>>> problem space to be addressed by the WG including example > > high- > > >>>>>> level use cases. Additionally, the WG will normalize > > >> nomenclature > > >>>>>> and definitions for service function chaining. > > >>>>>> > > >>>>>> 2) Architecture: This document will provide a description of the > > >>>>>> architectural building blocks and their relationships > > including > > >>>>>> interconnection, placement of capabilities, management, > > >>>>>> diagnostics, design analysis, and security models, as well as > > >>>>>> requirements on the protocol mechanisms. > > >>>>>> > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A document > > will > > >>>>>> describe the single service-level data plane encapsulation > > >> format > > >>>>>> for > > >>>>>> conveying the service function chain and the service function > > >>>> path, > > >>>>>> and for communicating context information between nodes that > > >>>>>> implement service functions. It is intended that the > > >>>> encapsulation > > >>>>>> be agnostic to the layer at which it is applied and the > > >>>>>> service > > >>>> that > > >>>>>> is > > >>>>>> being constructed. That is, the same encapsulation may be > > used > > >> on > > >>>>>> a service function path realized at the network layer or at > > >>>>>> any other > > >>>>>> layer, and the same encapsulation will apply for the > > >> construction > > >>>> of > > >>>>>> service function paths regardless of the actual service. > > >>>>>> > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > developed to > > >>>>>> describe requirements and protocols necessary to convey > > >>>> information > > >>>>>> to service function implementation points. Where possible, > > >>>> existing > > >>>>>> IETF protocols will be used and extended. All protocol > > >> extensions > > >>>>>> work should be carried out in the working groups responsible > > >>>>>> for > > >>>> the > > >>>>>> protocols being modified in coordination with this working > > >> group, > > >>>>>> but > > >>>>>> may be done in this working group after agreement with all > > the > > >>>>>> relevant WG chairs and responsible ADs. > > >>>>>> > > >>>>>> 5) Manageability: Work on the management and configuration of > > >> service > > >>>>>> functions in support of SFC components will certainly be > > needed, > > >>>>>> but first needs to be better understood and scoped. > > >>>>>> > > >>>>>> Proposed Milestones > > >>>>>> > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining the > > >>>> problem > > >>>>>> statement and core use cases for Service Function Chaining > > >>>>>> > > >>>>>> May 2014 Consult with OPS Area on possible charter modifications > > >>>>>> for management and configuration of SFC components > > >>>>>> > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > >>>> architecture > > >>>>>> for SFC > > >>>>>> > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > > >>>>>> function chaining encapsulation protocol > > >>>>>> > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying the > > >>>> generic > > >>>>>> service function chaining header encapsulation > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thomas > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>> _______________________________________________ > > >>>>> nsc mailing list > > >>>>> nsc@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From diego@tid.es Tue Nov 12 07:53:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E51B21E8260 for ; Tue, 12 Nov 2013 07:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.487 X-Spam-Level: X-Spam-Status: No, score=-6.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klAi8mIR4Xge for ; Tue, 12 Nov 2013 07:53:01 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2597121E824B for ; Tue, 12 Nov 2013 07:53:01 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MW500DZLQSBZI@tid.hi.inet> for nsc@ietf.org; Tue, 12 Nov 2013 16:53:00 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 27.CC.03197.BDE42825; Tue, 12 Nov 2013 16:52:59 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MW500DZBQSBZI@tid.hi.inet> for nsc@ietf.org; Tue, 12 Nov 2013 16:52:59 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.212]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 16:52:59 +0100 Date: Tue, 12 Nov 2013 15:52:58 +0000 From: "Diego R. Lopez" In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> X-Originating-IP: [10.95.64.115] To: Linda Dunbar Message-id: <8E715FBD-D549-4993-AFBA-F7368E57463C@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [nsc] Current Proposed SFC charter Thread-index: AQHO2yN7m3OAQxch8keQPslbkvW+7pohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMD//0UOAIAABVqA X-AuditID: 0a5f4068-b7f3e8e000000c7d-e3-52824edb827b X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhinfg0r3t1xRk0N1tbXF83342B0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlnHrjXXBAoOL6bacGxg6BLkZODgkBE4mXk16xQ9hiEhfurWfr YuTiEBI4wCjRtG8PE4TzlVHiw5cl7BDOTEaJK58bWUBaWARUJRYdesEIYrMB2Y+af4ONEhbQ lzg89yQriM0pECGxecJVNogVChJ/zj0G6xUR0JJ4fO8M2FBmgflMEguXfgRr4BWwlJjT+Bds ELOAmcT61w9YIOKCEj8m3wOyOYDi6hJTpuRClIhLNLfeZIGwFSWmLWoAu4dRQFbi3fz5rBC7 DCSefd7DCLJLRGAGo8TlBztZIA4SkFiy5zwzhC0q8fLxP1aIL68zSzS+f8o8gVFiFpI7ZiG5 YxbCHbOQ3DELyR0LGFlXMYoVJxVlpmeU5CZm5qQbGOplZOpl5qWWbGKExF3GDsblO1UOMQpw MCrx8B4QbAwSYk0sK67MPcQowcGsJMK7ybMpSIg3JbGyKrUoP76oNCe1+BAjEwenVAPjep9J u3pkAt8cMvzQ2nV6rtjNvvZjOzQndtx/JKKayGAzrU1OUV58nukttzaP/zPnlX34Nq23ICtw 5vRI03gr/woOhlNG5cHLe5avW/9ISPhNzZ03ezarv3F6rBeuwTzxb5hppp5xT0ZhSLs1U5Jo FVNF6LJMRz8JXs5tst3cbNt6lzvn3VFiKc5INNRiLipOBABKvH9OmQIAAA== References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Kevin J Ma , "Hongyu Li \(Julio\)" , Ron Parker , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:53:06 -0000 SGksDQoNCk9uIDEyIE5vdiAyMDEzLCBhdCAxNjozMyAsIExpbmRhIER1bmJhciB3cm90ZToNCj4N Cj4gRmlyc3QsIHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0ICJicmFuY2hpbmciICE9IHJlY2xh c3NpZmljYXRpb24sIGFncmVlPw0KDQpEUkw+IEF0IGxlYXN0LCBJIGRvIGFncmVlLiBSZWNsYXNz aWZpY2F0aW9uIGNhbiBsZWFkIHRvIGJyYW5jaGluZyBvciBub3QsIGRlcGVuZGluZyBvbiB0aGUg cGF0aHMgYXZhaWxhYmxlIGF0IHRoZSByZWNsYXNzaWZ5aW5nIG5vZGUuLi4NCg0KPiBTZWNvbmQs IHRoZSByZXByZXNlbnRhdGlvbiBvZiBicmFuY2hpbmcgKG9yIHNlcnZpY2UgZ3JhcGgpIGNhbiBi ZSBpbiBhIGZvcm0gb2YgbG9naWMgb24gYSBzZXJ2aWNlIGZ1bmN0aW9uLiBTb21lIHNlcnZpY2Ug ZnVuY3Rpb25zLCBlc3BlY2lhbGx5IEw3IGJhc2VkLCBjYW4gdXNlIHZhbHVlIGluIGEgRGF0YWJh c2UgdG8gZGV0ZXJtaW5lIHdoYXQgaXMgdGhlIG5leHQgc2VydmljZSBmdW5jdGlvbi4NCg0KRFJM PiBBbnl3YXksIGEgZ3JhcGggaXMgd2hhdCBJIHNlZSBhcyB0aGUgYmVzdCBjb25jZXB0LCBjb3Zl cmluZyBhbGwgcG9zc2libGUgY2FzZXMgSSBjYW4gdGhpbmsgb2YuIElmIHJlY2xhc3NpZmljYXRp b24gb3IgYnJhbmNoaW5nIGhhcHBlbnMsIHdlIHdvdWxkIGJlIHRhbGtpbmcgb2YgZGlmZmVyZW50 IG5vZGUgdHlwZXMgYW5kL29yIGxhYmVsbGVkIGxpbmtzIGJldHdlZW4gbm9kZXMuIE9uY2Ugd2Ug YWdyZWUgaW4gdGhlIGdyYXBoIGFzIHRoZSBjb25jZXB0dWFsIG1vZGVsLCBJJ2QgZ28gZm9yIGFn cmVlaW5nIGluIHRoZSBpbmZvcm1hdGlvbiBtb2RlbCAodGhlIG5vZGUgYW5kIGxpbmsgYXR0cmli dXRlcykgYW5kIG9uZSBvciBldmVuIHNldmVyYWwgZGF0YSBtb2RlbHMgZm9yIGl0Lg0KDQpCZSBn b29kZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoN CkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMv ZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5 IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K RXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4g UHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24g ZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0K VGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBX ZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBz ZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgN Cg== From Ron_Parker@affirmednetworks.com Tue Nov 12 07:54:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEB821E8271 for ; Tue, 12 Nov 2013 07:54:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d2+Gm45CeBp for ; Tue, 12 Nov 2013 07:53:56 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id B584821E8260 for ; Tue, 12 Nov 2013 07:53:51 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 07:53:44 -0800 From: Ron Parker To: Kevin J Ma , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMD//9vuAIAABCAAgACFyFA= Date: Tue, 12 Nov 2013 15:53:44 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 15:54:00 -0000 I think the lack of definition of "reclassification" may be causing some mi= sunderstandings here. A branch would occur for some policy-driven reason= based on the behavior and conclusions of the service function, itself. T= he graph would represent the fact that there is a branch point, but the ser= vice function, itself, being aware that it is a branching point would conta= in the policy and logic to decide on which branch to take. Specifying tha= t policy and logic is out of scope, IMO. Ron -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Tuesday, November 12, 2013 10:49 AM To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter Hi Linda, Are you saying that a branching point is "never" a reclassification point, or are you saying that a branching point "does not have to be" a reclassification point? I think this is an important distinction that needs to be clarified. If branching is never reclassification, then the meaning of a chain is different than I originally inferred. If the chain is a tree with other "branching" points in it, then that limits the scope of the problem statement goals. While this could be a degenerate case, and any implementation could define bad service chains, is it the intent of SFC to only look at the simpler packet-level classification cases, or is it the intent to consider the case where a branching point is viewed as a re-classification point? thanx. -- Kevin J. Ma > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Tuesday, November 12, 2013 10:34 AM > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Ron, > > First, want to make it clear that "branching" !=3D reclassification, agre= e? > > Second, the representation of branching (or service graph) can be in a=20 > form of logic on a service function. Some service functions,=20 > especially L7 based, can use value in a Database to determine what is=20 > the next service function. > > Linda > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > Of Ron Parker > > Sent: Tuesday, November 12, 2013 8:16 AM > > To: Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Hongyu, > > > > I agree completely that re-classification is not limited to DPI. > > > > And also, that an area for us to explore as a group is how to represent > > the service graph. Do we want to represent it as a proper graph with > > an adjacency list or other representational model? Or, do we want to > > represent it as a set of linear segments and if so, how are the > > segments connected into a graph? Other ideas? > > > > Ron > > > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > Of Hongyu Li (Julio) > > Sent: Tuesday, November 12, 2013 6:57 AM > > To: Ron Parker; Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Branching/forking is a very interesting topic of SFC. About the re-=20 > > classification point, probably we shall not limit it to DPI. It is=20 > > also possible that packets go to different branches after been=20 > > processed by a certain service function, decision of which branches=20 > > to go is made based on the result of service function's process,=20 > > i.e. not just re- classification by DPI. > > > > Hongyu > > > > -----Original Message----- > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > Of Ron Parker > > Sent: Tuesday, November 12, 2013 7:45 PM > > To: Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > > Majee > > Subject: Re: [nsc] Current Proposed SFC charter > > > > Hi, Kevin > > > > You ask a great question about branching the graph. The details=20 > > around how to convey the selection of the subtree/subgraph are still to= be > > defined. Is it one chain id for the whole graph? Does each branch > > have its own chain id? Some combination? > > > > Ron > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma"=20 > > > > wrote: > > > > >> Yes, reclassification can change the service path and=20 > > >> re-classification may happen at any node along a service path. > > > > > > Just to expand on that, going back to the original question about=20 > > > service header encapsulation, is it intended that a chain that is=20 > > > re-classified will get a new chain ID which fully describes a=20 > > > chain that is a superset of the original chain ID, prior to=20 > > > DPI-based re-classification? (assuming the goal is "a single=20 > > > chain ID that is commonly understood along the entire service chain" > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > And the applicable subset of the permutative list of service paths=20 > > > would be configured at each appropriate service node? > > > e.g., ID 1: NAT + firewall + DPI > > > ID 2: NAT + firewall + DPI + AV > > > ID 3: NAT + firewall + DPI + AV + NAT > > > ID 4: NAT + firewall + DPI + NAT > > > ID 5: NAT + firewall + DPI + AV + LB > > > ID 6: NAT + firewall + DPI + LB > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > ID 8: NAT + firewall + DPI + CACHE > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every=20 > > > flow then be initially classified as ID 1, but eventually get re- > > classified > > > to ID 2-11, after the DPI phase? > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > >> -----Original Message----- > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > >> nsc@ietf.org > > >> Subject: Re: [nsc] Current Proposed SFC charter > > >> > > >> > > >> > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote= : > > >>> > > >>> Hi Surendra, > > >>> > > >>> Classification may be out of scope, but the level of service=20 > > >>> that > > is > > >>> applicable is dependent upon the level of classification that=20 > > >>> can > > be > > >>> performed. An assumption of packet level encapsulation has > > >> implications > > >>> on the level of classification being performed? If the stated > > goals > > >> are > > >>> for firewall and load balancer functionality, then the=20 > > >>> application > > >> level > > >>> nature of those functions needs to be taken into account? If,=20 > > >>> on the other hand, the service function scope is limited due to=20 > > >>> limitations in classification, that would be and important piece=20 > > >>> of > > information? > > >>> > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork=20 > > >>> points of the service paths seem like re-classification points? =20 > > >>> Is that the interpretation from the architecture perspective? =20 > > >>> Or is the service function chain classification exclusive of DPI > > functionality? > > >> I have not fully read that draft yet. But in general, as=20 > > >> described in the arch draft, the collection of services form a=20 > > >> graph, segments of which are service paths. Yes, reclassification=20 > > >> can > > change > > >> the service path and re-classification may happen at any node=20 > > >> along > > a service path. > > >> > > >> Surendra. > > >>> > > >>> thanx. > > >>> > > >>> -- Kevin J. Ma > > >>> > > >>>> -----Original Message----- > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > >>>> nsc@ietf.org > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>> > > >>>> Kevin, > > >>>> > > >>>> Classification mechanism is outside the scope of SFC. It can be=20 > > >>>> based > > >> on > > >>>> the packet or information not in the packet(environmental=20 > > >>>> attributes > > >> for > > >>>> instance) or a combination thereof. What is important is that=20 > > >>>> such classification aids in traffic selection and service path=20 > > >>>> identification. > > >>>> It is no different from a policy in this regard except that the=20 > > >>>> policy now specifies the service path. > > >>>> Further, classification is not limited to the network elements=20 > > >>>> but the service functions as well. Some of this is described in=20 > > >>>> the > > >> architecture > > >>>> drafts as well - > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > >>>> > > >>>> Surendra. > > >>>> > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > > wrote: > > >>>>> > > >>>>> Hi Ron, > > >>>>> > > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI,=20 > > >>>>> but I had a similar question wrt bullet 11 in section 2 of the > > problem > > >>>>> statement: > > >>>>> > > >>>>> 11. Per-Service (re)Classification: Classification occurs=20 > > >>>>> at > > each > > >>>>> service, independent from previously applied service > > >>>> functions. > > >>>>> These unrelated classification events consume resources > > per > > >>>>> service. More importantly, the classification > > functionality > > >>>>> often differs per service function and service function > > >> cannot > > >>>>> leverage the results from other deployed network or > > service. > > >>>>> > > >>>>> as it relates to section 5.2 of the framework document: > > >>>>> > > >>>>> The SFC Classifier classifies packets based on (some of) the > > >>>> contents > > >>>>> of the packet header. Concretely, it classifies packets=20 > > >>>>> based on > > >>>> the > > >>>>> possible combination of one or more header fields, such as > > source > > >>>>> address, destination address, DS field, protocol ID, source > > port > > >>>> and > > >>>>> destination port numbers, and any other information. > > >>>>> > > >>>>> A packet-based classifier as described in the framework=20 > > >>>>> document > > >>>> would > > >>>>> seem to be limited in what it can classify? The service=20 > > >>>>> function identifier lookup does not seem to be a significant=20 > > >>>>> optimization > > >> over > > >>>>> a packet-based 5-tuple lookup? There seems to be some missing > > >> detail > > >>>>> wrt how classification information is determined and reused? > > >>>>> > > >>>>> When thinking about higher level services, e.g., HTTP and TLS > > >>>> encrypted > > >>>>> flows, a packet-based classifier seems inadequate? I was also > > >>>> wondering > > >>>>> how independent HLS segment requests might be classified and > > >>>> associated? > > >>>>> Were these types of use cases discussed in the BoF? > > >>>>> > > >>>>> thanx. > > >>>>> > > >>>>> -- Kevin J. Ma > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > >>>>>> Behalf > > >> Of > > >>>>>> Ron > > >>>>>> Parker > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> As was discussed in Vancouver, there are already many=20 > > >>>>>> existing ways > > >>>> to > > >>>>>> accomplish service chaining. But none of them provide a > > >>>> sufficient > > >>>>>> combination of interoperability, flexibility, and resiliency. > > A > > >>>> single > > >>>>>> service chain encapsulation will go a long way to ensuring=20 > > >>>>>> these > > >>>> goals. > > >>>>>> It may not be the absolutely most efficient approach for=20 > > >>>>>> every > > >>>> single > > >>>>>> network topology and every single use case, but its=20 > > >>>>>> ubiquitous > > >> nature > > >>>>>> should improve its adoption. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Ron, > > >>>>>> > > >>>>>> Absolutely, that was an example of one type of derivation. > > >>>>>> However > > >>>> this > > >>>>>> could be augmented with classification result, again one more > > >>>> example. > > >>>>>> > > >>>>>>>> All flows from the same source IP do not necessarily follow > > the > > >>>> same > > >>>>>> chain. > > >>>>>> Correct. It is also not necessary that all transaction of the=20 > > >>>>>> same > > >>>> flow > > >>>>>> follow the same chain either. So why stop at flow itself. > > >>>>>> > > >>>>>> Again the point here is that do we always need SFC header or Not= . > > >>>>>> > > >>>>>> Sumandra > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> The intention of service function chaining is to allow for=20 > > >>>>>> operation > > >>>> at > > >>>>>> the fully qualified flow level, or even finer grained at the > > >>>> transaction > > >>>>>> level (this is an implementation matter for the PDP). All > > flows > > >>>> from > > >>>>>> the same source IP do not necessarily follow the same chain. > > >> Source > > >>>>>> IP, > > >>>>>> therefore, does not identify the chain ID. Another intention > > of > > >>>>>> service function chaining is to operate over any network > > topology > > >> and > > >>>>>> not > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > > the > > >>>>>> transport, it does not adequately identify the service chain, > > >> either. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Ron, > > >>>>>> > > >>>>>> The service header is meant to carry the context which can > > *also* > > >>>>>> be derived (for example use source ip and vlan to identify=20 > > >>>>>> chainID and > > >>>>>> position) or encapsulated as part of another tunnel header.=20 > > >>>>>> So this could be optional IMHO. > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Sumandra, > > >>>>>> > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF=20 > > >>>>>> or from > > >>>> SF > > >>>>>> to > > >>>>>> SF will look like: > > >>>>>> > > >>>>>> +------------------------+ > > >>>>>> | "transport" | > > >>>>>> +------------------------+ > > >>>>>> | service header | > > >>>>>> +------------------------+ > > >>>>>> | original IP header | > > >>>>>> +------------------------+ > > >>>>>> | | original IP=20 > > >>>>>> | payload > > | > > >>>>>> | | > > >>>>>> +------------------------+ > > >>>>>> > > >>>>>> Where service header contains, at a minimum, enough=20 > > >>>>>> information to > > >>>> allow > > >>>>>> the packet to be propagated along the full length of the=20 > > >>>>>> chain, and optionally, other metadata that enhances the=20 > > >>>>>> operation of > > one > > >>>>>> or > > >> more > > >>>>>> service functions. > > >>>>>> > > >>>>>> And where "transport" could conceivably be any of, but not=20 > > >>>>>> limited > > >>>> to: > > >>>>>> > > >>>>>> * Ethernet > > >>>>>> * Ethernet + LLC2 > > >>>>>> * Ethernet + MPLS > > >>>>>> * Ethernet + IP + GRE > > >>>>>> * Ethernet + IP +UDP > > >>>>>> > > >>>>>> > > >>>>>> Also, "original" in the diagram above is not meant to imply=20 > > >>>>>> immutability, but rather to specify the packet that is > > propagated > > >>>>>> from preceding entity to succeeding entity, prior to=20 > > >>>>>> encapsulation. > > >>>>>> > > >>>>>> Ron > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > >>>>>> Behalf > > >> Of > > >>>>>> Sumandra Majee > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > >>>>>> To: Thomas Narten; nsc@ietf.org > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Generic Service Function Chaining Encapsulation: A document will > > >>>>>> describe the single service-level data plane encapsulation > > >> format > > >>>>>> for > > >>>>>> conveying the service function chain and the service=20 > > >>>>>> function > > >>>> path, > > >>>>>> and for communicating context information between nodes that > > >>>>>> implement service functions. It is intended that the > > >>>> encapsulation > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > >>>>>> service > > >>>> that > > >>>>>> is > > >>>>>> being constructed. That is, the same encapsulation may be > > used > > >> on > > >>>>>> a service function path realized at the network layer or=20 > > >>>>>> at any other > > >>>>>> layer, and the same encapsulation will apply for the > > >> construction > > >>>> of > > >>>>>> service function paths regardless of the actual service. > > >>>>>> > > >>>>>> [SM] What does it mean by a single service-level=20 > > >>>>>> encapsulation, > > a > > >>>> new > > >>>>>> encapsulation format > > >>>>>> or an ability to select one encapsulation format=20 > > >>>>>> that > > >>>> fits > > >>>>>> the > > >>>>>> need for a given service chain? > > >>>>>> The ability to select a specific encapsulation =20 > > >>>>>> would be > > >> a > > >>>>>> management plane decision. > > >>>>>> There are quite a few existing encapsulation methods=20 > > >>>>>> that > > >>>> can > > >>>>>> possibly be reused to provide > > >>>>>> context information between service nodes. I have > > seen > > >>>>>> mention > > >>>>>> of GRE, for HTTP based > > >>>>>> applications contexts are transferred via headers. > > >>>>>> > > >>>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > >>>>>> Behalf > > >> Of > > >>>>>> Thomas Narten > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > >>>>>> To: nsc@ietf.org > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > >>>>>> > > >>>>>> Hi. > > >>>>>> > > >>>>>> Current charter can be found at > > >>>>>> https://datatracker.ietf.org/doc/charter- > > >>>>>> ietf-sfc/. > > >>>>>> > > >>>>>> It contains the revised management text as well as updated > > >>>> milestones. > > >>>>>> > > >>>>>> All known issues have been addressed. If there are any=20 > > >>>>>> remaining > > >>>> issues, > > >>>>>> please speak up! > > >>>>>> > > >>>>>> Charter charter-ietf-sfc-00-04 > > >>>>>> > > >>>>>> Networks, servers, storage technologies, and applications,=20 > > >>>>>> have all undergone significant change in recent years with=20 > > >>>>>> the introduction > > >> of > > >>>>>> virtualization, network overlays, and orchestration. Service > > >> delivery > > >>>> is > > >>>>>> currently both a technical and organizational challenge that > > >> involves > > >>>>>> significant modification to the network configuration. > > >>>>>> Services are typically implemented by the ordered combination=20 > > >>>>>> of a number of service functions that are deployed at=20 > > >>>>>> different points within > > >> the > > >>>>>> network. Today, a common deployment model has service=20 > > >>>>>> functions physically inserted on the data forwarding path=20 > > >>>>>> between communicating peers. > > >>>> Going > > >>>>>> forward, however, there is a desire to move to a different=20 > > >>>>>> model, > > >>>> where > > >>>>>> service functions are not required to reside on the default=20 > > >>>>>> data > > >> path > > >>>>>> and > > >>>>>> traffic is instead steered through services, wherever they=20 > > >>>>>> are > > >>>> deployed. > > >>>>>> > > >>>>>> For a given service, the abstracted view of the required=20 > > >>>>>> service functions and the order in which they are to be=20 > > >>>>>> applied is > > called > > >>>>>> a Service Function Chain (SFC). Since a given service=20 > > >>>>>> function may be available on more than one node within a=20 > > >>>>>> network, a Service Function Chain is instantiated > > >>>> via > > >>>>>> the selection of specific service function instances and the=20 > > >>>>>> network nodes on which they are provided, thereby forming a=20 > > >>>>>> service topology: > > >>>>>> this is called a Service Function Path. The service functions > > may > > >>>>>> be applied at a specific layer within the network protocol=20 > > >>>>>> stack > > >>>> (network > > >>>>>> layer, application layer, etc.). > > >>>>>> > > >>>>>> The Service Function Chaining (SFC) working group will=20 > > >>>>>> develop new approaches to service delivery and deployment. It=20 > > >>>>>> will produce a framework for service function chaining that=20 > > >>>>>> includes the necessary protocols > > >>>> or > > >>>>>> protocol extensions to convey the service path and service=20 > > >>>>>> path information to nodes that implement service functions,=20 > > >>>>>> as well > > as > > >>>>>> mechanisms for steering traffic through service functions.=20 > > >>>>>> The > > >>>> working > > >>>>>> group will also examine what information needs to be gathered=20 > > >>>>>> from > > >>>> the > > >>>>>> network and service functions in support of service function > > >> chaining > > >>>>>> and > > >>>>>> how that information may be made available to nodes that=20 > > >>>>>> implement > > >>>> the > > >>>>>> service functions. > > >>>>>> > > >>>>>> Specifically, the SFC WG is chartered to deliver the following: > > >>>>>> > > >>>>>> 1) Problem Statement: This document will provide a summary of > > the > > >>>>>> problem space to be addressed by the WG including example > > high- > > >>>>>> level use cases. Additionally, the WG will normalize > > >> nomenclature > > >>>>>> and definitions for service function chaining. > > >>>>>> > > >>>>>> 2) Architecture: This document will provide a description of the > > >>>>>> architectural building blocks and their relationships > > including > > >>>>>> interconnection, placement of capabilities, management, > > >>>>>> diagnostics, design analysis, and security models, as well as > > >>>>>> requirements on the protocol mechanisms. > > >>>>>> > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 > > >>>>>> document > > will > > >>>>>> describe the single service-level data plane encapsulation > > >> format > > >>>>>> for > > >>>>>> conveying the service function chain and the service=20 > > >>>>>> function > > >>>> path, > > >>>>>> and for communicating context information between nodes that > > >>>>>> implement service functions. It is intended that the > > >>>> encapsulation > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > >>>>>> service > > >>>> that > > >>>>>> is > > >>>>>> being constructed. That is, the same encapsulation may be > > used > > >> on > > >>>>>> a service function path realized at the network layer or=20 > > >>>>>> at any other > > >>>>>> layer, and the same encapsulation will apply for the > > >> construction > > >>>> of > > >>>>>> service function paths regardless of the actual service. > > >>>>>> > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > developed to > > >>>>>> describe requirements and protocols necessary to convey > > >>>> information > > >>>>>> to service function implementation points. Where possible, > > >>>> existing > > >>>>>> IETF protocols will be used and extended. All protocol > > >> extensions > > >>>>>> work should be carried out in the working groups=20 > > >>>>>> responsible for > > >>>> the > > >>>>>> protocols being modified in coordination with this working > > >> group, > > >>>>>> but > > >>>>>> may be done in this working group after agreement with all > > the > > >>>>>> relevant WG chairs and responsible ADs. > > >>>>>> > > >>>>>> 5) Manageability: Work on the management and configuration of > > >> service > > >>>>>> functions in support of SFC components will certainly be > > needed, > > >>>>>> but first needs to be better understood and scoped. > > >>>>>> > > >>>>>> Proposed Milestones > > >>>>>> > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining=20 > > >>>>>> the > > >>>> problem > > >>>>>> statement and core use cases for Service Function Chaining > > >>>>>> > > >>>>>> May 2014 Consult with OPS Area on possible charter=20 > > >>>>>> modifications for management and configuration of SFC=20 > > >>>>>> components > > >>>>>> > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > >>>> architecture > > >>>>>> for SFC > > >>>>>> > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 > > >>>>>> function chaining encapsulation protocol > > >>>>>> > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying=20 > > >>>>>> the > > >>>> generic > > >>>>>> service function chaining header encapsulation > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Thomas > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>>> _______________________________________________ > > >>>>>> nsc mailing list > > >>>>>> nsc@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > >>>>> _______________________________________________ > > >>>>> nsc mailing list > > >>>>> nsc@ietf.org > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 12 08:03:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10FBE21E80A1 for ; Tue, 12 Nov 2013 08:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6t7KAyNU19S for ; Tue, 12 Nov 2013 08:03:43 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84321E80C5 for ; Tue, 12 Nov 2013 08:03:40 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 47E677AEE6A; Tue, 12 Nov 2013 11:03:39 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 57BBB7AED33; Tue, 12 Nov 2013 11:03:37 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Tue, 12 Nov 2013 11:02:38 -0500 From: Kevin J Ma To: Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Date: Tue, 12 Nov 2013 11:02:36 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMD//9vuAIAABCAAgACFyFCAAQoKAA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6B0280260A5@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:03:47 -0000 Hi Ron, In that case, it would seem to me that a lot of application layer flows would get thrown into the same bucket. I'm thinking about HTTP/1.1+TLS (or worse yet, HTTP/2.0). I am trying to figure out if these cases are really covered by SFC. The problem statement and the use cases seem to imply that they are, but the classification implies that they are not? Are they only included by virtue of low level packet-based classification= , and after that are only subject to "branching" points after demuxing, decryption, and DPI? That is what is unclear to me. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Tuesday, November 12, 2013 10:54 AM > To: Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee > Subject: RE: [nsc] Current Proposed SFC charter > > I think the lack of definition of "reclassification" may be causing some > misunderstandings here. A branch would occur for some policy-driven > reason based on the behavior and conclusions of the service function, > itself. The graph would represent the fact that there is a branch point= , > but the service function, itself, being aware that it is a branching poin= t > would contain the policy and logic to decide on which branch to take. > Specifying that policy and logic is out of scope, IMO. > > Ron > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, November 12, 2013 10:49 AM > To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Hi Linda, > > Are you saying that a branching point is "never" a reclassification > point, or are you saying that a branching point "does not have to be" > a reclassification point? > > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain > is different than I originally inferred. If the chain is a tree with > other "branching" points in it, then that limits the scope of the > problem statement goals. > > While this could be a degenerate case, and any implementation could > define bad service chains, is it the intent of SFC to only look at > the simpler packet-level classification cases, or is it the intent > to consider the case where a branching point is viewed as a > re-classification point? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Tuesday, November 12, 2013 10:34 AM > > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > Majee > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > First, want to make it clear that "branching" !=3D reclassification, > agree? > > > > Second, the representation of branching (or service graph) can be in a > > form of logic on a service function. Some service functions, > > especially L7 based, can use value in a Database to determine what is > > the next service function. > > > > Linda > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > > > Of Ron Parker > > > Sent: Tuesday, November 12, 2013 8:16 AM > > > To: Hongyu Li (Julio); Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hongyu, > > > > > > I agree completely that re-classification is not limited to DPI. > > > > > > And also, that an area for us to explore as a group is how to > represent > > > the service graph. Do we want to represent it as a proper graph wit= h > > > an adjacency list or other representational model? Or, do we want t= o > > > represent it as a set of linear segments and if so, how are the > > > segments connected into a graph? Other ideas? > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > > > Of Hongyu Li (Julio) > > > Sent: Tuesday, November 12, 2013 6:57 AM > > > To: Ron Parker; Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Branching/forking is a very interesting topic of SFC. About the re- > > > classification point, probably we shall not limit it to DPI. It is > > > also possible that packets go to different branches after been > > > processed by a certain service function, decision of which branches > > > to go is made based on the result of service function's process, > > > i.e. not just re- classification by DPI. > > > > > > Hongyu > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > > > Of Ron Parker > > > Sent: Tuesday, November 12, 2013 7:45 PM > > > To: Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hi, Kevin > > > > > > You ask a great question about branching the graph. The details > > > around how to convey the selection of the subtree/subgraph are still > to be > > > defined. Is it one chain id for the whole graph? Does each branch > > > have its own chain id? Some combination? > > > > > > Ron > > > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > > > > > > wrote: > > > > > > >> Yes, reclassification can change the service path and > > > >> re-classification may happen at any node along a service path. > > > > > > > > Just to expand on that, going back to the original question about > > > > service header encapsulation, is it intended that a chain that is > > > > re-classified will get a new chain ID which fully describes a > > > > chain that is a superset of the original chain ID, prior to > > > > DPI-based re-classification? (assuming the goal is "a single > > > > chain ID that is commonly understood along the entire service chain= " > > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > > > And the applicable subset of the permutative list of service paths > > > > would be configured at each appropriate service node? > > > > e.g., ID 1: NAT + firewall + DPI > > > > ID 2: NAT + firewall + DPI + AV > > > > ID 3: NAT + firewall + DPI + AV + NAT > > > > ID 4: NAT + firewall + DPI + NAT > > > > ID 5: NAT + firewall + DPI + AV + LB > > > > ID 6: NAT + firewall + DPI + LB > > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > > ID 8: NAT + firewall + DPI + CACHE > > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > > > > flow then be initially classified as ID 1, but eventually get re- > > > classified > > > > to ID 2-11, after the DPI phase? > > > > > > > > thanx. > > > > > > > > -- Kevin J. Ma > > > > > > > >> -----Original Message----- > > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > > >> nsc@ietf.org > > > >> Subject: Re: [nsc] Current Proposed SFC charter > > > >> > > > >> > > > >> > > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > wrote: > > > >>> > > > >>> Hi Surendra, > > > >>> > > > >>> Classification may be out of scope, but the level of service > > > >>> that > > > is > > > >>> applicable is dependent upon the level of classification that > > > >>> can > > > be > > > >>> performed. An assumption of packet level encapsulation has > > > >> implications > > > >>> on the level of classification being performed? If the stated > > > goals > > > >> are > > > >>> for firewall and load balancer functionality, then the > > > >>> application > > > >> level > > > >>> nature of those functions needs to be taken into account? If, > > > >>> on the other hand, the service function scope is limited due to > > > >>> limitations in classification, that would be and important piece > > > >>> of > > > information? > > > >>> > > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > > > >>> points of the service paths seem like re-classification points? > > > >>> Is that the interpretation from the architecture perspective? > > > >>> Or is the service function chain classification exclusive of DPI > > > functionality? > > > >> I have not fully read that draft yet. But in general, as > > > >> described in the arch draft, the collection of services form a > > > >> graph, segments of which are service paths. Yes, reclassification > > > >> can > > > change > > > >> the service path and re-classification may happen at any node > > > >> along > > > a service path. > > > >> > > > >> Surendra. > > > >>> > > > >>> thanx. > > > >>> > > > >>> -- Kevin J. Ma > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > > >>>> nsc@ietf.org > > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>> > > > >>>> Kevin, > > > >>>> > > > >>>> Classification mechanism is outside the scope of SFC. It can be > > > >>>> based > > > >> on > > > >>>> the packet or information not in the packet(environmental > > > >>>> attributes > > > >> for > > > >>>> instance) or a combination thereof. What is important is that > > > >>>> such classification aids in traffic selection and service path > > > >>>> identification. > > > >>>> It is no different from a policy in this regard except that the > > > >>>> policy now specifies the service path. > > > >>>> Further, classification is not limited to the network elements > > > >>>> but the service functions as well. Some of this is described in > > > >>>> the > > > >> architecture > > > >>>> drafts as well - > > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > > >>>> > > > >>>> Surendra. > > > >>>> > > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > > > wrote: > > > >>>>> > > > >>>>> Hi Ron, > > > >>>>> > > > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > > > >>>>> but I had a similar question wrt bullet 11 in section 2 of the > > > problem > > > >>>>> statement: > > > >>>>> > > > >>>>> 11. Per-Service (re)Classification: Classification occurs > > > >>>>> at > > > each > > > >>>>> service, independent from previously applied service > > > >>>> functions. > > > >>>>> These unrelated classification events consume resources > > > per > > > >>>>> service. More importantly, the classification > > > functionality > > > >>>>> often differs per service function and service function > > > >> cannot > > > >>>>> leverage the results from other deployed network or > > > service. > > > >>>>> > > > >>>>> as it relates to section 5.2 of the framework document: > > > >>>>> > > > >>>>> The SFC Classifier classifies packets based on (some of) the > > > >>>> contents > > > >>>>> of the packet header. Concretely, it classifies packets > > > >>>>> based on > > > >>>> the > > > >>>>> possible combination of one or more header fields, such as > > > source > > > >>>>> address, destination address, DS field, protocol ID, source > > > port > > > >>>> and > > > >>>>> destination port numbers, and any other information. > > > >>>>> > > > >>>>> A packet-based classifier as described in the framework > > > >>>>> document > > > >>>> would > > > >>>>> seem to be limited in what it can classify? The service > > > >>>>> function identifier lookup does not seem to be a significant > > > >>>>> optimization > > > >> over > > > >>>>> a packet-based 5-tuple lookup? There seems to be some missing > > > >> detail > > > >>>>> wrt how classification information is determined and reused? > > > >>>>> > > > >>>>> When thinking about higher level services, e.g., HTTP and TLS > > > >>>> encrypted > > > >>>>> flows, a packet-based classifier seems inadequate? I was also > > > >>>> wondering > > > >>>>> how independent HLS segment requests might be classified and > > > >>>> associated? > > > >>>>> Were these types of use cases discussed in the BoF? > > > >>>>> > > > >>>>> thanx. > > > >>>>> > > > >>>>> -- Kevin J. Ma > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Ron > > > >>>>>> Parker > > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As was discussed in Vancouver, there are already many > > > >>>>>> existing ways > > > >>>> to > > > >>>>>> accomplish service chaining. But none of them provide a > > > >>>> sufficient > > > >>>>>> combination of interoperability, flexibility, and resiliency. > > > A > > > >>>> single > > > >>>>>> service chain encapsulation will go a long way to ensuring > > > >>>>>> these > > > >>>> goals. > > > >>>>>> It may not be the absolutely most efficient approach for > > > >>>>>> every > > > >>>> single > > > >>>>>> network topology and every single use case, but its > > > >>>>>> ubiquitous > > > >> nature > > > >>>>>> should improve its adoption. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> Absolutely, that was an example of one type of derivation. > > > >>>>>> However > > > >>>> this > > > >>>>>> could be augmented with classification result, again one more > > > >>>> example. > > > >>>>>> > > > >>>>>>>> All flows from the same source IP do not necessarily follow > > > the > > > >>>> same > > > >>>>>> chain. > > > >>>>>> Correct. It is also not necessary that all transaction of the > > > >>>>>> same > > > >>>> flow > > > >>>>>> follow the same chain either. So why stop at flow itself. > > > >>>>>> > > > >>>>>> Again the point here is that do we always need SFC header or > Not. > > > >>>>>> > > > >>>>>> Sumandra > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> The intention of service function chaining is to allow for > > > >>>>>> operation > > > >>>> at > > > >>>>>> the fully qualified flow level, or even finer grained at the > > > >>>> transaction > > > >>>>>> level (this is an implementation matter for the PDP). All > > > flows > > > >>>> from > > > >>>>>> the same source IP do not necessarily follow the same chain. > > > >> Source > > > >>>>>> IP, > > > >>>>>> therefore, does not identify the chain ID. Another > intention > > > of > > > >>>>>> service function chaining is to operate over any network > > > topology > > > >> and > > > >>>>>> not > > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > > > the > > > >>>>>> transport, it does not adequately identify the service chain, > > > >> either. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> The service header is meant to carry the context which can > > > *also* > > > >>>>>> be derived (for example use source ip and vlan to identify > > > >>>>>> chainID and > > > >>>>>> position) or encapsulated as part of another tunnel header. > > > >>>>>> So this could be optional IMHO. > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF > > > >>>>>> or from > > > >>>> SF > > > >>>>>> to > > > >>>>>> SF will look like: > > > >>>>>> > > > >>>>>> +------------------------+ > > > >>>>>> | "transport" | > > > >>>>>> +------------------------+ > > > >>>>>> | service header | > > > >>>>>> +------------------------+ > > > >>>>>> | original IP header | > > > >>>>>> +------------------------+ > > > >>>>>> | | original IP > > > >>>>>> | payload > > > | > > > >>>>>> | | > > > >>>>>> +------------------------+ > > > >>>>>> > > > >>>>>> Where service header contains, at a minimum, enough > > > >>>>>> information to > > > >>>> allow > > > >>>>>> the packet to be propagated along the full length of the > > > >>>>>> chain, and optionally, other metadata that enhances the > > > >>>>>> operation of > > > one > > > >>>>>> or > > > >> more > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> And where "transport" could conceivably be any of, but not > > > >>>>>> limited > > > >>>> to: > > > >>>>>> > > > >>>>>> * Ethernet > > > >>>>>> * Ethernet + LLC2 > > > >>>>>> * Ethernet + MPLS > > > >>>>>> * Ethernet + IP + GRE > > > >>>>>> * Ethernet + IP +UDP > > > >>>>>> > > > >>>>>> > > > >>>>>> Also, "original" in the diagram above is not meant to imply > > > >>>>>> immutability, but rather to specify the packet that is > > > propagated > > > >>>>>> from preceding entity to succeeding entity, prior to > > > >>>>>> encapsulation. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Sumandra Majee > > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > > >>>>>> To: Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Generic Service Function Chaining Encapsulation: A document > will > > > >>>>>> describe the single service-level data plane encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > > > >>>>>> function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes tha= t > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > > > >>>>>> at any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> [SM] What does it mean by a single service-level > > > >>>>>> encapsulation, > > > a > > > >>>> new > > > >>>>>> encapsulation format > > > >>>>>> or an ability to select one encapsulation format > > > >>>>>> that > > > >>>> fits > > > >>>>>> the > > > >>>>>> need for a given service chain? > > > >>>>>> The ability to select a specific encapsulation > > > >>>>>> would be > > > >> a > > > >>>>>> management plane decision. > > > >>>>>> There are quite a few existing encapsulation methods > > > >>>>>> that > > > >>>> can > > > >>>>>> possibly be reused to provide > > > >>>>>> context information between service nodes. I have > > > seen > > > >>>>>> mention > > > >>>>>> of GRE, for HTTP based > > > >>>>>> applications contexts are transferred via headers. > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Thomas Narten > > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > > >>>>>> To: nsc@ietf.org > > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Hi. > > > >>>>>> > > > >>>>>> Current charter can be found at > > > >>>>>> https://datatracker.ietf.org/doc/charter- > > > >>>>>> ietf-sfc/. > > > >>>>>> > > > >>>>>> It contains the revised management text as well as updated > > > >>>> milestones. > > > >>>>>> > > > >>>>>> All known issues have been addressed. If there are any > > > >>>>>> remaining > > > >>>> issues, > > > >>>>>> please speak up! > > > >>>>>> > > > >>>>>> Charter charter-ietf-sfc-00-04 > > > >>>>>> > > > >>>>>> Networks, servers, storage technologies, and applications, > > > >>>>>> have all undergone significant change in recent years with > > > >>>>>> the introduction > > > >> of > > > >>>>>> virtualization, network overlays, and orchestration. Service > > > >> delivery > > > >>>> is > > > >>>>>> currently both a technical and organizational challenge that > > > >> involves > > > >>>>>> significant modification to the network configuration. > > > >>>>>> Services are typically implemented by the ordered combination > > > >>>>>> of a number of service functions that are deployed at > > > >>>>>> different points within > > > >> the > > > >>>>>> network. Today, a common deployment model has service > > > >>>>>> functions physically inserted on the data forwarding path > > > >>>>>> between communicating peers. > > > >>>> Going > > > >>>>>> forward, however, there is a desire to move to a different > > > >>>>>> model, > > > >>>> where > > > >>>>>> service functions are not required to reside on the default > > > >>>>>> data > > > >> path > > > >>>>>> and > > > >>>>>> traffic is instead steered through services, wherever they > > > >>>>>> are > > > >>>> deployed. > > > >>>>>> > > > >>>>>> For a given service, the abstracted view of the required > > > >>>>>> service functions and the order in which they are to be > > > >>>>>> applied is > > > called > > > >>>>>> a Service Function Chain (SFC). Since a given service > > > >>>>>> function may be available on more than one node within a > > > >>>>>> network, a Service Function Chain is instantiated > > > >>>> via > > > >>>>>> the selection of specific service function instances and the > > > >>>>>> network nodes on which they are provided, thereby forming a > > > >>>>>> service topology: > > > >>>>>> this is called a Service Function Path. The service functions > > > may > > > >>>>>> be applied at a specific layer within the network protocol > > > >>>>>> stack > > > >>>> (network > > > >>>>>> layer, application layer, etc.). > > > >>>>>> > > > >>>>>> The Service Function Chaining (SFC) working group will > > > >>>>>> develop new approaches to service delivery and deployment. It > > > >>>>>> will produce a framework for service function chaining that > > > >>>>>> includes the necessary protocols > > > >>>> or > > > >>>>>> protocol extensions to convey the service path and service > > > >>>>>> path information to nodes that implement service functions, > > > >>>>>> as well > > > as > > > >>>>>> mechanisms for steering traffic through service functions. > > > >>>>>> The > > > >>>> working > > > >>>>>> group will also examine what information needs to be gathered > > > >>>>>> from > > > >>>> the > > > >>>>>> network and service functions in support of service function > > > >> chaining > > > >>>>>> and > > > >>>>>> how that information may be made available to nodes that > > > >>>>>> implement > > > >>>> the > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> Specifically, the SFC WG is chartered to deliver the following= : > > > >>>>>> > > > >>>>>> 1) Problem Statement: This document will provide a summary of > > > the > > > >>>>>> problem space to be addressed by the WG including example > > > high- > > > >>>>>> level use cases. Additionally, the WG will normalize > > > >> nomenclature > > > >>>>>> and definitions for service function chaining. > > > >>>>>> > > > >>>>>> 2) Architecture: This document will provide a description of > the > > > >>>>>> architectural building blocks and their relationships > > > including > > > >>>>>> interconnection, placement of capabilities, management, > > > >>>>>> diagnostics, design analysis, and security models, as well > as > > > >>>>>> requirements on the protocol mechanisms. > > > >>>>>> > > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A > > > >>>>>> document > > > will > > > >>>>>> describe the single service-level data plane encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > > > >>>>>> function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes tha= t > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > > > >>>>>> at any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > > developed to > > > >>>>>> describe requirements and protocols necessary to convey > > > >>>> information > > > >>>>>> to service function implementation points. Where possible, > > > >>>> existing > > > >>>>>> IETF protocols will be used and extended. All protocol > > > >> extensions > > > >>>>>> work should be carried out in the working groups > > > >>>>>> responsible for > > > >>>> the > > > >>>>>> protocols being modified in coordination with this working > > > >> group, > > > >>>>>> but > > > >>>>>> may be done in this working group after agreement with all > > > the > > > >>>>>> relevant WG chairs and responsible ADs. > > > >>>>>> > > > >>>>>> 5) Manageability: Work on the management and configuration of > > > >> service > > > >>>>>> functions in support of SFC components will certainly be > > > needed, > > > >>>>>> but first needs to be better understood and scoped. > > > >>>>>> > > > >>>>>> Proposed Milestones > > > >>>>>> > > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining > > > >>>>>> the > > > >>>> problem > > > >>>>>> statement and core use cases for Service Function Chaining > > > >>>>>> > > > >>>>>> May 2014 Consult with OPS Area on possible charter > > > >>>>>> modifications for management and configuration of SFC > > > >>>>>> components > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > > >>>> architecture > > > >>>>>> for SFC > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > > > >>>>>> function chaining encapsulation protocol > > > >>>>>> > > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying > > > >>>>>> the > > > >>>> generic > > > >>>>>> service function chaining header encapsulation > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Thomas > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>> _______________________________________________ > > > >>>>> nsc mailing list > > > >>>>> nsc@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Tue Nov 12 08:04:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336F221E8255 for ; Tue, 12 Nov 2013 08:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mB7KwZMnCfUH for ; Tue, 12 Nov 2013 08:03:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 134B611E8190 for ; Tue, 12 Nov 2013 08:03:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE59556; Tue, 12 Nov 2013 16:03:55 +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, 12 Nov 2013 16:03:40 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 16:03:53 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 08:03:44 -0800 From: Linda Dunbar To: Kevin J Ma , Ron Parker , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN+0+4iz5RRxkOCS0vXxMG0/5ohQBeAgAAOHICAACcJgIAAAa2AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oD//46zEIAAAodQgAAEmtA= Date: Tue, 12 Nov 2013 16:03:44 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C055E6@dfweml509-mbx.china.huawei.com> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:04:02 -0000 I just want to point out that branching and reclassification are two separa= te functions. Yes, sometimes, those two functions can be collocated on same= device. But they don't have to be. IMHO, "re-classification" should be associated with assigning a different = Chain-ID or mega data to a flow, whereas, "branching" is about one service = function directing traffic to different service functions depending on some= conditions.=20 Linda =20 > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, November 12, 2013 9:49 AM > To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Hi Linda, >=20 > Are you saying that a branching point is "never" a reclassification > point, or are you saying that a branching point "does not have to be" > a reclassification point? >=20 > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain > is different than I originally inferred. =20 >If the chain is a tree with > other "branching" points in it, then that limits the scope of the > problem statement goals. >=20 > While this could be a degenerate case, and any implementation could > define bad service chains, is it the intent of SFC to only look at > the simpler packet-level classification cases, or is it the intent > to consider the case where a branching point is viewed as a > re-classification point? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Tuesday, November 12, 2013 10:34 AM > > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > First, want to make it clear that "branching" !=3D reclassification, > agree? > > > > Second, the representation of branching (or service graph) can be in > a > > form of logic on a service function. Some service functions, > especially L7 > > based, can use value in a Database to determine what is the next > service > > function. > > > > Linda > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Ron Parker > > > Sent: Tuesday, November 12, 2013 8:16 AM > > > To: Hongyu Li (Julio); Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hongyu, > > > > > > I agree completely that re-classification is not limited to DPI. > > > > > > And also, that an area for us to explore as a group is how to > represent > > > the service graph. Do we want to represent it as a proper graph > with > > > an adjacency list or other representational model? Or, do we want > to > > > represent it as a set of linear segments and if so, how are the > > > segments connected into a graph? Other ideas? > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Hongyu Li (Julio) > > > Sent: Tuesday, November 12, 2013 6:57 AM > > > To: Ron Parker; Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Branching/forking is a very interesting topic of SFC. About the re- > > > classification point, probably we shall not limit it to DPI. It is > also > > > possible that packets go to different branches after been processed > by > > > a certain service function, decision of which branches to go is > made > > > based on the result of service function's process, i.e. not just > re- > > > classification by DPI. > > > > > > Hongyu > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Ron Parker > > > Sent: Tuesday, November 12, 2013 7:45 PM > > > To: Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > > > Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hi, Kevin > > > > > > You ask a great question about branching the graph. The details > around > > > how to convey the selection of the subtree/subgraph are still to be > > > defined. Is it one chain id for the whole graph? Does each > branch > > > have its own chain id? Some combination? > > > > > > Ron > > > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > > > > wrote: > > > > > > >> Yes, reclassification can change the service path and > > > >> re-classification may happen at any node along a service path. > > > > > > > > Just to expand on that, going back to the original question about > > > > service header encapsulation, is it intended that a chain that is > > > > re-classified will get a new chain ID which fully describes a > chain > > > > that is a superset of the original chain ID, prior to DPI-based > > > > re-classification? (assuming the goal is "a single chain ID that > is > > > > commonly understood along the entire service chain" > > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > > > And the applicable subset of the permutative list of service > paths > > > > would be configured at each appropriate service node? > > > > e.g., ID 1: NAT + firewall + DPI > > > > ID 2: NAT + firewall + DPI + AV > > > > ID 3: NAT + firewall + DPI + AV + NAT > > > > ID 4: NAT + firewall + DPI + NAT > > > > ID 5: NAT + firewall + DPI + AV + LB > > > > ID 6: NAT + firewall + DPI + LB > > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > > ID 8: NAT + firewall + DPI + CACHE > > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > flow > > > > then be initially classified as ID 1, but eventually get re- > > > classified > > > > to ID 2-11, after the DPI phase? > > > > > > > > thanx. > > > > > > > > -- Kevin J. Ma > > > > > > > >> -----Original Message----- > > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > > >> nsc@ietf.org > > > >> Subject: Re: [nsc] Current Proposed SFC charter > > > >> > > > >> > > > >> > > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > wrote: > > > >>> > > > >>> Hi Surendra, > > > >>> > > > >>> Classification may be out of scope, but the level of service > that > > > is > > > >>> applicable is dependent upon the level of classification that > can > > > be > > > >>> performed. An assumption of packet level encapsulation has > > > >> implications > > > >>> on the level of classification being performed? If the stated > > > goals > > > >> are > > > >>> for firewall and load balancer functionality, then the > application > > > >> level > > > >>> nature of those functions needs to be taken into account? If, > on > > > >>> the other hand, the service function scope is limited due to > > > >>> limitations in classification, that would be and important > piece of > > > information? > > > >>> > > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the > fork > > > >>> points of the service paths seem like re-classification points? > Is > > > >>> that the interpretation from the architecture perspective? Or > is > > > >>> the service function chain classification exclusive of DPI > > > functionality? > > > >> I have not fully read that draft yet. But in general, as > > > >> described in the arch draft, the collection of services form a > graph, > > > >> segments of which are service paths. Yes, reclassification can > > > change > > > >> the service path and re-classification may happen at any node > along > > > a service path. > > > >> > > > >> Surendra. > > > >>> > > > >>> thanx. > > > >>> > > > >>> -- Kevin J. Ma > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > > > >>>> nsc@ietf.org > > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>> > > > >>>> Kevin, > > > >>>> > > > >>>> Classification mechanism is outside the scope of SFC. It can > be > > > >>>> based > > > >> on > > > >>>> the packet or information not in the packet(environmental > > > >>>> attributes > > > >> for > > > >>>> instance) or a combination thereof. What is important is that > such > > > >>>> classification aids in traffic selection and service path > > > >>>> identification. > > > >>>> It is no different from a policy in this regard except that > the > > > >>>> policy now specifies the service path. > > > >>>> Further, classification is not limited to the network elements > but > > > >>>> the service functions as well. Some of this is described in > the > > > >> architecture > > > >>>> drafts as well - > > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > > >>>> > > > >>>> Surendra. > > > >>>> > > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > > > wrote: > > > >>>>> > > > >>>>> Hi Ron, > > > >>>>> > > > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > but > > > >>>>> I had a similar question wrt bullet 11 in section 2 of the > > > problem > > > >>>>> statement: > > > >>>>> > > > >>>>> 11. Per-Service (re)Classification: Classification occurs > at > > > each > > > >>>>> service, independent from previously applied service > > > >>>> functions. > > > >>>>> These unrelated classification events consume > resources > > > per > > > >>>>> service. More importantly, the classification > > > functionality > > > >>>>> often differs per service function and service > function > > > >> cannot > > > >>>>> leverage the results from other deployed network or > > > service. > > > >>>>> > > > >>>>> as it relates to section 5.2 of the framework document: > > > >>>>> > > > >>>>> The SFC Classifier classifies packets based on (some of) > the > > > >>>> contents > > > >>>>> of the packet header. Concretely, it classifies packets > based > > > >>>>> on > > > >>>> the > > > >>>>> possible combination of one or more header fields, such as > > > source > > > >>>>> address, destination address, DS field, protocol ID, source > > > port > > > >>>> and > > > >>>>> destination port numbers, and any other information. > > > >>>>> > > > >>>>> A packet-based classifier as described in the framework > document > > > >>>> would > > > >>>>> seem to be limited in what it can classify? The service > function > > > >>>>> identifier lookup does not seem to be a significant > optimization > > > >> over > > > >>>>> a packet-based 5-tuple lookup? There seems to be some > missing > > > >> detail > > > >>>>> wrt how classification information is determined and reused? > > > >>>>> > > > >>>>> When thinking about higher level services, e.g., HTTP and TLS > > > >>>> encrypted > > > >>>>> flows, a packet-based classifier seems inadequate? I was > also > > > >>>> wondering > > > >>>>> how independent HLS segment requests might be classified and > > > >>>> associated? > > > >>>>> Were these types of use cases discussed in the BoF? > > > >>>>> > > > >>>>> thanx. > > > >>>>> > > > >>>>> -- Kevin J. Ma > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Ron > > > >>>>>> Parker > > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As was discussed in Vancouver, there are already many > existing > > > >>>>>> ways > > > >>>> to > > > >>>>>> accomplish service chaining. But none of them provide a > > > >>>> sufficient > > > >>>>>> combination of interoperability, flexibility, and resiliency. > > > A > > > >>>> single > > > >>>>>> service chain encapsulation will go a long way to ensuring > these > > > >>>> goals. > > > >>>>>> It may not be the absolutely most efficient approach for > every > > > >>>> single > > > >>>>>> network topology and every single use case, but its > ubiquitous > > > >> nature > > > >>>>>> should improve its adoption. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> Absolutely, that was an example of one type of derivation. > > > >>>>>> However > > > >>>> this > > > >>>>>> could be augmented with classification result, again one > more > > > >>>> example. > > > >>>>>> > > > >>>>>>>> All flows from the same source IP do not necessarily > follow > > > the > > > >>>> same > > > >>>>>> chain. > > > >>>>>> Correct. It is also not necessary that all transaction of > the > > > >>>>>> same > > > >>>> flow > > > >>>>>> follow the same chain either. So why stop at flow itself. > > > >>>>>> > > > >>>>>> Again the point here is that do we always need SFC header or > Not. > > > >>>>>> > > > >>>>>> Sumandra > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> The intention of service function chaining is to allow for > > > >>>>>> operation > > > >>>> at > > > >>>>>> the fully qualified flow level, or even finer grained at the > > > >>>> transaction > > > >>>>>> level (this is an implementation matter for the PDP). > All > > > flows > > > >>>> from > > > >>>>>> the same source IP do not necessarily follow the same chain. > > > >> Source > > > >>>>>> IP, > > > >>>>>> therefore, does not identify the chain ID. Another > intention > > > of > > > >>>>>> service function chaining is to operate over any network > > > topology > > > >> and > > > >>>>>> not > > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part > of > > > the > > > >>>>>> transport, it does not adequately identify the service chain, > > > >> either. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> The service header is meant to carry the context which can > > > *also* > > > >>>>>> be derived (for example use source ip and vlan to identify > > > >>>>>> chainID and > > > >>>>>> position) or encapsulated as part of another tunnel header. > So > > > >>>>>> this could be optional IMHO. > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF > or > > > >>>>>> from > > > >>>> SF > > > >>>>>> to > > > >>>>>> SF will look like: > > > >>>>>> > > > >>>>>> +------------------------+ > > > >>>>>> | "transport" | > > > >>>>>> +------------------------+ > > > >>>>>> | service header | > > > >>>>>> +------------------------+ > > > >>>>>> | original IP header | > > > >>>>>> +------------------------+ > > > >>>>>> | | original IP > payload > > > | > > > >>>>>> | | > > > >>>>>> +------------------------+ > > > >>>>>> > > > >>>>>> Where service header contains, at a minimum, enough > information > > > >>>>>> to > > > >>>> allow > > > >>>>>> the packet to be propagated along the full length of the > chain, > > > >>>>>> and optionally, other metadata that enhances the operation > of > > > one > > > >>>>>> or > > > >> more > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> And where "transport" could conceivably be any of, but not > > > >>>>>> limited > > > >>>> to: > > > >>>>>> > > > >>>>>> * Ethernet > > > >>>>>> * Ethernet + LLC2 > > > >>>>>> * Ethernet + MPLS > > > >>>>>> * Ethernet + IP + GRE > > > >>>>>> * Ethernet + IP +UDP > > > >>>>>> > > > >>>>>> > > > >>>>>> Also, "original" in the diagram above is not meant to imply > > > >>>>>> immutability, but rather to specify the packet that is > > > propagated > > > >>>>>> from preceding entity to succeeding entity, prior to > > > >>>>>> encapsulation. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Sumandra Majee > > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > > >>>>>> To: Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Generic Service Function Chaining Encapsulation: A document > will > > > >>>>>> describe the single service-level data plane > encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes > that > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > at > > > >>>>>> any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> [SM] What does it mean by a single service-level > encapsulation, > > > a > > > >>>> new > > > >>>>>> encapsulation format > > > >>>>>> or an ability to select one encapsulation format > that > > > >>>> fits > > > >>>>>> the > > > >>>>>> need for a given service chain? > > > >>>>>> The ability to select a specific encapsulation > would > > > >>>>>> be > > > >> a > > > >>>>>> management plane decision. > > > >>>>>> There are quite a few existing encapsulation > methods > > > >>>>>> that > > > >>>> can > > > >>>>>> possibly be reused to provide > > > >>>>>> context information between service nodes. I have > > > seen > > > >>>>>> mention > > > >>>>>> of GRE, for HTTP based > > > >>>>>> applications contexts are transferred via headers. > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Thomas Narten > > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > > >>>>>> To: nsc@ietf.org > > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Hi. > > > >>>>>> > > > >>>>>> Current charter can be found at > > > >>>>>> https://datatracker.ietf.org/doc/charter- > > > >>>>>> ietf-sfc/. > > > >>>>>> > > > >>>>>> It contains the revised management text as well as updated > > > >>>> milestones. > > > >>>>>> > > > >>>>>> All known issues have been addressed. If there are any > remaining > > > >>>> issues, > > > >>>>>> please speak up! > > > >>>>>> > > > >>>>>> Charter charter-ietf-sfc-00-04 > > > >>>>>> > > > >>>>>> Networks, servers, storage technologies, and applications, > have > > > >>>>>> all undergone significant change in recent years with the > > > >>>>>> introduction > > > >> of > > > >>>>>> virtualization, network overlays, and orchestration. Service > > > >> delivery > > > >>>> is > > > >>>>>> currently both a technical and organizational challenge that > > > >> involves > > > >>>>>> significant modification to the network configuration. > > > >>>>>> Services are typically implemented by the ordered > combination of > > > >>>>>> a number of service functions that are deployed at different > > > >>>>>> points within > > > >> the > > > >>>>>> network. Today, a common deployment model has service > functions > > > >>>>>> physically inserted on the data forwarding path between > > > >>>>>> communicating peers. > > > >>>> Going > > > >>>>>> forward, however, there is a desire to move to a different > model, > > > >>>> where > > > >>>>>> service functions are not required to reside on the default > data > > > >> path > > > >>>>>> and > > > >>>>>> traffic is instead steered through services, wherever they > are > > > >>>> deployed. > > > >>>>>> > > > >>>>>> For a given service, the abstracted view of the required > service > > > >>>>>> functions and the order in which they are to be applied is > > > called > > > >>>>>> a Service Function Chain (SFC). Since a given service > function > > > >>>>>> may be available on more than one node within a network, a > > > >>>>>> Service Function Chain is instantiated > > > >>>> via > > > >>>>>> the selection of specific service function instances and the > > > >>>>>> network nodes on which they are provided, thereby forming a > > > >>>>>> service topology: > > > >>>>>> this is called a Service Function Path. The service > functions > > > may > > > >>>>>> be applied at a specific layer within the network protocol > stack > > > >>>> (network > > > >>>>>> layer, application layer, etc.). > > > >>>>>> > > > >>>>>> The Service Function Chaining (SFC) working group will > develop > > > >>>>>> new approaches to service delivery and deployment. It will > > > >>>>>> produce a framework for service function chaining that > includes > > > >>>>>> the necessary protocols > > > >>>> or > > > >>>>>> protocol extensions to convey the service path and service > path > > > >>>>>> information to nodes that implement service functions, as > well > > > as > > > >>>>>> mechanisms for steering traffic through service functions. > The > > > >>>> working > > > >>>>>> group will also examine what information needs to be > gathered > > > >>>>>> from > > > >>>> the > > > >>>>>> network and service functions in support of service function > > > >> chaining > > > >>>>>> and > > > >>>>>> how that information may be made available to nodes that > > > >>>>>> implement > > > >>>> the > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> Specifically, the SFC WG is chartered to deliver the > following: > > > >>>>>> > > > >>>>>> 1) Problem Statement: This document will provide a summary > of > > > the > > > >>>>>> problem space to be addressed by the WG including example > > > high- > > > >>>>>> level use cases. Additionally, the WG will normalize > > > >> nomenclature > > > >>>>>> and definitions for service function chaining. > > > >>>>>> > > > >>>>>> 2) Architecture: This document will provide a description of > the > > > >>>>>> architectural building blocks and their relationships > > > including > > > >>>>>> interconnection, placement of capabilities, management, > > > >>>>>> diagnostics, design analysis, and security models, as > well as > > > >>>>>> requirements on the protocol mechanisms. > > > >>>>>> > > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A > document > > > will > > > >>>>>> describe the single service-level data plane > encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes > that > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > at > > > >>>>>> any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > > developed to > > > >>>>>> describe requirements and protocols necessary to convey > > > >>>> information > > > >>>>>> to service function implementation points. Where possible, > > > >>>> existing > > > >>>>>> IETF protocols will be used and extended. All protocol > > > >> extensions > > > >>>>>> work should be carried out in the working groups > responsible > > > >>>>>> for > > > >>>> the > > > >>>>>> protocols being modified in coordination with this > working > > > >> group, > > > >>>>>> but > > > >>>>>> may be done in this working group after agreement with > all > > > the > > > >>>>>> relevant WG chairs and responsible ADs. > > > >>>>>> > > > >>>>>> 5) Manageability: Work on the management and configuration > of > > > >> service > > > >>>>>> functions in support of SFC components will certainly be > > > needed, > > > >>>>>> but first needs to be better understood and scoped. > > > >>>>>> > > > >>>>>> Proposed Milestones > > > >>>>>> > > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining > the > > > >>>> problem > > > >>>>>> statement and core use cases for Service Function Chaining > > > >>>>>> > > > >>>>>> May 2014 Consult with OPS Area on possible charter > modifications > > > >>>>>> for management and configuration of SFC components > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > > >>>> architecture > > > >>>>>> for SFC > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > > > >>>>>> function chaining encapsulation protocol > > > >>>>>> > > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying > the > > > >>>> generic > > > >>>>>> service function chaining header encapsulation > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Thomas > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>> _______________________________________________ > > > >>>>> nsc mailing list > > > >>>>> nsc@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Tue Nov 12 08:22:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175A221E81E3 for ; Tue, 12 Nov 2013 08:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQQDZhGJBjf6 for ; Tue, 12 Nov 2013 08:22:08 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id A7E0D21E81D3 for ; Tue, 12 Nov 2013 08:22:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 08:22:08 -0800 From: Ron Parker To: Kevin J Ma , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMD//9vuAIAABCAAgACFyFCAAQoKAIACDtWw Date: Tue, 12 Nov 2013 16:22:07 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6B0280260A5@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B0280260A5@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:22:13 -0000 Hi, Kevin. There are no assumptions regarding the type and effectiveness of classifica= tion (stateful or otherwise). SFC allows for the creation of a graph of s= ervice functions but does not dictate what those service functions are and = how they operate. =20 Ron -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Tuesday, November 12, 2013 11:03 AM To: Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter Hi Ron, In that case, it would seem to me that a lot of application layer flows would get thrown into the same bucket. I'm thinking about HTTP/1.1+TLS (or worse yet, HTTP/2.0). I am trying to figure out if these cases are really covered by SFC. The problem statement and the use cases seem to imply that they are, but the classification implies that they are not? Are they only included by virtue of low level packet-based classification= , and after that are only subject to "branching" points after demuxing, decryption, and DPI? That is what is unclear to me. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Tuesday, November 12, 2013 10:54 AM > To: Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > Majee > Subject: RE: [nsc] Current Proposed SFC charter > > I think the lack of definition of "reclassification" may be causing some > misunderstandings here. A branch would occur for some policy-driven > reason based on the behavior and conclusions of the service function, > itself. The graph would represent the fact that there is a branch point= , > but the service function, itself, being aware that it is a branching=20 > point would contain the policy and logic to decide on which branch to tak= e. > Specifying that policy and logic is out of scope, IMO. > > Ron > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, November 12, 2013 10:49 AM > To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Hi Linda, > > Are you saying that a branching point is "never" a reclassification > point, or are you saying that a branching point "does not have to be" > a reclassification point? > > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain > is different than I originally inferred. If the chain is a tree with > other "branching" points in it, then that limits the scope of the > problem statement goals. > > While this could be a degenerate case, and any implementation could > define bad service chains, is it the intent of SFC to only look at > the simpler packet-level classification cases, or is it the intent > to consider the case where a branching point is viewed as a > re-classification point? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Tuesday, November 12, 2013 10:34 AM > > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > > Majee > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > First, want to make it clear that "branching" !=3D reclassification, > agree? > > > > Second, the representation of branching (or service graph) can be in=20 > > a form of logic on a service function. Some service functions,=20 > > especially L7 based, can use value in a Database to determine what=20 > > is the next service function. > > > > Linda > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > > Of Ron Parker > > > Sent: Tuesday, November 12, 2013 8:16 AM > > > To: Hongyu Li (Julio); Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hongyu, > > > > > > I agree completely that re-classification is not limited to DPI. > > > > > > And also, that an area for us to explore as a group is how to > represent > > > the service graph. Do we want to represent it as a proper graph wit= h > > > an adjacency list or other representational model? Or, do we want t= o > > > represent it as a set of linear segments and if so, how are the > > > segments connected into a graph? Other ideas? > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > > Of Hongyu Li (Julio) > > > Sent: Tuesday, November 12, 2013 6:57 AM > > > To: Ron Parker; Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Branching/forking is a very interesting topic of SFC. About the=20 > > > re- classification point, probably we shall not limit it to DPI.=20 > > > It is also possible that packets go to different branches after=20 > > > been processed by a certain service function, decision of which=20 > > > branches to go is made based on the result of service function's=20 > > > process, i.e. not just re- classification by DPI. > > > > > > Hongyu > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 > > > Of Ron Parker > > > Sent: Tuesday, November 12, 2013 7:45 PM > > > To: Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hi, Kevin > > > > > > You ask a great question about branching the graph. The details=20 > > > around how to convey the selection of the subtree/subgraph are=20 > > > still > to be > > > defined. Is it one chain id for the whole graph? Does each branch > > > have its own chain id? Some combination? > > > > > > Ron > > > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > > > > > > wrote: > > > > > > >> Yes, reclassification can change the service path and=20 > > > >> re-classification may happen at any node along a service path. > > > > > > > > Just to expand on that, going back to the original question=20 > > > > about service header encapsulation, is it intended that a chain=20 > > > > that is re-classified will get a new chain ID which fully=20 > > > > describes a chain that is a superset of the original chain ID,=20 > > > > prior to DPI-based re-classification? (assuming the goal is "a=20 > > > > single chain ID that is commonly understood along the entire servic= e chain" > > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > > > And the applicable subset of the permutative list of service=20 > > > > paths would be configured at each appropriate service node? > > > > e.g., ID 1: NAT + firewall + DPI > > > > ID 2: NAT + firewall + DPI + AV > > > > ID 3: NAT + firewall + DPI + AV + NAT > > > > ID 4: NAT + firewall + DPI + NAT > > > > ID 5: NAT + firewall + DPI + AV + LB > > > > ID 6: NAT + firewall + DPI + LB > > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > > ID 8: NAT + firewall + DPI + CACHE > > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every=20 > > > > flow then be initially classified as ID 1, but eventually get=20 > > > > re- > > > classified > > > > to ID 2-11, after the DPI phase? > > > > > > > > thanx. > > > > > > > > -- Kevin J. Ma > > > > > > > >> -----Original Message----- > > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > > >> nsc@ietf.org > > > >> Subject: Re: [nsc] Current Proposed SFC charter > > > >> > > > >> > > > >> > > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > wrote: > > > >>> > > > >>> Hi Surendra, > > > >>> > > > >>> Classification may be out of scope, but the level of service=20 > > > >>> that > > > is > > > >>> applicable is dependent upon the level of classification that=20 > > > >>> can > > > be > > > >>> performed. An assumption of packet level encapsulation has > > > >> implications > > > >>> on the level of classification being performed? If the stated > > > goals > > > >> are > > > >>> for firewall and load balancer functionality, then the=20 > > > >>> application > > > >> level > > > >>> nature of those functions needs to be taken into account? If,=20 > > > >>> on the other hand, the service function scope is limited due=20 > > > >>> to limitations in classification, that would be and important=20 > > > >>> piece of > > > information? > > > >>> > > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 > > > >>> fork points of the service paths seem like re-classification poin= ts? > > > >>> Is that the interpretation from the architecture perspective? > > > >>> Or is the service function chain classification exclusive of=20 > > > >>> DPI > > > functionality? > > > >> I have not fully read that draft yet. But in general, as=20 > > > >> described in the arch draft, the collection of services form a=20 > > > >> graph, segments of which are service paths. Yes,=20 > > > >> reclassification can > > > change > > > >> the service path and re-classification may happen at any node=20 > > > >> along > > > a service path. > > > >> > > > >> Surendra. > > > >>> > > > >>> thanx. > > > >>> > > > >>> -- Kevin J. Ma > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > > >>>> nsc@ietf.org > > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>> > > > >>>> Kevin, > > > >>>> > > > >>>> Classification mechanism is outside the scope of SFC. It can=20 > > > >>>> be based > > > >> on > > > >>>> the packet or information not in the packet(environmental=20 > > > >>>> attributes > > > >> for > > > >>>> instance) or a combination thereof. What is important is that=20 > > > >>>> such classification aids in traffic selection and service=20 > > > >>>> path identification. > > > >>>> It is no different from a policy in this regard except that=20 > > > >>>> the policy now specifies the service path. > > > >>>> Further, classification is not limited to the network=20 > > > >>>> elements but the service functions as well. Some of this is=20 > > > >>>> described in the > > > >> architecture > > > >>>> drafts as well - > > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > > >>>> > > > >>>> Surendra. > > > >>>> > > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma"=20 > > > >>>>> > > > wrote: > > > >>>>> > > > >>>>> Hi Ron, > > > >>>>> > > > >>>>> I was unable to make the SFC BoF due to a conflict with=20 > > > >>>>> CDNI, but I had a similar question wrt bullet 11 in section=20 > > > >>>>> 2 of the > > > problem > > > >>>>> statement: > > > >>>>> > > > >>>>> 11. Per-Service (re)Classification: Classification occurs=20 > > > >>>>> at > > > each > > > >>>>> service, independent from previously applied service > > > >>>> functions. > > > >>>>> These unrelated classification events consume=20 > > > >>>>> resources > > > per > > > >>>>> service. More importantly, the classification > > > functionality > > > >>>>> often differs per service function and service=20 > > > >>>>> function > > > >> cannot > > > >>>>> leverage the results from other deployed network or > > > service. > > > >>>>> > > > >>>>> as it relates to section 5.2 of the framework document: > > > >>>>> > > > >>>>> The SFC Classifier classifies packets based on (some of)=20 > > > >>>>> the > > > >>>> contents > > > >>>>> of the packet header. Concretely, it classifies packets=20 > > > >>>>> based on > > > >>>> the > > > >>>>> possible combination of one or more header fields, such as > > > source > > > >>>>> address, destination address, DS field, protocol ID,=20 > > > >>>>> source > > > port > > > >>>> and > > > >>>>> destination port numbers, and any other information. > > > >>>>> > > > >>>>> A packet-based classifier as described in the framework=20 > > > >>>>> document > > > >>>> would > > > >>>>> seem to be limited in what it can classify? The service=20 > > > >>>>> function identifier lookup does not seem to be a significant=20 > > > >>>>> optimization > > > >> over > > > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 > > > >>>>> missing > > > >> detail > > > >>>>> wrt how classification information is determined and reused? > > > >>>>> > > > >>>>> When thinking about higher level services, e.g., HTTP and=20 > > > >>>>> TLS > > > >>>> encrypted > > > >>>>> flows, a packet-based classifier seems inadequate? I was=20 > > > >>>>> also > > > >>>> wondering > > > >>>>> how independent HLS segment requests might be classified and > > > >>>> associated? > > > >>>>> Were these types of use cases discussed in the BoF? > > > >>>>> > > > >>>>> thanx. > > > >>>>> > > > >>>>> -- Kevin J. Ma > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Ron > > > >>>>>> Parker > > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As was discussed in Vancouver, there are already many=20 > > > >>>>>> existing ways > > > >>>> to > > > >>>>>> accomplish service chaining. But none of them provide a > > > >>>> sufficient > > > >>>>>> combination of interoperability, flexibility, and resiliency. > > > A > > > >>>> single > > > >>>>>> service chain encapsulation will go a long way to ensuring=20 > > > >>>>>> these > > > >>>> goals. > > > >>>>>> It may not be the absolutely most efficient approach for=20 > > > >>>>>> every > > > >>>> single > > > >>>>>> network topology and every single use case, but its=20 > > > >>>>>> ubiquitous > > > >> nature > > > >>>>>> should improve its adoption. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> Absolutely, that was an example of one type of derivation. > > > >>>>>> However > > > >>>> this > > > >>>>>> could be augmented with classification result, again one=20 > > > >>>>>> more > > > >>>> example. > > > >>>>>> > > > >>>>>>>> All flows from the same source IP do not necessarily=20 > > > >>>>>>>> follow > > > the > > > >>>> same > > > >>>>>> chain. > > > >>>>>> Correct. It is also not necessary that all transaction of=20 > > > >>>>>> the same > > > >>>> flow > > > >>>>>> follow the same chain either. So why stop at flow itself. > > > >>>>>> > > > >>>>>> Again the point here is that do we always need SFC header=20 > > > >>>>>> or > Not. > > > >>>>>> > > > >>>>>> Sumandra > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> The intention of service function chaining is to allow for=20 > > > >>>>>> operation > > > >>>> at > > > >>>>>> the fully qualified flow level, or even finer grained at=20 > > > >>>>>> the > > > >>>> transaction > > > >>>>>> level (this is an implementation matter for the PDP). All > > > flows > > > >>>> from > > > >>>>>> the same source IP do not necessarily follow the same chain. > > > >> Source > > > >>>>>> IP, > > > >>>>>> therefore, does not identify the chain ID. Another > intention > > > of > > > >>>>>> service function chaining is to operate over any network > > > topology > > > >> and > > > >>>>>> not > > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > > > the > > > >>>>>> transport, it does not adequately identify the service=20 > > > >>>>>> chain, > > > >> either. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> The service header is meant to carry the context which can > > > *also* > > > >>>>>> be derived (for example use source ip and vlan to identify=20 > > > >>>>>> chainID and > > > >>>>>> position) or encapsulated as part of another tunnel header. > > > >>>>>> So this could be optional IMHO. > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF=20 > > > >>>>>> or from > > > >>>> SF > > > >>>>>> to > > > >>>>>> SF will look like: > > > >>>>>> > > > >>>>>> +------------------------+ > > > >>>>>> | "transport" | > > > >>>>>> +------------------------+ > > > >>>>>> | service header | > > > >>>>>> +------------------------+ > > > >>>>>> | original IP header | > > > >>>>>> +------------------------+ > > > >>>>>> | | original IP=20 > > > >>>>>> | payload > > > | > > > >>>>>> | | > > > >>>>>> +------------------------+ > > > >>>>>> > > > >>>>>> Where service header contains, at a minimum, enough=20 > > > >>>>>> information to > > > >>>> allow > > > >>>>>> the packet to be propagated along the full length of the=20 > > > >>>>>> chain, and optionally, other metadata that enhances the=20 > > > >>>>>> operation of > > > one > > > >>>>>> or > > > >> more > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> And where "transport" could conceivably be any of, but not=20 > > > >>>>>> limited > > > >>>> to: > > > >>>>>> > > > >>>>>> * Ethernet > > > >>>>>> * Ethernet + LLC2 > > > >>>>>> * Ethernet + MPLS > > > >>>>>> * Ethernet + IP + GRE > > > >>>>>> * Ethernet + IP +UDP > > > >>>>>> > > > >>>>>> > > > >>>>>> Also, "original" in the diagram above is not meant to imply=20 > > > >>>>>> immutability, but rather to specify the packet that is > > > propagated > > > >>>>>> from preceding entity to succeeding entity, prior to=20 > > > >>>>>> encapsulation. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Sumandra Majee > > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > > >>>>>> To: Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Generic Service Function Chaining Encapsulation: A document > will > > > >>>>>> describe the single service-level data plane=20 > > > >>>>>> encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service=20 > > > >>>>>> function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes tha= t > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may=20 > > > >>>>>> be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or=20 > > > >>>>>> at any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> [SM] What does it mean by a single service-level=20 > > > >>>>>> encapsulation, > > > a > > > >>>> new > > > >>>>>> encapsulation format > > > >>>>>> or an ability to select one encapsulation format=20 > > > >>>>>> that > > > >>>> fits > > > >>>>>> the > > > >>>>>> need for a given service chain? > > > >>>>>> The ability to select a specific encapsulation=20 > > > >>>>>> would be > > > >> a > > > >>>>>> management plane decision. > > > >>>>>> There are quite a few existing encapsulation=20 > > > >>>>>> methods that > > > >>>> can > > > >>>>>> possibly be reused to provide > > > >>>>>> context information between service nodes. I have > > > seen > > > >>>>>> mention > > > >>>>>> of GRE, for HTTP based > > > >>>>>> applications contexts are transferred via headers. > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Thomas Narten > > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > > >>>>>> To: nsc@ietf.org > > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Hi. > > > >>>>>> > > > >>>>>> Current charter can be found at > > > >>>>>> https://datatracker.ietf.org/doc/charter- > > > >>>>>> ietf-sfc/. > > > >>>>>> > > > >>>>>> It contains the revised management text as well as updated > > > >>>> milestones. > > > >>>>>> > > > >>>>>> All known issues have been addressed. If there are any=20 > > > >>>>>> remaining > > > >>>> issues, > > > >>>>>> please speak up! > > > >>>>>> > > > >>>>>> Charter charter-ietf-sfc-00-04 > > > >>>>>> > > > >>>>>> Networks, servers, storage technologies, and applications,=20 > > > >>>>>> have all undergone significant change in recent years with=20 > > > >>>>>> the introduction > > > >> of > > > >>>>>> virtualization, network overlays, and orchestration.=20 > > > >>>>>> Service > > > >> delivery > > > >>>> is > > > >>>>>> currently both a technical and organizational challenge=20 > > > >>>>>> that > > > >> involves > > > >>>>>> significant modification to the network configuration. > > > >>>>>> Services are typically implemented by the ordered=20 > > > >>>>>> combination of a number of service functions that are=20 > > > >>>>>> deployed at different points within > > > >> the > > > >>>>>> network. Today, a common deployment model has service=20 > > > >>>>>> functions physically inserted on the data forwarding path=20 > > > >>>>>> between communicating peers. > > > >>>> Going > > > >>>>>> forward, however, there is a desire to move to a different=20 > > > >>>>>> model, > > > >>>> where > > > >>>>>> service functions are not required to reside on the default=20 > > > >>>>>> data > > > >> path > > > >>>>>> and > > > >>>>>> traffic is instead steered through services, wherever they=20 > > > >>>>>> are > > > >>>> deployed. > > > >>>>>> > > > >>>>>> For a given service, the abstracted view of the required=20 > > > >>>>>> service functions and the order in which they are to be=20 > > > >>>>>> applied is > > > called > > > >>>>>> a Service Function Chain (SFC). Since a given service=20 > > > >>>>>> function may be available on more than one node within a=20 > > > >>>>>> network, a Service Function Chain is instantiated > > > >>>> via > > > >>>>>> the selection of specific service function instances and=20 > > > >>>>>> the network nodes on which they are provided, thereby=20 > > > >>>>>> forming a service topology: > > > >>>>>> this is called a Service Function Path. The service=20 > > > >>>>>> functions > > > may > > > >>>>>> be applied at a specific layer within the network protocol=20 > > > >>>>>> stack > > > >>>> (network > > > >>>>>> layer, application layer, etc.). > > > >>>>>> > > > >>>>>> The Service Function Chaining (SFC) working group will=20 > > > >>>>>> develop new approaches to service delivery and deployment.=20 > > > >>>>>> It will produce a framework for service function chaining=20 > > > >>>>>> that includes the necessary protocols > > > >>>> or > > > >>>>>> protocol extensions to convey the service path and service=20 > > > >>>>>> path information to nodes that implement service functions,=20 > > > >>>>>> as well > > > as > > > >>>>>> mechanisms for steering traffic through service functions. > > > >>>>>> The > > > >>>> working > > > >>>>>> group will also examine what information needs to be=20 > > > >>>>>> gathered from > > > >>>> the > > > >>>>>> network and service functions in support of service=20 > > > >>>>>> function > > > >> chaining > > > >>>>>> and > > > >>>>>> how that information may be made available to nodes that=20 > > > >>>>>> implement > > > >>>> the > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> Specifically, the SFC WG is chartered to deliver the following= : > > > >>>>>> > > > >>>>>> 1) Problem Statement: This document will provide a summary=20 > > > >>>>>> of > > > the > > > >>>>>> problem space to be addressed by the WG including=20 > > > >>>>>> example > > > high- > > > >>>>>> level use cases. Additionally, the WG will normalize > > > >> nomenclature > > > >>>>>> and definitions for service function chaining. > > > >>>>>> > > > >>>>>> 2) Architecture: This document will provide a description=20 > > > >>>>>> of > the > > > >>>>>> architectural building blocks and their relationships > > > including > > > >>>>>> interconnection, placement of capabilities, management, > > > >>>>>> diagnostics, design analysis, and security models, as=20 > > > >>>>>> well > as > > > >>>>>> requirements on the protocol mechanisms. > > > >>>>>> > > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 > > > >>>>>> document > > > will > > > >>>>>> describe the single service-level data plane=20 > > > >>>>>> encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service=20 > > > >>>>>> function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes tha= t > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may=20 > > > >>>>>> be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or=20 > > > >>>>>> at any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > > developed to > > > >>>>>> describe requirements and protocols necessary to convey > > > >>>> information > > > >>>>>> to service function implementation points. Where=20 > > > >>>>>> possible, > > > >>>> existing > > > >>>>>> IETF protocols will be used and extended. All protocol > > > >> extensions > > > >>>>>> work should be carried out in the working groups=20 > > > >>>>>> responsible for > > > >>>> the > > > >>>>>> protocols being modified in coordination with this=20 > > > >>>>>> working > > > >> group, > > > >>>>>> but > > > >>>>>> may be done in this working group after agreement with=20 > > > >>>>>> all > > > the > > > >>>>>> relevant WG chairs and responsible ADs. > > > >>>>>> > > > >>>>>> 5) Manageability: Work on the management and configuration=20 > > > >>>>>> of > > > >> service > > > >>>>>> functions in support of SFC components will certainly be > > > needed, > > > >>>>>> but first needs to be better understood and scoped. > > > >>>>>> > > > >>>>>> Proposed Milestones > > > >>>>>> > > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining=20 > > > >>>>>> the > > > >>>> problem > > > >>>>>> statement and core use cases for Service Function Chaining > > > >>>>>> > > > >>>>>> May 2014 Consult with OPS Area on possible charter=20 > > > >>>>>> modifications for management and configuration of SFC=20 > > > >>>>>> components > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > > >>>> architecture > > > >>>>>> for SFC > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 > > > >>>>>> function chaining encapsulation protocol > > > >>>>>> > > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying=20 > > > >>>>>> the > > > >>>> generic > > > >>>>>> service function chaining header encapsulation > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Thomas > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>> _______________________________________________ > > > >>>>> nsc mailing list > > > >>>>> nsc@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Tue Nov 12 08:29:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF9F11E8171 for ; Tue, 12 Nov 2013 08:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFuBWACK7cH4 for ; Tue, 12 Nov 2013 08:28:53 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAA621E8219 for ; Tue, 12 Nov 2013 08:28:53 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 08:28:52 -0800 From: Ron Parker To: Linda Dunbar , Kevin J Ma , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoD//8uHuoAAiY6AgABgpMD//9vuAIAABCAAgAAEPQCAAIDpcA== Date: Tue, 12 Nov 2013 16:28:51 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-mbx.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C6B02802607A@MAILR002.mail.lan> <4A95BA014132FF49AE685FAB4B9F17F645C055E6@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C055E6@dfweml509-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 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:29:05 -0000 Linda, In general, I agree that the service function and reclassification are dist= inct. I could conceive of a chain that has a service function F1 followed= by a classifier C that branches to service functions F2 and F3. Let's as= sume that C is placed in the chain because F1 will come to some useful conc= lusion regarding the flow or transaction. In this case, metadata would n= eed to be transferred from F1 to C in the SFC service header. Also, that = metadata would have to be standardized in some way that F1 and C agree (i.= e., defined by SFC). There are possibly some common use cases that lend = themselves to this type of approach. If, on the other hand, F1 and C are integrated, then the metadata handoff i= s private and need not be specified by SFC. This approach allows for fast= er innovation by service function developers since there is no need to stan= dardize the metadata (or perhaps we revert to vendor-specific metadata whic= h has its own set of problems). I think both scenarios are valid. Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Linda= Dunbar Sent: Tuesday, November 12, 2013 11:04 AM To: Kevin J Ma; Ron Parker; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter I just want to point out that branching and reclassification are two separa= te functions. Yes, sometimes, those two functions can be collocated on same= device. But they don't have to be. IMHO, "re-classification" should be associated with assigning a different = Chain-ID or mega data to a flow, whereas, "branching" is about one service = function directing traffic to different service functions depending on some= conditions.=20 Linda =20 > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, November 12, 2013 9:49 AM > To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > Majee > Subject: RE: [nsc] Current Proposed SFC charter >=20 > Hi Linda, >=20 > Are you saying that a branching point is "never" a reclassification > point, or are you saying that a branching point "does not have to be" > a reclassification point? >=20 > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain > is different than I originally inferred. =20 >If the chain is a tree with > other "branching" points in it, then that limits the scope of the > problem statement goals. >=20 > While this could be a degenerate case, and any implementation could > define bad service chains, is it the intent of SFC to only look at > the simpler packet-level classification cases, or is it the intent > to consider the case where a branching point is viewed as a > re-classification point? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > > Sent: Tuesday, November 12, 2013 10:34 AM > > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > Majee > > Subject: RE: [nsc] Current Proposed SFC charter > > > > Ron, > > > > First, want to make it clear that "branching" !=3D reclassification, > agree? > > > > Second, the representation of branching (or service graph) can be in > a > > form of logic on a service function. Some service functions, > especially L7 > > based, can use value in a Database to determine what is the next > service > > function. > > > > Linda > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Ron Parker > > > Sent: Tuesday, November 12, 2013 8:16 AM > > > To: Hongyu Li (Julio); Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hongyu, > > > > > > I agree completely that re-classification is not limited to DPI. > > > > > > And also, that an area for us to explore as a group is how to > represent > > > the service graph. Do we want to represent it as a proper graph > with > > > an adjacency list or other representational model? Or, do we want > to > > > represent it as a set of linear segments and if so, how are the > > > segments connected into a graph? Other ideas? > > > > > > Ron > > > > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Hongyu Li (Julio) > > > Sent: Tuesday, November 12, 2013 6:57 AM > > > To: Ron Parker; Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Branching/forking is a very interesting topic of SFC. About the=20 > > > re- classification point, probably we shall not limit it to DPI.=20 > > > It is > also > > > possible that packets go to different branches after been=20 > > > processed > by > > > a certain service function, decision of which branches to go is > made > > > based on the result of service function's process, i.e. not just > re- > > > classification by DPI. > > > > > > Hongyu > > > > > > -----Original Message----- > > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > > > Ron Parker > > > Sent: Tuesday, November 12, 2013 7:45 PM > > > To: Kevin J Ma > > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > > > Sumandra Majee > > > Subject: Re: [nsc] Current Proposed SFC charter > > > > > > Hi, Kevin > > > > > > You ask a great question about branching the graph. The details > around > > > how to convey the selection of the subtree/subgraph are still to be > > > defined. Is it one chain id for the whole graph? Does each > branch > > > have its own chain id? Some combination? > > > > > > Ron > > > > > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > > > > wrote: > > > > > > >> Yes, reclassification can change the service path and=20 > > > >> re-classification may happen at any node along a service path. > > > > > > > > Just to expand on that, going back to the original question=20 > > > > about service header encapsulation, is it intended that a chain=20 > > > > that is re-classified will get a new chain ID which fully=20 > > > > describes a > chain > > > > that is a superset of the original chain ID, prior to DPI-based=20 > > > > re-classification? (assuming the goal is "a single chain ID=20 > > > > that > is > > > > commonly understood along the entire service chain" > > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > > > > > > And the applicable subset of the permutative list of service > paths > > > > would be configured at each appropriate service node? > > > > e.g., ID 1: NAT + firewall + DPI > > > > ID 2: NAT + firewall + DPI + AV > > > > ID 3: NAT + firewall + DPI + AV + NAT > > > > ID 4: NAT + firewall + DPI + NAT > > > > ID 5: NAT + firewall + DPI + AV + LB > > > > ID 6: NAT + firewall + DPI + LB > > > > ID 7: NAT + firewall + DPI + LB + CACHE > > > > ID 8: NAT + firewall + DPI + CACHE > > > > ID 9: NAT + firewall + DPI + optimizer + LB > > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > flow > > > > then be initially classified as ID 1, but eventually get re- > > > classified > > > > to ID 2-11, after the DPI phase? > > > > > > > > thanx. > > > > > > > > -- Kevin J. Ma > > > > > > > >> -----Original Message----- > > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >> Sent: Tuesday, November 12, 2013 1:01 AM > > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > > >> nsc@ietf.org > > > >> Subject: Re: [nsc] Current Proposed SFC charter > > > >> > > > >> > > > >> > > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > wrote: > > > >>> > > > >>> Hi Surendra, > > > >>> > > > >>> Classification may be out of scope, but the level of service > that > > > is > > > >>> applicable is dependent upon the level of classification that > can > > > be > > > >>> performed. An assumption of packet level encapsulation has > > > >> implications > > > >>> on the level of classification being performed? If the stated > > > goals > > > >> are > > > >>> for firewall and load balancer functionality, then the > application > > > >> level > > > >>> nature of those functions needs to be taken into account? If, > on > > > >>> the other hand, the service function scope is limited due to=20 > > > >>> limitations in classification, that would be and important > piece of > > > information? > > > >>> > > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the > fork > > > >>> points of the service paths seem like re-classification points? > Is > > > >>> that the interpretation from the architecture perspective? Or > is > > > >>> the service function chain classification exclusive of DPI > > > functionality? > > > >> I have not fully read that draft yet. But in general, as=20 > > > >> described in the arch draft, the collection of services form a > graph, > > > >> segments of which are service paths. Yes, reclassification can > > > change > > > >> the service path and re-classification may happen at any node > along > > > a service path. > > > >> > > > >> Surendra. > > > >>> > > > >>> thanx. > > > >>> > > > >>> -- Kevin J. Ma > > > >>> > > > >>>> -----Original Message----- > > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > > > >>>> nsc@ietf.org > > > >>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>> > > > >>>> Kevin, > > > >>>> > > > >>>> Classification mechanism is outside the scope of SFC. It can > be > > > >>>> based > > > >> on > > > >>>> the packet or information not in the packet(environmental=20 > > > >>>> attributes > > > >> for > > > >>>> instance) or a combination thereof. What is important is that > such > > > >>>> classification aids in traffic selection and service path=20 > > > >>>> identification. > > > >>>> It is no different from a policy in this regard except that > the > > > >>>> policy now specifies the service path. > > > >>>> Further, classification is not limited to the network=20 > > > >>>> elements > but > > > >>>> the service functions as well. Some of this is described in > the > > > >> architecture > > > >>>> drafts as well - > > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > > > >>>> > > > >>>> Surendra. > > > >>>> > > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma"=20 > > > >>>>> > > > wrote: > > > >>>>> > > > >>>>> Hi Ron, > > > >>>>> > > > >>>>> I was unable to make the SFC BoF due to a conflict with=20 > > > >>>>> CDNI, > but > > > >>>>> I had a similar question wrt bullet 11 in section 2 of the > > > problem > > > >>>>> statement: > > > >>>>> > > > >>>>> 11. Per-Service (re)Classification: Classification occurs > at > > > each > > > >>>>> service, independent from previously applied service > > > >>>> functions. > > > >>>>> These unrelated classification events consume > resources > > > per > > > >>>>> service. More importantly, the classification > > > functionality > > > >>>>> often differs per service function and service > function > > > >> cannot > > > >>>>> leverage the results from other deployed network or > > > service. > > > >>>>> > > > >>>>> as it relates to section 5.2 of the framework document: > > > >>>>> > > > >>>>> The SFC Classifier classifies packets based on (some of) > the > > > >>>> contents > > > >>>>> of the packet header. Concretely, it classifies packets > based > > > >>>>> on > > > >>>> the > > > >>>>> possible combination of one or more header fields, such as > > > source > > > >>>>> address, destination address, DS field, protocol ID,=20 > > > >>>>> source > > > port > > > >>>> and > > > >>>>> destination port numbers, and any other information. > > > >>>>> > > > >>>>> A packet-based classifier as described in the framework > document > > > >>>> would > > > >>>>> seem to be limited in what it can classify? The service > function > > > >>>>> identifier lookup does not seem to be a significant > optimization > > > >> over > > > >>>>> a packet-based 5-tuple lookup? There seems to be some > missing > > > >> detail > > > >>>>> wrt how classification information is determined and reused? > > > >>>>> > > > >>>>> When thinking about higher level services, e.g., HTTP and=20 > > > >>>>> TLS > > > >>>> encrypted > > > >>>>> flows, a packet-based classifier seems inadequate? I was > also > > > >>>> wondering > > > >>>>> how independent HLS segment requests might be classified and > > > >>>> associated? > > > >>>>> Were these types of use cases discussed in the BoF? > > > >>>>> > > > >>>>> thanx. > > > >>>>> > > > >>>>> -- Kevin J. Ma > > > >>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Ron > > > >>>>>> Parker > > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As was discussed in Vancouver, there are already many > existing > > > >>>>>> ways > > > >>>> to > > > >>>>>> accomplish service chaining. But none of them provide a > > > >>>> sufficient > > > >>>>>> combination of interoperability, flexibility, and resiliency. > > > A > > > >>>> single > > > >>>>>> service chain encapsulation will go a long way to ensuring > these > > > >>>> goals. > > > >>>>>> It may not be the absolutely most efficient approach for > every > > > >>>> single > > > >>>>>> network topology and every single use case, but its > ubiquitous > > > >> nature > > > >>>>>> should improve its adoption. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> Absolutely, that was an example of one type of derivation. > > > >>>>>> However > > > >>>> this > > > >>>>>> could be augmented with classification result, again one > more > > > >>>> example. > > > >>>>>> > > > >>>>>>>> All flows from the same source IP do not necessarily > follow > > > the > > > >>>> same > > > >>>>>> chain. > > > >>>>>> Correct. It is also not necessary that all transaction of > the > > > >>>>>> same > > > >>>> flow > > > >>>>>> follow the same chain either. So why stop at flow itself. > > > >>>>>> > > > >>>>>> Again the point here is that do we always need SFC header=20 > > > >>>>>> or > Not. > > > >>>>>> > > > >>>>>> Sumandra > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> The intention of service function chaining is to allow for=20 > > > >>>>>> operation > > > >>>> at > > > >>>>>> the fully qualified flow level, or even finer grained at=20 > > > >>>>>> the > > > >>>> transaction > > > >>>>>> level (this is an implementation matter for the PDP). > All > > > flows > > > >>>> from > > > >>>>>> the same source IP do not necessarily follow the same chain. > > > >> Source > > > >>>>>> IP, > > > >>>>>> therefore, does not identify the chain ID. Another > intention > > > of > > > >>>>>> service function chaining is to operate over any network > > > topology > > > >> and > > > >>>>>> not > > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part > of > > > the > > > >>>>>> transport, it does not adequately identify the service=20 > > > >>>>>> chain, > > > >> either. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Ron, > > > >>>>>> > > > >>>>>> The service header is meant to carry the context which can > > > *also* > > > >>>>>> be derived (for example use source ip and vlan to identify=20 > > > >>>>>> chainID and > > > >>>>>> position) or encapsulated as part of another tunnel header. > So > > > >>>>>> this could be optional IMHO. > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Sumandra, > > > >>>>>> > > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF > or > > > >>>>>> from > > > >>>> SF > > > >>>>>> to > > > >>>>>> SF will look like: > > > >>>>>> > > > >>>>>> +------------------------+ > > > >>>>>> | "transport" | > > > >>>>>> +------------------------+ > > > >>>>>> | service header | > > > >>>>>> +------------------------+ > > > >>>>>> | original IP header | > > > >>>>>> +------------------------+ > > > >>>>>> | | original IP > payload > > > | > > > >>>>>> | | > > > >>>>>> +------------------------+ > > > >>>>>> > > > >>>>>> Where service header contains, at a minimum, enough > information > > > >>>>>> to > > > >>>> allow > > > >>>>>> the packet to be propagated along the full length of the > chain, > > > >>>>>> and optionally, other metadata that enhances the operation > of > > > one > > > >>>>>> or > > > >> more > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> And where "transport" could conceivably be any of, but not=20 > > > >>>>>> limited > > > >>>> to: > > > >>>>>> > > > >>>>>> * Ethernet > > > >>>>>> * Ethernet + LLC2 > > > >>>>>> * Ethernet + MPLS > > > >>>>>> * Ethernet + IP + GRE > > > >>>>>> * Ethernet + IP +UDP > > > >>>>>> > > > >>>>>> > > > >>>>>> Also, "original" in the diagram above is not meant to imply=20 > > > >>>>>> immutability, but rather to specify the packet that is > > > propagated > > > >>>>>> from preceding entity to succeeding entity, prior to=20 > > > >>>>>> encapsulation. > > > >>>>>> > > > >>>>>> Ron > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Sumandra Majee > > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > > > >>>>>> To: Thomas Narten; nsc@ietf.org > > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Generic Service Function Chaining Encapsulation: A document > will > > > >>>>>> describe the single service-level data plane > encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes > that > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may=20 > > > >>>>>> be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > at > > > >>>>>> any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> [SM] What does it mean by a single service-level > encapsulation, > > > a > > > >>>> new > > > >>>>>> encapsulation format > > > >>>>>> or an ability to select one encapsulation format > that > > > >>>> fits > > > >>>>>> the > > > >>>>>> need for a given service chain? > > > >>>>>> The ability to select a specific encapsulation > would > > > >>>>>> be > > > >> a > > > >>>>>> management plane decision. > > > >>>>>> There are quite a few existing encapsulation > methods > > > >>>>>> that > > > >>>> can > > > >>>>>> possibly be reused to provide > > > >>>>>> context information between service nodes. I have > > > seen > > > >>>>>> mention > > > >>>>>> of GRE, for HTTP based > > > >>>>>> applications contexts are transferred via headers. > > > >>>>>> > > > >>>>>> > > > >>>>>> -----Original Message----- > > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > > > >>>>>> Behalf > > > >> Of > > > >>>>>> Thomas Narten > > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > > > >>>>>> To: nsc@ietf.org > > > >>>>>> Subject: [nsc] Current Proposed SFC charter > > > >>>>>> > > > >>>>>> Hi. > > > >>>>>> > > > >>>>>> Current charter can be found at > > > >>>>>> https://datatracker.ietf.org/doc/charter- > > > >>>>>> ietf-sfc/. > > > >>>>>> > > > >>>>>> It contains the revised management text as well as updated > > > >>>> milestones. > > > >>>>>> > > > >>>>>> All known issues have been addressed. If there are any > remaining > > > >>>> issues, > > > >>>>>> please speak up! > > > >>>>>> > > > >>>>>> Charter charter-ietf-sfc-00-04 > > > >>>>>> > > > >>>>>> Networks, servers, storage technologies, and applications, > have > > > >>>>>> all undergone significant change in recent years with the=20 > > > >>>>>> introduction > > > >> of > > > >>>>>> virtualization, network overlays, and orchestration.=20 > > > >>>>>> Service > > > >> delivery > > > >>>> is > > > >>>>>> currently both a technical and organizational challenge=20 > > > >>>>>> that > > > >> involves > > > >>>>>> significant modification to the network configuration. > > > >>>>>> Services are typically implemented by the ordered > combination of > > > >>>>>> a number of service functions that are deployed at=20 > > > >>>>>> different points within > > > >> the > > > >>>>>> network. Today, a common deployment model has service > functions > > > >>>>>> physically inserted on the data forwarding path between=20 > > > >>>>>> communicating peers. > > > >>>> Going > > > >>>>>> forward, however, there is a desire to move to a different > model, > > > >>>> where > > > >>>>>> service functions are not required to reside on the default > data > > > >> path > > > >>>>>> and > > > >>>>>> traffic is instead steered through services, wherever they > are > > > >>>> deployed. > > > >>>>>> > > > >>>>>> For a given service, the abstracted view of the required > service > > > >>>>>> functions and the order in which they are to be applied is > > > called > > > >>>>>> a Service Function Chain (SFC). Since a given service > function > > > >>>>>> may be available on more than one node within a network, a=20 > > > >>>>>> Service Function Chain is instantiated > > > >>>> via > > > >>>>>> the selection of specific service function instances and=20 > > > >>>>>> the network nodes on which they are provided, thereby=20 > > > >>>>>> forming a service topology: > > > >>>>>> this is called a Service Function Path. The service > functions > > > may > > > >>>>>> be applied at a specific layer within the network protocol > stack > > > >>>> (network > > > >>>>>> layer, application layer, etc.). > > > >>>>>> > > > >>>>>> The Service Function Chaining (SFC) working group will > develop > > > >>>>>> new approaches to service delivery and deployment. It will=20 > > > >>>>>> produce a framework for service function chaining that > includes > > > >>>>>> the necessary protocols > > > >>>> or > > > >>>>>> protocol extensions to convey the service path and service > path > > > >>>>>> information to nodes that implement service functions, as > well > > > as > > > >>>>>> mechanisms for steering traffic through service functions. > The > > > >>>> working > > > >>>>>> group will also examine what information needs to be > gathered > > > >>>>>> from > > > >>>> the > > > >>>>>> network and service functions in support of service=20 > > > >>>>>> function > > > >> chaining > > > >>>>>> and > > > >>>>>> how that information may be made available to nodes that=20 > > > >>>>>> implement > > > >>>> the > > > >>>>>> service functions. > > > >>>>>> > > > >>>>>> Specifically, the SFC WG is chartered to deliver the > following: > > > >>>>>> > > > >>>>>> 1) Problem Statement: This document will provide a summary > of > > > the > > > >>>>>> problem space to be addressed by the WG including=20 > > > >>>>>> example > > > high- > > > >>>>>> level use cases. Additionally, the WG will normalize > > > >> nomenclature > > > >>>>>> and definitions for service function chaining. > > > >>>>>> > > > >>>>>> 2) Architecture: This document will provide a description=20 > > > >>>>>> of > the > > > >>>>>> architectural building blocks and their relationships > > > including > > > >>>>>> interconnection, placement of capabilities, management, > > > >>>>>> diagnostics, design analysis, and security models, as > well as > > > >>>>>> requirements on the protocol mechanisms. > > > >>>>>> > > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A > document > > > will > > > >>>>>> describe the single service-level data plane > encapsulation > > > >> format > > > >>>>>> for > > > >>>>>> conveying the service function chain and the service > function > > > >>>> path, > > > >>>>>> and for communicating context information between nodes > that > > > >>>>>> implement service functions. It is intended that the > > > >>>> encapsulation > > > >>>>>> be agnostic to the layer at which it is applied and the=20 > > > >>>>>> service > > > >>>> that > > > >>>>>> is > > > >>>>>> being constructed. That is, the same encapsulation may=20 > > > >>>>>> be > > > used > > > >> on > > > >>>>>> a service function path realized at the network layer or > at > > > >>>>>> any other > > > >>>>>> layer, and the same encapsulation will apply for the > > > >> construction > > > >>>> of > > > >>>>>> service function paths regardless of the actual service. > > > >>>>>> > > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > > > developed to > > > >>>>>> describe requirements and protocols necessary to convey > > > >>>> information > > > >>>>>> to service function implementation points. Where=20 > > > >>>>>> possible, > > > >>>> existing > > > >>>>>> IETF protocols will be used and extended. All protocol > > > >> extensions > > > >>>>>> work should be carried out in the working groups > responsible > > > >>>>>> for > > > >>>> the > > > >>>>>> protocols being modified in coordination with this > working > > > >> group, > > > >>>>>> but > > > >>>>>> may be done in this working group after agreement with > all > > > the > > > >>>>>> relevant WG chairs and responsible ADs. > > > >>>>>> > > > >>>>>> 5) Manageability: Work on the management and configuration > of > > > >> service > > > >>>>>> functions in support of SFC components will certainly be > > > needed, > > > >>>>>> but first needs to be better understood and scoped. > > > >>>>>> > > > >>>>>> Proposed Milestones > > > >>>>>> > > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining > the > > > >>>> problem > > > >>>>>> statement and core use cases for Service Function Chaining > > > >>>>>> > > > >>>>>> May 2014 Consult with OPS Area on possible charter > modifications > > > >>>>>> for management and configuration of SFC components > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG Informational document defining the > > > >>>> architecture > > > >>>>>> for SFC > > > >>>>>> > > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 > > > >>>>>> function chaining encapsulation protocol > > > >>>>>> > > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying > the > > > >>>> generic > > > >>>>>> service function chaining header encapsulation > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> > > > >>>>>> Thomas > > > >>>>>> > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>>> _______________________________________________ > > > >>>>>> nsc mailing list > > > >>>>>> nsc@ietf.org > > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > > > >>>>> _______________________________________________ > > > >>>>> nsc mailing list > > > >>>>> nsc@ietf.org > > > >>>>> https://www.ietf.org/mailman/listinfo/nsc > > > > > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > > > nsc mailing list > > > nsc@ietf.org > > > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 08:44:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EE711E810B for ; Tue, 12 Nov 2013 08:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.557 X-Spam-Level: X-Spam-Status: No, score=-10.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlIDS1Fk6pjx for ; Tue, 12 Nov 2013 08:44:07 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 311F311E8106 for ; Tue, 12 Nov 2013 08:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30285; q=dns/txt; s=iport; t=1384274647; x=1385484247; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Kaft2iPqy0MUrg8YXRklrC9+vb8qQEwP0LtdyhwYl1E=; b=Va1CKHX4XMbik+E8nhKe3Ctbgn12vBsXGKduW2pyHuly/KNSBACiD4zR S5q0/gD5CPR2Zj+fiqsgbqpr29viN8aRsOmZzgGYLCBUmD0IfPrbh/+bw bubDuKATBsIDieATB6USjftCRQr9uTqqNX76mN0gs/RwAyGREquOzDbXT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGtaglKtJXG+/2dsb2JhbABQCoMHOFO/GYEqFnSCJQEBAQQBAQEXICsCBwQHDAYBCBEBAwEBARUJCS4LFAMGCAIEAQkEBQmHeA2/C44cBAEFBoEIKwIFAgQEhCcDlC6DYZIKgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283577526" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2013 16:43:59 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACGhxBc003281 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 16:43:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 10:43:58 -0600 From: "Jim Guichard (jguichar)" To: Linda Dunbar , Kevin J Ma , Ron Parker , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAAEPQD//7dogA== Date: Tue, 12 Nov 2013 16:43:57 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C055E6@dfweml509-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.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:44:13 -0000 Linda, Could you explain in detail why you believe branching and reclassification are two different things as to me they are one of the same? On 11/12/13 11:03 AM, "Linda Dunbar" wrote: > > >I just want to point out that branching and reclassification are two >separate functions. Yes, sometimes, those two functions can be collocated >on same device. But they don't have to be. > >IMHO, "re-classification" should be associated with assigning a different > Chain-ID or mega data to a flow, whereas, "branching" is about one >service function directing traffic to different service functions >depending on some conditions. > >Linda >=20 > >> -----Original Message----- >> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> Sent: Tuesday, November 12, 2013 9:49 AM >> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> Subject: RE: [nsc] Current Proposed SFC charter >>=20 >> Hi Linda, >>=20 >> Are you saying that a branching point is "never" a reclassification >> point, or are you saying that a branching point "does not have to be" >> a reclassification point? > > >>=20 >> I think this is an important distinction that needs to be clarified. >> If branching is never reclassification, then the meaning of a chain >> is different than I originally inferred. > > > >>If the chain is a tree with >> other "branching" points in it, then that limits the scope of the >> problem statement goals. >>=20 >> While this could be a degenerate case, and any implementation could >> define bad service chains, is it the intent of SFC to only look at >> the simpler packet-level classification cases, or is it the intent >> to consider the case where a branching point is viewed as a >> re-classification point? >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >> > -----Original Message----- >> > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> > Sent: Tuesday, November 12, 2013 10:34 AM >> > To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> > Subject: RE: [nsc] Current Proposed SFC charter >> > >> > Ron, >> > >> > First, want to make it clear that "branching" !=3D reclassification, >> agree? >> > >> > Second, the representation of branching (or service graph) can be in >> a >> > form of logic on a service function. Some service functions, >> especially L7 >> > based, can use value in a Database to determine what is the next >> service >> > function. >> > >> > Linda >> > >> > > -----Original Message----- >> > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> > > Ron Parker >> > > Sent: Tuesday, November 12, 2013 8:16 AM >> > > To: Hongyu Li (Julio); Kevin J Ma >> > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > > Majee >> > > Subject: Re: [nsc] Current Proposed SFC charter >> > > >> > > Hongyu, >> > > >> > > I agree completely that re-classification is not limited to DPI. >> > > >> > > And also, that an area for us to explore as a group is how to >> represent >> > > the service graph. Do we want to represent it as a proper graph >> with >> > > an adjacency list or other representational model? Or, do we want >> to >> > > represent it as a set of linear segments and if so, how are the >> > > segments connected into a graph? Other ideas? >> > > >> > > Ron >> > > >> > > >> > > -----Original Message----- >> > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> > > Hongyu Li (Julio) >> > > Sent: Tuesday, November 12, 2013 6:57 AM >> > > To: Ron Parker; Kevin J Ma >> > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > > Majee >> > > Subject: Re: [nsc] Current Proposed SFC charter >> > > >> > > Branching/forking is a very interesting topic of SFC. About the re- >> > > classification point, probably we shall not limit it to DPI. It is >> also >> > > possible that packets go to different branches after been processed >> by >> > > a certain service function, decision of which branches to go is >> made >> > > based on the result of service function's process, i.e. not just >> re- >> > > classification by DPI. >> > > >> > > Hongyu >> > > >> > > -----Original Message----- >> > > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> Of >> > > Ron Parker >> > > Sent: Tuesday, November 12, 2013 7:45 PM >> > > To: Kevin J Ma >> > > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > > Majee >> > > Subject: Re: [nsc] Current Proposed SFC charter >> > > >> > > Hi, Kevin >> > > >> > > You ask a great question about branching the graph. The details >> around >> > > how to convey the selection of the subtree/subgraph are still to be >> > > defined. Is it one chain id for the whole graph? Does each >> branch >> > > have its own chain id? Some combination? >> > > >> > > Ron >> > > >> > > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > > wrote: >> > > >> > > >> Yes, reclassification can change the service path and >> > > >> re-classification may happen at any node along a service path. >> > > > >> > > > Just to expand on that, going back to the original question about >> > > > service header encapsulation, is it intended that a chain that is >> > > > re-classified will get a new chain ID which fully describes a >> chain >> > > > that is a superset of the original chain ID, prior to DPI-based >> > > > re-classification? (assuming the goal is "a single chain ID that >> is >> > > > commonly understood along the entire service chain" >> > > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> > > > >> > > > And the applicable subset of the permutative list of service >> paths >> > > > would be configured at each appropriate service node? >> > > > e.g., ID 1: NAT + firewall + DPI >> > > > ID 2: NAT + firewall + DPI + AV >> > > > ID 3: NAT + firewall + DPI + AV + NAT >> > > > ID 4: NAT + firewall + DPI + NAT >> > > > ID 5: NAT + firewall + DPI + AV + LB >> > > > ID 6: NAT + firewall + DPI + LB >> > > > ID 7: NAT + firewall + DPI + LB + CACHE >> > > > ID 8: NAT + firewall + DPI + CACHE >> > > > ID 9: NAT + firewall + DPI + optimizer + LB >> > > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> > > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >> flow >> > > > then be initially classified as ID 1, but eventually get re- >> > > classified >> > > > to ID 2-11, after the DPI phase? >> > > > >> > > > thanx. >> > > > >> > > > -- Kevin J. Ma >> > > > >> > > >> -----Original Message----- >> > > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > > >> Sent: Tuesday, November 12, 2013 1:01 AM >> > > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> > > >> nsc@ietf.org >> > > >> Subject: Re: [nsc] Current Proposed SFC charter >> > > >> >> > > >> >> > > >> >> > > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >> wrote: >> > > >>> >> > > >>> Hi Surendra, >> > > >>> >> > > >>> Classification may be out of scope, but the level of service >> that >> > > is >> > > >>> applicable is dependent upon the level of classification that >> can >> > > be >> > > >>> performed. An assumption of packet level encapsulation has >> > > >> implications >> > > >>> on the level of classification being performed? If the stated >> > > goals >> > > >> are >> > > >>> for firewall and load balancer functionality, then the >> application >> > > >> level >> > > >>> nature of those functions needs to be taken into account? If, >> on >> > > >>> the other hand, the service function scope is limited due to >> > > >>> limitations in classification, that would be and important >> piece of >> > > information? >> > > >>> >> > > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >> fork >> > > >>> points of the service paths seem like re-classification points? >> Is >> > > >>> that the interpretation from the architecture perspective? Or >> is >> > > >>> the service function chain classification exclusive of DPI >> > > functionality? >> > > >> I have not fully read that draft yet. But in general, as >> > > >> described in the arch draft, the collection of services form a >> graph, >> > > >> segments of which are service paths. Yes, reclassification can >> > > change >> > > >> the service path and re-classification may happen at any node >> along >> > > a service path. >> > > >> >> > > >> Surendra. >> > > >>> >> > > >>> thanx. >> > > >>> >> > > >>> -- Kevin J. Ma >> > > >>> >> > > >>>> -----Original Message----- >> > > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> > > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> > > >>>> nsc@ietf.org >> > > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> > > >>>> >> > > >>>> Kevin, >> > > >>>> >> > > >>>> Classification mechanism is outside the scope of SFC. It can >> be >> > > >>>> based >> > > >> on >> > > >>>> the packet or information not in the packet(environmental >> > > >>>> attributes >> > > >> for >> > > >>>> instance) or a combination thereof. What is important is that >> such >> > > >>>> classification aids in traffic selection and service path >> > > >>>> identification. >> > > >>>> It is no different from a policy in this regard except that >> the >> > > >>>> policy now specifies the service path. >> > > >>>> Further, classification is not limited to the network elements >> but >> > > >>>> the service functions as well. Some of this is described in >> the >> > > >> architecture >> > > >>>> drafts as well - >> > > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> > > >>>> >> > > >>>> Surendra. >> > > >>>> >> > > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> > > wrote: >> > > >>>>> >> > > >>>>> Hi Ron, >> > > >>>>> >> > > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >> but >> > > >>>>> I had a similar question wrt bullet 11 in section 2 of the >> > > problem >> > > >>>>> statement: >> > > >>>>> >> > > >>>>> 11. Per-Service (re)Classification: Classification occurs >> at >> > > each >> > > >>>>> service, independent from previously applied service >> > > >>>> functions. >> > > >>>>> These unrelated classification events consume >> resources >> > > per >> > > >>>>> service. More importantly, the classification >> > > functionality >> > > >>>>> often differs per service function and service >> function >> > > >> cannot >> > > >>>>> leverage the results from other deployed network or >> > > service. >> > > >>>>> >> > > >>>>> as it relates to section 5.2 of the framework document: >> > > >>>>> >> > > >>>>> The SFC Classifier classifies packets based on (some of) >> the >> > > >>>> contents >> > > >>>>> of the packet header. Concretely, it classifies packets >> based >> > > >>>>> on >> > > >>>> the >> > > >>>>> possible combination of one or more header fields, such as >> > > source >> > > >>>>> address, destination address, DS field, protocol ID, source >> > > port >> > > >>>> and >> > > >>>>> destination port numbers, and any other information. >> > > >>>>> >> > > >>>>> A packet-based classifier as described in the framework >> document >> > > >>>> would >> > > >>>>> seem to be limited in what it can classify? The service >> function >> > > >>>>> identifier lookup does not seem to be a significant >> optimization >> > > >> over >> > > >>>>> a packet-based 5-tuple lookup? There seems to be some >> missing >> > > >> detail >> > > >>>>> wrt how classification information is determined and reused? >> > > >>>>> >> > > >>>>> When thinking about higher level services, e.g., HTTP and TLS >> > > >>>> encrypted >> > > >>>>> flows, a packet-based classifier seems inadequate? I was >> also >> > > >>>> wondering >> > > >>>>> how independent HLS segment requests might be classified and >> > > >>>> associated? >> > > >>>>> Were these types of use cases discussed in the BoF? >> > > >>>>> >> > > >>>>> thanx. >> > > >>>>> >> > > >>>>> -- Kevin J. Ma >> > > >>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > > >>>>>> Behalf >> > > >> Of >> > > >>>>>> Ron >> > > >>>>>> Parker >> > > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Sumandra, >> > > >>>>>> >> > > >>>>>> As was discussed in Vancouver, there are already many >> existing >> > > >>>>>> ways >> > > >>>> to >> > > >>>>>> accomplish service chaining. But none of them provide a >> > > >>>> sufficient >> > > >>>>>> combination of interoperability, flexibility, and resiliency. >> > > A >> > > >>>> single >> > > >>>>>> service chain encapsulation will go a long way to ensuring >> these >> > > >>>> goals. >> > > >>>>>> It may not be the absolutely most efficient approach for >> every >> > > >>>> single >> > > >>>>>> network topology and every single use case, but its >> ubiquitous >> > > >> nature >> > > >>>>>> should improve its adoption. >> > > >>>>>> >> > > >>>>>> Ron >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Ron, >> > > >>>>>> >> > > >>>>>> Absolutely, that was an example of one type of derivation. >> > > >>>>>> However >> > > >>>> this >> > > >>>>>> could be augmented with classification result, again one >> more >> > > >>>> example. >> > > >>>>>> >> > > >>>>>>>> All flows from the same source IP do not necessarily >> follow >> > > the >> > > >>>> same >> > > >>>>>> chain. >> > > >>>>>> Correct. It is also not necessary that all transaction of >> the >> > > >>>>>> same >> > > >>>> flow >> > > >>>>>> follow the same chain either. So why stop at flow itself. >> > > >>>>>> >> > > >>>>>> Again the point here is that do we always need SFC header or >> Not. >> > > >>>>>> >> > > >>>>>> Sumandra >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Sumandra, >> > > >>>>>> >> > > >>>>>> The intention of service function chaining is to allow for >> > > >>>>>> operation >> > > >>>> at >> > > >>>>>> the fully qualified flow level, or even finer grained at the >> > > >>>> transaction >> > > >>>>>> level (this is an implementation matter for the PDP). >> All >> > > flows >> > > >>>> from >> > > >>>>>> the same source IP do not necessarily follow the same chain. >> > > >> Source >> > > >>>>>> IP, >> > > >>>>>> therefore, does not identify the chain ID. Another >> intention >> > > of >> > > >>>>>> service function chaining is to operate over any network >> > > topology >> > > >> and >> > > >>>>>> not >> > > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >> of >> > > the >> > > >>>>>> transport, it does not adequately identify the service chain, >> > > >> either. >> > > >>>>>> >> > > >>>>>> Ron >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> > > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Ron, >> > > >>>>>> >> > > >>>>>> The service header is meant to carry the context which can >> > > *also* >> > > >>>>>> be derived (for example use source ip and vlan to identify >> > > >>>>>> chainID and >> > > >>>>>> position) or encapsulated as part of another tunnel header. >> So >> > > >>>>>> this could be optional IMHO. >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> > > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Sumandra, >> > > >>>>>> >> > > >>>>>> As I understand it, an SFC packet traversing from PDP to SF >> or >> > > >>>>>> from >> > > >>>> SF >> > > >>>>>> to >> > > >>>>>> SF will look like: >> > > >>>>>> >> > > >>>>>> +------------------------+ >> > > >>>>>> | "transport" | >> > > >>>>>> +------------------------+ >> > > >>>>>> | service header | >> > > >>>>>> +------------------------+ >> > > >>>>>> | original IP header | >> > > >>>>>> +------------------------+ >> > > >>>>>> | | original IP >> payload >> > > | >> > > >>>>>> | | >> > > >>>>>> +------------------------+ >> > > >>>>>> >> > > >>>>>> Where service header contains, at a minimum, enough >> information >> > > >>>>>> to >> > > >>>> allow >> > > >>>>>> the packet to be propagated along the full length of the >> chain, >> > > >>>>>> and optionally, other metadata that enhances the operation >> of >> > > one >> > > >>>>>> or >> > > >> more >> > > >>>>>> service functions. >> > > >>>>>> >> > > >>>>>> And where "transport" could conceivably be any of, but not >> > > >>>>>> limited >> > > >>>> to: >> > > >>>>>> >> > > >>>>>> * Ethernet >> > > >>>>>> * Ethernet + LLC2 >> > > >>>>>> * Ethernet + MPLS >> > > >>>>>> * Ethernet + IP + GRE >> > > >>>>>> * Ethernet + IP +UDP >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> Also, "original" in the diagram above is not meant to imply >> > > >>>>>> immutability, but rather to specify the packet that is >> > > propagated >> > > >>>>>> from preceding entity to succeeding entity, prior to >> > > >>>>>> encapsulation. >> > > >>>>>> >> > > >>>>>> Ron >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > > >>>>>> Behalf >> > > >> Of >> > > >>>>>> Sumandra Majee >> > > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> > > >>>>>> To: Thomas Narten; nsc@ietf.org >> > > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Generic Service Function Chaining Encapsulation: A document >> will >> > > >>>>>> describe the single service-level data plane >> encapsulation >> > > >> format >> > > >>>>>> for >> > > >>>>>> conveying the service function chain and the service >> function >> > > >>>> path, >> > > >>>>>> and for communicating context information between nodes >> that >> > > >>>>>> implement service functions. It is intended that the >> > > >>>> encapsulation >> > > >>>>>> be agnostic to the layer at which it is applied and the >> > > >>>>>> service >> > > >>>> that >> > > >>>>>> is >> > > >>>>>> being constructed. That is, the same encapsulation may be >> > > used >> > > >> on >> > > >>>>>> a service function path realized at the network layer or >> at >> > > >>>>>> any other >> > > >>>>>> layer, and the same encapsulation will apply for the >> > > >> construction >> > > >>>> of >> > > >>>>>> service function paths regardless of the actual service. >> > > >>>>>> >> > > >>>>>> [SM] What does it mean by a single service-level >> encapsulation, >> > > a >> > > >>>> new >> > > >>>>>> encapsulation format >> > > >>>>>> or an ability to select one encapsulation format >> that >> > > >>>> fits >> > > >>>>>> the >> > > >>>>>> need for a given service chain? >> > > >>>>>> The ability to select a specific encapsulation >> would >> > > >>>>>> be >> > > >> a >> > > >>>>>> management plane decision. >> > > >>>>>> There are quite a few existing encapsulation >> methods >> > > >>>>>> that >> > > >>>> can >> > > >>>>>> possibly be reused to provide >> > > >>>>>> context information between service nodes. I have >> > > seen >> > > >>>>>> mention >> > > >>>>>> of GRE, for HTTP based >> > > >>>>>> applications contexts are transferred via headers. >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> -----Original Message----- >> > > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > > >>>>>> Behalf >> > > >> Of >> > > >>>>>> Thomas Narten >> > > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> > > >>>>>> To: nsc@ietf.org >> > > >>>>>> Subject: [nsc] Current Proposed SFC charter >> > > >>>>>> >> > > >>>>>> Hi. >> > > >>>>>> >> > > >>>>>> Current charter can be found at >> > > >>>>>> https://datatracker.ietf.org/doc/charter- >> > > >>>>>> ietf-sfc/. >> > > >>>>>> >> > > >>>>>> It contains the revised management text as well as updated >> > > >>>> milestones. >> > > >>>>>> >> > > >>>>>> All known issues have been addressed. If there are any >> remaining >> > > >>>> issues, >> > > >>>>>> please speak up! >> > > >>>>>> >> > > >>>>>> Charter charter-ietf-sfc-00-04 >> > > >>>>>> >> > > >>>>>> Networks, servers, storage technologies, and applications, >> have >> > > >>>>>> all undergone significant change in recent years with the >> > > >>>>>> introduction >> > > >> of >> > > >>>>>> virtualization, network overlays, and orchestration. Service >> > > >> delivery >> > > >>>> is >> > > >>>>>> currently both a technical and organizational challenge that >> > > >> involves >> > > >>>>>> significant modification to the network configuration. >> > > >>>>>> Services are typically implemented by the ordered >> combination of >> > > >>>>>> a number of service functions that are deployed at different >> > > >>>>>> points within >> > > >> the >> > > >>>>>> network. Today, a common deployment model has service >> functions >> > > >>>>>> physically inserted on the data forwarding path between >> > > >>>>>> communicating peers. >> > > >>>> Going >> > > >>>>>> forward, however, there is a desire to move to a different >> model, >> > > >>>> where >> > > >>>>>> service functions are not required to reside on the default >> data >> > > >> path >> > > >>>>>> and >> > > >>>>>> traffic is instead steered through services, wherever they >> are >> > > >>>> deployed. >> > > >>>>>> >> > > >>>>>> For a given service, the abstracted view of the required >> service >> > > >>>>>> functions and the order in which they are to be applied is >> > > called >> > > >>>>>> a Service Function Chain (SFC). Since a given service >> function >> > > >>>>>> may be available on more than one node within a network, a >> > > >>>>>> Service Function Chain is instantiated >> > > >>>> via >> > > >>>>>> the selection of specific service function instances and the >> > > >>>>>> network nodes on which they are provided, thereby forming a >> > > >>>>>> service topology: >> > > >>>>>> this is called a Service Function Path. The service >> functions >> > > may >> > > >>>>>> be applied at a specific layer within the network protocol >> stack >> > > >>>> (network >> > > >>>>>> layer, application layer, etc.). >> > > >>>>>> >> > > >>>>>> The Service Function Chaining (SFC) working group will >> develop >> > > >>>>>> new approaches to service delivery and deployment. It will >> > > >>>>>> produce a framework for service function chaining that >> includes >> > > >>>>>> the necessary protocols >> > > >>>> or >> > > >>>>>> protocol extensions to convey the service path and service >> path >> > > >>>>>> information to nodes that implement service functions, as >> well >> > > as >> > > >>>>>> mechanisms for steering traffic through service functions. >> The >> > > >>>> working >> > > >>>>>> group will also examine what information needs to be >> gathered >> > > >>>>>> from >> > > >>>> the >> > > >>>>>> network and service functions in support of service function >> > > >> chaining >> > > >>>>>> and >> > > >>>>>> how that information may be made available to nodes that >> > > >>>>>> implement >> > > >>>> the >> > > >>>>>> service functions. >> > > >>>>>> >> > > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> > > >>>>>> >> > > >>>>>> 1) Problem Statement: This document will provide a summary >> of >> > > the >> > > >>>>>> problem space to be addressed by the WG including example >> > > high- >> > > >>>>>> level use cases. Additionally, the WG will normalize >> > > >> nomenclature >> > > >>>>>> and definitions for service function chaining. >> > > >>>>>> >> > > >>>>>> 2) Architecture: This document will provide a description of >> the >> > > >>>>>> architectural building blocks and their relationships >> > > including >> > > >>>>>> interconnection, placement of capabilities, management, >> > > >>>>>> diagnostics, design analysis, and security models, as >> well as >> > > >>>>>> requirements on the protocol mechanisms. >> > > >>>>>> >> > > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >> document >> > > will >> > > >>>>>> describe the single service-level data plane >> encapsulation >> > > >> format >> > > >>>>>> for >> > > >>>>>> conveying the service function chain and the service >> function >> > > >>>> path, >> > > >>>>>> and for communicating context information between nodes >> that >> > > >>>>>> implement service functions. It is intended that the >> > > >>>> encapsulation >> > > >>>>>> be agnostic to the layer at which it is applied and the >> > > >>>>>> service >> > > >>>> that >> > > >>>>>> is >> > > >>>>>> being constructed. That is, the same encapsulation may be >> > > used >> > > >> on >> > > >>>>>> a service function path realized at the network layer or >> at >> > > >>>>>> any other >> > > >>>>>> layer, and the same encapsulation will apply for the >> > > >> construction >> > > >>>> of >> > > >>>>>> service function paths regardless of the actual service. >> > > >>>>>> >> > > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> > > developed to >> > > >>>>>> describe requirements and protocols necessary to convey >> > > >>>> information >> > > >>>>>> to service function implementation points. Where possible, >> > > >>>> existing >> > > >>>>>> IETF protocols will be used and extended. All protocol >> > > >> extensions >> > > >>>>>> work should be carried out in the working groups >> responsible >> > > >>>>>> for >> > > >>>> the >> > > >>>>>> protocols being modified in coordination with this >> working >> > > >> group, >> > > >>>>>> but >> > > >>>>>> may be done in this working group after agreement with >> all >> > > the >> > > >>>>>> relevant WG chairs and responsible ADs. >> > > >>>>>> >> > > >>>>>> 5) Manageability: Work on the management and configuration >> of >> > > >> service >> > > >>>>>> functions in support of SFC components will certainly be >> > > needed, >> > > >>>>>> but first needs to be better understood and scoped. >> > > >>>>>> >> > > >>>>>> Proposed Milestones >> > > >>>>>> >> > > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining >> the >> > > >>>> problem >> > > >>>>>> statement and core use cases for Service Function Chaining >> > > >>>>>> >> > > >>>>>> May 2014 Consult with OPS Area on possible charter >> modifications >> > > >>>>>> for management and configuration of SFC components >> > > >>>>>> >> > > >>>>>> Jan 2015 Submit to IESG Informational document defining the >> > > >>>> architecture >> > > >>>>>> for SFC >> > > >>>>>> >> > > >>>>>> Jan 2015 Submit to IESG requirements for a generic service >> > > >>>>>> function chaining encapsulation protocol >> > > >>>>>> >> > > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying >> the >> > > >>>> generic >> > > >>>>>> service function chaining header encapsulation >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> >> > > >>>>>> Thomas >> > > >>>>>> >> > > >>>>>> _______________________________________________ >> > > >>>>>> nsc mailing list >> > > >>>>>> nsc@ietf.org >> > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > >>>>>> _______________________________________________ >> > > >>>>>> nsc mailing list >> > > >>>>>> nsc@ietf.org >> > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > >>>>>> _______________________________________________ >> > > >>>>>> nsc mailing list >> > > >>>>>> nsc@ietf.org >> > > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > >>>>> _______________________________________________ >> > > >>>>> nsc mailing list >> > > >>>>> nsc@ietf.org >> > > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > > >> > > _______________________________________________ >> > > nsc mailing list >> > > nsc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/nsc >> > > _______________________________________________ >> > > nsc mailing list >> > > nsc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/nsc >> > > _______________________________________________ >> > > nsc mailing list >> > > nsc@ietf.org >> > > https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 12 08:47:21 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3607611E8106 for ; Tue, 12 Nov 2013 08:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWabm7UlHtvp for ; Tue, 12 Nov 2013 08:47:17 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9FB11E810B for ; Tue, 12 Nov 2013 08:47:16 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C6A607AEB9C; Tue, 12 Nov 2013 11:47:02 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0F5A97AE919; Tue, 12 Nov 2013 11:47:01 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Tue, 12 Nov 2013 11:47:00 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Tue, 12 Nov 2013 11:46:58 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAIAAGzeg Message-ID: <291CC3F9E50E7641901A54E85D0977C6B028026108@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 16:47:21 -0000 Hi Jim, In the example you have below, does the PCRF have to be concerned about reverse-mapping on the return path? Or would the return path be handled independently, classifying to a different set of chains? In the example below, branching does equate to re-classification? thanx. -- Kevin J. Ma > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Tuesday, November 12, 2013 9:07 AM > To: Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Sumandra Majee; > Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter > > Hi Kevin, > > Let me try and provide a concrete example to see if this answers your > specific question: > > Use case: P-GW -> PCRF -> services applied to traffic based on > applicationID and subscriberID. > > Instantiated as: > > SFC1: P-GW -> DPI -> PCRF > SFC2: PCRF -> video-optimization -> metering -> FW > SFC3: PCRF -> parental-control -> metering -> FW > > In this case DPI is performed on SFC1 and identifies applicationID. The > applicationID is carried in the service encapsulation to PCRF. PCRF uses > solution specific logic (identifies subscriber, applies policies, etc) an= d > uses the result along with the applicationID received from DPI to select > an outbound service chain, SFC2 or SFC3. Note that in this case branching > occurs from SFC1 to either SFC2 or SFC3. > > > > > On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > > >> Yes, reclassification can change the service path and > >> re-classification may happen at any node along a service path. > > > >Just to expand on that, going back to the original question about > >service header encapsulation, is it intended that a chain that > >is re-classified will get a new chain ID which fully describes > >a chain that is a superset of the original chain ID, prior to > >DPI-based re-classification? (assuming the goal is "a single > >chain ID that is commonly understood along the entire service chain" > >http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > > > >And the applicable subset of the permutative list of service > >paths would be configured at each appropriate service node? > >e.g., ID 1: NAT + firewall + DPI > > ID 2: NAT + firewall + DPI + AV > > ID 3: NAT + firewall + DPI + AV + NAT > > ID 4: NAT + firewall + DPI + NAT > > ID 5: NAT + firewall + DPI + AV + LB > > ID 6: NAT + firewall + DPI + LB > > ID 7: NAT + firewall + DPI + LB + CACHE > > ID 8: NAT + firewall + DPI + CACHE > > ID 9: NAT + firewall + DPI + optimizer + LB > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > > ID 11: NAT + firewall + DPI + optimizer + CACHE > >Would every flow then be initially classified as ID 1, but > >eventually get re-classified to ID 2-11, after the DPI phase? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> Sent: Tuesday, November 12, 2013 1:01 AM > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; nsc@ietf.or= g > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> > >> > >> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: > >> > >> >Hi Surendra, > >> > > >> > Classification may be out of scope, but the level of service that i= s > >> > applicable is dependent upon the level of classification that can b= e > >> > performed. An assumption of packet level encapsulation has > >> implications > >> > on the level of classification being performed? If the stated goal= s > >> are > >> > for firewall and load balancer functionality, then the application > >> level > >> > nature of those functions needs to be taken into account? If, on > the > >> > other hand, the service function scope is limited due to limitation= s > >>in > >> > classification, that would be and important piece of information? > >> > > >> > Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > >>points > >> > of the service paths seem like re-classification points? Is that > the > >> > interpretation from the architecture perspective? Or is the servic= e > >> > function chain classification exclusive of DPI functionality? > >> I have not fully read that draft yet. But in general, as describe= d > >>in > >> the arch draft, the collection of services form a graph, segments of > >>which > >> are service paths. Yes, reclassification can change the service path > and > >> re-classification may happen at any node along a service path. > >> > >> Surendra. > >> > > >> >thanx. > >> > > >> >-- Kevin J. Ma > >> > > >> >> -----Original Message----- > >> >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> >> Sent: Tuesday, November 12, 2013 12:08 AM > >> >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>nsc@ietf.org > >> >> Subject: Re: [nsc] Current Proposed SFC charter > >> >> > >> >> Kevin, > >> >> > >> >> Classification mechanism is outside the scope of SFC. It can be > based > >> on > >> >> the packet or information not in the packet(environmental attribute= s > >> for > >> >> instance) or a combination thereof. What is important is that such > >> >> classification aids in traffic selection and service path > >> >>identification. > >> >> It is no different from a policy in this regard except that the > >>policy > >> >>now > >> >> specifies the service path. > >> >> Further, classification is not limited to the network elements but > >>the > >> >> service functions as well. Some of this is described in the > >> architecture > >> >> drafts as well - > >> >>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >> >> > >> >> Surendra. > >> >> > >> >> On 11/11/13 7:33 PM, "Kevin J Ma" wrote= : > >> >> > >> >> >Hi Ron, > >> >> > > >> >> > I was unable to make the SFC BoF due to a conflict with CDNI, bu= t > >>I > >> >> > had a similar question wrt bullet 11 in section 2 of the problem > >> >> >statement: > >> >> > > >> >> > 11. Per-Service (re)Classification: Classification occurs at > >>each > >> >> > service, independent from previously applied service > >> >>functions. > >> >> > These unrelated classification events consume resources > per > >> >> > service. More importantly, the classification > >>functionality > >> >> > often differs per service function and service function > >> cannot > >> >> > leverage the results from other deployed network or > >>service. > >> >> > > >> >> > as it relates to section 5.2 of the framework document: > >> >> > > >> >> > The SFC Classifier classifies packets based on (some of) the > >> >>contents > >> >> > of the packet header. Concretely, it classifies packets based > >>on > >> >>the > >> >> > possible combination of one or more header fields, such as > >>source > >> >> > address, destination address, DS field, protocol ID, source > port > >> >>and > >> >> > destination port numbers, and any other information. > >> >> > > >> >> > A packet-based classifier as described in the framework document > >> >>would > >> >> > seem to be limited in what it can classify? The service functio= n > >> >> > identifier lookup does not seem to be a significant optimization > >> over > >> >> > a packet-based 5-tuple lookup? There seems to be some missing > >> detail > >> >> > wrt how classification information is determined and reused? > >> >> > > >> >> > When thinking about higher level services, e.g., HTTP and TLS > >> >>encrypted > >> >> > flows, a packet-based classifier seems inadequate? I was also > >> >> wondering > >> >> > how independent HLS segment requests might be classified and > >> >> associated? > >> >> > Were these types of use cases discussed in the BoF? > >> >> > > >> >> >thanx. > >> >> > > >> >> >-- Kevin J. Ma > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> >>Ron > >> >> >> Parker > >> >> >> Sent: Monday, November 11, 2013 10:16 PM > >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> >> Subject: Re: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Sumandra, > >> >> >> > >> >> >> As was discussed in Vancouver, there are already many existing > >>ways > >> >>to > >> >> >> accomplish service chaining. But none of them provide a > >> >>sufficient > >> >> >> combination of interoperability, flexibility, and resiliency. = A > >> >> single > >> >> >> service chain encapsulation will go a long way to ensuring these > >> >>goals. > >> >> >> It may not be the absolutely most efficient approach for every > >> >>single > >> >> >> network topology and every single use case, but its ubiquitous > >> nature > >> >> >> should improve its adoption. > >> >> >> > >> >> >> Ron > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> >> >> Sent: Monday, November 11, 2013 10:10 PM > >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Ron, > >> >> >> > >> >> >> Absolutely, that was an example of one type of derivation. > However > >> >>this > >> >> >> could be augmented with classification result, again one more > >> >>example. > >> >> >> > >> >> >> >>All flows from the same source IP do not necessarily follow th= e > >> >>same > >> >> >> chain. > >> >> >> Correct. It is also not necessary that all transaction of the > same > >> >>flow > >> >> >> follow the same chain either. So why stop at flow itself. > >> >> >> > >> >> >> Again the point here is that do we always need SFC header or Not= . > >> >> >> > >> >> >> Sumandra > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> >> Sent: Monday, November 11, 2013 7:02 PM > >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Sumandra, > >> >> >> > >> >> >> The intention of service function chaining is to allow for > >>operation > >> >>at > >> >> >> the fully qualified flow level, or even finer grained at the > >> >> transaction > >> >> >> level (this is an implementation matter for the PDP). All > >>flows > >> >> from > >> >> >> the same source IP do not necessarily follow the same chain. > >> Source > >> >> >>IP, > >> >> >> therefore, does not identify the chain ID. Another intention > >>of > >> >> >> service function chaining is to operate over any network topolog= y > >> and > >> >> >>not > >> >> >> be limited to a single LAN. Thus, while VLAN may be part of th= e > >> >> >> transport, it does not adequately identify the service chain, > >> either. > >> >> >> > >> >> >> Ron > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> >> >> Sent: Monday, November 11, 2013 9:56 PM > >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Ron, > >> >> >> > >> >> >> The service header is meant to carry the context which can *also= * > >>be > >> >> >> derived (for example use source ip and vlan to identify chainID > >>and > >> >> >> position) or encapsulated as part of another tunnel header. So > >>this > >> >> >>could > >> >> >> be optional IMHO. > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> >> >> Sent: Monday, November 11, 2013 4:36 PM > >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> >> >> Subject: RE: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Sumandra, > >> >> >> > >> >> >> As I understand it, an SFC packet traversing from PDP to SF or > >>from > >> >>SF > >> >> >>to > >> >> >> SF will look like: > >> >> >> > >> >> >> +------------------------+ > >> >> >> | "transport" | > >> >> >> +------------------------+ > >> >> >> | service header | > >> >> >> +------------------------+ > >> >> >> | original IP header | > >> >> >> +------------------------+ > >> >> >> | | original IP payload > >>| > >> >> >> | | > >> >> >> +------------------------+ > >> >> >> > >> >> >> Where service header contains, at a minimum, enough information > to > >> >> allow > >> >> >> the packet to be propagated along the full length of the chain, > >>and > >> >> >> optionally, other metadata that enhances the operation of one or > >> more > >> >> >> service functions. > >> >> >> > >> >> >> And where "transport" could conceivably be any of, but not > >>limited > >> >>to: > >> >> >> > >> >> >> * Ethernet > >> >> >> * Ethernet + LLC2 > >> >> >> * Ethernet + MPLS > >> >> >> * Ethernet + IP + GRE > >> >> >> * Ethernet + IP +UDP > >> >> >> > >> >> >> > >> >> >> Also, "original" in the diagram above is not meant to imply > >> >> >>immutability, > >> >> >> but rather to specify the packet that is propagated from > preceding > >> >> >>entity > >> >> >> to succeeding entity, prior to encapsulation. > >> >> >> > >> >> >> Ron > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> >> Sumandra Majee > >> >> >> Sent: Monday, November 11, 2013 6:46 PM > >> >> >> To: Thomas Narten; nsc@ietf.org > >> >> >> Subject: Re: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Generic Service Function Chaining Encapsulation: A document will > >> >> >> describe the single service-level data plane encapsulation > >> format > >> >> >>for > >> >> >> conveying the service function chain and the service functio= n > >> >>path, > >> >> >> and for communicating context information between nodes that > >> >> >> implement service functions. It is intended that the > >> >>encapsulation > >> >> >> be agnostic to the layer at which it is applied and the > >>service > >> >> that > >> >> >> is > >> >> >> being constructed. That is, the same encapsulation may be > used > >> on > >> >> >> a service function path realized at the network layer or at > >>any > >> >> >>other > >> >> >> layer, and the same encapsulation will apply for the > >> construction > >> >> of > >> >> >> service function paths regardless of the actual service. > >> >> >> > >> >> >> [SM] What does it mean by a single service-level encapsulation, > a > >> >>new > >> >> >> encapsulation format > >> >> >> or an ability to select one encapsulation format tha= t > >> >>fits > >> >> >>the > >> >> >> need for a given service chain? > >> >> >> The ability to select a specific encapsulation would > >>be > >> a > >> >> >> management plane decision. > >> >> >> There are quite a few existing encapsulation methods > >>that > >> >>can > >> >> >> possibly be reused to provide > >> >> >> context information between service nodes. I have > seen > >> >> >>mention > >> >> >> of GRE, for HTTP based > >> >> >> applications contexts are transferred via headers. > >> >> >> > >> >> >> > >> >> >> -----Original Message----- > >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > Behalf > >> Of > >> >> >> Thomas Narten > >> >> >> Sent: Wednesday, November 06, 2013 11:07 AM > >> >> >> To: nsc@ietf.org > >> >> >> Subject: [nsc] Current Proposed SFC charter > >> >> >> > >> >> >> Hi. > >> >> >> > >> >> >> Current charter can be found at > >> >> >>https://datatracker.ietf.org/doc/charter- > >> >> >> ietf-sfc/. > >> >> >> > >> >> >> It contains the revised management text as well as updated > >> >>milestones. > >> >> >> > >> >> >> All known issues have been addressed. If there are any remaining > >> >> issues, > >> >> >> please speak up! > >> >> >> > >> >> >> Charter charter-ietf-sfc-00-04 > >> >> >> > >> >> >> Networks, servers, storage technologies, and applications, have > >>all > >> >> >> undergone significant change in recent years with the > introduction > >> of > >> >> >> virtualization, network overlays, and orchestration. Service > >> delivery > >> >> is > >> >> >> currently both a technical and organizational challenge that > >> involves > >> >> >> significant modification to the network configuration. > >> >> >> Services are typically implemented by the ordered combination of > a > >> >> >>number > >> >> >> of service functions that are deployed at different points withi= n > >> the > >> >> >> network. Today, a common deployment model has service functions > >> >> >>physically > >> >> >> inserted on the data forwarding path between communicating peers= . > >> >>Going > >> >> >> forward, however, there is a desire to move to a different model= , > >> >>where > >> >> >> service functions are not required to reside on the default data > >> path > >> >> >>and > >> >> >> traffic is instead steered through services, wherever they are > >> >> deployed. > >> >> >> > >> >> >> For a given service, the abstracted view of the required service > >> >> >>functions > >> >> >> and the order in which they are to be applied is called a Servic= e > >> >> >>Function > >> >> >> Chain (SFC). Since a given service function may be available on > >>more > >> >> >>than > >> >> >> one node within a network, a Service Function Chain is > >>instantiated > >> >>via > >> >> >> the selection of specific service function instances and the > >>network > >> >> >>nodes > >> >> >> on which they are provided, thereby forming a service topology: > >> >> >> this is called a Service Function Path. The service functions ma= y > >>be > >> >> >> applied at a specific layer within the network protocol stack > >> >>(network > >> >> >> layer, application layer, etc.). > >> >> >> > >> >> >> The Service Function Chaining (SFC) working group will develop > new > >> >> >> approaches to service delivery and deployment. It will produce a > >> >> >>framework > >> >> >> for service function chaining that includes the necessary > >>protocols > >> >>or > >> >> >> protocol extensions to convey the service path and service path > >> >> >> information to nodes that implement service functions, as well a= s > >> >> >> mechanisms for steering traffic through service functions. The > >> >>working > >> >> >> group will also examine what information needs to be gathered > from > >> >>the > >> >> >> network and service functions in support of service function > >> chaining > >> >> >>and > >> >> >> how that information may be made available to nodes that > implement > >> >>the > >> >> >> service functions. > >> >> >> > >> >> >> Specifically, the SFC WG is chartered to deliver the following: > >> >> >> > >> >> >> 1) Problem Statement: This document will provide a summary of th= e > >> >> >> problem space to be addressed by the WG including example > >>high- > >> >> >> level use cases. Additionally, the WG will normalize > >> nomenclature > >> >> >> and definitions for service function chaining. > >> >> >> > >> >> >> 2) Architecture: This document will provide a description of the > >> >> >> architectural building blocks and their relationships > >>including > >> >> >> interconnection, placement of capabilities, management, > >> >> >> diagnostics, design analysis, and security models, as well a= s > >> >> >> requirements on the protocol mechanisms. > >> >> >> > >> >> >> 3) Generic Service Function Chaining Encapsulation: A document > >>will > >> >> >> describe the single service-level data plane encapsulation > >> format > >> >> >>for > >> >> >> conveying the service function chain and the service functio= n > >> >>path, > >> >> >> and for communicating context information between nodes that > >> >> >> implement service functions. It is intended that the > >> >>encapsulation > >> >> >> be agnostic to the layer at which it is applied and the > >>service > >> >> that > >> >> >> is > >> >> >> being constructed. That is, the same encapsulation may be > used > >> on > >> >> >> a service function path realized at the network layer or at > >>any > >> >> >>other > >> >> >> layer, and the same encapsulation will apply for the > >> construction > >> >> of > >> >> >> service function paths regardless of the actual service. > >> >> >> > >> >> >> 4) Control Plane Mechanisms: A set of documents will be develope= d > >>to > >> >> >> describe requirements and protocols necessary to convey > >> >>information > >> >> >> to service function implementation points. Where possible, > >> >>existing > >> >> >> IETF protocols will be used and extended. All protocol > >> extensions > >> >> >> work should be carried out in the working groups responsible > >>for > >> >> the > >> >> >> protocols being modified in coordination with this working > >> group, > >> >> >>but > >> >> >> may be done in this working group after agreement with all > the > >> >> >> relevant WG chairs and responsible ADs. > >> >> >> > >> >> >> 5) Manageability: Work on the management and configuration of > >> service > >> >> >> functions in support of SFC components will certainly be > >>needed, > >> >> >> but first needs to be better understood and scoped. > >> >> >> > >> >> >> Proposed Milestones > >> >> >> > >> >> >> Apr 2014 Submit to IESG Informational document(s) defining the > >> >>problem > >> >> >> statement and core use cases for Service Function Chaining > >> >> >> > >> >> >> May 2014 Consult with OPS Area on possible charter modifications > >>for > >> >> >> management and configuration of SFC components > >> >> >> > >> >> >> Jan 2015 Submit to IESG Informational document defining the > >> >> architecture > >> >> >> for SFC > >> >> >> > >> >> >> Jan 2015 Submit to IESG requirements for a generic service > >>function > >> >> >> chaining encapsulation protocol > >> >> >> > >> >> >> Aug 2015 Submit to IESG Standards Track document specifying the > >> >>generic > >> >> >> service function chaining header encapsulation > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> Thomas > >> >> >> > >> >> >> _______________________________________________ > >> >> >> nsc mailing list > >> >> >> nsc@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >> >> _______________________________________________ > >> >> >> nsc mailing list > >> >> >> nsc@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >> >> _______________________________________________ > >> >> >> nsc mailing list > >> >> >> nsc@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/nsc > >> >> >_______________________________________________ > >> >> >nsc mailing list > >> >> >nsc@ietf.org > >> >> >https://www.ietf.org/mailman/listinfo/nsc > >> > > > > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 09:02:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FA421E8283 for ; Tue, 12 Nov 2013 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mZINiLq0T1J for ; Tue, 12 Nov 2013 09:02:41 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 730DE21E82AB for ; Tue, 12 Nov 2013 09:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24878; q=dns/txt; s=iport; t=1384275756; x=1385485356; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=7x8ewgFFxFzmxAL8+XsiTRP5vHu/5s7xfW/ybTKbX4Y=; b=aAAYDXRhBPoLYTwlTb8QaTUzoYzAAbuI8tea+Hl9cHg45GGhG1/bWQus jv2L3O162mplH/Q8LVk4G/oL4SKEtFlbZ6b0liYdg2yXmGCx3TSGbFHZz QgHPSRVgjTTVwHAc1xaF+rXKT5devHzzfmiirZxcStS9XkfaAoivCT69y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPBdglKtJXG//2dsb2JhbABQCoMHOFO/FoEqFnSCJQEBAQQBAQEXDRMrAgcEEwYBCBEBAwEBARUJCS4LFAMGCAIEAQkJCRKHZg2/EY4cBAYGgQgtBQIEBIQnA5Qug2GSCoMmgWgBCBci X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283587151" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 12 Nov 2013 17:02:34 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rACH2YIR018189 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:02:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:02:33 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , "Sumandra Majee" , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAIAAGzeggAAVzQA= Date: Tue, 12 Nov 2013 17:02:33 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B028026108@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:02:45 -0000 Hi Kevin, It is implementation specific. For instance PCRF can be stateful and hence does not have to reclassify on the return path. However, as an architecture we should not prevent a different chain to be applied in the reverse path for those exceptional use cases. The example I used does indeed equate to a re-classification at the branching point as traffic is forwarded into a *new* chain. On 11/12/13 11:46 AM, "Kevin J Ma" wrote: >Hi Jim, > > In the example you have below, does the PCRF have to be concerned > about reverse-mapping on the return path? Or would the return path > be handled independently, classifying to a different set of chains? > > In the example below, branching does equate to re-classification? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Tuesday, November 12, 2013 9:07 AM >> To: Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Sumandra Majee; >> Thomas Narten; nsc@ietf.org >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Hi Kevin, >> >> Let me try and provide a concrete example to see if this answers your >> specific question: >> >> Use case: P-GW -> PCRF -> services applied to traffic based on >> applicationID and subscriberID. >> >> Instantiated as: >> >> SFC1: P-GW -> DPI -> PCRF >> SFC2: PCRF -> video-optimization -> metering -> FW >> SFC3: PCRF -> parental-control -> metering -> FW >> >> In this case DPI is performed on SFC1 and identifies applicationID. The >> applicationID is carried in the service encapsulation to PCRF. PCRF uses >> solution specific logic (identifies subscriber, applies policies, etc) >>and >> uses the result along with the applicationID received from DPI to select >> an outbound service chain, SFC2 or SFC3. Note that in this case >>branching >> occurs from SFC1 to either SFC2 or SFC3. >> >> >> >> >> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >> >> >> Yes, reclassification can change the service path and >> >> re-classification may happen at any node along a service path. >> > >> >Just to expand on that, going back to the original question about >> >service header encapsulation, is it intended that a chain that >> >is re-classified will get a new chain ID which fully describes >> >a chain that is a superset of the original chain ID, prior to >> >DPI-based re-classification? (assuming the goal is "a single >> >chain ID that is commonly understood along the entire service chain" >> >http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> > >> >And the applicable subset of the permutative list of service >> >paths would be configured at each appropriate service node? >> >e.g., ID 1: NAT + firewall + DPI >> > ID 2: NAT + firewall + DPI + AV >> > ID 3: NAT + firewall + DPI + AV + NAT >> > ID 4: NAT + firewall + DPI + NAT >> > ID 5: NAT + firewall + DPI + AV + LB >> > ID 6: NAT + firewall + DPI + LB >> > ID 7: NAT + firewall + DPI + LB + CACHE >> > ID 8: NAT + firewall + DPI + CACHE >> > ID 9: NAT + firewall + DPI + optimizer + LB >> > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> > ID 11: NAT + firewall + DPI + optimizer + CACHE >> >Would every flow then be initially classified as ID 1, but >> >eventually get re-classified to ID 2-11, after the DPI phase? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>nsc@ietf.org >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >> >> >> >> >Hi Surendra, >> >> > >> >> > Classification may be out of scope, but the level of service that >>is >> >> > applicable is dependent upon the level of classification that can >>be >> >> > performed. An assumption of packet level encapsulation has >> >> implications >> >> > on the level of classification being performed? If the stated >>goals >> >> are >> >> > for firewall and load balancer functionality, then the application >> >> level >> >> > nature of those functions needs to be taken into account? If, on >> the >> >> > other hand, the service function scope is limited due to >>limitations >> >>in >> >> > classification, that would be and important piece of information? >> >> > >> >> > Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >> >>points >> >> > of the service paths seem like re-classification points? Is that >> the >> >> > interpretation from the architecture perspective? Or is the >>service >> >> > function chain classification exclusive of DPI functionality? >> >> I have not fully read that draft yet. But in general, as >>described >> >>in >> >> the arch draft, the collection of services form a graph, segments of >> >>which >> >> are service paths. Yes, reclassification can change the service path >> and >> >> re-classification may happen at any node along a service path. >> >> >> >> Surendra. >> >> > >> >> >thanx. >> >> > >> >> >-- Kevin J. Ma >> >> > >> >> >> -----Original Message----- >> >> >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> >> Sent: Tuesday, November 12, 2013 12:08 AM >> >> >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >>nsc@ietf.org >> >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> Kevin, >> >> >> >> >> >> Classification mechanism is outside the scope of SFC. It can be >> based >> >> on >> >> >> the packet or information not in the packet(environmental >>attributes >> >> for >> >> >> instance) or a combination thereof. What is important is that such >> >> >> classification aids in traffic selection and service path >> >> >>identification. >> >> >> It is no different from a policy in this regard except that the >> >>policy >> >> >>now >> >> >> specifies the service path. >> >> >> Further, classification is not limited to the network elements but >> >>the >> >> >> service functions as well. Some of this is described in the >> >> architecture >> >> >> drafts as well - >> >> >>"https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> >> >> >> >> Surendra. >> >> >> >> >> >> On 11/11/13 7:33 PM, "Kevin J Ma" >>wrote: >> >> >> >> >> >> >Hi Ron, >> >> >> > >> >> >> > I was unable to make the SFC BoF due to a conflict with CDNI, >>but >> >>I >> >> >> > had a similar question wrt bullet 11 in section 2 of the >>problem >> >> >> >statement: >> >> >> > >> >> >> > 11. Per-Service (re)Classification: Classification occurs at >> >>each >> >> >> > service, independent from previously applied service >> >> >>functions. >> >> >> > These unrelated classification events consume resources >> per >> >> >> > service. More importantly, the classification >> >>functionality >> >> >> > often differs per service function and service function >> >> cannot >> >> >> > leverage the results from other deployed network or >> >>service. >> >> >> > >> >> >> > as it relates to section 5.2 of the framework document: >> >> >> > >> >> >> > The SFC Classifier classifies packets based on (some of) the >> >> >>contents >> >> >> > of the packet header. Concretely, it classifies packets >>based >> >>on >> >> >>the >> >> >> > possible combination of one or more header fields, such as >> >>source >> >> >> > address, destination address, DS field, protocol ID, source >> port >> >> >>and >> >> >> > destination port numbers, and any other information. >> >> >> > >> >> >> > A packet-based classifier as described in the framework >>document >> >> >>would >> >> >> > seem to be limited in what it can classify? The service >>function >> >> >> > identifier lookup does not seem to be a significant >>optimization >> >> over >> >> >> > a packet-based 5-tuple lookup? There seems to be some missing >> >> detail >> >> >> > wrt how classification information is determined and reused? >> >> >> > >> >> >> > When thinking about higher level services, e.g., HTTP and TLS >> >> >>encrypted >> >> >> > flows, a packet-based classifier seems inadequate? I was also >> >> >> wondering >> >> >> > how independent HLS segment requests might be classified and >> >> >> associated? >> >> >> > Were these types of use cases discussed in the BoF? >> >> >> > >> >> >> >thanx. >> >> >> > >> >> >> >-- Kevin J. Ma >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> >>Ron >> >> >> >> Parker >> >> >> >> Sent: Monday, November 11, 2013 10:16 PM >> >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> >> >> As was discussed in Vancouver, there are already many existing >> >>ways >> >> >>to >> >> >> >> accomplish service chaining. But none of them provide a >> >> >>sufficient >> >> >> >> combination of interoperability, flexibility, and resiliency. >> A >> >> >> single >> >> >> >> service chain encapsulation will go a long way to ensuring >>these >> >> >>goals. >> >> >> >> It may not be the absolutely most efficient approach for every >> >> >>single >> >> >> >> network topology and every single use case, but its ubiquitous >> >> nature >> >> >> >> should improve its adoption. >> >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> >> >> Sent: Monday, November 11, 2013 10:10 PM >> >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Ron, >> >> >> >> >> >> >> >> Absolutely, that was an example of one type of derivation. >> However >> >> >>this >> >> >> >> could be augmented with classification result, again one more >> >> >>example. >> >> >> >> >> >> >> >> >>All flows from the same source IP do not necessarily follow >>the >> >> >>same >> >> >> >> chain. >> >> >> >> Correct. It is also not necessary that all transaction of the >> same >> >> >>flow >> >> >> >> follow the same chain either. So why stop at flow itself. >> >> >> >> >> >> >> >> Again the point here is that do we always need SFC header or >>Not. >> >> >> >> >> >> >> >> Sumandra >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> >> >> Sent: Monday, November 11, 2013 7:02 PM >> >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> >> >> The intention of service function chaining is to allow for >> >>operation >> >> >>at >> >> >> >> the fully qualified flow level, or even finer grained at the >> >> >> transaction >> >> >> >> level (this is an implementation matter for the PDP). All >> >>flows >> >> >> from >> >> >> >> the same source IP do not necessarily follow the same chain. >> >> Source >> >> >> >>IP, >> >> >> >> therefore, does not identify the chain ID. Another >>intention >> >>of >> >> >> >> service function chaining is to operate over any network >>topology >> >> and >> >> >> >>not >> >> >> >> be limited to a single LAN. Thus, while VLAN may be part of >>the >> >> >> >> transport, it does not adequately identify the service chain, >> >> either. >> >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> >> >> Sent: Monday, November 11, 2013 9:56 PM >> >> >> >> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Ron, >> >> >> >> >> >> >> >> The service header is meant to carry the context which can >>*also* >> >>be >> >> >> >> derived (for example use source ip and vlan to identify chainID >> >>and >> >> >> >> position) or encapsulated as part of another tunnel header. So >> >>this >> >> >> >>could >> >> >> >> be optional IMHO. >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> >> >> Sent: Monday, November 11, 2013 4:36 PM >> >> >> >> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Sumandra, >> >> >> >> >> >> >> >> As I understand it, an SFC packet traversing from PDP to SF or >> >>from >> >> >>SF >> >> >> >>to >> >> >> >> SF will look like: >> >> >> >> >> >> >> >> +------------------------+ >> >> >> >> | "transport" | >> >> >> >> +------------------------+ >> >> >> >> | service header | >> >> >> >> +------------------------+ >> >> >> >> | original IP header | >> >> >> >> +------------------------+ >> >> >> >> | | original IP >>payload >> >>| >> >> >> >> | | >> >> >> >> +------------------------+ >> >> >> >> >> >> >> >> Where service header contains, at a minimum, enough information >> to >> >> >> allow >> >> >> >> the packet to be propagated along the full length of the chain, >> >>and >> >> >> >> optionally, other metadata that enhances the operation of one >>or >> >> more >> >> >> >> service functions. >> >> >> >> >> >> >> >> And where "transport" could conceivably be any of, but not >> >>limited >> >> >>to: >> >> >> >> >> >> >> >> * Ethernet >> >> >> >> * Ethernet + LLC2 >> >> >> >> * Ethernet + MPLS >> >> >> >> * Ethernet + IP + GRE >> >> >> >> * Ethernet + IP +UDP >> >> >> >> >> >> >> >> >> >> >> >> Also, "original" in the diagram above is not meant to imply >> >> >> >>immutability, >> >> >> >> but rather to specify the packet that is propagated from >> preceding >> >> >> >>entity >> >> >> >> to succeeding entity, prior to encapsulation. >> >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> >> Sumandra Majee >> >> >> >> Sent: Monday, November 11, 2013 6:46 PM >> >> >> >> To: Thomas Narten; nsc@ietf.org >> >> >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Generic Service Function Chaining Encapsulation: A document >>will >> >> >> >> describe the single service-level data plane encapsulation >> >> format >> >> >> >>for >> >> >> >> conveying the service function chain and the service >>function >> >> >>path, >> >> >> >> and for communicating context information between nodes >>that >> >> >> >> implement service functions. It is intended that the >> >> >>encapsulation >> >> >> >> be agnostic to the layer at which it is applied and the >> >>service >> >> >> that >> >> >> >> is >> >> >> >> being constructed. That is, the same encapsulation may be >> used >> >> on >> >> >> >> a service function path realized at the network layer or at >> >>any >> >> >> >>other >> >> >> >> layer, and the same encapsulation will apply for the >> >> construction >> >> >> of >> >> >> >> service function paths regardless of the actual service. >> >> >> >> >> >> >> >> [SM] What does it mean by a single service-level encapsulation, >> a >> >> >>new >> >> >> >> encapsulation format >> >> >> >> or an ability to select one encapsulation format >>that >> >> >>fits >> >> >> >>the >> >> >> >> need for a given service chain? >> >> >> >> The ability to select a specific encapsulation >>would >> >>be >> >> a >> >> >> >> management plane decision. >> >> >> >> There are quite a few existing encapsulation methods >> >>that >> >> >>can >> >> >> >> possibly be reused to provide >> >> >> >> context information between service nodes. I have >> seen >> >> >> >>mention >> >> >> >> of GRE, for HTTP based >> >> >> >> applications contexts are transferred via headers. >> >> >> >> >> >> >> >> >> >> >> >> -----Original Message----- >> >> >> >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> Behalf >> >> Of >> >> >> >> Thomas Narten >> >> >> >> Sent: Wednesday, November 06, 2013 11:07 AM >> >> >> >> To: nsc@ietf.org >> >> >> >> Subject: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >> Hi. >> >> >> >> >> >> >> >> Current charter can be found at >> >> >> >>https://datatracker.ietf.org/doc/charter- >> >> >> >> ietf-sfc/. >> >> >> >> >> >> >> >> It contains the revised management text as well as updated >> >> >>milestones. >> >> >> >> >> >> >> >> All known issues have been addressed. If there are any >>remaining >> >> >> issues, >> >> >> >> please speak up! >> >> >> >> >> >> >> >> Charter charter-ietf-sfc-00-04 >> >> >> >> >> >> >> >> Networks, servers, storage technologies, and applications, have >> >>all >> >> >> >> undergone significant change in recent years with the >> introduction >> >> of >> >> >> >> virtualization, network overlays, and orchestration. Service >> >> delivery >> >> >> is >> >> >> >> currently both a technical and organizational challenge that >> >> involves >> >> >> >> significant modification to the network configuration. >> >> >> >> Services are typically implemented by the ordered combination >>of >> a >> >> >> >>number >> >> >> >> of service functions that are deployed at different points >>within >> >> the >> >> >> >> network. Today, a common deployment model has service functions >> >> >> >>physically >> >> >> >> inserted on the data forwarding path between communicating >>peers. >> >> >>Going >> >> >> >> forward, however, there is a desire to move to a different >>model, >> >> >>where >> >> >> >> service functions are not required to reside on the default >>data >> >> path >> >> >> >>and >> >> >> >> traffic is instead steered through services, wherever they are >> >> >> deployed. >> >> >> >> >> >> >> >> For a given service, the abstracted view of the required >>service >> >> >> >>functions >> >> >> >> and the order in which they are to be applied is called a >>Service >> >> >> >>Function >> >> >> >> Chain (SFC). Since a given service function may be available on >> >>more >> >> >> >>than >> >> >> >> one node within a network, a Service Function Chain is >> >>instantiated >> >> >>via >> >> >> >> the selection of specific service function instances and the >> >>network >> >> >> >>nodes >> >> >> >> on which they are provided, thereby forming a service topology: >> >> >> >> this is called a Service Function Path. The service functions >>may >> >>be >> >> >> >> applied at a specific layer within the network protocol stack >> >> >>(network >> >> >> >> layer, application layer, etc.). >> >> >> >> >> >> >> >> The Service Function Chaining (SFC) working group will develop >> new >> >> >> >> approaches to service delivery and deployment. It will produce >>a >> >> >> >>framework >> >> >> >> for service function chaining that includes the necessary >> >>protocols >> >> >>or >> >> >> >> protocol extensions to convey the service path and service path >> >> >> >> information to nodes that implement service functions, as well >>as >> >> >> >> mechanisms for steering traffic through service functions. The >> >> >>working >> >> >> >> group will also examine what information needs to be gathered >> from >> >> >>the >> >> >> >> network and service functions in support of service function >> >> chaining >> >> >> >>and >> >> >> >> how that information may be made available to nodes that >> implement >> >> >>the >> >> >> >> service functions. >> >> >> >> >> >> >> >> Specifically, the SFC WG is chartered to deliver the following: >> >> >> >> >> >> >> >> 1) Problem Statement: This document will provide a summary of >>the >> >> >> >> problem space to be addressed by the WG including example >> >>high- >> >> >> >> level use cases. Additionally, the WG will normalize >> >> nomenclature >> >> >> >> and definitions for service function chaining. >> >> >> >> >> >> >> >> 2) Architecture: This document will provide a description of >>the >> >> >> >> architectural building blocks and their relationships >> >>including >> >> >> >> interconnection, placement of capabilities, management, >> >> >> >> diagnostics, design analysis, and security models, as well >>as >> >> >> >> requirements on the protocol mechanisms. >> >> >> >> >> >> >> >> 3) Generic Service Function Chaining Encapsulation: A document >> >>will >> >> >> >> describe the single service-level data plane encapsulation >> >> format >> >> >> >>for >> >> >> >> conveying the service function chain and the service >>function >> >> >>path, >> >> >> >> and for communicating context information between nodes >>that >> >> >> >> implement service functions. It is intended that the >> >> >>encapsulation >> >> >> >> be agnostic to the layer at which it is applied and the >> >>service >> >> >> that >> >> >> >> is >> >> >> >> being constructed. That is, the same encapsulation may be >> used >> >> on >> >> >> >> a service function path realized at the network layer or at >> >>any >> >> >> >>other >> >> >> >> layer, and the same encapsulation will apply for the >> >> construction >> >> >> of >> >> >> >> service function paths regardless of the actual service. >> >> >> >> >> >> >> >> 4) Control Plane Mechanisms: A set of documents will be >>developed >> >>to >> >> >> >> describe requirements and protocols necessary to convey >> >> >>information >> >> >> >> to service function implementation points. Where possible, >> >> >>existing >> >> >> >> IETF protocols will be used and extended. All protocol >> >> extensions >> >> >> >> work should be carried out in the working groups >>responsible >> >>for >> >> >> the >> >> >> >> protocols being modified in coordination with this working >> >> group, >> >> >> >>but >> >> >> >> may be done in this working group after agreement with all >> the >> >> >> >> relevant WG chairs and responsible ADs. >> >> >> >> >> >> >> >> 5) Manageability: Work on the management and configuration of >> >> service >> >> >> >> functions in support of SFC components will certainly be >> >>needed, >> >> >> >> but first needs to be better understood and scoped. >> >> >> >> >> >> >> >> Proposed Milestones >> >> >> >> >> >> >> >> Apr 2014 Submit to IESG Informational document(s) defining the >> >> >>problem >> >> >> >> statement and core use cases for Service Function Chaining >> >> >> >> >> >> >> >> May 2014 Consult with OPS Area on possible charter >>modifications >> >>for >> >> >> >> management and configuration of SFC components >> >> >> >> >> >> >> >> Jan 2015 Submit to IESG Informational document defining the >> >> >> architecture >> >> >> >> for SFC >> >> >> >> >> >> >> >> Jan 2015 Submit to IESG requirements for a generic service >> >>function >> >> >> >> chaining encapsulation protocol >> >> >> >> >> >> >> >> Aug 2015 Submit to IESG Standards Track document specifying the >> >> >>generic >> >> >> >> service function chaining header encapsulation >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thomas >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> >> nsc mailing list >> >> >> >> nsc@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> >> _______________________________________________ >> >> >> >> nsc mailing list >> >> >> >> nsc@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> >> _______________________________________________ >> >> >> >> nsc mailing list >> >> >> >> nsc@ietf.org >> >> >> >> https://www.ietf.org/mailman/listinfo/nsc >> >> >> >_______________________________________________ >> >> >> >nsc mailing list >> >> >> >nsc@ietf.org >> >> >> >https://www.ietf.org/mailman/listinfo/nsc >> >> > >> > >> >_______________________________________________ >> >nsc mailing list >> >nsc@ietf.org >> >https://www.ietf.org/mailman/listinfo/nsc > From smkumar@cisco.com Tue Nov 12 09:03:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C0F21E82AD for ; Tue, 12 Nov 2013 09:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwwYgixh+Xc2 for ; Tue, 12 Nov 2013 09:02:58 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AE35B21E82B2 for ; Tue, 12 Nov 2013 09:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24674; q=dns/txt; s=iport; t=1384275777; x=1385485377; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=K+XeINCE5tAHiOfWajS7DVIOnqeafxVD8lI2ujH/48s=; b=YANhbMTSbILiBnTHPP3WeTBsn1hZ5kLJZ3QTrHG4at0ULAT4PiUIsj5P zeNrLLgvi40xfHlSdNfr2XmXF1QZdlzrLJ5Oq8wkc4h5A69F9DT/m9krk b8qujDItSk8Dc3+9GZ6dAfb9fX4bIsNSr0s3CUZ2lkw5vHGY3+bbvQ8AT o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAGNeglKtJXG//2dsb2JhbABQCoMHOFO/FoEqFnSCJQEBAQQBAQEXDRMrAgcEEwYBCA4DAQMBAQEVCQkuCxQDBggCBAEJCQkSh2YNvxaOHAQGBoEILQUCBASEJwOULoNhkgqDJoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283802854" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2013 17:02:56 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rACH2ugd018882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:02:56 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:02:56 -0600 From: "Surendra Kumar (smkumar)" To: Jerome Moisand , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "Kevin J Ma" , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAOe7AIAACW8AgAAH9wD//5mYgA== Date: Tue, 12 Nov 2013 17:02:55 +0000 Message-ID: In-Reply-To: <06825c9329714f04ac0ce09ae995f7ed@BN1PR05MB251.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.85.152] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:03:02 -0000 Jerome, It is at a high level and not a specific implementation. I'm sure there are many of achieving what Jim said. Surendra.=20 On 11/12/13 7:09 AM, "Jerome Moisand" wrote: >No clue what you guys are discussing. > >PCRF (when relevant for a given type of domain, e.g. mobile broadband) >has a role to play in service chaining for sure, but... A PCRF is a >control plane element, not a data plane element. It is not part of a >service chain, it would control (part of) it. > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Joel M. Halpern >Sent: Tuesday, November 12, 2013 9:41 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Jim, thank you for a concrete example. >I would suggest that in the usual cases, there is a better way to handle >this than branching and rewriting at the PCRF. > >If the DPI engine or PCRF logic (whichever makes the decision) notifies >the control logic about the decision for the flow, then the ingress can >direct subsequent packets to the correct place, avoiding needless >processing of further packets in the DPI and PCRF logic. >Further, the needed control information can be passed to the optimization >or parental control so that it does not matter where the first packet is >sent, avoiding the need for the PCRF to understand how to direct packets >to service paths. > >Yours, >Joel > >On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >> Hi Kevin, >> >> Let me try and provide a concrete example to see if this answers your >> specific question: >> >> Use case: P-GW -> PCRF -> services applied to traffic based on >> applicationID and subscriberID. >> >> Instantiated as: >> >> SFC1: P-GW -> DPI -> PCRF >> SFC2: PCRF -> video-optimization -> metering -> FW >> SFC3: PCRF -> parental-control -> metering -> FW >> >> In this case DPI is performed on SFC1 and identifies applicationID. >> The applicationID is carried in the service encapsulation to PCRF. >> PCRF uses solution specific logic (identifies subscriber, applies >> policies, etc) and uses the result along with the applicationID >> received from DPI to select an outbound service chain, SFC2 or SFC3. >> Note that in this case branching occurs from SFC1 to either SFC2 or >>SFC3. >> >> >> >> >> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >> >>>> Yes, reclassification can change the service path and >>>> re-classification may happen at any node along a service path. >>> >>> Just to expand on that, going back to the original question about >>> service header encapsulation, is it intended that a chain that is >>> re-classified will get a new chain ID which fully describes a chain >>> that is a superset of the original chain ID, prior to DPI-based >>> re-classification? (assuming the goal is "a single chain ID that is >>> commonly understood along the entire service chain" >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>> >>> And the applicable subset of the permutative list of service paths >>> would be configured at each appropriate service node? >>> e.g., ID 1: NAT + firewall + DPI >>> ID 2: NAT + firewall + DPI + AV >>> ID 3: NAT + firewall + DPI + AV + NAT >>> ID 4: NAT + firewall + DPI + NAT >>> ID 5: NAT + firewall + DPI + AV + LB >>> ID 6: NAT + firewall + DPI + LB >>> ID 7: NAT + firewall + DPI + LB + CACHE >>> ID 8: NAT + firewall + DPI + CACHE >>> ID 9: NAT + firewall + DPI + optimizer + LB >>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >>> flow then be initially classified as ID 1, but eventually get >>> re-classified to ID 2-11, after the DPI phase? >>> >>> thanx. >>> >>> -- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> nsc@ietf.org >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >>>> >>>> >>>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>> >>>>> Hi Surendra, >>>>> >>>>> Classification may be out of scope, but the level of service that >>>>>is >>>>> applicable is dependent upon the level of classification that can >>>>>be >>>>> performed. An assumption of packet level encapsulation has >>>> implications >>>>> on the level of classification being performed? If the stated >>>>> goals >>>> are >>>>> for firewall and load balancer functionality, then the >>>>> application >>>> level >>>>> nature of those functions needs to be taken into account? If, on >>>>>the >>>>> other hand, the service function scope is limited due to >>>>> limitations >>>> in >>>>> classification, that would be and important piece of information? >>>>> >>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>> points >>>>> of the service paths seem like re-classification points? Is that >>>>>the >>>>> interpretation from the architecture perspective? Or is the >>>>>service >>>>> function chain classification exclusive of DPI functionality? >>>> I have not fully read that draft yet. But in general, as >>>> described in the arch draft, the collection of services form a >>>> graph, segments of which are service paths. Yes, reclassification >>>> can change the service path and re-classification may happen at any >>>> node along a service path. >>>> >>>> Surendra. >>>>> >>>>> thanx. >>>>> >>>>> -- Kevin J. Ma >>>>> >>>>>> -----Original Message----- >>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>> >>>>>> Kevin, >>>>>> >>>>>> Classification mechanism is outside the scope of SFC. It can be >>>>>> based >>>> on >>>>>> the packet or information not in the packet(environmental >>>>>> attributes >>>> for >>>>>> instance) or a combination thereof. What is important is that such >>>>>> classification aids in traffic selection and service path >>>>>> identification. >>>>>> It is no different from a policy in this regard except that the >>>> policy >>>>>> now >>>>>> specifies the service path. >>>>>> Further, classification is not limited to the network elements but >>>> the >>>>>> service functions as well. Some of this is described in the >>>> architecture >>>>>> drafts as well - >>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>> >>>>>> Surendra. >>>>>> >>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>> >>>>>>> Hi Ron, >>>>>>> >>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >>>>>>> but >>>> I >>>>>>> had a similar question wrt bullet 11 in section 2 of the >>>>>>> problem >>>>>>> statement: >>>>>>> >>>>>>> 11. Per-Service (re)Classification: Classification occurs at >>>> each >>>>>>> service, independent from previously applied service >>>>>> functions. >>>>>>> These unrelated classification events consume resources >>>>>>>per >>>>>>> service. More importantly, the classification >>>> functionality >>>>>>> often differs per service function and service function >>>> cannot >>>>>>> leverage the results from other deployed network or >>>> service. >>>>>>> >>>>>>> as it relates to section 5.2 of the framework document: >>>>>>> >>>>>>> The SFC Classifier classifies packets based on (some of) the >>>>>> contents >>>>>>> of the packet header. Concretely, it classifies packets >>>>>>> based >>>> on >>>>>> the >>>>>>> possible combination of one or more header fields, such as >>>> source >>>>>>> address, destination address, DS field, protocol ID, source >>>>>>> port >>>>>> and >>>>>>> destination port numbers, and any other information. >>>>>>> >>>>>>> A packet-based classifier as described in the framework >>>>>>> document >>>>>> would >>>>>>> seem to be limited in what it can classify? The service function >>>>>>> identifier lookup does not seem to be a significant >>>>>>> optimization >>>> over >>>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>>> detail >>>>>>> wrt how classification information is determined and reused? >>>>>>> >>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>> encrypted >>>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>>> wondering >>>>>>> how independent HLS segment requests might be classified and >>>>>> associated? >>>>>>> Were these types of use cases discussed in the BoF? >>>>>>> >>>>>>> thanx. >>>>>>> >>>>>>> -- Kevin J. Ma >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Ron >>>>>>>> Parker >>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As was discussed in Vancouver, there are already many existing >>>> ways >>>>>> to >>>>>>>> accomplish service chaining. But none of them provide a >>>>>> sufficient >>>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>>> single >>>>>>>> service chain encapsulation will go a long way to ensuring these >>>>>> goals. >>>>>>>> It may not be the absolutely most efficient approach for every >>>>>> single >>>>>>>> network topology and every single use case, but its ubiquitous >>>> nature >>>>>>>> should improve its adoption. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>> However >>>>>> this >>>>>>>> could be augmented with classification result, again one more >>>>>> example. >>>>>>>> >>>>>>>>>> All flows from the same source IP do not necessarily follow >>>>>>>>>> the >>>>>> same >>>>>>>> chain. >>>>>>>> Correct. It is also not necessary that all transaction of the >>>>>>>> same >>>>>> flow >>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>> >>>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>>> >>>>>>>> Sumandra >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> The intention of service function chaining is to allow for >>>> operation >>>>>> at >>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>> transaction >>>>>>>> level (this is an implementation matter for the PDP). All >>>> flows >>>>>> from >>>>>>>> the same source IP do not necessarily follow the same chain. >>>> Source >>>>>>>> IP, >>>>>>>> therefore, does not identify the chain ID. Another intention >>>> of >>>>>>>> service function chaining is to operate over any network >>>>>>>> topology >>>> and >>>>>>>> not >>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>>> transport, it does not adequately identify the service chain, >>>> either. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> The service header is meant to carry the context which can >>>>>>>> *also* >>>> be >>>>>>>> derived (for example use source ip and vlan to identify chainID >>>> and >>>>>>>> position) or encapsulated as part of another tunnel header. So >>>> this >>>>>>>> could >>>>>>>> be optional IMHO. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>> from >>>>>> SF >>>>>>>> to >>>>>>>> SF will look like: >>>>>>>> >>>>>>>> +------------------------+ >>>>>>>> | "transport" | >>>>>>>> +------------------------+ >>>>>>>> | service header | >>>>>>>> +------------------------+ >>>>>>>> | original IP header | >>>>>>>> +------------------------+ >>>>>>>> | | original IP payload >>>> | >>>>>>>> | | >>>>>>>> +------------------------+ >>>>>>>> >>>>>>>> Where service header contains, at a minimum, enough information >>>>>>>> to >>>>>> allow >>>>>>>> the packet to be propagated along the full length of the chain, >>>> and >>>>>>>> optionally, other metadata that enhances the operation of one or >>>> more >>>>>>>> service functions. >>>>>>>> >>>>>>>> And where "transport" could conceivably be any of, but not >>>> limited >>>>>> to: >>>>>>>> >>>>>>>> * Ethernet >>>>>>>> * Ethernet + LLC2 >>>>>>>> * Ethernet + MPLS >>>>>>>> * Ethernet + IP + GRE >>>>>>>> * Ethernet + IP +UDP >>>>>>>> >>>>>>>> >>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>> immutability, but rather to specify the packet that is >>>>>>>> propagated from preceding entity to succeeding entity, prior to >>>>>>>> encapsulation. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Sumandra Majee >>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service >>>>>>>> function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>> used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> [SM] What does it mean by a single service-level encapsulation, >>>>>>>> a >>>>>> new >>>>>>>> encapsulation format >>>>>>>> or an ability to select one encapsulation format >>>>>>>> that >>>>>> fits >>>>>>>> the >>>>>>>> need for a given service chain? >>>>>>>> The ability to select a specific encapsulation >>>>>>>> would >>>> be >>>> a >>>>>>>> management plane decision. >>>>>>>> There are quite a few existing encapsulation methods >>>> that >>>>>> can >>>>>>>> possibly be reused to provide >>>>>>>> context information between service nodes. I have >>>>>>>>seen >>>>>>>> mention >>>>>>>> of GRE, for HTTP based >>>>>>>> applications contexts are transferred via headers. >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Thomas Narten >>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>> To: nsc@ietf.org >>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Hi. >>>>>>>> >>>>>>>> Current charter can be found at >>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>> ietf-sfc/. >>>>>>>> >>>>>>>> It contains the revised management text as well as updated >>>>>> milestones. >>>>>>>> >>>>>>>> All known issues have been addressed. If there are any remaining >>>>>> issues, >>>>>>>> please speak up! >>>>>>>> >>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>> >>>>>>>> Networks, servers, storage technologies, and applications, have >>>> all >>>>>>>> undergone significant change in recent years with the >>>>>>>> introduction >>>> of >>>>>>>> virtualization, network overlays, and orchestration. Service >>>> delivery >>>>>> is >>>>>>>> currently both a technical and organizational challenge that >>>> involves >>>>>>>> significant modification to the network configuration. >>>>>>>> Services are typically implemented by the ordered combination of >>>>>>>> a number of service functions that are deployed at different >>>>>>>> points within >>>> the >>>>>>>> network. Today, a common deployment model has service functions >>>>>>>> physically inserted on the data forwarding path between >>>>>>>> communicating peers. >>>>>> Going >>>>>>>> forward, however, there is a desire to move to a different >>>>>>>> model, >>>>>> where >>>>>>>> service functions are not required to reside on the default data >>>> path >>>>>>>> and >>>>>>>> traffic is instead steered through services, wherever they are >>>>>> deployed. >>>>>>>> >>>>>>>> For a given service, the abstracted view of the required service >>>>>>>> functions and the order in which they are to be applied is >>>>>>>> called a Service Function Chain (SFC). Since a given service >>>>>>>> function may be available on >>>> more >>>>>>>> than >>>>>>>> one node within a network, a Service Function Chain is >>>> instantiated >>>>>> via >>>>>>>> the selection of specific service function instances and the >>>> network >>>>>>>> nodes >>>>>>>> on which they are provided, thereby forming a service topology: >>>>>>>> this is called a Service Function Path. The service functions >>>>>>>> may >>>> be >>>>>>>> applied at a specific layer within the network protocol stack >>>>>> (network >>>>>>>> layer, application layer, etc.). >>>>>>>> >>>>>>>> The Service Function Chaining (SFC) working group will develop >>>>>>>> new approaches to service delivery and deployment. It will >>>>>>>> produce a framework for service function chaining that includes >>>>>>>> the necessary >>>> protocols >>>>>> or >>>>>>>> protocol extensions to convey the service path and service path >>>>>>>> information to nodes that implement service functions, as well >>>>>>>> as mechanisms for steering traffic through service functions. >>>>>>>> The >>>>>> working >>>>>>>> group will also examine what information needs to be gathered >>>>>>>> from >>>>>> the >>>>>>>> network and service functions in support of service function >>>> chaining >>>>>>>> and >>>>>>>> how that information may be made available to nodes that >>>>>>>> implement >>>>>> the >>>>>>>> service functions. >>>>>>>> >>>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>>> >>>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>>> problem space to be addressed by the WG including example >>>> high- >>>>>>>> level use cases. Additionally, the WG will normalize >>>> nomenclature >>>>>>>> and definitions for service function chaining. >>>>>>>> >>>>>>>> 2) Architecture: This document will provide a description of the >>>>>>>> architectural building blocks and their relationships >>>> including >>>>>>>> interconnection, placement of capabilities, management, >>>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>>> requirements on the protocol mechanisms. >>>>>>>> >>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>>> will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service >>>>>>>> function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>> used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>> developed >>>> to >>>>>>>> describe requirements and protocols necessary to convey >>>>>> information >>>>>>>> to service function implementation points. Where possible, >>>>>> existing >>>>>>>> IETF protocols will be used and extended. All protocol >>>> extensions >>>>>>>> work should be carried out in the working groups >>>>>>>> responsible >>>> for >>>>>> the >>>>>>>> protocols being modified in coordination with this working >>>> group, >>>>>>>> but >>>>>>>> may be done in this working group after agreement with all >>>>>>>>the >>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>> >>>>>>>> 5) Manageability: Work on the management and configuration of >>>> service >>>>>>>> functions in support of SFC components will certainly be >>>> needed, >>>>>>>> but first needs to be better understood and scoped. >>>>>>>> >>>>>>>> Proposed Milestones >>>>>>>> >>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>>> problem >>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>> >>>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>>> for >>>>>>>> management and configuration of SFC components >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>> architecture >>>>>>>> for SFC >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>> function >>>>>>>> chaining encapsulation protocol >>>>>>>> >>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>>> generic >>>>>>>> service function chaining header encapsulation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > > From smkumar@cisco.com Tue Nov 12 09:09:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A622711E810D for ; Tue, 12 Nov 2013 09:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfec2a-Hu-I1 for ; Tue, 12 Nov 2013 09:09:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 95D2011E810B for ; Tue, 12 Nov 2013 09:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25164; q=dns/txt; s=iport; t=1384276172; x=1385485772; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XUHX32BW1PUo0zHUJZlGD2UYqToBqxKdvANTM/CcNhw=; b=lui4AWijmKOIedYiTSEqO/aJGbtHluYk0E0TRWqZU8NZBdk2i/0EV+ou a7yGM4XzUgFKeHOrKK+5JN6q2A49QUTP0kzr2R+wdi88Eb1CRYvvZc1/1 25UK082BLefWnyiJclv9/IvQWI6aH2IibTJRBZGgq2vgufEwJWQ303L7F I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAMdfglKtJV2Y/2dsb2JhbABQCoMHOFO/FoEqFnSCJQEBAQQBAQEXDRMrAgcEBwwGAQgRAQMBAQEVCQkuCxQDBggCBAEJBAUJh3gNvxmOHAQBBQaBAAgrAgUCBASEJwOULoNhkgqDJoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283746531" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 12 Nov 2013 17:09:26 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACH9PmQ005902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:09:25 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:09:25 -0600 From: "Surendra Kumar (smkumar)" To: Linda Dunbar , Ron Parker , "Hongyu Li (Julio)" , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAL/tAIAAA3OAgAAm0oCAABXAAP//lJkA Date: Tue, 12 Nov 2013 17:09:25 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645C053AE@dfweml509-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.8.130913 x-originating-ip: [10.21.85.152] Content-Type: text/plain; charset="us-ascii" Content-ID: <8CE87B1D40B59949908C97B163F524A5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:09:37 -0000 On 11/12/13 7:33 AM, "Linda Dunbar" wrote: >Ron,=20 > >First, want to make it clear that "branching" !=3D reclassification, agree= ? branching is a result of reclassification. > >Second, the representation of branching (or service graph) can be in a >form of logic on a service function. Some service functions, especially >L7 based, can use value in a Database to determine what is the next >service function. that is reclassification, no matter how you do it. Your classification may be as simple as "all traffic coming in service path x -> service path-y". Surendra. >=20 > >Linda > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Ron Parker >> Sent: Tuesday, November 12, 2013 8:16 AM >> To: Hongyu Li (Julio); Kevin J Ma >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Hongyu, >>=20 >> I agree completely that re-classification is not limited to DPI. >>=20 >> And also, that an area for us to explore as a group is how to represent >> the service graph. Do we want to represent it as a proper graph with >> an adjacency list or other representational model? Or, do we want to >> represent it as a set of linear segments and if so, how are the >> segments connected into a graph? Other ideas? >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Hongyu Li (Julio) >> Sent: Tuesday, November 12, 2013 6:57 AM >> To: Ron Parker; Kevin J Ma >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Branching/forking is a very interesting topic of SFC. About the re- >> classification point, probably we shall not limit it to DPI. It is also >> possible that packets go to different branches after been processed by >> a certain service function, decision of which branches to go is made >> based on the result of service function's process, i.e. not just re- >> classification by DPI. >>=20 >> Hongyu >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Ron Parker >> Sent: Tuesday, November 12, 2013 7:45 PM >> To: Kevin J Ma >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Hi, Kevin >>=20 >> You ask a great question about branching the graph. The details around >> how to convey the selection of the subtree/subgraph are still to be >> defined. Is it one chain id for the whole graph? Does each branch >> have its own chain id? Some combination? >>=20 >> Ron >>=20 >> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> wrote: >>=20 >> >> Yes, reclassification can change the service path and >> >> re-classification may happen at any node along a service path. >> > >> > Just to expand on that, going back to the original question about >> > service header encapsulation, is it intended that a chain that is >> > re-classified will get a new chain ID which fully describes a chain >> > that is a superset of the original chain ID, prior to DPI-based >> > re-classification? (assuming the goal is "a single chain ID that is >> > commonly understood along the entire service chain" >> > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> > >> > And the applicable subset of the permutative list of service paths >> > would be configured at each appropriate service node? >> > e.g., ID 1: NAT + firewall + DPI >> > ID 2: NAT + firewall + DPI + AV >> > ID 3: NAT + firewall + DPI + AV + NAT >> > ID 4: NAT + firewall + DPI + NAT >> > ID 5: NAT + firewall + DPI + AV + LB >> > ID 6: NAT + firewall + DPI + LB >> > ID 7: NAT + firewall + DPI + LB + CACHE >> > ID 8: NAT + firewall + DPI + CACHE >> > ID 9: NAT + firewall + DPI + optimizer + LB >> > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every flow >> > then be initially classified as ID 1, but eventually get re- >> classified >> > to ID 2-11, after the DPI phase? >> > >> > thanx. >> > >> > -- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >> nsc@ietf.org >> >> Subject: Re: [nsc] Current Proposed SFC charter >> >> >> >> >> >> >> >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >> >>> >> >>> Hi Surendra, >> >>> >> >>> Classification may be out of scope, but the level of service that >> is >> >>> applicable is dependent upon the level of classification that can >> be >> >>> performed. An assumption of packet level encapsulation has >> >> implications >> >>> on the level of classification being performed? If the stated >> goals >> >> are >> >>> for firewall and load balancer functionality, then the application >> >> level >> >>> nature of those functions needs to be taken into account? If, on >> >>> the other hand, the service function scope is limited due to >> >>> limitations in classification, that would be and important piece of >> information? >> >>> >> >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >> >>> points of the service paths seem like re-classification points? Is >> >>> that the interpretation from the architecture perspective? Or is >> >>> the service function chain classification exclusive of DPI >> functionality? >> >> I have not fully read that draft yet. But in general, as >> >> described in the arch draft, the collection of services form a graph, >> >> segments of which are service paths. Yes, reclassification can >> change >> >> the service path and re-classification may happen at any node along >> a service path. >> >> >> >> Surendra. >> >>> >> >>> thanx. >> >>> >> >>> -- Kevin J. Ma >> >>> >> >>>> -----Original Message----- >> >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >>>> nsc@ietf.org >> >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >>>> >> >>>> Kevin, >> >>>> >> >>>> Classification mechanism is outside the scope of SFC. It can be >> >>>> based >> >> on >> >>>> the packet or information not in the packet(environmental >> >>>> attributes >> >> for >> >>>> instance) or a combination thereof. What is important is that such >> >>>> classification aids in traffic selection and service path >> >>>> identification. >> >>>> It is no different from a policy in this regard except that the >> >>>> policy now specifies the service path. >> >>>> Further, classification is not limited to the network elements but >> >>>> the service functions as well. Some of this is described in the >> >> architecture >> >>>> drafts as well - >> >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >>>> >> >>>> Surendra. >> >>>> >> >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> wrote: >> >>>>> >> >>>>> Hi Ron, >> >>>>> >> >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but >> >>>>> I had a similar question wrt bullet 11 in section 2 of the >> problem >> >>>>> statement: >> >>>>> >> >>>>> 11. Per-Service (re)Classification: Classification occurs at >> each >> >>>>> service, independent from previously applied service >> >>>> functions. >> >>>>> These unrelated classification events consume resources >> per >> >>>>> service. More importantly, the classification >> functionality >> >>>>> often differs per service function and service function >> >> cannot >> >>>>> leverage the results from other deployed network or >> service. >> >>>>> >> >>>>> as it relates to section 5.2 of the framework document: >> >>>>> >> >>>>> The SFC Classifier classifies packets based on (some of) the >> >>>> contents >> >>>>> of the packet header. Concretely, it classifies packets based >> >>>>> on >> >>>> the >> >>>>> possible combination of one or more header fields, such as >> source >> >>>>> address, destination address, DS field, protocol ID, source >> port >> >>>> and >> >>>>> destination port numbers, and any other information. >> >>>>> >> >>>>> A packet-based classifier as described in the framework document >> >>>> would >> >>>>> seem to be limited in what it can classify? The service function >> >>>>> identifier lookup does not seem to be a significant optimization >> >> over >> >>>>> a packet-based 5-tuple lookup? There seems to be some missing >> >> detail >> >>>>> wrt how classification information is determined and reused? >> >>>>> >> >>>>> When thinking about higher level services, e.g., HTTP and TLS >> >>>> encrypted >> >>>>> flows, a packet-based classifier seems inadequate? I was also >> >>>> wondering >> >>>>> how independent HLS segment requests might be classified and >> >>>> associated? >> >>>>> Were these types of use cases discussed in the BoF? >> >>>>> >> >>>>> thanx. >> >>>>> >> >>>>> -- Kevin J. Ma >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >>>>>> Behalf >> >> Of >> >>>>>> Ron >> >>>>>> Parker >> >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Sumandra, >> >>>>>> >> >>>>>> As was discussed in Vancouver, there are already many existing >> >>>>>> ways >> >>>> to >> >>>>>> accomplish service chaining. But none of them provide a >> >>>> sufficient >> >>>>>> combination of interoperability, flexibility, and resiliency. >> A >> >>>> single >> >>>>>> service chain encapsulation will go a long way to ensuring these >> >>>> goals. >> >>>>>> It may not be the absolutely most efficient approach for every >> >>>> single >> >>>>>> network topology and every single use case, but its ubiquitous >> >> nature >> >>>>>> should improve its adoption. >> >>>>>> >> >>>>>> Ron >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Ron, >> >>>>>> >> >>>>>> Absolutely, that was an example of one type of derivation. >> >>>>>> However >> >>>> this >> >>>>>> could be augmented with classification result, again one more >> >>>> example. >> >>>>>> >> >>>>>>>> All flows from the same source IP do not necessarily follow >> the >> >>>> same >> >>>>>> chain. >> >>>>>> Correct. It is also not necessary that all transaction of the >> >>>>>> same >> >>>> flow >> >>>>>> follow the same chain either. So why stop at flow itself. >> >>>>>> >> >>>>>> Again the point here is that do we always need SFC header or Not. >> >>>>>> >> >>>>>> Sumandra >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Sumandra, >> >>>>>> >> >>>>>> The intention of service function chaining is to allow for >> >>>>>> operation >> >>>> at >> >>>>>> the fully qualified flow level, or even finer grained at the >> >>>> transaction >> >>>>>> level (this is an implementation matter for the PDP). All >> flows >> >>>> from >> >>>>>> the same source IP do not necessarily follow the same chain. >> >> Source >> >>>>>> IP, >> >>>>>> therefore, does not identify the chain ID. Another intention >> of >> >>>>>> service function chaining is to operate over any network >> topology >> >> and >> >>>>>> not >> >>>>>> be limited to a single LAN. Thus, while VLAN may be part of >> the >> >>>>>> transport, it does not adequately identify the service chain, >> >> either. >> >>>>>> >> >>>>>> Ron >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Ron, >> >>>>>> >> >>>>>> The service header is meant to carry the context which can >> *also* >> >>>>>> be derived (for example use source ip and vlan to identify >> >>>>>> chainID and >> >>>>>> position) or encapsulated as part of another tunnel header. So >> >>>>>> this could be optional IMHO. >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Sumandra, >> >>>>>> >> >>>>>> As I understand it, an SFC packet traversing from PDP to SF or >> >>>>>> from >> >>>> SF >> >>>>>> to >> >>>>>> SF will look like: >> >>>>>> >> >>>>>> +------------------------+ >> >>>>>> | "transport" | >> >>>>>> +------------------------+ >> >>>>>> | service header | >> >>>>>> +------------------------+ >> >>>>>> | original IP header | >> >>>>>> +------------------------+ >> >>>>>> | | original IP payload >> | >> >>>>>> | | >> >>>>>> +------------------------+ >> >>>>>> >> >>>>>> Where service header contains, at a minimum, enough information >> >>>>>> to >> >>>> allow >> >>>>>> the packet to be propagated along the full length of the chain, >> >>>>>> and optionally, other metadata that enhances the operation of >> one >> >>>>>> or >> >> more >> >>>>>> service functions. >> >>>>>> >> >>>>>> And where "transport" could conceivably be any of, but not >> >>>>>> limited >> >>>> to: >> >>>>>> >> >>>>>> * Ethernet >> >>>>>> * Ethernet + LLC2 >> >>>>>> * Ethernet + MPLS >> >>>>>> * Ethernet + IP + GRE >> >>>>>> * Ethernet + IP +UDP >> >>>>>> >> >>>>>> >> >>>>>> Also, "original" in the diagram above is not meant to imply >> >>>>>> immutability, but rather to specify the packet that is >> propagated >> >>>>>> from preceding entity to succeeding entity, prior to >> >>>>>> encapsulation. >> >>>>>> >> >>>>>> Ron >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >>>>>> Behalf >> >> Of >> >>>>>> Sumandra Majee >> >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >>>>>> To: Thomas Narten; nsc@ietf.org >> >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Generic Service Function Chaining Encapsulation: A document will >> >>>>>> describe the single service-level data plane encapsulation >> >> format >> >>>>>> for >> >>>>>> conveying the service function chain and the service function >> >>>> path, >> >>>>>> and for communicating context information between nodes that >> >>>>>> implement service functions. It is intended that the >> >>>> encapsulation >> >>>>>> be agnostic to the layer at which it is applied and the >> >>>>>> service >> >>>> that >> >>>>>> is >> >>>>>> being constructed. That is, the same encapsulation may be >> used >> >> on >> >>>>>> a service function path realized at the network layer or at >> >>>>>> any other >> >>>>>> layer, and the same encapsulation will apply for the >> >> construction >> >>>> of >> >>>>>> service function paths regardless of the actual service. >> >>>>>> >> >>>>>> [SM] What does it mean by a single service-level encapsulation, >> a >> >>>> new >> >>>>>> encapsulation format >> >>>>>> or an ability to select one encapsulation format that >> >>>> fits >> >>>>>> the >> >>>>>> need for a given service chain? >> >>>>>> The ability to select a specific encapsulation would >> >>>>>> be >> >> a >> >>>>>> management plane decision. >> >>>>>> There are quite a few existing encapsulation methods >> >>>>>> that >> >>>> can >> >>>>>> possibly be reused to provide >> >>>>>> context information between service nodes. I have >> seen >> >>>>>> mention >> >>>>>> of GRE, for HTTP based >> >>>>>> applications contexts are transferred via headers. >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >>>>>> Behalf >> >> Of >> >>>>>> Thomas Narten >> >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >>>>>> To: nsc@ietf.org >> >>>>>> Subject: [nsc] Current Proposed SFC charter >> >>>>>> >> >>>>>> Hi. >> >>>>>> >> >>>>>> Current charter can be found at >> >>>>>> https://datatracker.ietf.org/doc/charter- >> >>>>>> ietf-sfc/. >> >>>>>> >> >>>>>> It contains the revised management text as well as updated >> >>>> milestones. >> >>>>>> >> >>>>>> All known issues have been addressed. If there are any remaining >> >>>> issues, >> >>>>>> please speak up! >> >>>>>> >> >>>>>> Charter charter-ietf-sfc-00-04 >> >>>>>> >> >>>>>> Networks, servers, storage technologies, and applications, have >> >>>>>> all undergone significant change in recent years with the >> >>>>>> introduction >> >> of >> >>>>>> virtualization, network overlays, and orchestration. Service >> >> delivery >> >>>> is >> >>>>>> currently both a technical and organizational challenge that >> >> involves >> >>>>>> significant modification to the network configuration. >> >>>>>> Services are typically implemented by the ordered combination of >> >>>>>> a number of service functions that are deployed at different >> >>>>>> points within >> >> the >> >>>>>> network. Today, a common deployment model has service functions >> >>>>>> physically inserted on the data forwarding path between >> >>>>>> communicating peers. >> >>>> Going >> >>>>>> forward, however, there is a desire to move to a different model, >> >>>> where >> >>>>>> service functions are not required to reside on the default data >> >> path >> >>>>>> and >> >>>>>> traffic is instead steered through services, wherever they are >> >>>> deployed. >> >>>>>> >> >>>>>> For a given service, the abstracted view of the required service >> >>>>>> functions and the order in which they are to be applied is >> called >> >>>>>> a Service Function Chain (SFC). Since a given service function >> >>>>>> may be available on more than one node within a network, a >> >>>>>> Service Function Chain is instantiated >> >>>> via >> >>>>>> the selection of specific service function instances and the >> >>>>>> network nodes on which they are provided, thereby forming a >> >>>>>> service topology: >> >>>>>> this is called a Service Function Path. The service functions >> may >> >>>>>> be applied at a specific layer within the network protocol stack >> >>>> (network >> >>>>>> layer, application layer, etc.). >> >>>>>> >> >>>>>> The Service Function Chaining (SFC) working group will develop >> >>>>>> new approaches to service delivery and deployment. It will >> >>>>>> produce a framework for service function chaining that includes >> >>>>>> the necessary protocols >> >>>> or >> >>>>>> protocol extensions to convey the service path and service path >> >>>>>> information to nodes that implement service functions, as well >> as >> >>>>>> mechanisms for steering traffic through service functions. The >> >>>> working >> >>>>>> group will also examine what information needs to be gathered >> >>>>>> from >> >>>> the >> >>>>>> network and service functions in support of service function >> >> chaining >> >>>>>> and >> >>>>>> how that information may be made available to nodes that >> >>>>>> implement >> >>>> the >> >>>>>> service functions. >> >>>>>> >> >>>>>> Specifically, the SFC WG is chartered to deliver the following: >> >>>>>> >> >>>>>> 1) Problem Statement: This document will provide a summary of >> the >> >>>>>> problem space to be addressed by the WG including example >> high- >> >>>>>> level use cases. Additionally, the WG will normalize >> >> nomenclature >> >>>>>> and definitions for service function chaining. >> >>>>>> >> >>>>>> 2) Architecture: This document will provide a description of the >> >>>>>> architectural building blocks and their relationships >> including >> >>>>>> interconnection, placement of capabilities, management, >> >>>>>> diagnostics, design analysis, and security models, as well as >> >>>>>> requirements on the protocol mechanisms. >> >>>>>> >> >>>>>> 3) Generic Service Function Chaining Encapsulation: A document >> will >> >>>>>> describe the single service-level data plane encapsulation >> >> format >> >>>>>> for >> >>>>>> conveying the service function chain and the service function >> >>>> path, >> >>>>>> and for communicating context information between nodes that >> >>>>>> implement service functions. It is intended that the >> >>>> encapsulation >> >>>>>> be agnostic to the layer at which it is applied and the >> >>>>>> service >> >>>> that >> >>>>>> is >> >>>>>> being constructed. That is, the same encapsulation may be >> used >> >> on >> >>>>>> a service function path realized at the network layer or at >> >>>>>> any other >> >>>>>> layer, and the same encapsulation will apply for the >> >> construction >> >>>> of >> >>>>>> service function paths regardless of the actual service. >> >>>>>> >> >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> developed to >> >>>>>> describe requirements and protocols necessary to convey >> >>>> information >> >>>>>> to service function implementation points. Where possible, >> >>>> existing >> >>>>>> IETF protocols will be used and extended. All protocol >> >> extensions >> >>>>>> work should be carried out in the working groups responsible >> >>>>>> for >> >>>> the >> >>>>>> protocols being modified in coordination with this working >> >> group, >> >>>>>> but >> >>>>>> may be done in this working group after agreement with all >> the >> >>>>>> relevant WG chairs and responsible ADs. >> >>>>>> >> >>>>>> 5) Manageability: Work on the management and configuration of >> >> service >> >>>>>> functions in support of SFC components will certainly be >> needed, >> >>>>>> but first needs to be better understood and scoped. >> >>>>>> >> >>>>>> Proposed Milestones >> >>>>>> >> >>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >> >>>> problem >> >>>>>> statement and core use cases for Service Function Chaining >> >>>>>> >> >>>>>> May 2014 Consult with OPS Area on possible charter modifications >> >>>>>> for management and configuration of SFC components >> >>>>>> >> >>>>>> Jan 2015 Submit to IESG Informational document defining the >> >>>> architecture >> >>>>>> for SFC >> >>>>>> >> >>>>>> Jan 2015 Submit to IESG requirements for a generic service >> >>>>>> function chaining encapsulation protocol >> >>>>>> >> >>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >> >>>> generic >> >>>>>> service function chaining header encapsulation >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> Thomas >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> nsc mailing list >> >>>>>> nsc@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >>>>>> _______________________________________________ >> >>>>>> nsc mailing list >> >>>>>> nsc@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >>>>>> _______________________________________________ >> >>>>>> nsc mailing list >> >>>>>> nsc@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >>>>> _______________________________________________ >> >>>>> nsc mailing list >> >>>>> nsc@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Tue Nov 12 09:20:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA82311E8202 for ; Tue, 12 Nov 2013 09:20:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYarONMNYg5z for ; Tue, 12 Nov 2013 09:20:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DA50811E821A for ; Tue, 12 Nov 2013 09:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1982; q=dns/txt; s=iport; t=1384276838; x=1385486438; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f6OKesjlt2IRNr2UgLWmhNyJDZbW1ucIGDPliwG07aQ=; b=WDMxkA8RsFeOMnGUwjIGURlLF2EEoUzLpHIt28PaeAjqolftVUtxb9B8 iPWUpy4mOFgZFgbVjj0IqjRxA6ysLc01ClSjPL4EwfcFp6xFDFQJEGGRM K0x7VB5P7khmtCRy1ShwN1q3gEoY9PtGg2TYyGVIQoQd4pD3UMtaxWne+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAAxjglKtJXG+/2dsb2JhbABagwc4U78WgSoWdIIlAQEBAwF5EgEIGGAlAgQBDQWHewYNvxOOFhCBBggrBwKELwOJCo8FgS+QW4MmgXE5 X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283811378" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2013 17:20:27 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACHKQ7H026644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:20:26 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:20:26 -0600 From: "Surendra Kumar (smkumar)" To: "Diego R. Lopez" , Linda Dunbar Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAL/tAIAAA3OAgAAm0oCAABXAAIAABVsA//+SUQA= Date: Tue, 12 Nov 2013 17:20:25 +0000 Message-ID: In-Reply-To: <8E715FBD-D549-4993-AFBA-F7368E57463C@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.85.152] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee , Kevin J Ma , "Hongyu Li \(Julio\)" , Ron Parker Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:20:48 -0000 Diego, On 11/12/13 7:52 AM, "Diego R. Lopez" wrote: >Hi, > >On 12 Nov 2013, at 16:33 , Linda Dunbar wrote: >> >> First, want to make it clear that "branching" !=3D reclassification, >>agree? > >DRL> At least, I do agree. Reclassification can lead to branching or not, >depending on the paths available at the reclassifying node... You are right about branching or not: branching is a consequence of reclassification. In theory, reclassification is not required to lead to branching. Further, there could be reclassification within the SF that does not impact the service path, only the service function. Surendra. > >> Second, the representation of branching (or service graph) can be in a >>form of logic on a service function. Some service functions, especially >>L7 based, can use value in a Database to determine what is the next >>service function. > >DRL> Anyway, a graph is what I see as the best concept, covering all >possible cases I can think of. If reclassification or branching happens, >we would be talking of different node types and/or labelled links between >nodes. Once we agree in the graph as the conceptual model, I'd go for >agreeing in the information model (the node and link attributes) and one >or even several data models for it. > >Be goode, > >-- >"Esta vez no fallaremos, Doctor Infierno" > >Dr Diego R. Lopez >Telefonica I+D >http://people.tid.es/diego.lopez/ > >e-mail: diego@tid.es >Tel: +34 913 129 041 >Mobile: +34 682 051 091 >----------------------------------------- > > >________________________________ > >Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el = enlace >situado m=E1s abajo. >This message is intended exclusively for its addressee. We only send and >receive email on the basis of the terms set out at: >http://www.tid.es/ES/PAGINAS/disclaimer.aspx From smkumar@cisco.com Tue Nov 12 09:25:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2CD21E80B2 for ; Tue, 12 Nov 2013 09:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.556 X-Spam-Level: X-Spam-Status: No, score=-10.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96m7jbU6DToY for ; Tue, 12 Nov 2013 09:25:43 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9A4CF11E80FE for ; Tue, 12 Nov 2013 09:25:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28997; q=dns/txt; s=iport; t=1384277142; x=1385486742; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=BjCqN6LQFQ6IWqLC3Hij6lWNO1/wuHMa8BGBAl6UY0Q=; b=RTyYF4DDT4An49Rw+6B5Xsq041lHzy4La585JI0QCugaYvI5BIEzeTu/ ZEs99QIiObw+vhVJzL2RvY6nkOmquHW8oUGUmnQxzd0Y0kJBrSYzThwky IrvDdLMbWi+OmZzHsz6Kc0HupOahN8+O6dj83FEjIr9As0oAyjFZIpkzs U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFADlkglKtJV2Z/2dsb2JhbABQCoMHOFO/FoEqFnSCJQEBAQMBAQEBFyArAgcEBwwGAQgRAQMBAQEVCQkuCxQDBggCBAEJBAUJh3IGDb8ZjhwEAQUGgQgrAgUCBASEJwOULoNhkgqDJoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283813808" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2013 17:25:40 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACHPeGq004380 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:25:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:25:40 -0600 From: "Surendra Kumar (smkumar)" To: Ron Parker , Kevin J Ma , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAL/tAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgD//5OPgA== Date: Tue, 12 Nov 2013 17:25:39 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.85.152] Content-Type: text/plain; charset="us-ascii" Content-ID: <15E61A23196CB14EBE2E545DB8EF3EB1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:25:48 -0000 Ron, Classification of traffic is well understood and we do not have to redefine it - it's been around for all the time middle boxes have been or for that matter the L2/L3 devices. All we are talking about is the applicability of the classification to branching in SFC. You are right, it is all about policy which is outside the scope of SFC. Surendra. On 11/12/13 7:53 AM, "Ron Parker" wrote: >I think the lack of definition of "reclassification" may be causing some >misunderstandings here. A branch would occur for some policy-driven >reason based on the behavior and conclusions of the service function, >itself. The graph would represent the fact that there is a branch >point, but the service function, itself, being aware that it is a >branching point would contain the policy and logic to decide on which >branch to take. Specifying that policy and logic is out of scope, IMO. > > Ron > > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: Tuesday, November 12, 2013 10:49 AM >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >Hi Linda, > > Are you saying that a branching point is "never" a reclassification > point, or are you saying that a branching point "does not have to be" > a reclassification point? > > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain > is different than I originally inferred. If the chain is a tree with > other "branching" points in it, then that limits the scope of the > problem statement goals. > > While this could be a degenerate case, and any implementation could > define bad service chains, is it the intent of SFC to only look at > the simpler packet-level classification cases, or is it the intent > to consider the case where a branching point is viewed as a > re-classification point? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Tuesday, November 12, 2013 10:34 AM >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Ron, >> >> First, want to make it clear that "branching" !=3D reclassification, >>agree? >> >> Second, the representation of branching (or service graph) can be in a >> form of logic on a service function. Some service functions, >> especially L7 based, can use value in a Database to determine what is >> the next service function. >> >> Linda >> >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> > Of Ron Parker >> > Sent: Tuesday, November 12, 2013 8:16 AM >> > To: Hongyu Li (Julio); Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Hongyu, >> > >> > I agree completely that re-classification is not limited to DPI. >> > >> > And also, that an area for us to explore as a group is how to >>represent >> > the service graph. Do we want to represent it as a proper graph with >> > an adjacency list or other representational model? Or, do we want to >> > represent it as a set of linear segments and if so, how are the >> > segments connected into a graph? Other ideas? >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> > Of Hongyu Li (Julio) >> > Sent: Tuesday, November 12, 2013 6:57 AM >> > To: Ron Parker; Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Branching/forking is a very interesting topic of SFC. About the re- >> > classification point, probably we shall not limit it to DPI. It is >> > also possible that packets go to different branches after been >> > processed by a certain service function, decision of which branches >> > to go is made based on the result of service function's process, >> > i.e. not just re- classification by DPI. >> > >> > Hongyu >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> > Of Ron Parker >> > Sent: Tuesday, November 12, 2013 7:45 PM >> > To: Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Hi, Kevin >> > >> > You ask a great question about branching the graph. The details >> > around how to convey the selection of the subtree/subgraph are still >>to be >> > defined. Is it one chain id for the whole graph? Does each branch >> > have its own chain id? Some combination? >> > >> > Ron >> > >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> > >> > wrote: >> > >> > >> Yes, reclassification can change the service path and >> > >> re-classification may happen at any node along a service path. >> > > >> > > Just to expand on that, going back to the original question about >> > > service header encapsulation, is it intended that a chain that is >> > > re-classified will get a new chain ID which fully describes a >> > > chain that is a superset of the original chain ID, prior to >> > > DPI-based re-classification? (assuming the goal is "a single >> > > chain ID that is commonly understood along the entire service chain" >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> > > >> > > And the applicable subset of the permutative list of service paths >> > > would be configured at each appropriate service node? >> > > e.g., ID 1: NAT + firewall + DPI >> > > ID 2: NAT + firewall + DPI + AV >> > > ID 3: NAT + firewall + DPI + AV + NAT >> > > ID 4: NAT + firewall + DPI + NAT >> > > ID 5: NAT + firewall + DPI + AV + LB >> > > ID 6: NAT + firewall + DPI + LB >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> > > ID 8: NAT + firewall + DPI + CACHE >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >> > > flow then be initially classified as ID 1, but eventually get re- >> > classified >> > > to ID 2-11, after the DPI phase? >> > > >> > > thanx. >> > > >> > > -- Kevin J. Ma >> > > >> > >> -----Original Message----- >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> > >> nsc@ietf.org >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> > >> >> > >> >> > >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>wrote: >> > >>> >> > >>> Hi Surendra, >> > >>> >> > >>> Classification may be out of scope, but the level of service >> > >>> that >> > is >> > >>> applicable is dependent upon the level of classification that >> > >>> can >> > be >> > >>> performed. An assumption of packet level encapsulation has >> > >> implications >> > >>> on the level of classification being performed? If the stated >> > goals >> > >> are >> > >>> for firewall and load balancer functionality, then the >> > >>> application >> > >> level >> > >>> nature of those functions needs to be taken into account? If, >> > >>> on the other hand, the service function scope is limited due to >> > >>> limitations in classification, that would be and important piece >> > >>> of >> > information? >> > >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >> > >>> points of the service paths seem like re-classification points? >> > >>> Is that the interpretation from the architecture perspective? >> > >>> Or is the service function chain classification exclusive of DPI >> > functionality? >> > >> I have not fully read that draft yet. But in general, as >> > >> described in the arch draft, the collection of services form a >> > >> graph, segments of which are service paths. Yes, reclassification >> > >> can >> > change >> > >> the service path and re-classification may happen at any node >> > >> along >> > a service path. >> > >> >> > >> Surendra. >> > >>> >> > >>> thanx. >> > >>> >> > >>> -- Kevin J. Ma >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> > >>>> nsc@ietf.org >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>> >> > >>>> Kevin, >> > >>>> >> > >>>> Classification mechanism is outside the scope of SFC. It can be >> > >>>> based >> > >> on >> > >>>> the packet or information not in the packet(environmental >> > >>>> attributes >> > >> for >> > >>>> instance) or a combination thereof. What is important is that >> > >>>> such classification aids in traffic selection and service path >> > >>>> identification. >> > >>>> It is no different from a policy in this regard except that the >> > >>>> policy now specifies the service path. >> > >>>> Further, classification is not limited to the network elements >> > >>>> but the service functions as well. Some of this is described in >> > >>>> the >> > >> architecture >> > >>>> drafts as well - >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> > >>>> >> > >>>> Surendra. >> > >>>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> > wrote: >> > >>>>> >> > >>>>> Hi Ron, >> > >>>>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >> > >>>>> but I had a similar question wrt bullet 11 in section 2 of the >> > problem >> > >>>>> statement: >> > >>>>> >> > >>>>> 11. Per-Service (re)Classification: Classification occurs >> > >>>>> at >> > each >> > >>>>> service, independent from previously applied service >> > >>>> functions. >> > >>>>> These unrelated classification events consume resources >> > per >> > >>>>> service. More importantly, the classification >> > functionality >> > >>>>> often differs per service function and service function >> > >> cannot >> > >>>>> leverage the results from other deployed network or >> > service. >> > >>>>> >> > >>>>> as it relates to section 5.2 of the framework document: >> > >>>>> >> > >>>>> The SFC Classifier classifies packets based on (some of) the >> > >>>> contents >> > >>>>> of the packet header. Concretely, it classifies packets >> > >>>>> based on >> > >>>> the >> > >>>>> possible combination of one or more header fields, such as >> > source >> > >>>>> address, destination address, DS field, protocol ID, source >> > port >> > >>>> and >> > >>>>> destination port numbers, and any other information. >> > >>>>> >> > >>>>> A packet-based classifier as described in the framework >> > >>>>> document >> > >>>> would >> > >>>>> seem to be limited in what it can classify? The service >> > >>>>> function identifier lookup does not seem to be a significant >> > >>>>> optimization >> > >> over >> > >>>>> a packet-based 5-tuple lookup? There seems to be some missing >> > >> detail >> > >>>>> wrt how classification information is determined and reused? >> > >>>>> >> > >>>>> When thinking about higher level services, e.g., HTTP and TLS >> > >>>> encrypted >> > >>>>> flows, a packet-based classifier seems inadequate? I was also >> > >>>> wondering >> > >>>>> how independent HLS segment requests might be classified and >> > >>>> associated? >> > >>>>> Were these types of use cases discussed in the BoF? >> > >>>>> >> > >>>>> thanx. >> > >>>>> >> > >>>>> -- Kevin J. Ma >> > >>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Ron >> > >>>>>> Parker >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> As was discussed in Vancouver, there are already many >> > >>>>>> existing ways >> > >>>> to >> > >>>>>> accomplish service chaining. But none of them provide a >> > >>>> sufficient >> > >>>>>> combination of interoperability, flexibility, and resiliency. >> > A >> > >>>> single >> > >>>>>> service chain encapsulation will go a long way to ensuring >> > >>>>>> these >> > >>>> goals. >> > >>>>>> It may not be the absolutely most efficient approach for >> > >>>>>> every >> > >>>> single >> > >>>>>> network topology and every single use case, but its >> > >>>>>> ubiquitous >> > >> nature >> > >>>>>> should improve its adoption. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Ron, >> > >>>>>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> > >>>>>> However >> > >>>> this >> > >>>>>> could be augmented with classification result, again one more >> > >>>> example. >> > >>>>>> >> > >>>>>>>> All flows from the same source IP do not necessarily follow >> > the >> > >>>> same >> > >>>>>> chain. >> > >>>>>> Correct. It is also not necessary that all transaction of the >> > >>>>>> same >> > >>>> flow >> > >>>>>> follow the same chain either. So why stop at flow itself. >> > >>>>>> >> > >>>>>> Again the point here is that do we always need SFC header or >>Not. >> > >>>>>> >> > >>>>>> Sumandra >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> The intention of service function chaining is to allow for >> > >>>>>> operation >> > >>>> at >> > >>>>>> the fully qualified flow level, or even finer grained at the >> > >>>> transaction >> > >>>>>> level (this is an implementation matter for the PDP). All >> > flows >> > >>>> from >> > >>>>>> the same source IP do not necessarily follow the same chain. >> > >> Source >> > >>>>>> IP, >> > >>>>>> therefore, does not identify the chain ID. Another >>intention >> > of >> > >>>>>> service function chaining is to operate over any network >> > topology >> > >> and >> > >>>>>> not >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of >> > the >> > >>>>>> transport, it does not adequately identify the service chain, >> > >> either. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Ron, >> > >>>>>> >> > >>>>>> The service header is meant to carry the context which can >> > *also* >> > >>>>>> be derived (for example use source ip and vlan to identify >> > >>>>>> chainID and >> > >>>>>> position) or encapsulated as part of another tunnel header. >> > >>>>>> So this could be optional IMHO. >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF >> > >>>>>> or from >> > >>>> SF >> > >>>>>> to >> > >>>>>> SF will look like: >> > >>>>>> >> > >>>>>> +------------------------+ >> > >>>>>> | "transport" | >> > >>>>>> +------------------------+ >> > >>>>>> | service header | >> > >>>>>> +------------------------+ >> > >>>>>> | original IP header | >> > >>>>>> +------------------------+ >> > >>>>>> | | original IP >> > >>>>>> | payload >> > | >> > >>>>>> | | >> > >>>>>> +------------------------+ >> > >>>>>> >> > >>>>>> Where service header contains, at a minimum, enough >> > >>>>>> information to >> > >>>> allow >> > >>>>>> the packet to be propagated along the full length of the >> > >>>>>> chain, and optionally, other metadata that enhances the >> > >>>>>> operation of >> > one >> > >>>>>> or >> > >> more >> > >>>>>> service functions. >> > >>>>>> >> > >>>>>> And where "transport" could conceivably be any of, but not >> > >>>>>> limited >> > >>>> to: >> > >>>>>> >> > >>>>>> * Ethernet >> > >>>>>> * Ethernet + LLC2 >> > >>>>>> * Ethernet + MPLS >> > >>>>>> * Ethernet + IP + GRE >> > >>>>>> * Ethernet + IP +UDP >> > >>>>>> >> > >>>>>> >> > >>>>>> Also, "original" in the diagram above is not meant to imply >> > >>>>>> immutability, but rather to specify the packet that is >> > propagated >> > >>>>>> from preceding entity to succeeding entity, prior to >> > >>>>>> encapsulation. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Sumandra Majee >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A document >>will >> > >>>>>> describe the single service-level data plane encapsulation >> > >> format >> > >>>>>> for >> > >>>>>> conveying the service function chain and the service >> > >>>>>> function >> > >>>> path, >> > >>>>>> and for communicating context information between nodes that >> > >>>>>> implement service functions. It is intended that the >> > >>>> encapsulation >> > >>>>>> be agnostic to the layer at which it is applied and the >> > >>>>>> service >> > >>>> that >> > >>>>>> is >> > >>>>>> being constructed. That is, the same encapsulation may be >> > used >> > >> on >> > >>>>>> a service function path realized at the network layer or >> > >>>>>> at any other >> > >>>>>> layer, and the same encapsulation will apply for the >> > >> construction >> > >>>> of >> > >>>>>> service function paths regardless of the actual service. >> > >>>>>> >> > >>>>>> [SM] What does it mean by a single service-level >> > >>>>>> encapsulation, >> > a >> > >>>> new >> > >>>>>> encapsulation format >> > >>>>>> or an ability to select one encapsulation format >> > >>>>>> that >> > >>>> fits >> > >>>>>> the >> > >>>>>> need for a given service chain? >> > >>>>>> The ability to select a specific encapsulation >> > >>>>>> would be >> > >> a >> > >>>>>> management plane decision. >> > >>>>>> There are quite a few existing encapsulation methods >> > >>>>>> that >> > >>>> can >> > >>>>>> possibly be reused to provide >> > >>>>>> context information between service nodes. I have >> > seen >> > >>>>>> mention >> > >>>>>> of GRE, for HTTP based >> > >>>>>> applications contexts are transferred via headers. >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Thomas Narten >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> > >>>>>> To: nsc@ietf.org >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Hi. >> > >>>>>> >> > >>>>>> Current charter can be found at >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> > >>>>>> ietf-sfc/. >> > >>>>>> >> > >>>>>> It contains the revised management text as well as updated >> > >>>> milestones. >> > >>>>>> >> > >>>>>> All known issues have been addressed. If there are any >> > >>>>>> remaining >> > >>>> issues, >> > >>>>>> please speak up! >> > >>>>>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> > >>>>>> >> > >>>>>> Networks, servers, storage technologies, and applications, >> > >>>>>> have all undergone significant change in recent years with >> > >>>>>> the introduction >> > >> of >> > >>>>>> virtualization, network overlays, and orchestration. Service >> > >> delivery >> > >>>> is >> > >>>>>> currently both a technical and organizational challenge that >> > >> involves >> > >>>>>> significant modification to the network configuration. >> > >>>>>> Services are typically implemented by the ordered combination >> > >>>>>> of a number of service functions that are deployed at >> > >>>>>> different points within >> > >> the >> > >>>>>> network. Today, a common deployment model has service >> > >>>>>> functions physically inserted on the data forwarding path >> > >>>>>> between communicating peers. >> > >>>> Going >> > >>>>>> forward, however, there is a desire to move to a different >> > >>>>>> model, >> > >>>> where >> > >>>>>> service functions are not required to reside on the default >> > >>>>>> data >> > >> path >> > >>>>>> and >> > >>>>>> traffic is instead steered through services, wherever they >> > >>>>>> are >> > >>>> deployed. >> > >>>>>> >> > >>>>>> For a given service, the abstracted view of the required >> > >>>>>> service functions and the order in which they are to be >> > >>>>>> applied is >> > called >> > >>>>>> a Service Function Chain (SFC). Since a given service >> > >>>>>> function may be available on more than one node within a >> > >>>>>> network, a Service Function Chain is instantiated >> > >>>> via >> > >>>>>> the selection of specific service function instances and the >> > >>>>>> network nodes on which they are provided, thereby forming a >> > >>>>>> service topology: >> > >>>>>> this is called a Service Function Path. The service functions >> > may >> > >>>>>> be applied at a specific layer within the network protocol >> > >>>>>> stack >> > >>>> (network >> > >>>>>> layer, application layer, etc.). >> > >>>>>> >> > >>>>>> The Service Function Chaining (SFC) working group will >> > >>>>>> develop new approaches to service delivery and deployment. It >> > >>>>>> will produce a framework for service function chaining that >> > >>>>>> includes the necessary protocols >> > >>>> or >> > >>>>>> protocol extensions to convey the service path and service >> > >>>>>> path information to nodes that implement service functions, >> > >>>>>> as well >> > as >> > >>>>>> mechanisms for steering traffic through service functions. >> > >>>>>> The >> > >>>> working >> > >>>>>> group will also examine what information needs to be gathered >> > >>>>>> from >> > >>>> the >> > >>>>>> network and service functions in support of service function >> > >> chaining >> > >>>>>> and >> > >>>>>> how that information may be made available to nodes that >> > >>>>>> implement >> > >>>> the >> > >>>>>> service functions. >> > >>>>>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the following: >> > >>>>>> >> > >>>>>> 1) Problem Statement: This document will provide a summary of >> > the >> > >>>>>> problem space to be addressed by the WG including example >> > high- >> > >>>>>> level use cases. Additionally, the WG will normalize >> > >> nomenclature >> > >>>>>> and definitions for service function chaining. >> > >>>>>> >> > >>>>>> 2) Architecture: This document will provide a description of >>the >> > >>>>>> architectural building blocks and their relationships >> > including >> > >>>>>> interconnection, placement of capabilities, management, >> > >>>>>> diagnostics, design analysis, and security models, as well >>as >> > >>>>>> requirements on the protocol mechanisms. >> > >>>>>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >> > >>>>>> document >> > will >> > >>>>>> describe the single service-level data plane encapsulation >> > >> format >> > >>>>>> for >> > >>>>>> conveying the service function chain and the service >> > >>>>>> function >> > >>>> path, >> > >>>>>> and for communicating context information between nodes that >> > >>>>>> implement service functions. It is intended that the >> > >>>> encapsulation >> > >>>>>> be agnostic to the layer at which it is applied and the >> > >>>>>> service >> > >>>> that >> > >>>>>> is >> > >>>>>> being constructed. That is, the same encapsulation may be >> > used >> > >> on >> > >>>>>> a service function path realized at the network layer or >> > >>>>>> at any other >> > >>>>>> layer, and the same encapsulation will apply for the >> > >> construction >> > >>>> of >> > >>>>>> service function paths regardless of the actual service. >> > >>>>>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> > developed to >> > >>>>>> describe requirements and protocols necessary to convey >> > >>>> information >> > >>>>>> to service function implementation points. Where possible, >> > >>>> existing >> > >>>>>> IETF protocols will be used and extended. All protocol >> > >> extensions >> > >>>>>> work should be carried out in the working groups >> > >>>>>> responsible for >> > >>>> the >> > >>>>>> protocols being modified in coordination with this working >> > >> group, >> > >>>>>> but >> > >>>>>> may be done in this working group after agreement with all >> > the >> > >>>>>> relevant WG chairs and responsible ADs. >> > >>>>>> >> > >>>>>> 5) Manageability: Work on the management and configuration of >> > >> service >> > >>>>>> functions in support of SFC components will certainly be >> > needed, >> > >>>>>> but first needs to be better understood and scoped. >> > >>>>>> >> > >>>>>> Proposed Milestones >> > >>>>>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining >> > >>>>>> the >> > >>>> problem >> > >>>>>> statement and core use cases for Service Function Chaining >> > >>>>>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter >> > >>>>>> modifications for management and configuration of SFC >> > >>>>>> components >> > >>>>>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining the >> > >>>> architecture >> > >>>>>> for SFC >> > >>>>>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service >> > >>>>>> function chaining encapsulation protocol >> > >>>>>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying >> > >>>>>> the >> > >>>> generic >> > >>>>>> service function chaining header encapsulation >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> Thomas >> > >>>>>> >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>> _______________________________________________ >> > >>>>> nsc mailing list >> > >>>>> nsc@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc From dlake@cisco.com Tue Nov 12 09:59:53 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DCF11E80EA for ; Tue, 12 Nov 2013 09:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KILT+diaev19 for ; Tue, 12 Nov 2013 09:59:47 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 73F0211E810A for ; Tue, 12 Nov 2013 09:59:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30746; q=dns/txt; s=iport; t=1384279187; x=1385488787; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JI9k5sRNcSm8iSZ/hVkq3vJFlYMXT0qMcSABouJTFFM=; b=JHN2hIJQX3hI5jo/ujQUJvM1K6Ul3fPSuFqwI3+ETridbaC8QGtSbtcL xXOJoVDH+IHM9GYAF3tlF8duGq1Um8pNtuiBkMpxCgz2cS5U8kKdtutb2 ITWvVVte2uhskb0Fmcrf7yKOMJjfyTO3BxcnaRjhE4qtylsWZGechPM4D s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIJrglKtJV2Y/2dsb2JhbABQCoMHOFO/FoEqFnSCJQEBAQQBAQEXICsCBwQHDAQCAQgRAQMBAQEKCwkJBycLFAMGCAIEAQkEBQgBh3gNvyKOHAQBBQaBAgYrAgUCBASDFoERA5QulWuDJoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283817149" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2013 17:59:46 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rACHxj64023442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 17:59:45 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 11:59:45 -0600 From: "David Lake (dlake)" To: "Surendra Kumar (smkumar)" , Ron Parker , Kevin J Ma , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgAB1UoCAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugP//o12w Date: Tue, 12 Nov 2013 17:59:45 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB0C8E9EE0@xmb-aln-x09.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.27.58.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:59:53 -0000 Policy may be outside of the scope of SFC, but without strong mapping betwe= en Policy and the inserted Service Header(s), we run-the-risk of limiting t= he efficacy of the protocol IMO. For example, in a world where the network has "gone dark," (as per the IETF= Technical Plenary ?:-) ) what is our ability to determine policy based on = DPI of packets-in-flight ? In those circumstances, only the end applications themselves or a reasonabl= y broad-brushed classification (really traffic steering based on what we ca= n see at ingress) is going to be useful - is THAT what we're aiming for her= e ? David -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Suren= dra Kumar (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Ron, Classification of traffic is well understood and we do not have to redefine= it - it's been around for all the time middle boxes have been or for that = matter the L2/L3 devices. All we are talking about is the applicability of = the classification to branching in SFC. You are right, it is all about policy which is outside the scope of SFC. Surendra. On 11/12/13 7:53 AM, "Ron Parker" wrote: >I think the lack of definition of "reclassification" may be causing some >misunderstandings here. A branch would occur for some policy-driven >reason based on the behavior and conclusions of the service function, >itself. The graph would represent the fact that there is a branch >point, but the service function, itself, being aware that it is a=20 >branching point would contain the policy and logic to decide on which >branch to take. Specifying that policy and logic is out of scope, IMO. > > Ron > > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: Tuesday, November 12, 2013 10:49 AM >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >Majee >Subject: RE: [nsc] Current Proposed SFC charter > >Hi Linda, > > Are you saying that a branching point is "never" a reclassification =20 > point, or are you saying that a branching point "does not have to be" > a reclassification point? > > I think this is an important distinction that needs to be clarified. > If branching is never reclassification, then the meaning of a chain =20 > is different than I originally inferred. If the chain is a tree with =20 > other "branching" points in it, then that limits the scope of the =20 > problem statement goals. > > While this could be a degenerate case, and any implementation could =20 > define bad service chains, is it the intent of SFC to only look at =20 > the simpler packet-level classification cases, or is it the intent to=20 > consider the case where a branching point is viewed as a =20 > re-classification point? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> Sent: Tuesday, November 12, 2013 10:34 AM >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Ron, >> >> First, want to make it clear that "branching" !=3D reclassification,=20 >>agree? >> >> Second, the representation of branching (or service graph) can be in=20 >> a form of logic on a service function. Some service functions,=20 >> especially L7 based, can use value in a Database to determine what is=20 >> the next service function. >> >> Linda >> >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >> > Of Ron Parker >> > Sent: Tuesday, November 12, 2013 8:16 AM >> > To: Hongyu Li (Julio); Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Hongyu, >> > >> > I agree completely that re-classification is not limited to DPI. >> > >> > And also, that an area for us to explore as a group is how to >>represent >> > the service graph. Do we want to represent it as a proper graph with >> > an adjacency list or other representational model? Or, do we want to >> > represent it as a set of linear segments and if so, how are the >> > segments connected into a graph? Other ideas? >> > >> > Ron >> > >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >> > Of Hongyu Li (Julio) >> > Sent: Tuesday, November 12, 2013 6:57 AM >> > To: Ron Parker; Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Branching/forking is a very interesting topic of SFC. About the re-=20 >> > classification point, probably we shall not limit it to DPI. It is=20 >> > also possible that packets go to different branches after been=20 >> > processed by a certain service function, decision of which branches=20 >> > to go is made based on the result of service function's process,=20 >> > i.e. not just re- classification by DPI. >> > >> > Hongyu >> > >> > -----Original Message----- >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >> > Of Ron Parker >> > Sent: Tuesday, November 12, 2013 7:45 PM >> > To: Kevin J Ma >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> > Majee >> > Subject: Re: [nsc] Current Proposed SFC charter >> > >> > Hi, Kevin >> > >> > You ask a great question about branching the graph. The details=20 >> > around how to convey the selection of the subtree/subgraph are=20 >> > still >>to be >> > defined. Is it one chain id for the whole graph? Does each branch >> > have its own chain id? Some combination? >> > >> > Ron >> > >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> > >> > wrote: >> > >> > >> Yes, reclassification can change the service path and=20 >> > >> re-classification may happen at any node along a service path. >> > > >> > > Just to expand on that, going back to the original question about=20 >> > > service header encapsulation, is it intended that a chain that is=20 >> > > re-classified will get a new chain ID which fully describes a=20 >> > > chain that is a superset of the original chain ID, prior to=20 >> > > DPI-based re-classification? (assuming the goal is "a single=20 >> > > chain ID that is commonly understood along the entire service chain" >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> > > >> > > And the applicable subset of the permutative list of service=20 >> > > paths would be configured at each appropriate service node? >> > > e.g., ID 1: NAT + firewall + DPI >> > > ID 2: NAT + firewall + DPI + AV >> > > ID 3: NAT + firewall + DPI + AV + NAT >> > > ID 4: NAT + firewall + DPI + NAT >> > > ID 5: NAT + firewall + DPI + AV + LB >> > > ID 6: NAT + firewall + DPI + LB >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> > > ID 8: NAT + firewall + DPI + CACHE >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every=20 >> > > flow then be initially classified as ID 1, but eventually get re- >> > classified >> > > to ID 2-11, after the DPI phase? >> > > >> > > thanx. >> > > >> > > -- Kevin J. Ma >> > > >> > >> -----Original Message----- >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> > >> nsc@ietf.org >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> > >> >> > >> >> > >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>wrote: >> > >>> >> > >>> Hi Surendra, >> > >>> >> > >>> Classification may be out of scope, but the level of service=20 >> > >>> that >> > is >> > >>> applicable is dependent upon the level of classification that=20 >> > >>> can >> > be >> > >>> performed. An assumption of packet level encapsulation has >> > >> implications >> > >>> on the level of classification being performed? If the stated >> > goals >> > >> are >> > >>> for firewall and load balancer functionality, then the=20 >> > >>> application >> > >> level >> > >>> nature of those functions needs to be taken into account? If,=20 >> > >>> on the other hand, the service function scope is limited due to=20 >> > >>> limitations in classification, that would be and important=20 >> > >>> piece of >> > information? >> > >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >> > >>> fork points of the service paths seem like re-classification point= s? >> > >>> Is that the interpretation from the architecture perspective? >> > >>> Or is the service function chain classification exclusive of=20 >> > >>> DPI >> > functionality? >> > >> I have not fully read that draft yet. But in general, as=20 >> > >> described in the arch draft, the collection of services form a=20 >> > >> graph, segments of which are service paths. Yes,=20 >> > >> reclassification can >> > change >> > >> the service path and re-classification may happen at any node=20 >> > >> along >> > a service path. >> > >> >> > >> Surendra. >> > >>> >> > >>> thanx. >> > >>> >> > >>> -- Kevin J. Ma >> > >>> >> > >>>> -----Original Message----- >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> > >>>> nsc@ietf.org >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>> >> > >>>> Kevin, >> > >>>> >> > >>>> Classification mechanism is outside the scope of SFC. It can=20 >> > >>>> be based >> > >> on >> > >>>> the packet or information not in the packet(environmental=20 >> > >>>> attributes >> > >> for >> > >>>> instance) or a combination thereof. What is important is that=20 >> > >>>> such classification aids in traffic selection and service path=20 >> > >>>> identification. >> > >>>> It is no different from a policy in this regard except that=20 >> > >>>> the policy now specifies the service path. >> > >>>> Further, classification is not limited to the network elements=20 >> > >>>> but the service functions as well. Some of this is described=20 >> > >>>> in the >> > >> architecture >> > >>>> drafts as well - >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> > >>>> >> > >>>> Surendra. >> > >>>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> > wrote: >> > >>>>> >> > >>>>> Hi Ron, >> > >>>>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI,=20 >> > >>>>> but I had a similar question wrt bullet 11 in section 2 of=20 >> > >>>>> the >> > problem >> > >>>>> statement: >> > >>>>> >> > >>>>> 11. Per-Service (re)Classification: Classification occurs=20 >> > >>>>> at >> > each >> > >>>>> service, independent from previously applied service >> > >>>> functions. >> > >>>>> These unrelated classification events consume=20 >> > >>>>> resources >> > per >> > >>>>> service. More importantly, the classification >> > functionality >> > >>>>> often differs per service function and service=20 >> > >>>>> function >> > >> cannot >> > >>>>> leverage the results from other deployed network or >> > service. >> > >>>>> >> > >>>>> as it relates to section 5.2 of the framework document: >> > >>>>> >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 >> > >>>>> the >> > >>>> contents >> > >>>>> of the packet header. Concretely, it classifies packets=20 >> > >>>>> based on >> > >>>> the >> > >>>>> possible combination of one or more header fields, such as >> > source >> > >>>>> address, destination address, DS field, protocol ID, source >> > port >> > >>>> and >> > >>>>> destination port numbers, and any other information. >> > >>>>> >> > >>>>> A packet-based classifier as described in the framework=20 >> > >>>>> document >> > >>>> would >> > >>>>> seem to be limited in what it can classify? The service=20 >> > >>>>> function identifier lookup does not seem to be a significant=20 >> > >>>>> optimization >> > >> over >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >> > >>>>> missing >> > >> detail >> > >>>>> wrt how classification information is determined and reused? >> > >>>>> >> > >>>>> When thinking about higher level services, e.g., HTTP and TLS >> > >>>> encrypted >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >> > >>>>> also >> > >>>> wondering >> > >>>>> how independent HLS segment requests might be classified and >> > >>>> associated? >> > >>>>> Were these types of use cases discussed in the BoF? >> > >>>>> >> > >>>>> thanx. >> > >>>>> >> > >>>>> -- Kevin J. Ma >> > >>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Ron >> > >>>>>> Parker >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >> > >>>>>> existing ways >> > >>>> to >> > >>>>>> accomplish service chaining. But none of them provide a >> > >>>> sufficient >> > >>>>>> combination of interoperability, flexibility, and resiliency. >> > A >> > >>>> single >> > >>>>>> service chain encapsulation will go a long way to ensuring=20 >> > >>>>>> these >> > >>>> goals. >> > >>>>>> It may not be the absolutely most efficient approach for=20 >> > >>>>>> every >> > >>>> single >> > >>>>>> network topology and every single use case, but its=20 >> > >>>>>> ubiquitous >> > >> nature >> > >>>>>> should improve its adoption. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Ron, >> > >>>>>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> > >>>>>> However >> > >>>> this >> > >>>>>> could be augmented with classification result, again one=20 >> > >>>>>> more >> > >>>> example. >> > >>>>>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >> > >>>>>>>> follow >> > the >> > >>>> same >> > >>>>>> chain. >> > >>>>>> Correct. It is also not necessary that all transaction of=20 >> > >>>>>> the same >> > >>>> flow >> > >>>>>> follow the same chain either. So why stop at flow itself. >> > >>>>>> >> > >>>>>> Again the point here is that do we always need SFC header or >>Not. >> > >>>>>> >> > >>>>>> Sumandra >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> The intention of service function chaining is to allow for=20 >> > >>>>>> operation >> > >>>> at >> > >>>>>> the fully qualified flow level, or even finer grained at the >> > >>>> transaction >> > >>>>>> level (this is an implementation matter for the PDP). All >> > flows >> > >>>> from >> > >>>>>> the same source IP do not necessarily follow the same chain. >> > >> Source >> > >>>>>> IP, >> > >>>>>> therefore, does not identify the chain ID. Another >>intention >> > of >> > >>>>>> service function chaining is to operate over any network >> > topology >> > >> and >> > >>>>>> not >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of >> > the >> > >>>>>> transport, it does not adequately identify the service=20 >> > >>>>>> chain, >> > >> either. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Ron, >> > >>>>>> >> > >>>>>> The service header is meant to carry the context which can >> > *also* >> > >>>>>> be derived (for example use source ip and vlan to identify=20 >> > >>>>>> chainID and >> > >>>>>> position) or encapsulated as part of another tunnel header. >> > >>>>>> So this could be optional IMHO. >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Sumandra, >> > >>>>>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF=20 >> > >>>>>> or from >> > >>>> SF >> > >>>>>> to >> > >>>>>> SF will look like: >> > >>>>>> >> > >>>>>> +------------------------+ >> > >>>>>> | "transport" | >> > >>>>>> +------------------------+ >> > >>>>>> | service header | >> > >>>>>> +------------------------+ >> > >>>>>> | original IP header | >> > >>>>>> +------------------------+ >> > >>>>>> | | original IP=20 >> > >>>>>> | payload >> > | >> > >>>>>> | | >> > >>>>>> +------------------------+ >> > >>>>>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >> > >>>>>> information to >> > >>>> allow >> > >>>>>> the packet to be propagated along the full length of the=20 >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >> > >>>>>> operation of >> > one >> > >>>>>> or >> > >> more >> > >>>>>> service functions. >> > >>>>>> >> > >>>>>> And where "transport" could conceivably be any of, but not=20 >> > >>>>>> limited >> > >>>> to: >> > >>>>>> >> > >>>>>> * Ethernet >> > >>>>>> * Ethernet + LLC2 >> > >>>>>> * Ethernet + MPLS >> > >>>>>> * Ethernet + IP + GRE >> > >>>>>> * Ethernet + IP +UDP >> > >>>>>> >> > >>>>>> >> > >>>>>> Also, "original" in the diagram above is not meant to imply=20 >> > >>>>>> immutability, but rather to specify the packet that is >> > propagated >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >> > >>>>>> encapsulation. >> > >>>>>> >> > >>>>>> Ron >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Sumandra Majee >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A document >>will >> > >>>>>> describe the single service-level data plane=20 >> > >>>>>> encapsulation >> > >> format >> > >>>>>> for >> > >>>>>> conveying the service function chain and the service=20 >> > >>>>>> function >> > >>>> path, >> > >>>>>> and for communicating context information between nodes that >> > >>>>>> implement service functions. It is intended that the >> > >>>> encapsulation >> > >>>>>> be agnostic to the layer at which it is applied and the=20 >> > >>>>>> service >> > >>>> that >> > >>>>>> is >> > >>>>>> being constructed. That is, the same encapsulation may be >> > used >> > >> on >> > >>>>>> a service function path realized at the network layer or=20 >> > >>>>>> at any other >> > >>>>>> layer, and the same encapsulation will apply for the >> > >> construction >> > >>>> of >> > >>>>>> service function paths regardless of the actual service. >> > >>>>>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >> > >>>>>> encapsulation, >> > a >> > >>>> new >> > >>>>>> encapsulation format >> > >>>>>> or an ability to select one encapsulation format=20 >> > >>>>>> that >> > >>>> fits >> > >>>>>> the >> > >>>>>> need for a given service chain? >> > >>>>>> The ability to select a specific encapsulation=20 >> > >>>>>> would be >> > >> a >> > >>>>>> management plane decision. >> > >>>>>> There are quite a few existing encapsulation=20 >> > >>>>>> methods that >> > >>>> can >> > >>>>>> possibly be reused to provide >> > >>>>>> context information between service nodes. I have >> > seen >> > >>>>>> mention >> > >>>>>> of GRE, for HTTP based >> > >>>>>> applications contexts are transferred via headers. >> > >>>>>> >> > >>>>>> >> > >>>>>> -----Original Message----- >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> > >>>>>> Behalf >> > >> Of >> > >>>>>> Thomas Narten >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> > >>>>>> To: nsc@ietf.org >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> > >>>>>> >> > >>>>>> Hi. >> > >>>>>> >> > >>>>>> Current charter can be found at >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> > >>>>>> ietf-sfc/. >> > >>>>>> >> > >>>>>> It contains the revised management text as well as updated >> > >>>> milestones. >> > >>>>>> >> > >>>>>> All known issues have been addressed. If there are any=20 >> > >>>>>> remaining >> > >>>> issues, >> > >>>>>> please speak up! >> > >>>>>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> > >>>>>> >> > >>>>>> Networks, servers, storage technologies, and applications,=20 >> > >>>>>> have all undergone significant change in recent years with=20 >> > >>>>>> the introduction >> > >> of >> > >>>>>> virtualization, network overlays, and orchestration. Service >> > >> delivery >> > >>>> is >> > >>>>>> currently both a technical and organizational challenge that >> > >> involves >> > >>>>>> significant modification to the network configuration. >> > >>>>>> Services are typically implemented by the ordered=20 >> > >>>>>> combination of a number of service functions that are=20 >> > >>>>>> deployed at different points within >> > >> the >> > >>>>>> network. Today, a common deployment model has service=20 >> > >>>>>> functions physically inserted on the data forwarding path=20 >> > >>>>>> between communicating peers. >> > >>>> Going >> > >>>>>> forward, however, there is a desire to move to a different=20 >> > >>>>>> model, >> > >>>> where >> > >>>>>> service functions are not required to reside on the default=20 >> > >>>>>> data >> > >> path >> > >>>>>> and >> > >>>>>> traffic is instead steered through services, wherever they=20 >> > >>>>>> are >> > >>>> deployed. >> > >>>>>> >> > >>>>>> For a given service, the abstracted view of the required=20 >> > >>>>>> service functions and the order in which they are to be=20 >> > >>>>>> applied is >> > called >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >> > >>>>>> function may be available on more than one node within a=20 >> > >>>>>> network, a Service Function Chain is instantiated >> > >>>> via >> > >>>>>> the selection of specific service function instances and the=20 >> > >>>>>> network nodes on which they are provided, thereby forming a=20 >> > >>>>>> service topology: >> > >>>>>> this is called a Service Function Path. The service=20 >> > >>>>>> functions >> > may >> > >>>>>> be applied at a specific layer within the network protocol=20 >> > >>>>>> stack >> > >>>> (network >> > >>>>>> layer, application layer, etc.). >> > >>>>>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >> > >>>>>> develop new approaches to service delivery and deployment.=20 >> > >>>>>> It will produce a framework for service function chaining=20 >> > >>>>>> that includes the necessary protocols >> > >>>> or >> > >>>>>> protocol extensions to convey the service path and service=20 >> > >>>>>> path information to nodes that implement service functions,=20 >> > >>>>>> as well >> > as >> > >>>>>> mechanisms for steering traffic through service functions. >> > >>>>>> The >> > >>>> working >> > >>>>>> group will also examine what information needs to be=20 >> > >>>>>> gathered from >> > >>>> the >> > >>>>>> network and service functions in support of service function >> > >> chaining >> > >>>>>> and >> > >>>>>> how that information may be made available to nodes that=20 >> > >>>>>> implement >> > >>>> the >> > >>>>>> service functions. >> > >>>>>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the following: >> > >>>>>> >> > >>>>>> 1) Problem Statement: This document will provide a summary=20 >> > >>>>>> of >> > the >> > >>>>>> problem space to be addressed by the WG including example >> > high- >> > >>>>>> level use cases. Additionally, the WG will normalize >> > >> nomenclature >> > >>>>>> and definitions for service function chaining. >> > >>>>>> >> > >>>>>> 2) Architecture: This document will provide a description of >>the >> > >>>>>> architectural building blocks and their relationships >> > including >> > >>>>>> interconnection, placement of capabilities, management, >> > >>>>>> diagnostics, design analysis, and security models, as=20 >> > >>>>>> well >>as >> > >>>>>> requirements on the protocol mechanisms. >> > >>>>>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >> > >>>>>> document >> > will >> > >>>>>> describe the single service-level data plane=20 >> > >>>>>> encapsulation >> > >> format >> > >>>>>> for >> > >>>>>> conveying the service function chain and the service=20 >> > >>>>>> function >> > >>>> path, >> > >>>>>> and for communicating context information between nodes that >> > >>>>>> implement service functions. It is intended that the >> > >>>> encapsulation >> > >>>>>> be agnostic to the layer at which it is applied and the=20 >> > >>>>>> service >> > >>>> that >> > >>>>>> is >> > >>>>>> being constructed. That is, the same encapsulation may be >> > used >> > >> on >> > >>>>>> a service function path realized at the network layer or=20 >> > >>>>>> at any other >> > >>>>>> layer, and the same encapsulation will apply for the >> > >> construction >> > >>>> of >> > >>>>>> service function paths regardless of the actual service. >> > >>>>>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> > developed to >> > >>>>>> describe requirements and protocols necessary to convey >> > >>>> information >> > >>>>>> to service function implementation points. Where=20 >> > >>>>>> possible, >> > >>>> existing >> > >>>>>> IETF protocols will be used and extended. All protocol >> > >> extensions >> > >>>>>> work should be carried out in the working groups=20 >> > >>>>>> responsible for >> > >>>> the >> > >>>>>> protocols being modified in coordination with this=20 >> > >>>>>> working >> > >> group, >> > >>>>>> but >> > >>>>>> may be done in this working group after agreement with=20 >> > >>>>>> all >> > the >> > >>>>>> relevant WG chairs and responsible ADs. >> > >>>>>> >> > >>>>>> 5) Manageability: Work on the management and configuration=20 >> > >>>>>> of >> > >> service >> > >>>>>> functions in support of SFC components will certainly be >> > needed, >> > >>>>>> but first needs to be better understood and scoped. >> > >>>>>> >> > >>>>>> Proposed Milestones >> > >>>>>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining=20 >> > >>>>>> the >> > >>>> problem >> > >>>>>> statement and core use cases for Service Function Chaining >> > >>>>>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >> > >>>>>> modifications for management and configuration of SFC=20 >> > >>>>>> components >> > >>>>>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining the >> > >>>> architecture >> > >>>>>> for SFC >> > >>>>>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 >> > >>>>>> function chaining encapsulation protocol >> > >>>>>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying=20 >> > >>>>>> the >> > >>>> generic >> > >>>>>> service function chaining header encapsulation >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> >> > >>>>>> Thomas >> > >>>>>> >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>>> _______________________________________________ >> > >>>>>> nsc mailing list >> > >>>>>> nsc@ietf.org >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> > >>>>> _______________________________________________ >> > >>>>> nsc mailing list >> > >>>>> nsc@ietf.org >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> > > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 12 10:16:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3696D11E8169 for ; Tue, 12 Nov 2013 10:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLG9M2gNRETq for ; Tue, 12 Nov 2013 10:16:17 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 3003011E811B for ; Tue, 12 Nov 2013 10:16:14 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 20E777AEE91; Tue, 12 Nov 2013 13:16:14 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EB4497AEE20; Tue, 12 Nov 2013 13:16:12 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Tue, 12 Nov 2013 13:16:12 -0500 From: Kevin J Ma To: "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Date: Tue, 12 Nov 2013 13:16:09 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAL/tAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgD//5OPgAAFtUDw Message-ID: <291CC3F9E50E7641901A54E85D0977C6B0280261A2@MAILR002.mail.lan> 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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:16:26 -0000 > for that matter the L2/L3 devices. Hi Surrendra, An overly large focus on L2/L3 is a red flag for me. Can we assume your statement was just an exercise in hyperbole? The services being discussed are L5-7 services and it's not clear that L2/L3/L4 classification is sufficient to define chains for some of these application layer services? thanx. -- Kevin J. Ma > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Tuesday, November 12, 2013 12:26 PM > To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: Re: [nsc] Current Proposed SFC charter > > Ron, > > Classification of traffic is well understood and we do not have to > redefine it - it's been around for all the time middle boxes have been or > for that matter the L2/L3 devices. All we are talking about is the > applicability of the classification to branching in SFC. > > You are right, it is all about policy which is outside the scope of SFC. > > Surendra. > > On 11/12/13 7:53 AM, "Ron Parker" wrote= : > > >I think the lack of definition of "reclassification" may be causing some > >misunderstandings here. A branch would occur for some policy-driven > >reason based on the behavior and conclusions of the service function, > >itself. The graph would represent the fact that there is a branch > >point, but the service function, itself, being aware that it is a > >branching point would contain the policy and logic to decide on which > >branch to take. Specifying that policy and logic is out of scope, IMO. > > > > Ron > > > > > >-----Original Message----- > >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >Sent: Tuesday, November 12, 2013 10:49 AM > >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra Maje= e > >Subject: RE: [nsc] Current Proposed SFC charter > > > >Hi Linda, > > > > Are you saying that a branching point is "never" a reclassification > > point, or are you saying that a branching point "does not have to be" > > a reclassification point? > > > > I think this is an important distinction that needs to be clarified. > > If branching is never reclassification, then the meaning of a chain > > is different than I originally inferred. If the chain is a tree with > > other "branching" points in it, then that limits the scope of the > > problem statement goals. > > > > While this could be a degenerate case, and any implementation could > > define bad service chains, is it the intent of SFC to only look at > > the simpler packet-level classification cases, or is it the intent > > to consider the case where a branching point is viewed as a > > re-classification point? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> Sent: Tuesday, November 12, 2013 10:34 AM > >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> Majee > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Ron, > >> > >> First, want to make it clear that "branching" !=3D reclassification, > >>agree? > >> > >> Second, the representation of branching (or service graph) can be in a > >> form of logic on a service function. Some service functions, > >> especially L7 based, can use value in a Database to determine what is > >> the next service function. > >> > >> Linda > >> > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 8:16 AM > >> > To: Hongyu Li (Julio); Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hongyu, > >> > > >> > I agree completely that re-classification is not limited to DPI. > >> > > >> > And also, that an area for us to explore as a group is how to > >>represent > >> > the service graph. Do we want to represent it as a proper graph > with > >> > an adjacency list or other representational model? Or, do we want > to > >> > represent it as a set of linear segments and if so, how are the > >> > segments connected into a graph? Other ideas? > >> > > >> > Ron > >> > > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Hongyu Li (Julio) > >> > Sent: Tuesday, November 12, 2013 6:57 AM > >> > To: Ron Parker; Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Branching/forking is a very interesting topic of SFC. About the re- > >> > classification point, probably we shall not limit it to DPI. It is > >> > also possible that packets go to different branches after been > >> > processed by a certain service function, decision of which branches > >> > to go is made based on the result of service function's process, > >> > i.e. not just re- classification by DPI. > >> > > >> > Hongyu > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 7:45 PM > >> > To: Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hi, Kevin > >> > > >> > You ask a great question about branching the graph. The details > >> > around how to convey the selection of the subtree/subgraph are still > >>to be > >> > defined. Is it one chain id for the whole graph? Does each branc= h > >> > have its own chain id? Some combination? > >> > > >> > Ron > >> > > >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > >> > > >> > wrote: > >> > > >> > >> Yes, reclassification can change the service path and > >> > >> re-classification may happen at any node along a service path. > >> > > > >> > > Just to expand on that, going back to the original question about > >> > > service header encapsulation, is it intended that a chain that is > >> > > re-classified will get a new chain ID which fully describes a > >> > > chain that is a superset of the original chain ID, prior to > >> > > DPI-based re-classification? (assuming the goal is "a single > >> > > chain ID that is commonly understood along the entire service > chain" > >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >> > > > >> > > And the applicable subset of the permutative list of service paths > >> > > would be configured at each appropriate service node? > >> > > e.g., ID 1: NAT + firewall + DPI > >> > > ID 2: NAT + firewall + DPI + AV > >> > > ID 3: NAT + firewall + DPI + AV + NAT > >> > > ID 4: NAT + firewall + DPI + NAT > >> > > ID 5: NAT + firewall + DPI + AV + LB > >> > > ID 6: NAT + firewall + DPI + LB > >> > > ID 7: NAT + firewall + DPI + LB + CACHE > >> > > ID 8: NAT + firewall + DPI + CACHE > >> > > ID 9: NAT + firewall + DPI + optimizer + LB > >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > >> > > flow then be initially classified as ID 1, but eventually get re- > >> > classified > >> > > to ID 2-11, after the DPI phase? > >> > > > >> > > thanx. > >> > > > >> > > -- Kevin J. Ma > >> > > > >> > >> -----Original Message----- > >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >> Sent: Tuesday, November 12, 2013 1:01 AM > >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >> > >> nsc@ietf.org > >> > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> > >> > >> > >> > >> > >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > >>wrote: > >> > >>> > >> > >>> Hi Surendra, > >> > >>> > >> > >>> Classification may be out of scope, but the level of service > >> > >>> that > >> > is > >> > >>> applicable is dependent upon the level of classification that > >> > >>> can > >> > be > >> > >>> performed. An assumption of packet level encapsulation has > >> > >> implications > >> > >>> on the level of classification being performed? If the stated > >> > goals > >> > >> are > >> > >>> for firewall and load balancer functionality, then the > >> > >>> application > >> > >> level > >> > >>> nature of those functions needs to be taken into account? If, > >> > >>> on the other hand, the service function scope is limited due to > >> > >>> limitations in classification, that would be and important piece > >> > >>> of > >> > information? > >> > >>> > >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > >> > >>> points of the service paths seem like re-classification points? > >> > >>> Is that the interpretation from the architecture perspective? > >> > >>> Or is the service function chain classification exclusive of DPI > >> > functionality? > >> > >> I have not fully read that draft yet. But in general, as > >> > >> described in the arch draft, the collection of services form a > >> > >> graph, segments of which are service paths. Yes, reclassification > >> > >> can > >> > change > >> > >> the service path and re-classification may happen at any node > >> > >> along > >> > a service path. > >> > >> > >> > >> Surendra. > >> > >>> > >> > >>> thanx. > >> > >>> > >> > >>> -- Kevin J. Ma > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >> > >>>> nsc@ietf.org > >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>> > >> > >>>> Kevin, > >> > >>>> > >> > >>>> Classification mechanism is outside the scope of SFC. It can be > >> > >>>> based > >> > >> on > >> > >>>> the packet or information not in the packet(environmental > >> > >>>> attributes > >> > >> for > >> > >>>> instance) or a combination thereof. What is important is that > >> > >>>> such classification aids in traffic selection and service path > >> > >>>> identification. > >> > >>>> It is no different from a policy in this regard except that the > >> > >>>> policy now specifies the service path. > >> > >>>> Further, classification is not limited to the network elements > >> > >>>> but the service functions as well. Some of this is described in > >> > >>>> the > >> > >> architecture > >> > >>>> drafts as well - > >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >> > >>>> > >> > >>>> Surendra. > >> > >>>> > >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > >> > wrote: > >> > >>>>> > >> > >>>>> Hi Ron, > >> > >>>>> > >> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > >> > >>>>> but I had a similar question wrt bullet 11 in section 2 of the > >> > problem > >> > >>>>> statement: > >> > >>>>> > >> > >>>>> 11. Per-Service (re)Classification: Classification occurs > >> > >>>>> at > >> > each > >> > >>>>> service, independent from previously applied service > >> > >>>> functions. > >> > >>>>> These unrelated classification events consume resources > >> > per > >> > >>>>> service. More importantly, the classification > >> > functionality > >> > >>>>> often differs per service function and service function > >> > >> cannot > >> > >>>>> leverage the results from other deployed network or > >> > service. > >> > >>>>> > >> > >>>>> as it relates to section 5.2 of the framework document: > >> > >>>>> > >> > >>>>> The SFC Classifier classifies packets based on (some of) the > >> > >>>> contents > >> > >>>>> of the packet header. Concretely, it classifies packets > >> > >>>>> based on > >> > >>>> the > >> > >>>>> possible combination of one or more header fields, such as > >> > source > >> > >>>>> address, destination address, DS field, protocol ID, source > >> > port > >> > >>>> and > >> > >>>>> destination port numbers, and any other information. > >> > >>>>> > >> > >>>>> A packet-based classifier as described in the framework > >> > >>>>> document > >> > >>>> would > >> > >>>>> seem to be limited in what it can classify? The service > >> > >>>>> function identifier lookup does not seem to be a significant > >> > >>>>> optimization > >> > >> over > >> > >>>>> a packet-based 5-tuple lookup? There seems to be some missing > >> > >> detail > >> > >>>>> wrt how classification information is determined and reused? > >> > >>>>> > >> > >>>>> When thinking about higher level services, e.g., HTTP and TLS > >> > >>>> encrypted > >> > >>>>> flows, a packet-based classifier seems inadequate? I was also > >> > >>>> wondering > >> > >>>>> how independent HLS segment requests might be classified and > >> > >>>> associated? > >> > >>>>> Were these types of use cases discussed in the BoF? > >> > >>>>> > >> > >>>>> thanx. > >> > >>>>> > >> > >>>>> -- Kevin J. Ma > >> > >>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Ron > >> > >>>>>> Parker > >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As was discussed in Vancouver, there are already many > >> > >>>>>> existing ways > >> > >>>> to > >> > >>>>>> accomplish service chaining. But none of them provide a > >> > >>>> sufficient > >> > >>>>>> combination of interoperability, flexibility, and resiliency. > >> > A > >> > >>>> single > >> > >>>>>> service chain encapsulation will go a long way to ensuring > >> > >>>>>> these > >> > >>>> goals. > >> > >>>>>> It may not be the absolutely most efficient approach for > >> > >>>>>> every > >> > >>>> single > >> > >>>>>> network topology and every single use case, but its > >> > >>>>>> ubiquitous > >> > >> nature > >> > >>>>>> should improve its adoption. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> Absolutely, that was an example of one type of derivation. > >> > >>>>>> However > >> > >>>> this > >> > >>>>>> could be augmented with classification result, again one more > >> > >>>> example. > >> > >>>>>> > >> > >>>>>>>> All flows from the same source IP do not necessarily follow > >> > the > >> > >>>> same > >> > >>>>>> chain. > >> > >>>>>> Correct. It is also not necessary that all transaction of the > >> > >>>>>> same > >> > >>>> flow > >> > >>>>>> follow the same chain either. So why stop at flow itself. > >> > >>>>>> > >> > >>>>>> Again the point here is that do we always need SFC header or > >>Not. > >> > >>>>>> > >> > >>>>>> Sumandra > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> The intention of service function chaining is to allow for > >> > >>>>>> operation > >> > >>>> at > >> > >>>>>> the fully qualified flow level, or even finer grained at the > >> > >>>> transaction > >> > >>>>>> level (this is an implementation matter for the PDP). All > >> > flows > >> > >>>> from > >> > >>>>>> the same source IP do not necessarily follow the same chain. > >> > >> Source > >> > >>>>>> IP, > >> > >>>>>> therefore, does not identify the chain ID. Another > >>intention > >> > of > >> > >>>>>> service function chaining is to operate over any network > >> > topology > >> > >> and > >> > >>>>>> not > >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > >> > the > >> > >>>>>> transport, it does not adequately identify the service chain, > >> > >> either. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> The service header is meant to carry the context which can > >> > *also* > >> > >>>>>> be derived (for example use source ip and vlan to identify > >> > >>>>>> chainID and > >> > >>>>>> position) or encapsulated as part of another tunnel header. > >> > >>>>>> So this could be optional IMHO. > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF > >> > >>>>>> or from > >> > >>>> SF > >> > >>>>>> to > >> > >>>>>> SF will look like: > >> > >>>>>> > >> > >>>>>> +------------------------+ > >> > >>>>>> | "transport" | > >> > >>>>>> +------------------------+ > >> > >>>>>> | service header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | original IP header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | | original IP > >> > >>>>>> | payload > >> > | > >> > >>>>>> | | > >> > >>>>>> +------------------------+ > >> > >>>>>> > >> > >>>>>> Where service header contains, at a minimum, enough > >> > >>>>>> information to > >> > >>>> allow > >> > >>>>>> the packet to be propagated along the full length of the > >> > >>>>>> chain, and optionally, other metadata that enhances the > >> > >>>>>> operation of > >> > one > >> > >>>>>> or > >> > >> more > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> And where "transport" could conceivably be any of, but not > >> > >>>>>> limited > >> > >>>> to: > >> > >>>>>> > >> > >>>>>> * Ethernet > >> > >>>>>> * Ethernet + LLC2 > >> > >>>>>> * Ethernet + MPLS > >> > >>>>>> * Ethernet + IP + GRE > >> > >>>>>> * Ethernet + IP +UDP > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Also, "original" in the diagram above is not meant to imply > >> > >>>>>> immutability, but rather to specify the packet that is > >> > propagated > >> > >>>>>> from preceding entity to succeeding entity, prior to > >> > >>>>>> encapsulation. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Sumandra Majee > >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > >> > >>>>>> To: Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Generic Service Function Chaining Encapsulation: A document > >>will > >> > >>>>>> describe the single service-level data plane encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer or > >> > >>>>>> at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> [SM] What does it mean by a single service-level > >> > >>>>>> encapsulation, > >> > a > >> > >>>> new > >> > >>>>>> encapsulation format > >> > >>>>>> or an ability to select one encapsulation format > >> > >>>>>> that > >> > >>>> fits > >> > >>>>>> the > >> > >>>>>> need for a given service chain? > >> > >>>>>> The ability to select a specific encapsulation > >> > >>>>>> would be > >> > >> a > >> > >>>>>> management plane decision. > >> > >>>>>> There are quite a few existing encapsulation methods > >> > >>>>>> that > >> > >>>> can > >> > >>>>>> possibly be reused to provide > >> > >>>>>> context information between service nodes. I have > >> > seen > >> > >>>>>> mention > >> > >>>>>> of GRE, for HTTP based > >> > >>>>>> applications contexts are transferred via headers. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Thomas Narten > >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >> > >>>>>> To: nsc@ietf.org > >> > >>>>>> Subject: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Hi. > >> > >>>>>> > >> > >>>>>> Current charter can be found at > >> > >>>>>> https://datatracker.ietf.org/doc/charter- > >> > >>>>>> ietf-sfc/. > >> > >>>>>> > >> > >>>>>> It contains the revised management text as well as updated > >> > >>>> milestones. > >> > >>>>>> > >> > >>>>>> All known issues have been addressed. If there are any > >> > >>>>>> remaining > >> > >>>> issues, > >> > >>>>>> please speak up! > >> > >>>>>> > >> > >>>>>> Charter charter-ietf-sfc-00-04 > >> > >>>>>> > >> > >>>>>> Networks, servers, storage technologies, and applications, > >> > >>>>>> have all undergone significant change in recent years with > >> > >>>>>> the introduction > >> > >> of > >> > >>>>>> virtualization, network overlays, and orchestration. Service > >> > >> delivery > >> > >>>> is > >> > >>>>>> currently both a technical and organizational challenge that > >> > >> involves > >> > >>>>>> significant modification to the network configuration. > >> > >>>>>> Services are typically implemented by the ordered combination > >> > >>>>>> of a number of service functions that are deployed at > >> > >>>>>> different points within > >> > >> the > >> > >>>>>> network. Today, a common deployment model has service > >> > >>>>>> functions physically inserted on the data forwarding path > >> > >>>>>> between communicating peers. > >> > >>>> Going > >> > >>>>>> forward, however, there is a desire to move to a different > >> > >>>>>> model, > >> > >>>> where > >> > >>>>>> service functions are not required to reside on the default > >> > >>>>>> data > >> > >> path > >> > >>>>>> and > >> > >>>>>> traffic is instead steered through services, wherever they > >> > >>>>>> are > >> > >>>> deployed. > >> > >>>>>> > >> > >>>>>> For a given service, the abstracted view of the required > >> > >>>>>> service functions and the order in which they are to be > >> > >>>>>> applied is > >> > called > >> > >>>>>> a Service Function Chain (SFC). Since a given service > >> > >>>>>> function may be available on more than one node within a > >> > >>>>>> network, a Service Function Chain is instantiated > >> > >>>> via > >> > >>>>>> the selection of specific service function instances and the > >> > >>>>>> network nodes on which they are provided, thereby forming a > >> > >>>>>> service topology: > >> > >>>>>> this is called a Service Function Path. The service functions > >> > may > >> > >>>>>> be applied at a specific layer within the network protocol > >> > >>>>>> stack > >> > >>>> (network > >> > >>>>>> layer, application layer, etc.). > >> > >>>>>> > >> > >>>>>> The Service Function Chaining (SFC) working group will > >> > >>>>>> develop new approaches to service delivery and deployment. It > >> > >>>>>> will produce a framework for service function chaining that > >> > >>>>>> includes the necessary protocols > >> > >>>> or > >> > >>>>>> protocol extensions to convey the service path and service > >> > >>>>>> path information to nodes that implement service functions, > >> > >>>>>> as well > >> > as > >> > >>>>>> mechanisms for steering traffic through service functions. > >> > >>>>>> The > >> > >>>> working > >> > >>>>>> group will also examine what information needs to be gathered > >> > >>>>>> from > >> > >>>> the > >> > >>>>>> network and service functions in support of service function > >> > >> chaining > >> > >>>>>> and > >> > >>>>>> how that information may be made available to nodes that > >> > >>>>>> implement > >> > >>>> the > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> Specifically, the SFC WG is chartered to deliver the > following: > >> > >>>>>> > >> > >>>>>> 1) Problem Statement: This document will provide a summary of > >> > the > >> > >>>>>> problem space to be addressed by the WG including example > >> > high- > >> > >>>>>> level use cases. Additionally, the WG will normalize > >> > >> nomenclature > >> > >>>>>> and definitions for service function chaining. > >> > >>>>>> > >> > >>>>>> 2) Architecture: This document will provide a description of > >>the > >> > >>>>>> architectural building blocks and their relationships > >> > including > >> > >>>>>> interconnection, placement of capabilities, management, > >> > >>>>>> diagnostics, design analysis, and security models, as well > >>as > >> > >>>>>> requirements on the protocol mechanisms. > >> > >>>>>> > >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A > >> > >>>>>> document > >> > will > >> > >>>>>> describe the single service-level data plane encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer or > >> > >>>>>> at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > >> > developed to > >> > >>>>>> describe requirements and protocols necessary to convey > >> > >>>> information > >> > >>>>>> to service function implementation points. Where possible, > >> > >>>> existing > >> > >>>>>> IETF protocols will be used and extended. All protocol > >> > >> extensions > >> > >>>>>> work should be carried out in the working groups > >> > >>>>>> responsible for > >> > >>>> the > >> > >>>>>> protocols being modified in coordination with this working > >> > >> group, > >> > >>>>>> but > >> > >>>>>> may be done in this working group after agreement with all > >> > the > >> > >>>>>> relevant WG chairs and responsible ADs. > >> > >>>>>> > >> > >>>>>> 5) Manageability: Work on the management and configuration of > >> > >> service > >> > >>>>>> functions in support of SFC components will certainly be > >> > needed, > >> > >>>>>> but first needs to be better understood and scoped. > >> > >>>>>> > >> > >>>>>> Proposed Milestones > >> > >>>>>> > >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining > >> > >>>>>> the > >> > >>>> problem > >> > >>>>>> statement and core use cases for Service Function Chaining > >> > >>>>>> > >> > >>>>>> May 2014 Consult with OPS Area on possible charter > >> > >>>>>> modifications for management and configuration of SFC > >> > >>>>>> components > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG Informational document defining the > >> > >>>> architecture > >> > >>>>>> for SFC > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > >> > >>>>>> function chaining encapsulation protocol > >> > >>>>>> > >> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying > >> > >>>>>> the > >> > >>>> generic > >> > >>>>>> service function chaining header encapsulation > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Thomas > >> > >>>>>> > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>> _______________________________________________ > >> > >>>>> nsc mailing list > >> > >>>>> nsc@ietf.org > >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > > > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Tue Nov 12 10:22:17 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179FA11E811B for ; Tue, 12 Nov 2013 10:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj54iPgF1ono for ; Tue, 12 Nov 2013 10:22:12 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9E11E810A for ; Tue, 12 Nov 2013 10:22:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32298; q=dns/txt; s=iport; t=1384280530; x=1385490130; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RSXnM/n1gAty2nTqSvlLYQH0Xax2/sJR1HxuxovF2No=; b=UfL2o1FuldCPgByx/n0zke4HRrUaPee8R0tjGGH2Kj51qj8v2Tyqhqqi AYd6cTLbPyRdAGyApNzXj3pH3H1jzKVNcudVHhJj+naxFf4gkIwuG4c2z PsbwikRQjmBk5eaxKgW2x9GHUHYHBcBKTDbOR1ZO7D5vfxUF7Ou0IyeBL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAGJxglKtJV2Z/2dsb2JhbABQCoMHOFO/F4EqFnSCJQEBAQMBAQEBFwEfKwIHBAcFBwYBCBEBAwEBARUJCS4LFAMGCAIEAQkEBQmHcgYNvyGOHAQBBQaBCCsCBQIEBIQnA5Qug2GSCoMmgWgBCBci X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283831720" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2013 18:22:09 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rACIM88l015307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:22:08 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:22:07 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8VdkHboHqNUmhtu4dv7SQ1ZohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWA//+UdICAACXDsP//6M6AgAAmVECAAL/tAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgD//5OPgAAFtUDw///iHgA= Date: Tue, 12 Nov 2013 18:22:07 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B0280261A2@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.85.152] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:22:17 -0000 I was just commenting on the classification definition. Surendra. On 11/12/13 10:16 AM, "Kevin J Ma" wrote: >> for that matter the L2/L3 devices. > >Hi Surrendra, > > An overly large focus on L2/L3 is a red flag for me. > Can we assume your statement was just an exercise in hyperbole? > > The services being discussed are L5-7 services and > it's not clear that L2/L3/L4 classification is sufficient > to define chains for some of these application layer services? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> Sent: Tuesday, November 12, 2013 12:26 PM >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to >> redefine it - it's been around for all the time middle boxes have been >>or >> for that matter the L2/L3 devices. All we are talking about is the >> applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a reclassification >> > point, or are you saying that a branching point "does not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a chain >> > is different than I originally inferred. If the chain is a tree with >> > other "branching" points in it, then that limits the scope of the >> > problem statement goals. >> > >> > While this could be a degenerate case, and any implementation could >> > define bad service chains, is it the intent of SFC to only look at >> > the simpler packet-level classification cases, or is it the intent >> > to consider the case where a branching point is viewed as a >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >> Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification, >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be in >>a >> >> form of logic on a service function. Some service functions, >> >> especially L7 based, can use value in a Database to determine what is >> >> the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> >> > Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >> > Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> >> > Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >> > Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the re- >> >> > classification point, probably we shall not limit it to DPI. It is >> >> > also possible that packets go to different branches after been >> >> > processed by a certain service function, decision of which branches >> >> > to go is made based on the result of service function's process, >> >> > i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >> >> > Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >> > Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details >> >> > around how to convey the selection of the subtree/subgraph are >>still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question about >> >> > > service header encapsulation, is it intended that a chain that is >> >> > > re-classified will get a new chain ID which fully describes a >> >> > > chain that is a superset of the original chain ID, prior to >> >> > > DPI-based re-classification? (assuming the goal is "a single >> >> > > chain ID that is commonly understood along the entire service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> >> > > >> >> > > And the applicable subset of the permutative list of service >>paths >> >> > > would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >> >> > > flow then be initially classified as ID 1, but eventually get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification that >> >> > >>> can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? If, >> >> > >>> on the other hand, the service function scope is limited due to >> >> > >>> limitations in classification, that would be and important >>piece >> >> > >>> of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>fork >> >> > >>> points of the service paths seem like re-classification points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of >>DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as >> >> > >> described in the arch draft, the collection of services form a >> >> > >> graph, segments of which are service paths. Yes, >>reclassification >> >> > >> can >> >> > change >> >> > >> the service path and re-classification may happen at any node >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It can >>be >> >> > >>>> based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is that >> >> > >>>> such classification aids in traffic selection and service path >> >> > >>>> identification. >> >> > >>>> It is no different from a policy in this regard except that >>the >> >> > >>>> policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network elements >> >> > >>>> but the service functions as well. Some of this is described >>in >> >> > >>>> the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >> >> > >>>>> but I had a similar question wrt bullet 11 in section 2 of >>the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification occurs >> >> > >>>>> at >> >> > each >> >> > >>>>> service, independent from previously applied service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume >>resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service >>function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of) >>the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID, source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service >> >> > >>>>> function identifier lookup does not seem to be a significant >> >> > >>>>> optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > >>>>>> Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to ensuring >> >> > >>>>>> these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one >>more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily >>follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of >>the >> >> > >>>>>> same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow for >> >> > >>>>>> operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service >>chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to identify >> >> > >>>>>> chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF >> >> > >>>>>> or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the >> >> > >>>>>> chain, and optionally, other metadata that enhances the >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but not >> >> > >>>>>> limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to imply >> >> > >>>>>> immutability, but rather to specify the packet that is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > >>>>>> Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A document >> >>will >> >> > >>>>>> describe the single service-level data plane >>encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and the >> >> > >>>>>> service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer or >> >> > >>>>>> at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation format >> >> > >>>>>> that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation >>methods >> >> > >>>>>> that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > >>>>>> Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and applications, >> >> > >>>>>> have all undergone significant change in recent years with >> >> > >>>>>> the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered >>combination >> >> > >>>>>> of a number of service functions that are deployed at >> >> > >>>>>> different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service >> >> > >>>>>> functions physically inserted on the data forwarding path >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a different >> >> > >>>>>> model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the default >> >> > >>>>>> data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever they >> >> > >>>>>> are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required >> >> > >>>>>> service functions and the order in which they are to be >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service >> >> > >>>>>> function may be available on more than one node within a >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and the >> >> > >>>>>> network nodes on which they are provided, thereby forming a >> >> > >>>>>> service topology: >> >> > >>>>>> this is called a Service Function Path. The service >>functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network protocol >> >> > >>>>>> stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will >> >> > >>>>>> develop new approaches to service delivery and deployment. >>It >> >> > >>>>>> will produce a framework for service function chaining that >> >> > >>>>>> includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and service >> >> > >>>>>> path information to nodes that implement service functions, >> >> > >>>>>> as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be >>gathered >> >> > >>>>>> from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a summary >>of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as >>well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane >>encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and the >> >> > >>>>>> service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer or >> >> > >>>>>> at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where >>possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this >>working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with >>all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and configuration >>of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining >> >> > >>>>>> the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter >> >> > >>>>>> modifications for management and configuration of SFC >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service >> >> > >>>>>> function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying >> >> > >>>>>> the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc > From kevin.ma@azukisystems.com Tue Nov 12 10:27:33 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305F321E8122 for ; Tue, 12 Nov 2013 10:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8KxnhH7BSmb for ; Tue, 12 Nov 2013 10:27:29 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5E59311E810B for ; Tue, 12 Nov 2013 10:27:28 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E11C18BF050; Tue, 12 Nov 2013 13:27:27 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id B32468BF0A0; Tue, 12 Nov 2013 13:27:26 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 12 Nov 2013 13:27:26 -0500 From: Kevin J Ma To: "David Lake (dlake)" , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Date: Tue, 12 Nov 2013 13:27:24 -0500 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgAB1UoCAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugP//o12wgAAIhXA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6B0280261BF@MAILR002.mail.lan> References: <3512BB31280C39448A9880F61DD54CEB0C8E9EE0@xmb-aln-x09.cisco.com> In-Reply-To: <3512BB31280C39448A9880F61DD54CEB0C8E9EE0@xmb-aln-x09.cisco.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:27:33 -0000 > In those circumstances, only the end applications themselves or a > reasonably broad-brushed classification (really traffic steering based on > what we can see at ingress) is going to be useful - is THAT what we're > aiming for here ? I would certainly hope not, but that has been my concern as well. Application layer termination and re-classification seems a must? -- Kevin J. Ma > -----Original Message----- > From: David Lake (dlake) [mailto:dlake@cisco.com] > Sent: Tuesday, November 12, 2013 1:00 PM > To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; Hongy= u > Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Policy may be outside of the scope of SFC, but without strong mapping > between Policy and the inserted Service Header(s), we run-the-risk of > limiting the efficacy of the protocol IMO. > > For example, in a world where the network has "gone dark," (as per the > IETF Technical Plenary ?:-) ) what is our ability to determine policy > based on DPI of packets-in-flight ? > > In those circumstances, only the end applications themselves or a > reasonably broad-brushed classification (really traffic steering based on > what we can see at ingress) is going to be useful - is THAT what we're > aiming for here ? > > David > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Surendra Kumar (smkumar) > Sent: 12 November 2013 09:26 > To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: Re: [nsc] Current Proposed SFC charter > > Ron, > > Classification of traffic is well understood and we do not have to > redefine it - it's been around for all the time middle boxes have been or > for that matter the L2/L3 devices. All we are talking about is the > applicability of the classification to branching in SFC. > > You are right, it is all about policy which is outside the scope of SFC. > > Surendra. > > On 11/12/13 7:53 AM, "Ron Parker" wrote= : > > >I think the lack of definition of "reclassification" may be causing some > >misunderstandings here. A branch would occur for some policy-driven > >reason based on the behavior and conclusions of the service function, > >itself. The graph would represent the fact that there is a branch > >point, but the service function, itself, being aware that it is a > >branching point would contain the policy and logic to decide on which > >branch to take. Specifying that policy and logic is out of scope, IMO. > > > > Ron > > > > > >-----Original Message----- > >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >Sent: Tuesday, November 12, 2013 10:49 AM > >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >Majee > >Subject: RE: [nsc] Current Proposed SFC charter > > > >Hi Linda, > > > > Are you saying that a branching point is "never" a reclassification > > point, or are you saying that a branching point "does not have to be" > > a reclassification point? > > > > I think this is an important distinction that needs to be clarified. > > If branching is never reclassification, then the meaning of a chain > > is different than I originally inferred. If the chain is a tree with > > other "branching" points in it, then that limits the scope of the > > problem statement goals. > > > > While this could be a degenerate case, and any implementation could > > define bad service chains, is it the intent of SFC to only look at > > the simpler packet-level classification cases, or is it the intent to > > consider the case where a branching point is viewed as a > > re-classification point? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> Sent: Tuesday, November 12, 2013 10:34 AM > >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> Majee > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Ron, > >> > >> First, want to make it clear that "branching" !=3D reclassification, > >>agree? > >> > >> Second, the representation of branching (or service graph) can be in > >> a form of logic on a service function. Some service functions, > >> especially L7 based, can use value in a Database to determine what is > >> the next service function. > >> > >> Linda > >> > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 8:16 AM > >> > To: Hongyu Li (Julio); Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hongyu, > >> > > >> > I agree completely that re-classification is not limited to DPI. > >> > > >> > And also, that an area for us to explore as a group is how to > >>represent > >> > the service graph. Do we want to represent it as a proper graph > with > >> > an adjacency list or other representational model? Or, do we want > to > >> > represent it as a set of linear segments and if so, how are the > >> > segments connected into a graph? Other ideas? > >> > > >> > Ron > >> > > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Hongyu Li (Julio) > >> > Sent: Tuesday, November 12, 2013 6:57 AM > >> > To: Ron Parker; Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Branching/forking is a very interesting topic of SFC. About the re- > >> > classification point, probably we shall not limit it to DPI. It is > >> > also possible that packets go to different branches after been > >> > processed by a certain service function, decision of which branches > >> > to go is made based on the result of service function's process, > >> > i.e. not just re- classification by DPI. > >> > > >> > Hongyu > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > >> > Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 7:45 PM > >> > To: Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra > >> > Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hi, Kevin > >> > > >> > You ask a great question about branching the graph. The details > >> > around how to convey the selection of the subtree/subgraph are > >> > still > >>to be > >> > defined. Is it one chain id for the whole graph? Does each branc= h > >> > have its own chain id? Some combination? > >> > > >> > Ron > >> > > >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > >> > > >> > wrote: > >> > > >> > >> Yes, reclassification can change the service path and > >> > >> re-classification may happen at any node along a service path. > >> > > > >> > > Just to expand on that, going back to the original question about > >> > > service header encapsulation, is it intended that a chain that is > >> > > re-classified will get a new chain ID which fully describes a > >> > > chain that is a superset of the original chain ID, prior to > >> > > DPI-based re-classification? (assuming the goal is "a single > >> > > chain ID that is commonly understood along the entire service > chain" > >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >> > > > >> > > And the applicable subset of the permutative list of service > >> > > paths would be configured at each appropriate service node? > >> > > e.g., ID 1: NAT + firewall + DPI > >> > > ID 2: NAT + firewall + DPI + AV > >> > > ID 3: NAT + firewall + DPI + AV + NAT > >> > > ID 4: NAT + firewall + DPI + NAT > >> > > ID 5: NAT + firewall + DPI + AV + LB > >> > > ID 6: NAT + firewall + DPI + LB > >> > > ID 7: NAT + firewall + DPI + LB + CACHE > >> > > ID 8: NAT + firewall + DPI + CACHE > >> > > ID 9: NAT + firewall + DPI + optimizer + LB > >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > >> > > flow then be initially classified as ID 1, but eventually get re- > >> > classified > >> > > to ID 2-11, after the DPI phase? > >> > > > >> > > thanx. > >> > > > >> > > -- Kevin J. Ma > >> > > > >> > >> -----Original Message----- > >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >> Sent: Tuesday, November 12, 2013 1:01 AM > >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >> > >> nsc@ietf.org > >> > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> > >> > >> > >> > >> > >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > >>wrote: > >> > >>> > >> > >>> Hi Surendra, > >> > >>> > >> > >>> Classification may be out of scope, but the level of service > >> > >>> that > >> > is > >> > >>> applicable is dependent upon the level of classification that > >> > >>> can > >> > be > >> > >>> performed. An assumption of packet level encapsulation has > >> > >> implications > >> > >>> on the level of classification being performed? If the stated > >> > goals > >> > >> are > >> > >>> for firewall and load balancer functionality, then the > >> > >>> application > >> > >> level > >> > >>> nature of those functions needs to be taken into account? If, > >> > >>> on the other hand, the service function scope is limited due to > >> > >>> limitations in classification, that would be and important > >> > >>> piece of > >> > information? > >> > >>> > >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the > >> > >>> fork points of the service paths seem like re-classification > points? > >> > >>> Is that the interpretation from the architecture perspective? > >> > >>> Or is the service function chain classification exclusive of > >> > >>> DPI > >> > functionality? > >> > >> I have not fully read that draft yet. But in general, as > >> > >> described in the arch draft, the collection of services form a > >> > >> graph, segments of which are service paths. Yes, > >> > >> reclassification can > >> > change > >> > >> the service path and re-classification may happen at any node > >> > >> along > >> > a service path. > >> > >> > >> > >> Surendra. > >> > >>> > >> > >>> thanx. > >> > >>> > >> > >>> -- Kevin J. Ma > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >> > >>>> nsc@ietf.org > >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>> > >> > >>>> Kevin, > >> > >>>> > >> > >>>> Classification mechanism is outside the scope of SFC. It can > >> > >>>> be based > >> > >> on > >> > >>>> the packet or information not in the packet(environmental > >> > >>>> attributes > >> > >> for > >> > >>>> instance) or a combination thereof. What is important is that > >> > >>>> such classification aids in traffic selection and service path > >> > >>>> identification. > >> > >>>> It is no different from a policy in this regard except that > >> > >>>> the policy now specifies the service path. > >> > >>>> Further, classification is not limited to the network elements > >> > >>>> but the service functions as well. Some of this is described > >> > >>>> in the > >> > >> architecture > >> > >>>> drafts as well - > >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >> > >>>> > >> > >>>> Surendra. > >> > >>>> > >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > >> > wrote: > >> > >>>>> > >> > >>>>> Hi Ron, > >> > >>>>> > >> > >>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > >> > >>>>> but I had a similar question wrt bullet 11 in section 2 of > >> > >>>>> the > >> > problem > >> > >>>>> statement: > >> > >>>>> > >> > >>>>> 11. Per-Service (re)Classification: Classification occurs > >> > >>>>> at > >> > each > >> > >>>>> service, independent from previously applied service > >> > >>>> functions. > >> > >>>>> These unrelated classification events consume > >> > >>>>> resources > >> > per > >> > >>>>> service. More importantly, the classification > >> > functionality > >> > >>>>> often differs per service function and service > >> > >>>>> function > >> > >> cannot > >> > >>>>> leverage the results from other deployed network or > >> > service. > >> > >>>>> > >> > >>>>> as it relates to section 5.2 of the framework document: > >> > >>>>> > >> > >>>>> The SFC Classifier classifies packets based on (some of) > >> > >>>>> the > >> > >>>> contents > >> > >>>>> of the packet header. Concretely, it classifies packets > >> > >>>>> based on > >> > >>>> the > >> > >>>>> possible combination of one or more header fields, such as > >> > source > >> > >>>>> address, destination address, DS field, protocol ID, source > >> > port > >> > >>>> and > >> > >>>>> destination port numbers, and any other information. > >> > >>>>> > >> > >>>>> A packet-based classifier as described in the framework > >> > >>>>> document > >> > >>>> would > >> > >>>>> seem to be limited in what it can classify? The service > >> > >>>>> function identifier lookup does not seem to be a significant > >> > >>>>> optimization > >> > >> over > >> > >>>>> a packet-based 5-tuple lookup? There seems to be some > >> > >>>>> missing > >> > >> detail > >> > >>>>> wrt how classification information is determined and reused? > >> > >>>>> > >> > >>>>> When thinking about higher level services, e.g., HTTP and TLS > >> > >>>> encrypted > >> > >>>>> flows, a packet-based classifier seems inadequate? I was > >> > >>>>> also > >> > >>>> wondering > >> > >>>>> how independent HLS segment requests might be classified and > >> > >>>> associated? > >> > >>>>> Were these types of use cases discussed in the BoF? > >> > >>>>> > >> > >>>>> thanx. > >> > >>>>> > >> > >>>>> -- Kevin J. Ma > >> > >>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Ron > >> > >>>>>> Parker > >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As was discussed in Vancouver, there are already many > >> > >>>>>> existing ways > >> > >>>> to > >> > >>>>>> accomplish service chaining. But none of them provide a > >> > >>>> sufficient > >> > >>>>>> combination of interoperability, flexibility, and resiliency. > >> > A > >> > >>>> single > >> > >>>>>> service chain encapsulation will go a long way to ensuring > >> > >>>>>> these > >> > >>>> goals. > >> > >>>>>> It may not be the absolutely most efficient approach for > >> > >>>>>> every > >> > >>>> single > >> > >>>>>> network topology and every single use case, but its > >> > >>>>>> ubiquitous > >> > >> nature > >> > >>>>>> should improve its adoption. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> Absolutely, that was an example of one type of derivation. > >> > >>>>>> However > >> > >>>> this > >> > >>>>>> could be augmented with classification result, again one > >> > >>>>>> more > >> > >>>> example. > >> > >>>>>> > >> > >>>>>>>> All flows from the same source IP do not necessarily > >> > >>>>>>>> follow > >> > the > >> > >>>> same > >> > >>>>>> chain. > >> > >>>>>> Correct. It is also not necessary that all transaction of > >> > >>>>>> the same > >> > >>>> flow > >> > >>>>>> follow the same chain either. So why stop at flow itself. > >> > >>>>>> > >> > >>>>>> Again the point here is that do we always need SFC header or > >>Not. > >> > >>>>>> > >> > >>>>>> Sumandra > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> The intention of service function chaining is to allow for > >> > >>>>>> operation > >> > >>>> at > >> > >>>>>> the fully qualified flow level, or even finer grained at the > >> > >>>> transaction > >> > >>>>>> level (this is an implementation matter for the PDP). All > >> > flows > >> > >>>> from > >> > >>>>>> the same source IP do not necessarily follow the same chain. > >> > >> Source > >> > >>>>>> IP, > >> > >>>>>> therefore, does not identify the chain ID. Another > >>intention > >> > of > >> > >>>>>> service function chaining is to operate over any network > >> > topology > >> > >> and > >> > >>>>>> not > >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > >> > the > >> > >>>>>> transport, it does not adequately identify the service > >> > >>>>>> chain, > >> > >> either. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> The service header is meant to carry the context which can > >> > *also* > >> > >>>>>> be derived (for example use source ip and vlan to identify > >> > >>>>>> chainID and > >> > >>>>>> position) or encapsulated as part of another tunnel header. > >> > >>>>>> So this could be optional IMHO. > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As I understand it, an SFC packet traversing from PDP to SF > >> > >>>>>> or from > >> > >>>> SF > >> > >>>>>> to > >> > >>>>>> SF will look like: > >> > >>>>>> > >> > >>>>>> +------------------------+ > >> > >>>>>> | "transport" | > >> > >>>>>> +------------------------+ > >> > >>>>>> | service header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | original IP header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | | original IP > >> > >>>>>> | payload > >> > | > >> > >>>>>> | | > >> > >>>>>> +------------------------+ > >> > >>>>>> > >> > >>>>>> Where service header contains, at a minimum, enough > >> > >>>>>> information to > >> > >>>> allow > >> > >>>>>> the packet to be propagated along the full length of the > >> > >>>>>> chain, and optionally, other metadata that enhances the > >> > >>>>>> operation of > >> > one > >> > >>>>>> or > >> > >> more > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> And where "transport" could conceivably be any of, but not > >> > >>>>>> limited > >> > >>>> to: > >> > >>>>>> > >> > >>>>>> * Ethernet > >> > >>>>>> * Ethernet + LLC2 > >> > >>>>>> * Ethernet + MPLS > >> > >>>>>> * Ethernet + IP + GRE > >> > >>>>>> * Ethernet + IP +UDP > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Also, "original" in the diagram above is not meant to imply > >> > >>>>>> immutability, but rather to specify the packet that is > >> > propagated > >> > >>>>>> from preceding entity to succeeding entity, prior to > >> > >>>>>> encapsulation. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Sumandra Majee > >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > >> > >>>>>> To: Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Generic Service Function Chaining Encapsulation: A document > >>will > >> > >>>>>> describe the single service-level data plane > >> > >>>>>> encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer or > >> > >>>>>> at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> [SM] What does it mean by a single service-level > >> > >>>>>> encapsulation, > >> > a > >> > >>>> new > >> > >>>>>> encapsulation format > >> > >>>>>> or an ability to select one encapsulation format > >> > >>>>>> that > >> > >>>> fits > >> > >>>>>> the > >> > >>>>>> need for a given service chain? > >> > >>>>>> The ability to select a specific encapsulation > >> > >>>>>> would be > >> > >> a > >> > >>>>>> management plane decision. > >> > >>>>>> There are quite a few existing encapsulation > >> > >>>>>> methods that > >> > >>>> can > >> > >>>>>> possibly be reused to provide > >> > >>>>>> context information between service nodes. I have > >> > seen > >> > >>>>>> mention > >> > >>>>>> of GRE, for HTTP based > >> > >>>>>> applications contexts are transferred via headers. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >> > >>>>>> Behalf > >> > >> Of > >> > >>>>>> Thomas Narten > >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >> > >>>>>> To: nsc@ietf.org > >> > >>>>>> Subject: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Hi. > >> > >>>>>> > >> > >>>>>> Current charter can be found at > >> > >>>>>> https://datatracker.ietf.org/doc/charter- > >> > >>>>>> ietf-sfc/. > >> > >>>>>> > >> > >>>>>> It contains the revised management text as well as updated > >> > >>>> milestones. > >> > >>>>>> > >> > >>>>>> All known issues have been addressed. If there are any > >> > >>>>>> remaining > >> > >>>> issues, > >> > >>>>>> please speak up! > >> > >>>>>> > >> > >>>>>> Charter charter-ietf-sfc-00-04 > >> > >>>>>> > >> > >>>>>> Networks, servers, storage technologies, and applications, > >> > >>>>>> have all undergone significant change in recent years with > >> > >>>>>> the introduction > >> > >> of > >> > >>>>>> virtualization, network overlays, and orchestration. Service > >> > >> delivery > >> > >>>> is > >> > >>>>>> currently both a technical and organizational challenge that > >> > >> involves > >> > >>>>>> significant modification to the network configuration. > >> > >>>>>> Services are typically implemented by the ordered > >> > >>>>>> combination of a number of service functions that are > >> > >>>>>> deployed at different points within > >> > >> the > >> > >>>>>> network. Today, a common deployment model has service > >> > >>>>>> functions physically inserted on the data forwarding path > >> > >>>>>> between communicating peers. > >> > >>>> Going > >> > >>>>>> forward, however, there is a desire to move to a different > >> > >>>>>> model, > >> > >>>> where > >> > >>>>>> service functions are not required to reside on the default > >> > >>>>>> data > >> > >> path > >> > >>>>>> and > >> > >>>>>> traffic is instead steered through services, wherever they > >> > >>>>>> are > >> > >>>> deployed. > >> > >>>>>> > >> > >>>>>> For a given service, the abstracted view of the required > >> > >>>>>> service functions and the order in which they are to be > >> > >>>>>> applied is > >> > called > >> > >>>>>> a Service Function Chain (SFC). Since a given service > >> > >>>>>> function may be available on more than one node within a > >> > >>>>>> network, a Service Function Chain is instantiated > >> > >>>> via > >> > >>>>>> the selection of specific service function instances and the > >> > >>>>>> network nodes on which they are provided, thereby forming a > >> > >>>>>> service topology: > >> > >>>>>> this is called a Service Function Path. The service > >> > >>>>>> functions > >> > may > >> > >>>>>> be applied at a specific layer within the network protocol > >> > >>>>>> stack > >> > >>>> (network > >> > >>>>>> layer, application layer, etc.). > >> > >>>>>> > >> > >>>>>> The Service Function Chaining (SFC) working group will > >> > >>>>>> develop new approaches to service delivery and deployment. > >> > >>>>>> It will produce a framework for service function chaining > >> > >>>>>> that includes the necessary protocols > >> > >>>> or > >> > >>>>>> protocol extensions to convey the service path and service > >> > >>>>>> path information to nodes that implement service functions, > >> > >>>>>> as well > >> > as > >> > >>>>>> mechanisms for steering traffic through service functions. > >> > >>>>>> The > >> > >>>> working > >> > >>>>>> group will also examine what information needs to be > >> > >>>>>> gathered from > >> > >>>> the > >> > >>>>>> network and service functions in support of service function > >> > >> chaining > >> > >>>>>> and > >> > >>>>>> how that information may be made available to nodes that > >> > >>>>>> implement > >> > >>>> the > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> Specifically, the SFC WG is chartered to deliver the > following: > >> > >>>>>> > >> > >>>>>> 1) Problem Statement: This document will provide a summary > >> > >>>>>> of > >> > the > >> > >>>>>> problem space to be addressed by the WG including example > >> > high- > >> > >>>>>> level use cases. Additionally, the WG will normalize > >> > >> nomenclature > >> > >>>>>> and definitions for service function chaining. > >> > >>>>>> > >> > >>>>>> 2) Architecture: This document will provide a description of > >>the > >> > >>>>>> architectural building blocks and their relationships > >> > including > >> > >>>>>> interconnection, placement of capabilities, management, > >> > >>>>>> diagnostics, design analysis, and security models, as > >> > >>>>>> well > >>as > >> > >>>>>> requirements on the protocol mechanisms. > >> > >>>>>> > >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A > >> > >>>>>> document > >> > will > >> > >>>>>> describe the single service-level data plane > >> > >>>>>> encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer or > >> > >>>>>> at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > >> > developed to > >> > >>>>>> describe requirements and protocols necessary to convey > >> > >>>> information > >> > >>>>>> to service function implementation points. Where > >> > >>>>>> possible, > >> > >>>> existing > >> > >>>>>> IETF protocols will be used and extended. All protocol > >> > >> extensions > >> > >>>>>> work should be carried out in the working groups > >> > >>>>>> responsible for > >> > >>>> the > >> > >>>>>> protocols being modified in coordination with this > >> > >>>>>> working > >> > >> group, > >> > >>>>>> but > >> > >>>>>> may be done in this working group after agreement with > >> > >>>>>> all > >> > the > >> > >>>>>> relevant WG chairs and responsible ADs. > >> > >>>>>> > >> > >>>>>> 5) Manageability: Work on the management and configuration > >> > >>>>>> of > >> > >> service > >> > >>>>>> functions in support of SFC components will certainly be > >> > needed, > >> > >>>>>> but first needs to be better understood and scoped. > >> > >>>>>> > >> > >>>>>> Proposed Milestones > >> > >>>>>> > >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining > >> > >>>>>> the > >> > >>>> problem > >> > >>>>>> statement and core use cases for Service Function Chaining > >> > >>>>>> > >> > >>>>>> May 2014 Consult with OPS Area on possible charter > >> > >>>>>> modifications for management and configuration of SFC > >> > >>>>>> components > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG Informational document defining the > >> > >>>> architecture > >> > >>>>>> for SFC > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service > >> > >>>>>> function chaining encapsulation protocol > >> > >>>>>> > >> > >>>>>> Aug 2015 Submit to IESG Standards Track document specifying > >> > >>>>>> the > >> > >>>> generic > >> > >>>>>> service function chaining header encapsulation > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Thomas > >> > >>>>>> > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>> _______________________________________________ > >> > >>>>> nsc mailing list > >> > >>>>> nsc@ietf.org > >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > > > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From dlake@cisco.com Tue Nov 12 10:36:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D0511E810B for ; Tue, 12 Nov 2013 10:36:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kcq9Z+1iE59u for ; Tue, 12 Nov 2013 10:36:37 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8329611E8167 for ; Tue, 12 Nov 2013 10:36:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34785; q=dns/txt; s=iport; t=1384281396; x=1385490996; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FWfYYMXvE3TPrf35xhhi+W4JxqTdvj/ZASmsyGW/go4=; b=CNXGhgUy/vnUDklnrTiChgfuPwfr8tG5zsPmdBc1MTkt4gDe5i5WwAn8 M/vUR6Xt+R+Oe1nDI5sKYkTge2CzE3k1yMa3+pg0MO0ETkPfuEKUm33A/ v2V87yGbdB/WJhtNPXClsIqdZIJxUmWmnagb79UZFL1jhFsdryVjodRq5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMSAKl0glKtJV2b/2dsb2JhbABQCoFxAgGBEzhTvxeBKhZ0giUBAQEDAQEBARcBHysCBwQHBQcEAgEIEQEDAQEBCgsJCQcnCxQDBggCBAEJBAUIAYdyBg2/JY4cBAEFBoECBisCBQIEBIMWgREDlC6Va4MmgWgBCBci X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283843783" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2013 18:36:31 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rACIaVlI004273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:36:31 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:36:30 -0600 From: "David Lake (dlake)" To: Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , "Linda Dunbar" , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgAB1UoCAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugP//o12wgAAIhXCAAAFmgA== Date: Tue, 12 Nov 2013 18:36:30 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB0C8EA7B7@xmb-aln-x09.cisco.com> References: <3512BB31280C39448A9880F61DD54CEB0C8E9EE0@xmb-aln-x09.cisco.com> <291CC3F9E50E7641901A54E85D0977C6B0280261BF@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6B0280261BF@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.58.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:36:45 -0000 Exactly. But how can network-components "terminate" an application ???? I think we need a good understanding of a recursive policy mechanism (recur= sive because a user-land application will ride with a specific policy acros= s potentially different sets of carrier policies). I hate to bring this up now, but we also need to think about this multi-dom= ain issue - if I set a policy as a user, chances are I will be crossing sev= eral domain boundaries. Are we expecting the service headers to define the= service chaining for the duration of the entire flow across all domains, o= r just across a single one ? In which case, do I have to re-set policy as I traverse domains and where = does that policy get set ? It would be much better to set policy once bas= ed on L5-7 needs, and have that instantiated across the multiple domains. Again, this appears to be outside the scope of SFC, but pretty relevant to = how it would operate in the real world. David -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: 12 November 2013 10:27 To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda Dunbar;= Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter > In those circumstances, only the end applications themselves or a=20 > reasonably broad-brushed classification (really traffic steering based=20 > on what we can see at ingress) is going to be useful - is THAT what=20 > we're aiming for here ? I would certainly hope not, but that has been my concern as well. Application layer termination and re-classification seems a must? -- Kevin J. Ma > -----Original Message----- > From: David Lake (dlake) [mailto:dlake@cisco.com] > Sent: Tuesday, November 12, 2013 1:00 PM > To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 > Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: RE: [nsc] Current Proposed SFC charter > > Policy may be outside of the scope of SFC, but without strong mapping=20 > between Policy and the inserted Service Header(s), we run-the-risk of=20 > limiting the efficacy of the protocol IMO. > > For example, in a world where the network has "gone dark," (as per the=20 > IETF Technical Plenary ?:-) ) what is our ability to determine policy=20 > based on DPI of packets-in-flight ? > > In those circumstances, only the end applications themselves or a=20 > reasonably broad-brushed classification (really traffic steering based=20 > on what we can see at ingress) is going to be useful - is THAT what=20 > we're aiming for here ? > > David > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Surendra Kumar (smkumar) > Sent: 12 November 2013 09:26 > To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) > Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: Re: [nsc] Current Proposed SFC charter > > Ron, > > Classification of traffic is well understood and we do not have to=20 > redefine it - it's been around for all the time middle boxes have been=20 > or for that matter the L2/L3 devices. All we are talking about is the=20 > applicability of the classification to branching in SFC. > > You are right, it is all about policy which is outside the scope of SFC. > > Surendra. > > On 11/12/13 7:53 AM, "Ron Parker" wrote= : > > >I think the lack of definition of "reclassification" may be causing some > >misunderstandings here. A branch would occur for some policy-driven > >reason based on the behavior and conclusions of the service function, > >itself. The graph would represent the fact that there is a branch > >point, but the service function, itself, being aware that it is a=20 > >branching point would contain the policy and logic to decide on which > >branch to take. Specifying that policy and logic is out of scope, IMO. > > > > Ron > > > > > >-----Original Message----- > >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > >Sent: Tuesday, November 12, 2013 10:49 AM > >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) > >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > >Majee > >Subject: RE: [nsc] Current Proposed SFC charter > > > >Hi Linda, > > > > Are you saying that a branching point is "never" a reclassification=20 > > point, or are you saying that a branching point "does not have to be" > > a reclassification point? > > > > I think this is an important distinction that needs to be clarified. > > If branching is never reclassification, then the meaning of a chain=20 > > is different than I originally inferred. If the chain is a tree=20 > > with other "branching" points in it, then that limits the scope of=20 > > the problem statement goals. > > > > While this could be a degenerate case, and any implementation could=20 > > define bad service chains, is it the intent of SFC to only look at=20 > > the simpler packet-level classification cases, or is it the intent =20 > > to consider the case where a branching point is viewed as a=20 > > re-classification point? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >> Sent: Tuesday, November 12, 2013 10:34 AM > >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma > >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 > >> Majee > >> Subject: RE: [nsc] Current Proposed SFC charter > >> > >> Ron, > >> > >> First, want to make it clear that "branching" !=3D reclassification,=20 > >>agree? > >> > >> Second, the representation of branching (or service graph) can be=20 > >> in a form of logic on a service function. Some service functions,=20 > >> especially L7 based, can use value in a Database to determine what=20 > >> is the next service function. > >> > >> Linda > >> > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > >> > Behalf Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 8:16 AM > >> > To: Hongyu Li (Julio); Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > >> > Sumandra Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hongyu, > >> > > >> > I agree completely that re-classification is not limited to DPI. > >> > > >> > And also, that an area for us to explore as a group is how to > >>represent > >> > the service graph. Do we want to represent it as a proper graph > with > >> > an adjacency list or other representational model? Or, do we want > to > >> > represent it as a set of linear segments and if so, how are the > >> > segments connected into a graph? Other ideas? > >> > > >> > Ron > >> > > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > >> > Behalf Of Hongyu Li (Julio) > >> > Sent: Tuesday, November 12, 2013 6:57 AM > >> > To: Ron Parker; Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > >> > Sumandra Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Branching/forking is a very interesting topic of SFC. About the=20 > >> > re- classification point, probably we shall not limit it to DPI.=20 > >> > It is also possible that packets go to different branches after=20 > >> > been processed by a certain service function, decision of which=20 > >> > branches to go is made based on the result of service function's=20 > >> > process, i.e. not just re- classification by DPI. > >> > > >> > Hongyu > >> > > >> > -----Original Message----- > >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 > >> > Behalf Of Ron Parker > >> > Sent: Tuesday, November 12, 2013 7:45 PM > >> > To: Kevin J Ma > >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 > >> > Sumandra Majee > >> > Subject: Re: [nsc] Current Proposed SFC charter > >> > > >> > Hi, Kevin > >> > > >> > You ask a great question about branching the graph. The details=20 > >> > around how to convey the selection of the subtree/subgraph are=20 > >> > still > >>to be > >> > defined. Is it one chain id for the whole graph? Does each branc= h > >> > have its own chain id? Some combination? > >> > > >> > Ron > >> > > >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" > >> > > >> > wrote: > >> > > >> > >> Yes, reclassification can change the service path and=20 > >> > >> re-classification may happen at any node along a service path. > >> > > > >> > > Just to expand on that, going back to the original question=20 > >> > > about service header encapsulation, is it intended that a chain=20 > >> > > that is re-classified will get a new chain ID which fully=20 > >> > > describes a chain that is a superset of the original chain ID,=20 > >> > > prior to DPI-based re-classification? (assuming the goal is "a=20 > >> > > single chain ID that is commonly understood along the entire=20 > >> > > service > chain" > >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >> > > > >> > > And the applicable subset of the permutative list of service=20 > >> > > paths would be configured at each appropriate service node? > >> > > e.g., ID 1: NAT + firewall + DPI > >> > > ID 2: NAT + firewall + DPI + AV > >> > > ID 3: NAT + firewall + DPI + AV + NAT > >> > > ID 4: NAT + firewall + DPI + NAT > >> > > ID 5: NAT + firewall + DPI + AV + LB > >> > > ID 6: NAT + firewall + DPI + LB > >> > > ID 7: NAT + firewall + DPI + LB + CACHE > >> > > ID 8: NAT + firewall + DPI + CACHE > >> > > ID 9: NAT + firewall + DPI + optimizer + LB > >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 > >> > > every flow then be initially classified as ID 1, but eventually=20 > >> > > get re- > >> > classified > >> > > to ID 2-11, after the DPI phase? > >> > > > >> > > thanx. > >> > > > >> > > -- Kevin J. Ma > >> > > > >> > >> -----Original Message----- > >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >> Sent: Tuesday, November 12, 2013 1:01 AM > >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > >> > >> nsc@ietf.org > >> > >> Subject: Re: [nsc] Current Proposed SFC charter > >> > >> > >> > >> > >> > >> > >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" > >>wrote: > >> > >>> > >> > >>> Hi Surendra, > >> > >>> > >> > >>> Classification may be out of scope, but the level of service=20 > >> > >>> that > >> > is > >> > >>> applicable is dependent upon the level of classification that=20 > >> > >>> can > >> > be > >> > >>> performed. An assumption of packet level encapsulation has > >> > >> implications > >> > >>> on the level of classification being performed? If the=20 > >> > >>> stated > >> > goals > >> > >> are > >> > >>> for firewall and load balancer functionality, then the=20 > >> > >>> application > >> > >> level > >> > >>> nature of those functions needs to be taken into account? =20 > >> > >>> If, on the other hand, the service function scope is limited=20 > >> > >>> due to limitations in classification, that would be and=20 > >> > >>> important piece of > >> > information? > >> > >>> > >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 > >> > >>> fork points of the service paths seem like re-classification > points? > >> > >>> Is that the interpretation from the architecture perspective? > >> > >>> Or is the service function chain classification exclusive of=20 > >> > >>> DPI > >> > functionality? > >> > >> I have not fully read that draft yet. But in general, as=20 > >> > >> described in the arch draft, the collection of services form a=20 > >> > >> graph, segments of which are service paths. Yes,=20 > >> > >> reclassification can > >> > change > >> > >> the service path and re-classification may happen at any node=20 > >> > >> along > >> > a service path. > >> > >> > >> > >> Surendra. > >> > >>> > >> > >>> thanx. > >> > >>> > >> > >>> -- Kevin J. Ma > >> > >>> > >> > >>>> -----Original Message----- > >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM > >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 > >> > >>>> nsc@ietf.org > >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>> > >> > >>>> Kevin, > >> > >>>> > >> > >>>> Classification mechanism is outside the scope of SFC. It can=20 > >> > >>>> be based > >> > >> on > >> > >>>> the packet or information not in the packet(environmental=20 > >> > >>>> attributes > >> > >> for > >> > >>>> instance) or a combination thereof. What is important is=20 > >> > >>>> that such classification aids in traffic selection and=20 > >> > >>>> service path identification. > >> > >>>> It is no different from a policy in this regard except that=20 > >> > >>>> the policy now specifies the service path. > >> > >>>> Further, classification is not limited to the network=20 > >> > >>>> elements but the service functions as well. Some of this is=20 > >> > >>>> described in the > >> > >> architecture > >> > >>>> drafts as well - > >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >> > >>>> > >> > >>>> Surendra. > >> > >>>> > >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma"=20 > >> > >>>>> > >> > wrote: > >> > >>>>> > >> > >>>>> Hi Ron, > >> > >>>>> > >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 > >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in section=20 > >> > >>>>> 2 of the > >> > problem > >> > >>>>> statement: > >> > >>>>> > >> > >>>>> 11. Per-Service (re)Classification: Classification=20 > >> > >>>>> occurs at > >> > each > >> > >>>>> service, independent from previously applied service > >> > >>>> functions. > >> > >>>>> These unrelated classification events consume=20 > >> > >>>>> resources > >> > per > >> > >>>>> service. More importantly, the classification > >> > functionality > >> > >>>>> often differs per service function and service=20 > >> > >>>>> function > >> > >> cannot > >> > >>>>> leverage the results from other deployed network or > >> > service. > >> > >>>>> > >> > >>>>> as it relates to section 5.2 of the framework document: > >> > >>>>> > >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 > >> > >>>>> the > >> > >>>> contents > >> > >>>>> of the packet header. Concretely, it classifies packets=20 > >> > >>>>> based on > >> > >>>> the > >> > >>>>> possible combination of one or more header fields, such=20 > >> > >>>>> as > >> > source > >> > >>>>> address, destination address, DS field, protocol ID,=20 > >> > >>>>> source > >> > port > >> > >>>> and > >> > >>>>> destination port numbers, and any other information. > >> > >>>>> > >> > >>>>> A packet-based classifier as described in the framework=20 > >> > >>>>> document > >> > >>>> would > >> > >>>>> seem to be limited in what it can classify? The service=20 > >> > >>>>> function identifier lookup does not seem to be a=20 > >> > >>>>> significant optimization > >> > >> over > >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 > >> > >>>>> missing > >> > >> detail > >> > >>>>> wrt how classification information is determined and reused? > >> > >>>>> > >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 > >> > >>>>> TLS > >> > >>>> encrypted > >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 > >> > >>>>> also > >> > >>>> wondering > >> > >>>>> how independent HLS segment requests might be classified=20 > >> > >>>>> and > >> > >>>> associated? > >> > >>>>> Were these types of use cases discussed in the BoF? > >> > >>>>> > >> > >>>>> thanx. > >> > >>>>> > >> > >>>>> -- Kevin J. Ma > >> > >>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 > >> > >>>>>> On Behalf > >> > >> Of > >> > >>>>>> Ron > >> > >>>>>> Parker > >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As was discussed in Vancouver, there are already many=20 > >> > >>>>>> existing ways > >> > >>>> to > >> > >>>>>> accomplish service chaining. But none of them provide a > >> > >>>> sufficient > >> > >>>>>> combination of interoperability, flexibility, and resiliency. > >> > A > >> > >>>> single > >> > >>>>>> service chain encapsulation will go a long way to ensuring=20 > >> > >>>>>> these > >> > >>>> goals. > >> > >>>>>> It may not be the absolutely most efficient approach for=20 > >> > >>>>>> every > >> > >>>> single > >> > >>>>>> network topology and every single use case, but its=20 > >> > >>>>>> ubiquitous > >> > >> nature > >> > >>>>>> should improve its adoption. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> Absolutely, that was an example of one type of derivation. > >> > >>>>>> However > >> > >>>> this > >> > >>>>>> could be augmented with classification result, again one=20 > >> > >>>>>> more > >> > >>>> example. > >> > >>>>>> > >> > >>>>>>>> All flows from the same source IP do not necessarily=20 > >> > >>>>>>>> follow > >> > the > >> > >>>> same > >> > >>>>>> chain. > >> > >>>>>> Correct. It is also not necessary that all transaction of=20 > >> > >>>>>> the same > >> > >>>> flow > >> > >>>>>> follow the same chain either. So why stop at flow itself. > >> > >>>>>> > >> > >>>>>> Again the point here is that do we always need SFC header=20 > >> > >>>>>> or > >>Not. > >> > >>>>>> > >> > >>>>>> Sumandra > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> The intention of service function chaining is to allow for=20 > >> > >>>>>> operation > >> > >>>> at > >> > >>>>>> the fully qualified flow level, or even finer grained at=20 > >> > >>>>>> the > >> > >>>> transaction > >> > >>>>>> level (this is an implementation matter for the PDP). All > >> > flows > >> > >>>> from > >> > >>>>>> the same source IP do not necessarily follow the same chain. > >> > >> Source > >> > >>>>>> IP, > >> > >>>>>> therefore, does not identify the chain ID. Another > >>intention > >> > of > >> > >>>>>> service function chaining is to operate over any network > >> > topology > >> > >> and > >> > >>>>>> not > >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part of > >> > the > >> > >>>>>> transport, it does not adequately identify the service=20 > >> > >>>>>> chain, > >> > >> either. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM > >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Ron, > >> > >>>>>> > >> > >>>>>> The service header is meant to carry the context which can > >> > *also* > >> > >>>>>> be derived (for example use source ip and vlan to identify=20 > >> > >>>>>> chainID and > >> > >>>>>> position) or encapsulated as part of another tunnel header. > >> > >>>>>> So this could be optional IMHO. > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM > >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Sumandra, > >> > >>>>>> > >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 > >> > >>>>>> SF or from > >> > >>>> SF > >> > >>>>>> to > >> > >>>>>> SF will look like: > >> > >>>>>> > >> > >>>>>> +------------------------+ > >> > >>>>>> | "transport" | > >> > >>>>>> +------------------------+ > >> > >>>>>> | service header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | original IP header | > >> > >>>>>> +------------------------+ > >> > >>>>>> | | original IP=20 > >> > >>>>>> | payload > >> > | > >> > >>>>>> | | > >> > >>>>>> +------------------------+ > >> > >>>>>> > >> > >>>>>> Where service header contains, at a minimum, enough=20 > >> > >>>>>> information to > >> > >>>> allow > >> > >>>>>> the packet to be propagated along the full length of the=20 > >> > >>>>>> chain, and optionally, other metadata that enhances the=20 > >> > >>>>>> operation of > >> > one > >> > >>>>>> or > >> > >> more > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> And where "transport" could conceivably be any of, but not=20 > >> > >>>>>> limited > >> > >>>> to: > >> > >>>>>> > >> > >>>>>> * Ethernet > >> > >>>>>> * Ethernet + LLC2 > >> > >>>>>> * Ethernet + MPLS > >> > >>>>>> * Ethernet + IP + GRE > >> > >>>>>> * Ethernet + IP +UDP > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Also, "original" in the diagram above is not meant to=20 > >> > >>>>>> imply immutability, but rather to specify the packet that=20 > >> > >>>>>> is > >> > propagated > >> > >>>>>> from preceding entity to succeeding entity, prior to=20 > >> > >>>>>> encapsulation. > >> > >>>>>> > >> > >>>>>> Ron > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 > >> > >>>>>> On Behalf > >> > >> Of > >> > >>>>>> Sumandra Majee > >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM > >> > >>>>>> To: Thomas Narten; nsc@ietf.org > >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 > >> > >>>>>> document > >>will > >> > >>>>>> describe the single service-level data plane=20 > >> > >>>>>> encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service=20 > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the=20 > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may=20 > >> > >>>>>> be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer=20 > >> > >>>>>> or at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> [SM] What does it mean by a single service-level=20 > >> > >>>>>> encapsulation, > >> > a > >> > >>>> new > >> > >>>>>> encapsulation format > >> > >>>>>> or an ability to select one encapsulation=20 > >> > >>>>>> format that > >> > >>>> fits > >> > >>>>>> the > >> > >>>>>> need for a given service chain? > >> > >>>>>> The ability to select a specific encapsulation=20 > >> > >>>>>> would be > >> > >> a > >> > >>>>>> management plane decision. > >> > >>>>>> There are quite a few existing encapsulation=20 > >> > >>>>>> methods that > >> > >>>> can > >> > >>>>>> possibly be reused to provide > >> > >>>>>> context information between service nodes. I have > >> > seen > >> > >>>>>> mention > >> > >>>>>> of GRE, for HTTP based > >> > >>>>>> applications contexts are transferred via headers. > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> -----Original Message----- > >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 > >> > >>>>>> On Behalf > >> > >> Of > >> > >>>>>> Thomas Narten > >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >> > >>>>>> To: nsc@ietf.org > >> > >>>>>> Subject: [nsc] Current Proposed SFC charter > >> > >>>>>> > >> > >>>>>> Hi. > >> > >>>>>> > >> > >>>>>> Current charter can be found at > >> > >>>>>> https://datatracker.ietf.org/doc/charter- > >> > >>>>>> ietf-sfc/. > >> > >>>>>> > >> > >>>>>> It contains the revised management text as well as updated > >> > >>>> milestones. > >> > >>>>>> > >> > >>>>>> All known issues have been addressed. If there are any=20 > >> > >>>>>> remaining > >> > >>>> issues, > >> > >>>>>> please speak up! > >> > >>>>>> > >> > >>>>>> Charter charter-ietf-sfc-00-04 > >> > >>>>>> > >> > >>>>>> Networks, servers, storage technologies, and applications,=20 > >> > >>>>>> have all undergone significant change in recent years with=20 > >> > >>>>>> the introduction > >> > >> of > >> > >>>>>> virtualization, network overlays, and orchestration.=20 > >> > >>>>>> Service > >> > >> delivery > >> > >>>> is > >> > >>>>>> currently both a technical and organizational challenge=20 > >> > >>>>>> that > >> > >> involves > >> > >>>>>> significant modification to the network configuration. > >> > >>>>>> Services are typically implemented by the ordered=20 > >> > >>>>>> combination of a number of service functions that are=20 > >> > >>>>>> deployed at different points within > >> > >> the > >> > >>>>>> network. Today, a common deployment model has service=20 > >> > >>>>>> functions physically inserted on the data forwarding path=20 > >> > >>>>>> between communicating peers. > >> > >>>> Going > >> > >>>>>> forward, however, there is a desire to move to a different=20 > >> > >>>>>> model, > >> > >>>> where > >> > >>>>>> service functions are not required to reside on the=20 > >> > >>>>>> default data > >> > >> path > >> > >>>>>> and > >> > >>>>>> traffic is instead steered through services, wherever they=20 > >> > >>>>>> are > >> > >>>> deployed. > >> > >>>>>> > >> > >>>>>> For a given service, the abstracted view of the required=20 > >> > >>>>>> service functions and the order in which they are to be=20 > >> > >>>>>> applied is > >> > called > >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 > >> > >>>>>> function may be available on more than one node within a=20 > >> > >>>>>> network, a Service Function Chain is instantiated > >> > >>>> via > >> > >>>>>> the selection of specific service function instances and=20 > >> > >>>>>> the network nodes on which they are provided, thereby=20 > >> > >>>>>> forming a service topology: > >> > >>>>>> this is called a Service Function Path. The service=20 > >> > >>>>>> functions > >> > may > >> > >>>>>> be applied at a specific layer within the network protocol=20 > >> > >>>>>> stack > >> > >>>> (network > >> > >>>>>> layer, application layer, etc.). > >> > >>>>>> > >> > >>>>>> The Service Function Chaining (SFC) working group will=20 > >> > >>>>>> develop new approaches to service delivery and deployment. > >> > >>>>>> It will produce a framework for service function chaining=20 > >> > >>>>>> that includes the necessary protocols > >> > >>>> or > >> > >>>>>> protocol extensions to convey the service path and service=20 > >> > >>>>>> path information to nodes that implement service=20 > >> > >>>>>> functions, as well > >> > as > >> > >>>>>> mechanisms for steering traffic through service functions. > >> > >>>>>> The > >> > >>>> working > >> > >>>>>> group will also examine what information needs to be=20 > >> > >>>>>> gathered from > >> > >>>> the > >> > >>>>>> network and service functions in support of service=20 > >> > >>>>>> function > >> > >> chaining > >> > >>>>>> and > >> > >>>>>> how that information may be made available to nodes that=20 > >> > >>>>>> implement > >> > >>>> the > >> > >>>>>> service functions. > >> > >>>>>> > >> > >>>>>> Specifically, the SFC WG is chartered to deliver the > following: > >> > >>>>>> > >> > >>>>>> 1) Problem Statement: This document will provide a summary=20 > >> > >>>>>> of > >> > the > >> > >>>>>> problem space to be addressed by the WG including=20 > >> > >>>>>> example > >> > high- > >> > >>>>>> level use cases. Additionally, the WG will normalize > >> > >> nomenclature > >> > >>>>>> and definitions for service function chaining. > >> > >>>>>> > >> > >>>>>> 2) Architecture: This document will provide a description=20 > >> > >>>>>> of > >>the > >> > >>>>>> architectural building blocks and their relationships > >> > including > >> > >>>>>> interconnection, placement of capabilities, management, > >> > >>>>>> diagnostics, design analysis, and security models, as=20 > >> > >>>>>> well > >>as > >> > >>>>>> requirements on the protocol mechanisms. > >> > >>>>>> > >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 > >> > >>>>>> document > >> > will > >> > >>>>>> describe the single service-level data plane=20 > >> > >>>>>> encapsulation > >> > >> format > >> > >>>>>> for > >> > >>>>>> conveying the service function chain and the service=20 > >> > >>>>>> function > >> > >>>> path, > >> > >>>>>> and for communicating context information between nodes > that > >> > >>>>>> implement service functions. It is intended that the > >> > >>>> encapsulation > >> > >>>>>> be agnostic to the layer at which it is applied and the=20 > >> > >>>>>> service > >> > >>>> that > >> > >>>>>> is > >> > >>>>>> being constructed. That is, the same encapsulation may=20 > >> > >>>>>> be > >> > used > >> > >> on > >> > >>>>>> a service function path realized at the network layer=20 > >> > >>>>>> or at any other > >> > >>>>>> layer, and the same encapsulation will apply for the > >> > >> construction > >> > >>>> of > >> > >>>>>> service function paths regardless of the actual service. > >> > >>>>>> > >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be > >> > developed to > >> > >>>>>> describe requirements and protocols necessary to convey > >> > >>>> information > >> > >>>>>> to service function implementation points. Where=20 > >> > >>>>>> possible, > >> > >>>> existing > >> > >>>>>> IETF protocols will be used and extended. All protocol > >> > >> extensions > >> > >>>>>> work should be carried out in the working groups=20 > >> > >>>>>> responsible for > >> > >>>> the > >> > >>>>>> protocols being modified in coordination with this=20 > >> > >>>>>> working > >> > >> group, > >> > >>>>>> but > >> > >>>>>> may be done in this working group after agreement with=20 > >> > >>>>>> all > >> > the > >> > >>>>>> relevant WG chairs and responsible ADs. > >> > >>>>>> > >> > >>>>>> 5) Manageability: Work on the management and configuration=20 > >> > >>>>>> of > >> > >> service > >> > >>>>>> functions in support of SFC components will certainly=20 > >> > >>>>>> be > >> > needed, > >> > >>>>>> but first needs to be better understood and scoped. > >> > >>>>>> > >> > >>>>>> Proposed Milestones > >> > >>>>>> > >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining=20 > >> > >>>>>> the > >> > >>>> problem > >> > >>>>>> statement and core use cases for Service Function Chaining > >> > >>>>>> > >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 > >> > >>>>>> modifications for management and configuration of SFC=20 > >> > >>>>>> components > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 > >> > >>>>>> the > >> > >>>> architecture > >> > >>>>>> for SFC > >> > >>>>>> > >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 > >> > >>>>>> function chaining encapsulation protocol > >> > >>>>>> > >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 > >> > >>>>>> specifying the > >> > >>>> generic > >> > >>>>>> service function chaining header encapsulation > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> > >> > >>>>>> Thomas > >> > >>>>>> > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>>> _______________________________________________ > >> > >>>>>> nsc mailing list > >> > >>>>>> nsc@ietf.org > >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > >>>>> _______________________________________________ > >> > >>>>> nsc mailing list > >> > >>>>> nsc@ietf.org > >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc > >> > > > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 10:44:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9679121F9FAB for ; Tue, 12 Nov 2013 10:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLBqGWf8v2kM for ; Tue, 12 Nov 2013 10:44:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8E911E8167 for ; Tue, 12 Nov 2013 10:44:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35542; q=dns/txt; s=iport; t=1384281871; x=1385491471; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=ETD6pjDVlqSARqKYhVuzH6VvxhaaUim3y22t1CaF4g0=; b=OzdWnYpWBP4yFmJRFaciq7xzh/SNqyukg8jgn/gO/wGnmuKBzHNELBZD G/Tx6Bl6uBFlvDOqWWT+qeky5fYHWpWtQ/Bz4JP35tLT8b6iCnzCxAClO 7tuf7dHM/AJcGN/73+Y1DwlZX7XAKSK1pjisJDRTpKdcq2dFjtGjNwwAx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArASABB2glKtJXG+/2dsb2JhbABQCoFxAgGBEzhTvxeBKhZ0giUBAQEEAQEBFwEfKwIHBAcMBgEIEQEDAQEBFQkJLgsUAwYIAgQBCQQFCYd4Db8ijhwEAQUGgQgrAgUCBASEJwOULoNhkgqDJoFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283833394" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2013 18:44:30 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rACIiTI7007309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:44:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:44:29 -0600 From: "Jim Guichard (jguichar)" To: "David Lake (dlake)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugIAACYeAgAAHugCAAAKLAP//rmUA Date: Tue, 12 Nov 2013 18:44:29 +0000 Message-ID: In-Reply-To: <3512BB31280C39448A9880F61DD54CEB0C8EA7B7@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <5F32960C75A8AF4BBE9C08318073D222@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:44:36 -0000 As discussed during the BOF our initial work is single administrative domain for some of the very reasons you point out. We need to keep focused without trying to boil the ocean right off the bat. On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >Exactly. But how can network-components "terminate" an application ???? > >I think we need a good understanding of a recursive policy mechanism >(recursive because a user-land application will ride with a specific >policy across potentially different sets of carrier policies). > >I hate to bring this up now, but we also need to think about this >multi-domain issue - if I set a policy as a user, chances are I will be >crossing several domain boundaries. Are we expecting the service headers >to define the service chaining for the duration of the entire flow across >all domains, or just across a single one ? > >In which case, do I have to re-set policy as I traverse domains and >where does that policy get set ? It would be much better to set policy >once based on L5-7 needs, and have that instantiated across the multiple >domains. > >Again, this appears to be outside the scope of SFC, but pretty relevant >to how it would operate in the real world. > >David > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: 12 November 2013 10:27 >To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >> In those circumstances, only the end applications themselves or a >> reasonably broad-brushed classification (really traffic steering based >> on what we can see at ingress) is going to be useful - is THAT what >> we're aiming for here ? > >I would certainly hope not, but that has been my concern as well. >Application layer termination and re-classification seems a must? > >-- Kevin J. Ma > >> -----Original Message----- >> From: David Lake (dlake) [mailto:dlake@cisco.com] >> Sent: Tuesday, November 12, 2013 1:00 PM >> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >> Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Policy may be outside of the scope of SFC, but without strong mapping >> between Policy and the inserted Service Header(s), we run-the-risk of >> limiting the efficacy of the protocol IMO. >> >> For example, in a world where the network has "gone dark," (as per the >> IETF Technical Plenary ?:-) ) what is our ability to determine policy >> based on DPI of packets-in-flight ? >> >> In those circumstances, only the end applications themselves or a >> reasonably broad-brushed classification (really traffic steering based >> on what we can see at ingress) is going to be useful - is THAT what >> we're aiming for here ? >> >> David >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Surendra Kumar (smkumar) >> Sent: 12 November 2013 09:26 >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to >> redefine it - it's been around for all the time middle boxes have been >> or for that matter the L2/L3 devices. All we are talking about is the >> applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a reclassification >> > point, or are you saying that a branching point "does not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a chain >> > is different than I originally inferred. If the chain is a tree >> > with other "branching" points in it, then that limits the scope of >> > the problem statement goals. >> > >> > While this could be a degenerate case, and any implementation could >> > define bad service chains, is it the intent of SFC to only look at >> > the simpler packet-level classification cases, or is it the intent >> > to consider the case where a branching point is viewed as a >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >> >> Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification, >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be >> >> in a form of logic on a service function. Some service functions, >> >> especially L7 based, can use value in a Database to determine what >> >> is the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > Behalf Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the >> >> > re- classification point, probably we shall not limit it to DPI. >> >> > It is also possible that packets go to different branches after >> >> > been processed by a certain service function, decision of which >> >> > branches to go is made based on the result of service function's >> >> > process, i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details >> >> > around how to convey the selection of the subtree/subgraph are >> >> > still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question >> >> > > about service header encapsulation, is it intended that a chain >> >> > > that is re-classified will get a new chain ID which fully >> >> > > describes a chain that is a superset of the original chain ID, >> >> > > prior to DPI-based re-classification? (assuming the goal is "a >> >> > > single chain ID that is commonly understood along the entire >> >> > > service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> >> > > >> >> > > And the applicable subset of the permutative list of service >> >> > > paths would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >> >> > > every flow then be initially classified as ID 1, but eventually >> >> > > get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification that >> >> > >>> can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the >> >> > >>> stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? >> >> > >>> If, on the other hand, the service function scope is limited >> >> > >>> due to limitations in classification, that would be and >> >> > >>> important piece of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >> >> > >>> fork points of the service paths seem like re-classification >> points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of >> >> > >>> DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as >> >> > >> described in the arch draft, the collection of services form a >> >> > >> graph, segments of which are service paths. Yes, >> >> > >> reclassification can >> >> > change >> >> > >> the service path and re-classification may happen at any node >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It can >> >> > >>>> be based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is >> >> > >>>> that such classification aids in traffic selection and >> >> > >>>> service path identification. >> >> > >>>> It is no different from a policy in this regard except that >> >> > >>>> the policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network >> >> > >>>> elements but the service functions as well. Some of this is >> >> > >>>> described in the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > >>>>> >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in section >> >> > >>>>> 2 of the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification >> >> > >>>>> occurs at >> >> > each >> >> > >>>>> service, independent from previously applied service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume >> >> > >>>>> resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service >> >> > >>>>> function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of) >> >> > >>>>> the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such >> >> > >>>>> as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID, >> >> > >>>>> source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service >> >> > >>>>> function identifier lookup does not seem to be a >> >> > >>>>> significant optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >> >> > >>>>> missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and >> >> > >>>>> TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >> >> > >>>>> also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified >> >> > >>>>> and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to ensuring >> >> > >>>>>> these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one >> >> > >>>>>> more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily >> >> > >>>>>>>> follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of >> >> > >>>>>> the same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header >> >> > >>>>>> or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow for >> >> > >>>>>> operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at >> >> > >>>>>> the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service >> >> > >>>>>> chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to identify >> >> > >>>>>> chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >> >> > >>>>>> SF or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the >> >> > >>>>>> chain, and optionally, other metadata that enhances the >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but not >> >> > >>>>>> limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to >> >> > >>>>>> imply immutability, but rather to specify the packet that >> >> > >>>>>> is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >> >> > >>>>>> document >> >>will >> >> > >>>>>> describe the single service-level data plane >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and the >> >> > >>>>>> service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation >> >> > >>>>>> format that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation >> >> > >>>>>> methods that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and applications, >> >> > >>>>>> have all undergone significant change in recent years with >> >> > >>>>>> the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. >> >> > >>>>>> Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge >> >> > >>>>>> that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered >> >> > >>>>>> combination of a number of service functions that are >> >> > >>>>>> deployed at different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service >> >> > >>>>>> functions physically inserted on the data forwarding path >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a different >> >> > >>>>>> model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the >> >> > >>>>>> default data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever they >> >> > >>>>>> are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required >> >> > >>>>>> service functions and the order in which they are to be >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service >> >> > >>>>>> function may be available on more than one node within a >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and >> >> > >>>>>> the network nodes on which they are provided, thereby >> >> > >>>>>> forming a service topology: >> >> > >>>>>> this is called a Service Function Path. The service >> >> > >>>>>> functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network protocol >> >> > >>>>>> stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will >> >> > >>>>>> develop new approaches to service delivery and deployment. >> >> > >>>>>> It will produce a framework for service function chaining >> >> > >>>>>> that includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and service >> >> > >>>>>> path information to nodes that implement service >> >> > >>>>>> functions, as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be >> >> > >>>>>> gathered from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service >> >> > >>>>>> function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a summary >> >> > >>>>>> of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including >> >> > >>>>>> example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description >> >> > >>>>>> of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as >> >> > >>>>>> well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and the >> >> > >>>>>> service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where >> >> > >>>>>> possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this >> >> > >>>>>> working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with >> >> > >>>>>> all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and configuration >> >> > >>>>>> of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly >> >> > >>>>>> be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) defining >> >> > >>>>>> the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter >> >> > >>>>>> modifications for management and configuration of SFC >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining >> >> > >>>>>> the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic service=20 >> >> > >>>>>> function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >> >> > >>>>>> specifying the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From dlake@cisco.com Tue Nov 12 10:51:15 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5773A11E8171 for ; Tue, 12 Nov 2013 10:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc7q0smrs1VD for ; Tue, 12 Nov 2013 10:51:10 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBA911E816D for ; Tue, 12 Nov 2013 10:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36877; q=dns/txt; s=iport; t=1384282270; x=1385491870; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Cdnrt/Ccs6t5ge5TnM1rt5CgPXx0dimqvw2dP2/9uGs=; b=TN1FnlMAepS0/2FkvwiFGN10aXsHwH/G5fKQWkMMu4oLiyn2zhL7hhrc rcrCChHdrnRDCa4jTL44x3HzbxNCbEpE43ikENRFmjvk+0TQE9SqDcqlP 7nBlWLzs0pxWjZXexfdbgv/JDVTjyI5ZTuGcZbBMmFhFCiBOhq0NICc1t Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAOx3glKtJXHA/2dsb2JhbABQCoMHOFO/F4EqFnSCJQEBAQQBAQEXAR8rAgcEBwwEAgEIEQEDAQEBCgsJCQcnCxQDBggCBAEJBAUIAYd4Db8ojhwEAQUGgQIGKwIFAgQEgxaBEQOULpVrgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="280840936" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2013 18:51:04 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACIp4Ui007982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:51:04 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:51:04 -0600 From: "David Lake (dlake)" To: "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgAB1UoCAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugP//o12wgAAIhXCAAAFmgIAAaL+A//+cQdA= Date: Tue, 12 Nov 2013 18:51:03 +0000 Message-ID: <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> References: <3512BB31280C39448A9880F61DD54CEB0C8EA7B7@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.27.58.8] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:51:15 -0000 Understood - maybe just a little localised warming of the sea then ? But = I still think we need to consider where and how policy is defined/set even = for the single-domain instance. I don't think we can assume that any L1-3 device will be able to determine = much useful information from the data-plane. -----Original Message----- From: Jim Guichard (jguichar)=20 Sent: 12 November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter As discussed during the BOF our initial work is single administrative domai= n for some of the very reasons you point out. We need to keep focused witho= ut trying to boil the ocean right off the bat. On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >Exactly. But how can network-components "terminate" an application ???? > >I think we need a good understanding of a recursive policy mechanism=20 >(recursive because a user-land application will ride with a specific=20 >policy across potentially different sets of carrier policies). > >I hate to bring this up now, but we also need to think about this=20 >multi-domain issue - if I set a policy as a user, chances are I will be=20 >crossing several domain boundaries. Are we expecting the service=20 >headers to define the service chaining for the duration of the entire=20 >flow across all domains, or just across a single one ? > >In which case, do I have to re-set policy as I traverse domains and >where does that policy get set ? It would be much better to set policy >once based on L5-7 needs, and have that instantiated across the=20 >multiple domains. > >Again, this appears to be outside the scope of SFC, but pretty relevant=20 >to how it would operate in the real world. > >David > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: 12 November 2013 10:27 >To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? > >I would certainly hope not, but that has been my concern as well. >Application layer termination and re-classification seems a must? > >-- Kevin J. Ma > >> -----Original Message----- >> From: David Lake (dlake) [mailto:dlake@cisco.com] >> Sent: Tuesday, November 12, 2013 1:00 PM >> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >> Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Policy may be outside of the scope of SFC, but without strong mapping=20 >> between Policy and the inserted Service Header(s), we run-the-risk of=20 >> limiting the efficacy of the protocol IMO. >> >> For example, in a world where the network has "gone dark," (as per=20 >> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >> policy based on DPI of packets-in-flight ? >> >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? >> >> David >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Surendra Kumar (smkumar) >> Sent: 12 November 2013 09:26 >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to=20 >> redefine it - it's been around for all the time middle boxes have=20 >> been or for that matter the L2/L3 devices. All we are talking about=20 >> is the applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a=20 >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> >Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a=20 >> > reclassification point, or are you saying that a branching point "does= not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a=20 >> > chain is different than I originally inferred. If the chain is a=20 >> > tree with other "branching" points in it, then that limits the=20 >> > scope of the problem statement goals. >> > >> > While this could be a degenerate case, and any implementation=20 >> > could define bad service chains, is it the intent of SFC to only=20 >> > look at the simpler packet-level classification cases, or is it the=20 >> > intent to consider the case where a branching point is viewed as a=20 >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> Sumandra Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification,= =20 >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be=20 >> >> in a form of logic on a service function. Some service functions,=20 >> >> especially L7 based, can use value in a Database to determine what=20 >> >> is the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the >> >> > re- classification point, probably we shall not limit it to DPI. >> >> > It is also possible that packets go to different branches after=20 >> >> > been processed by a certain service function, decision of which=20 >> >> > branches to go is made based on the result of service function's=20 >> >> > process, i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details=20 >> >> > around how to convey the selection of the subtree/subgraph are=20 >> >> > still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and=20 >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question=20 >> >> > > about service header encapsulation, is it intended that a=20 >> >> > > chain that is re-classified will get a new chain ID which=20 >> >> > > fully describes a chain that is a superset of the original=20 >> >> > > chain ID, prior to DPI-based re-classification? (assuming the=20 >> >> > > goal is "a single chain ID that is commonly understood along=20 >> >> > > the entire service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >> >> > > ) >> >> > > >> >> > > And the applicable subset of the permutative list of service=20 >> >> > > paths would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >> >> > > every flow then be initially classified as ID 1, but=20 >> >> > > eventually get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma"=20 >> >> > >>> >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service=20 >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification=20 >> >> > >>> that can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the=20 >> >> > >>> stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the=20 >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? >> >> > >>> If, on the other hand, the service function scope is limited=20 >> >> > >>> due to limitations in classification, that would be and=20 >> >> > >>> important piece of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >> >> > >>> fork points of the service paths seem like re-classification >> points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of=20 >> >> > >>> DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as=20 >> >> > >> described in the arch draft, the collection of services form=20 >> >> > >> a graph, segments of which are service paths. Yes,=20 >> >> > >> reclassification can >> >> > change >> >> > >> the service path and re-classification may happen at any node=20 >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >> >> > >>>> can be based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental=20 >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is=20 >> >> > >>>> that such classification aids in traffic selection and=20 >> >> > >>>> service path identification. >> >> > >>>> It is no different from a policy in this regard except that=20 >> >> > >>>> the policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network=20 >> >> > >>>> elements but the service functions as well. Some of this is=20 >> >> > >>>> described in the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > >>>>> >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >> >> > >>>>> section >> >> > >>>>> 2 of the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >> >> > >>>>> occurs at >> >> > each >> >> > >>>>> service, independent from previously applied=20 >> >> > >>>>> service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume=20 >> >> > >>>>> resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service=20 >> >> > >>>>> function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 >> >> > >>>>> the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets=20 >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such=20 >> >> > >>>>> as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID,=20 >> >> > >>>>> source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework=20 >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service=20 >> >> > >>>>> function identifier lookup does not seem to be a=20 >> >> > >>>>> significant optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >> >> > >>>>> missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >> >> > >>>>> TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >> >> > >>>>> also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified=20 >> >> > >>>>> and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to=20 >> >> > >>>>>> ensuring these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for=20 >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its=20 >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one=20 >> >> > >>>>>> more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >> >> > >>>>>>>> follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of=20 >> >> > >>>>>> the same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header=20 >> >> > >>>>>> or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow=20 >> >> > >>>>>> for operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >> >> > >>>>>> the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service=20 >> >> > >>>>>> chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which=20 >> >> > >>>>>> can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to=20 >> >> > >>>>>> identify chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >> >> > >>>>>> SF or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP=20 >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough=20 >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the=20 >> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >> >> > >>>>>> not limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >> >> > >>>>>> imply immutability, but rather to specify the packet that=20 >> >> > >>>>>> is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >>will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level=20 >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation=20 >> >> > >>>>>> format that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation=20 >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation=20 >> >> > >>>>>> methods that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as=20 >> >> > >>>>>> updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any=20 >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and=20 >> >> > >>>>>> applications, have all undergone significant change in=20 >> >> > >>>>>> recent years with the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. >> >> > >>>>>> Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge=20 >> >> > >>>>>> that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered=20 >> >> > >>>>>> combination of a number of service functions that are=20 >> >> > >>>>>> deployed at different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service=20 >> >> > >>>>>> functions physically inserted on the data forwarding path=20 >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a=20 >> >> > >>>>>> different model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the=20 >> >> > >>>>>> default data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever=20 >> >> > >>>>>> they are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required=20 >> >> > >>>>>> service functions and the order in which they are to be=20 >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >> >> > >>>>>> function may be available on more than one node within a=20 >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and=20 >> >> > >>>>>> the network nodes on which they are provided, thereby=20 >> >> > >>>>>> forming a service topology: >> >> > >>>>>> this is called a Service Function Path. The service=20 >> >> > >>>>>> functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network=20 >> >> > >>>>>> protocol stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >> >> > >>>>>> develop new approaches to service delivery and deployment. >> >> > >>>>>> It will produce a framework for service function chaining=20 >> >> > >>>>>> that includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and=20 >> >> > >>>>>> service path information to nodes that implement service=20 >> >> > >>>>>> functions, as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be=20 >> >> > >>>>>> gathered from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service=20 >> >> > >>>>>> function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that=20 >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >> >> > >>>>>> summary of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including=20 >> >> > >>>>>> example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description=20 >> >> > >>>>>> of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >> >> > >>>>>> well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to=20 >> >> > >>>>>> convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where=20 >> >> > >>>>>> possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups=20 >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this=20 >> >> > >>>>>> working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with=20 >> >> > >>>>>> all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and=20 >> >> > >>>>>> configuration of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly=20 >> >> > >>>>>> be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >> >> > >>>>>> defining the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function=20 >> >> > >>>>>> Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >> >> > >>>>>> modifications for management and configuration of SFC=20 >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >> >> > >>>>>> the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >> >> > >>>>>> service function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >> >> > >>>>>> specifying the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Tue Nov 12 11:01:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9FB11E810F for ; Tue, 12 Nov 2013 11:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.562 X-Spam-Level: X-Spam-Status: No, score=-10.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrCttliHVIfW for ; Tue, 12 Nov 2013 11:01:00 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC6021F9F1B for ; Tue, 12 Nov 2013 11:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37827; q=dns/txt; s=iport; t=1384282857; x=1385492457; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=AqylMlkgRI1jpjYs2pnZ7LCxXD/gBr8/illPmzBnlsQ=; b=PiJWHQeDSd8IfhXDuAzFhILL2ErBGqpkej5tgmUUze/7zUyKx6FPZ4Ch WXnrroxmNL1vkknD+hBnxfMDKs+3QXcyc25i/h+32MkK6oub2fnKNTmXE Vtjbsn/MNyS1AjeaMNIKl2/uSuVFn7WyKvOJ14DQxAyeva+uhjU0SctSq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIJ6glKtJXG//2dsb2JhbABQCoMHOFO/F4EqFnSCJQEBAQMBAQEBFwEfKwIHBAcMBgEIEQEDAQEBFQkJLgsUAwYIAgQBCQQFCYdyBg2/NI4cBAEFBoEIKwIFAgQEhCcDlC6DYZIKgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208";a="283865813" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 12 Nov 2013 19:00:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rACJ0tAS017191 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 19:00:55 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 13:00:55 -0600 From: "Jim Guichard (jguichar)" To: "David Lake (dlake)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugIAACYeAgAAHugCAAAKLAP//rmUAgABVq4D//67tAA== Date: Tue, 12 Nov 2013 19:00:54 +0000 Message-ID: In-Reply-To: <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:01:13 -0000 The assumption is that classification may be performed at the network and/or application layer and that classification will be based on policy of some description. When we work through control plane aspects of the SFC charter presumably what policy needs to be generated and by what to where is part of the work item. Further, branching will occur because of a reclassification but reclassification may or may not force a branch from one chain to another. On 11/12/13 1:51 PM, "David Lake (dlake)" wrote: >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is defined/set >even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; >Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative >domain for some of the very reasons you point out. We need to keep >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism >>(recursive because a user-land application will ride with a specific >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this >>multi-domain issue - if I set a policy as a user, chances are I will be >>crossing several domain boundaries. Are we expecting the service >>headers to define the service chaining for the duration of the entire >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty relevant >>to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong mapping >>> between Policy and the inserted Service Header(s), we run-the-risk of >>> limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per >>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to >>> redefine it - it's been around for all the time middle boxes have >>> been or for that matter the L2/L3 devices. All we are talking about >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a >>> > chain is different than I originally inferred. If the chain is a >>> > tree with other "branching" points in it, then that limits the >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation >>> > could define bad service chains, is it the intent of SFC to only >>> > look at the simpler packet-level classification cases, or is it the >>> > intent to consider the case where a branching point is viewed as a >>> > re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D reclassification, >>> >>agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be >>> >> in a form of logic on a service function. Some service functions, >>> >> especially L7 based, can use value in a Database to determine what >>> >> is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after >>> >> > been processed by a certain service function, decision of which >>> >> > branches to go is made based on the result of service function's >>> >> > process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The details >>> >> > around how to convey the selection of the subtree/subgraph are >>> >> > still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question >>> >> > > about service header encapsulation, is it intended that a >>> >> > > chain that is re-classified will get a new chain ID which >>> >> > > fully describes a chain that is a superset of the original >>> >> > > chain ID, prior to DPI-based re-classification? (assuming the >>> >> > > goal is "a single chain ID that is commonly understood along >>> >> > > the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>> >> > > every flow then be initially classified as ID 1, but >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of service >>> >> > >>> that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is limited >>> >> > >>> due to limitations in classification, that would be and >>> >> > >>> important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>> >> > >>> fork points of the service paths seem like re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive of >>> >> > >>> DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general, as >>> >> > >> described in the arch draft, the collection of services form >>> >> > >> a graph, segments of which are service paths. Yes, >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any node >>> >> > >> along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is >>> >> > >>>> that such classification aids in traffic selection and >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except that >>> >> > >>>> the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network >>> >> > >>>> elements but the service functions as well. Some of this is >>> >> > >>>> described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some of) >>> >> > >>>>> the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies packets >>> >> > >>>>> based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID, >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service >>> >> > >>>>> function identifier lookup does not seem to be a >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach for >>> >> > >>>>>> every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction of >>> >> > >>>>>> the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC header >>> >> > >>>>>> or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the >>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>> >> > >>>>>> imply immutability, but rather to specify the packet that >>> >> > >>>>>> is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and >>> >> > >>>>>> applications, have all undergone significant change in >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered >>> >> > >>>>>> combination of a number of service functions that are >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service >>> >> > >>>>>> functions physically inserted on the data forwarding path >>> >> > >>>>>> between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required >>> >> > >>>>>> service functions and the order in which they are to be >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service >>> >> > >>>>>> function may be available on more than one node within a >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and >>> >> > >>>>>> the network nodes on which they are provided, thereby >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function chaining >>> >> > >>>>>> that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and >>> >> > >>>>>> service path information to nodes that implement service >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a description >>> >> > >>>>>> of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement with=20 >>> >> > >>>>>> all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > From david.i.allan@ericsson.com Tue Nov 12 11:04:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94EE11E8140 for ; Tue, 12 Nov 2013 11:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.727 X-Spam-Level: X-Spam-Status: No, score=-1.727 tagged_above=-999 required=5 tests=[AWL=0.872, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SU6Pl0SVWk7 for ; Tue, 12 Nov 2013 11:04:13 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7038B11E810F for ; Tue, 12 Nov 2013 11:04:13 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-0e-52827bac8fa7 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id FC.A9.23183.CAB72825; Tue, 12 Nov 2013 20:04:12 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 14:04:05 -0500 From: David Allan I To: "nsc@ietf.org" Thread-Topic: [nsc] re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQ Date: Tue, 12 Nov 2013 19:04:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyuXRPlO6a6qYgg38NyhbH9+1nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRvv2c6wFu5YzVfSce8HSwPj0GWMXIyeHhICJxPNZm6FsMYkL 99azdTFycQgJHGGUWHP3KVhCSGA5o8SB1+kgNpuAgcSe/1+A4hwcIgKKEjvfpICEhQVCJY59 b2cGsUUEwiS2HlzPCmEbSfxsu80CUs4ioCqx9VciSJhXwFfi2fYmsHJGoLXfT61hArGZBcQl bj2ZzwRxjoDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuErS2xbOFrZoj5ghInZz5h mcAoPAvJ2FlIWmYhaZmFpGUBI8sqRo7S4tSy3HQjg02MwEA+JsGmu4Nxz0vLQ4zSHCxK4rxf 3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDUz38tdyz0Zqn6e3mxbmvXtjs6+nnn7S98 eTHpQqz75X6zbwkFt2UyL8ttXf459VzAt89MC1L55z5d9vlfVJlR08TEEmUbtuPBwrs5/eb9 YnDYNutg/skrSyc9XT+f3zbD5MxFcTbRdcfyzacdzDueET2nbH8YI/fHkj2bwxwfXNk641/s t4AvSizFGYmGWsxFxYkAQDEzgDICAAA= Subject: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:04:18 -0000 Hi: (resend with recipient list cleaned up) I agree we are discussing multiple concepts, classification and flow-subset= ting. Perhaps more ;-) Defining a flow subset can be a result of classification, but it is not the= exclusive mechanism. Branching is a mechanism by which flow subsets are ex= posed and mapped to a set of subchains such that it can be identified in th= e dataplane... That's the view from here Dave -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Lake (dlake) Sent: Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Park= er; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Understood - maybe just a little localised warming of the sea then ? But = I still think we need to consider where and how policy is defined/set even = for the single-domain instance. I don't think we can assume that any L1-3 device will be able to determine = much useful information from the data-plane. -----Original Message----- From: Jim Guichard (jguichar) Sent: 12 November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter As discussed during the BOF our initial work is single administrative domai= n for some of the very reasons you point out. We need to keep focused witho= ut trying to boil the ocean right off the bat. On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >Exactly. But how can network-components "terminate" an application ???? > >I think we need a good understanding of a recursive policy mechanism=20 >(recursive because a user-land application will ride with a specific=20 >policy across potentially different sets of carrier policies). > >I hate to bring this up now, but we also need to think about this=20 >multi-domain issue - if I set a policy as a user, chances are I will be=20 >crossing several domain boundaries. Are we expecting the service=20 >headers to define the service chaining for the duration of the entire=20 >flow across all domains, or just across a single one ? > >In which case, do I have to re-set policy as I traverse domains and >where does that policy get set ? It would be much better to set policy >once based on L5-7 needs, and have that instantiated across the=20 >multiple domains. > >Again, this appears to be outside the scope of SFC, but pretty relevant=20 >to how it would operate in the real world. > >David > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: 12 November 2013 10:27 >To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? > >I would certainly hope not, but that has been my concern as well. >Application layer termination and re-classification seems a must? > >-- Kevin J. Ma > >> -----Original Message----- >> From: David Lake (dlake) [mailto:dlake@cisco.com] >> Sent: Tuesday, November 12, 2013 1:00 PM >> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >> Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Policy may be outside of the scope of SFC, but without strong mapping=20 >> between Policy and the inserted Service Header(s), we run-the-risk of=20 >> limiting the efficacy of the protocol IMO. >> >> For example, in a world where the network has "gone dark," (as per=20 >> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >> policy based on DPI of packets-in-flight ? >> >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? >> >> David >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Surendra Kumar (smkumar) >> Sent: 12 November 2013 09:26 >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to=20 >> redefine it - it's been around for all the time middle boxes have=20 >> been or for that matter the L2/L3 devices. All we are talking about=20 >> is the applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a=20 >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> >Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a=20 >> > reclassification point, or are you saying that a branching point "does= not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a=20 >> > chain is different than I originally inferred. If the chain is a=20 >> > tree with other "branching" points in it, then that limits the=20 >> > scope of the problem statement goals. >> > >> > While this could be a degenerate case, and any implementation=20 >> > could define bad service chains, is it the intent of SFC to only=20 >> > look at the simpler packet-level classification cases, or is it the=20 >> > intent to consider the case where a branching point is viewed as a=20 >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> Sumandra Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification,= =20 >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be=20 >> >> in a form of logic on a service function. Some service functions,=20 >> >> especially L7 based, can use value in a Database to determine what=20 >> >> is the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the >> >> > re- classification point, probably we shall not limit it to DPI. >> >> > It is also possible that packets go to different branches after=20 >> >> > been processed by a certain service function, decision of which=20 >> >> > branches to go is made based on the result of service function's=20 >> >> > process, i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details=20 >> >> > around how to convey the selection of the subtree/subgraph are=20 >> >> > still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and=20 >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question=20 >> >> > > about service header encapsulation, is it intended that a=20 >> >> > > chain that is re-classified will get a new chain ID which=20 >> >> > > fully describes a chain that is a superset of the original=20 >> >> > > chain ID, prior to DPI-based re-classification? (assuming the=20 >> >> > > goal is "a single chain ID that is commonly understood along=20 >> >> > > the entire service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >> >> > > ) >> >> > > >> >> > > And the applicable subset of the permutative list of service=20 >> >> > > paths would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >> >> > > every flow then be initially classified as ID 1, but=20 >> >> > > eventually get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma"=20 >> >> > >>> >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service=20 >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification=20 >> >> > >>> that can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the=20 >> >> > >>> stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the=20 >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? >> >> > >>> If, on the other hand, the service function scope is limited=20 >> >> > >>> due to limitations in classification, that would be and=20 >> >> > >>> important piece of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >> >> > >>> fork points of the service paths seem like re-classification >> points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of=20 >> >> > >>> DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as=20 >> >> > >> described in the arch draft, the collection of services form=20 >> >> > >> a graph, segments of which are service paths. Yes,=20 >> >> > >> reclassification can >> >> > change >> >> > >> the service path and re-classification may happen at any node=20 >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >> >> > >>>> can be based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental=20 >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is=20 >> >> > >>>> that such classification aids in traffic selection and=20 >> >> > >>>> service path identification. >> >> > >>>> It is no different from a policy in this regard except that=20 >> >> > >>>> the policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network=20 >> >> > >>>> elements but the service functions as well. Some of this is=20 >> >> > >>>> described in the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > >>>>> >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >> >> > >>>>> section >> >> > >>>>> 2 of the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >> >> > >>>>> occurs at >> >> > each >> >> > >>>>> service, independent from previously applied=20 >> >> > >>>>> service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume=20 >> >> > >>>>> resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service=20 >> >> > >>>>> function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 >> >> > >>>>> the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets=20 >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such=20 >> >> > >>>>> as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID,=20 >> >> > >>>>> source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework=20 >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service=20 >> >> > >>>>> function identifier lookup does not seem to be a=20 >> >> > >>>>> significant optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >> >> > >>>>> missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >> >> > >>>>> TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >> >> > >>>>> also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified=20 >> >> > >>>>> and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to=20 >> >> > >>>>>> ensuring these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for=20 >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its=20 >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one=20 >> >> > >>>>>> more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >> >> > >>>>>>>> follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of=20 >> >> > >>>>>> the same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header=20 >> >> > >>>>>> or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow=20 >> >> > >>>>>> for operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >> >> > >>>>>> the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service=20 >> >> > >>>>>> chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which=20 >> >> > >>>>>> can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to=20 >> >> > >>>>>> identify chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >> >> > >>>>>> SF or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP=20 >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough=20 >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the=20 >> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >> >> > >>>>>> not limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >> >> > >>>>>> imply immutability, but rather to specify the packet that=20 >> >> > >>>>>> is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >>will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level=20 >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation=20 >> >> > >>>>>> format that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation=20 >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation=20 >> >> > >>>>>> methods that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as=20 >> >> > >>>>>> updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any=20 >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and=20 >> >> > >>>>>> applications, have all undergone significant change in=20 >> >> > >>>>>> recent years with the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. >> >> > >>>>>> Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge=20 >> >> > >>>>>> that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered=20 >> >> > >>>>>> combination of a number of service functions that are=20 >> >> > >>>>>> deployed at different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service=20 >> >> > >>>>>> functions physically inserted on the data forwarding path=20 >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a=20 >> >> > >>>>>> different model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the=20 >> >> > >>>>>> default data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever=20 >> >> > >>>>>> they are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required=20 >> >> > >>>>>> service functions and the order in which they are to be=20 >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >> >> > >>>>>> function may be available on more than one node within a=20 >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and=20 >> >> > >>>>>> the network nodes on which they are provided, thereby=20 >> >> > >>>>>> forming a service topology: >> >> > >>>>>> this is called a Service Function Path. The service=20 >> >> > >>>>>> functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network=20 >> >> > >>>>>> protocol stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >> >> > >>>>>> develop new approaches to service delivery and deployment. >> >> > >>>>>> It will produce a framework for service function chaining=20 >> >> > >>>>>> that includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and=20 >> >> > >>>>>> service path information to nodes that implement service=20 >> >> > >>>>>> functions, as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be=20 >> >> > >>>>>> gathered from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service=20 >> >> > >>>>>> function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that=20 >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >> >> > >>>>>> summary of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including=20 >> >> > >>>>>> example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description=20 >> >> > >>>>>> of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >> >> > >>>>>> well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to=20 >> >> > >>>>>> convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where=20 >> >> > >>>>>> possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups=20 >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this=20 >> >> > >>>>>> working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with=20 >> >> > >>>>>> all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and=20 >> >> > >>>>>> configuration of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly=20 >> >> > >>>>>> be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >> >> > >>>>>> defining the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function=20 >> >> > >>>>>> Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >> >> > >>>>>> modifications for management and configuration of SFC=20 >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >> >> > >>>>>> the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >> >> > >>>>>> service function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >> >> > >>>>>> specifying the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Chuong.D.Pham@team.telstra.com Tue Nov 12 15:15:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2750611E8166 for ; Tue, 12 Nov 2013 15:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCecoyXuJ5on for ; Tue, 12 Nov 2013 15:15:32 -0800 (PST) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 57E3311E8160 for ; Tue, 12 Nov 2013 15:15:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,688,1378821600"; d="scan'208";a="173288822" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipobvi.tcif.telstra.com.au with ESMTP; 13 Nov 2013 10:15:25 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7257"; a="172920599" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdvi.tcif.telstra.com.au with ESMTP; 13 Nov 2013 10:15:07 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 13 Nov 2013 10:15:06 +1100 From: "Pham, Chuong D" To: "Joel M. Halpern" , "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , Thomas Narten , "nsc@ietf.org" Date: Wed, 13 Nov 2013 10:15:05 +1100 Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: Ac7ftT0mGyYzmGqCQLS8NJWuwh88GQAPghGg Message-ID: <5602569641FB314FB4D9AD5659D41B9C285C08FCB0@WSMSG3154V.srv.dir.telstra.com> References: <52823DF6.5050306@joelhalpern.com> In-Reply-To: <52823DF6.5050306@joelhalpern.com> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:15:37 -0000 Hi all, In the example below, PCRF is a control plane element. It is not in the pat= h of user plane traffic (traversing the service functions). I am not sure i= f the example is valid. However, if the example is meant to say in SFC1, th= e DPI informs the PCRF of the ApplicationID (aka via Sd interface of the "T= DF") so that the PCRF then informs the ingress node (a PCEF) to start steer= ing traffic to SFC2 or SFC3 instead SFC1 then it is valid. In this case, th= e DPI acts as an intelligence node supplying information to the PCRF so tha= t the PCRF can make a decision on which service chain will be used for a su= bscriber's flow. The issue here is once the traffic is no longer passing the DPI (SFC1 is no= longer used), no further decision based on DPI can be made. Another issue is by the time the DPI "understands" the ApplicationID and in= form the PCRF, the user has already established TCP (and perhaps applicatio= n layer) connection with the server. SCF2 and SFC3 will then be a case of s= teering mid-flow which will break TCP and application layer sessions. Also, I could consider SFC1 is a case of pre-steering mediation (to decide = whether SFC2 or SFC3 is to be used) rather than a case of reclassification = and branching. My example of a reclassification and branching would be a case where an DDo= S inspection node diverts a flow to a DDoS clearing node once DDoS attacks = have been detected. Regards, Chuong -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, 13 November 2013 1:41 AM To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Park= er; Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Current Proposed SFC charter Jim, thank you for a concrete example. I would suggest that in the usual cases, there is a better way to handle th= is than branching and rewriting at the PCRF. If the DPI engine or PCRF logic (whichever makes the decision) notifies the= control logic about the decision for the flow, then the ingress can direct= subsequent packets to the correct place, avoiding needless processing of f= urther packets in the DPI and PCRF logic. Further, the needed control information can be passed to the optimization o= r parental control so that it does not matter where the first packet is sen= t, avoiding the need for the PCRF to understand how to direct packets to se= rvice paths. Yours, Joel On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: > Hi Kevin, > > Let me try and provide a concrete example to see if this answers your > specific question: > > Use case: P-GW -> PCRF -> services applied to traffic based on > applicationID and subscriberID. > > Instantiated as: > > SFC1: P-GW -> DPI -> PCRF > SFC2: PCRF -> video-optimization -> metering -> FW > SFC3: PCRF -> parental-control -> metering -> FW > > In this case DPI is performed on SFC1 and identifies applicationID. > The applicationID is carried in the service encapsulation to PCRF. > PCRF uses solution specific logic (identifies subscriber, applies > policies, etc) and uses the result along with the applicationID > received from DPI to select an outbound service chain, SFC2 or SFC3. > Note that in this case branching occurs from SFC1 to either SFC2 or SFC3. > > > > > On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > >>> Yes, reclassification can change the service path and >>> re-classification may happen at any node along a service path. >> >> Just to expand on that, going back to the original question about >> service header encapsulation, is it intended that a chain that is >> re-classified will get a new chain ID which fully describes a chain >> that is a superset of the original chain ID, prior to DPI-based >> re-classification? (assuming the goal is "a single chain ID that is >> commonly understood along the entire service chain" >> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >> >> And the applicable subset of the permutative list of service paths >> would be configured at each appropriate service node? >> e.g., ID 1: NAT + firewall + DPI >> ID 2: NAT + firewall + DPI + AV >> ID 3: NAT + firewall + DPI + AV + NAT >> ID 4: NAT + firewall + DPI + NAT >> ID 5: NAT + firewall + DPI + AV + LB >> ID 6: NAT + firewall + DPI + LB >> ID 7: NAT + firewall + DPI + LB + CACHE >> ID 8: NAT + firewall + DPI + CACHE >> ID 9: NAT + firewall + DPI + optimizer + LB >> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >> flow then be initially classified as ID 1, but eventually get >> re-classified to ID 2-11, after the DPI phase? >> >> thanx. >> >> -- Kevin J. Ma >> >>> -----Original Message----- >>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:01 AM >>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> nsc@ietf.org >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> >>> >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>> >>>> Hi Surendra, >>>> >>>> Classification may be out of scope, but the level of service that is >>>> applicable is dependent upon the level of classification that can be >>>> performed. An assumption of packet level encapsulation has >>> implications >>>> on the level of classification being performed? If the stated >>>> goals >>> are >>>> for firewall and load balancer functionality, then the >>>> application >>> level >>>> nature of those functions needs to be taken into account? If, on th= e >>>> other hand, the service function scope is limited due to >>>> limitations >>> in >>>> classification, that would be and important piece of information? >>>> >>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>> points >>>> of the service paths seem like re-classification points? Is that th= e >>>> interpretation from the architecture perspective? Or is the service >>>> function chain classification exclusive of DPI functionality? >>> I have not fully read that draft yet. But in general, as >>> described in the arch draft, the collection of services form a >>> graph, segments of which are service paths. Yes, reclassification >>> can change the service path and re-classification may happen at any >>> node along a service path. >>> >>> Surendra. >>>> >>>> thanx. >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- >>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> nsc@ietf.org >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>> >>>>> Kevin, >>>>> >>>>> Classification mechanism is outside the scope of SFC. It can be >>>>> based >>> on >>>>> the packet or information not in the packet(environmental >>>>> attributes >>> for >>>>> instance) or a combination thereof. What is important is that such >>>>> classification aids in traffic selection and service path >>>>> identification. >>>>> It is no different from a policy in this regard except that the >>> policy >>>>> now >>>>> specifies the service path. >>>>> Further, classification is not limited to the network elements but >>> the >>>>> service functions as well. Some of this is described in the >>> architecture >>>>> drafts as well - >>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>> >>>>> Surendra. >>>>> >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>> >>>>>> Hi Ron, >>>>>> >>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >>>>>> but >>> I >>>>>> had a similar question wrt bullet 11 in section 2 of the >>>>>> problem >>>>>> statement: >>>>>> >>>>>> 11. Per-Service (re)Classification: Classification occurs at >>> each >>>>>> service, independent from previously applied service >>>>> functions. >>>>>> These unrelated classification events consume resources per >>>>>> service. More importantly, the classification >>> functionality >>>>>> often differs per service function and service function >>> cannot >>>>>> leverage the results from other deployed network or >>> service. >>>>>> >>>>>> as it relates to section 5.2 of the framework document: >>>>>> >>>>>> The SFC Classifier classifies packets based on (some of) the >>>>> contents >>>>>> of the packet header. Concretely, it classifies packets >>>>>> based >>> on >>>>> the >>>>>> possible combination of one or more header fields, such as >>> source >>>>>> address, destination address, DS field, protocol ID, source >>>>>> port >>>>> and >>>>>> destination port numbers, and any other information. >>>>>> >>>>>> A packet-based classifier as described in the framework >>>>>> document >>>>> would >>>>>> seem to be limited in what it can classify? The service function >>>>>> identifier lookup does not seem to be a significant >>>>>> optimization >>> over >>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>> detail >>>>>> wrt how classification information is determined and reused? >>>>>> >>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>> encrypted >>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>> wondering >>>>>> how independent HLS segment requests might be classified and >>>>> associated? >>>>>> Were these types of use cases discussed in the BoF? >>>>>> >>>>>> thanx. >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Ron >>>>>>> Parker >>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As was discussed in Vancouver, there are already many existing >>> ways >>>>> to >>>>>>> accomplish service chaining. But none of them provide a >>>>> sufficient >>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>> single >>>>>>> service chain encapsulation will go a long way to ensuring these >>>>> goals. >>>>>>> It may not be the absolutely most efficient approach for every >>>>> single >>>>>>> network topology and every single use case, but its ubiquitous >>> nature >>>>>>> should improve its adoption. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>> However >>>>> this >>>>>>> could be augmented with classification result, again one more >>>>> example. >>>>>>> >>>>>>>>> All flows from the same source IP do not necessarily follow >>>>>>>>> the >>>>> same >>>>>>> chain. >>>>>>> Correct. It is also not necessary that all transaction of the >>>>>>> same >>>>> flow >>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>> >>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>> >>>>>>> Sumandra >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> The intention of service function chaining is to allow for >>> operation >>>>> at >>>>>>> the fully qualified flow level, or even finer grained at the >>>>> transaction >>>>>>> level (this is an implementation matter for the PDP). All >>> flows >>>>> from >>>>>>> the same source IP do not necessarily follow the same chain. >>> Source >>>>>>> IP, >>>>>>> therefore, does not identify the chain ID. Another intention >>> of >>>>>>> service function chaining is to operate over any network >>>>>>> topology >>> and >>>>>>> not >>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>> transport, it does not adequately identify the service chain, >>> either. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> The service header is meant to carry the context which can >>>>>>> *also* >>> be >>>>>>> derived (for example use source ip and vlan to identify chainID >>> and >>>>>>> position) or encapsulated as part of another tunnel header. So >>> this >>>>>>> could >>>>>>> be optional IMHO. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Sumandra, >>>>>>> >>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>> from >>>>> SF >>>>>>> to >>>>>>> SF will look like: >>>>>>> >>>>>>> +------------------------+ >>>>>>> | "transport" | >>>>>>> +------------------------+ >>>>>>> | service header | >>>>>>> +------------------------+ >>>>>>> | original IP header | >>>>>>> +------------------------+ >>>>>>> | | original IP payload >>> | >>>>>>> | | >>>>>>> +------------------------+ >>>>>>> >>>>>>> Where service header contains, at a minimum, enough information >>>>>>> to >>>>> allow >>>>>>> the packet to be propagated along the full length of the chain, >>> and >>>>>>> optionally, other metadata that enhances the operation of one or >>> more >>>>>>> service functions. >>>>>>> >>>>>>> And where "transport" could conceivably be any of, but not >>> limited >>>>> to: >>>>>>> >>>>>>> * Ethernet >>>>>>> * Ethernet + LLC2 >>>>>>> * Ethernet + MPLS >>>>>>> * Ethernet + IP + GRE >>>>>>> * Ethernet + IP +UDP >>>>>>> >>>>>>> >>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>> immutability, but rather to specify the packet that is >>>>>>> propagated from preceding entity to succeeding entity, prior to >>>>>>> encapsulation. >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Sumandra Majee >>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service >>>>>>> function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be >>>>>>> used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> [SM] What does it mean by a single service-level encapsulation, >>>>>>> a >>>>> new >>>>>>> encapsulation format >>>>>>> or an ability to select one encapsulation format >>>>>>> that >>>>> fits >>>>>>> the >>>>>>> need for a given service chain? >>>>>>> The ability to select a specific encapsulation >>>>>>> would >>> be >>> a >>>>>>> management plane decision. >>>>>>> There are quite a few existing encapsulation methods >>> that >>>>> can >>>>>>> possibly be reused to provide >>>>>>> context information between service nodes. I have seen >>>>>>> mention >>>>>>> of GRE, for HTTP based >>>>>>> applications contexts are transferred via headers. >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>> Behalf >>> Of >>>>>>> Thomas Narten >>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>> To: nsc@ietf.org >>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Hi. >>>>>>> >>>>>>> Current charter can be found at >>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>> ietf-sfc/. >>>>>>> >>>>>>> It contains the revised management text as well as updated >>>>> milestones. >>>>>>> >>>>>>> All known issues have been addressed. If there are any remaining >>>>> issues, >>>>>>> please speak up! >>>>>>> >>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>> >>>>>>> Networks, servers, storage technologies, and applications, have >>> all >>>>>>> undergone significant change in recent years with the >>>>>>> introduction >>> of >>>>>>> virtualization, network overlays, and orchestration. Service >>> delivery >>>>> is >>>>>>> currently both a technical and organizational challenge that >>> involves >>>>>>> significant modification to the network configuration. >>>>>>> Services are typically implemented by the ordered combination of >>>>>>> a number of service functions that are deployed at different >>>>>>> points within >>> the >>>>>>> network. Today, a common deployment model has service functions >>>>>>> physically inserted on the data forwarding path between >>>>>>> communicating peers. >>>>> Going >>>>>>> forward, however, there is a desire to move to a different >>>>>>> model, >>>>> where >>>>>>> service functions are not required to reside on the default data >>> path >>>>>>> and >>>>>>> traffic is instead steered through services, wherever they are >>>>> deployed. >>>>>>> >>>>>>> For a given service, the abstracted view of the required service >>>>>>> functions and the order in which they are to be applied is >>>>>>> called a Service Function Chain (SFC). Since a given service >>>>>>> function may be available on >>> more >>>>>>> than >>>>>>> one node within a network, a Service Function Chain is >>> instantiated >>>>> via >>>>>>> the selection of specific service function instances and the >>> network >>>>>>> nodes >>>>>>> on which they are provided, thereby forming a service topology: >>>>>>> this is called a Service Function Path. The service functions >>>>>>> may >>> be >>>>>>> applied at a specific layer within the network protocol stack >>>>> (network >>>>>>> layer, application layer, etc.). >>>>>>> >>>>>>> The Service Function Chaining (SFC) working group will develop >>>>>>> new approaches to service delivery and deployment. It will >>>>>>> produce a framework for service function chaining that includes >>>>>>> the necessary >>> protocols >>>>> or >>>>>>> protocol extensions to convey the service path and service path >>>>>>> information to nodes that implement service functions, as well >>>>>>> as mechanisms for steering traffic through service functions. >>>>>>> The >>>>> working >>>>>>> group will also examine what information needs to be gathered >>>>>>> from >>>>> the >>>>>>> network and service functions in support of service function >>> chaining >>>>>>> and >>>>>>> how that information may be made available to nodes that >>>>>>> implement >>>>> the >>>>>>> service functions. >>>>>>> >>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>> >>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>> problem space to be addressed by the WG including example >>> high- >>>>>>> level use cases. Additionally, the WG will normalize >>> nomenclature >>>>>>> and definitions for service function chaining. >>>>>>> >>>>>>> 2) Architecture: This document will provide a description of the >>>>>>> architectural building blocks and their relationships >>> including >>>>>>> interconnection, placement of capabilities, management, >>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>> requirements on the protocol mechanisms. >>>>>>> >>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>> will >>>>>>> describe the single service-level data plane encapsulation >>> format >>>>>>> for >>>>>>> conveying the service function chain and the service >>>>>>> function >>>>> path, >>>>>>> and for communicating context information between nodes that >>>>>>> implement service functions. It is intended that the >>>>> encapsulation >>>>>>> be agnostic to the layer at which it is applied and the >>> service >>>>> that >>>>>>> is >>>>>>> being constructed. That is, the same encapsulation may be >>>>>>> used >>> on >>>>>>> a service function path realized at the network layer or at >>> any >>>>>>> other >>>>>>> layer, and the same encapsulation will apply for the >>> construction >>>>> of >>>>>>> service function paths regardless of the actual service. >>>>>>> >>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>> developed >>> to >>>>>>> describe requirements and protocols necessary to convey >>>>> information >>>>>>> to service function implementation points. Where possible, >>>>> existing >>>>>>> IETF protocols will be used and extended. All protocol >>> extensions >>>>>>> work should be carried out in the working groups >>>>>>> responsible >>> for >>>>> the >>>>>>> protocols being modified in coordination with this working >>> group, >>>>>>> but >>>>>>> may be done in this working group after agreement with all the >>>>>>> relevant WG chairs and responsible ADs. >>>>>>> >>>>>>> 5) Manageability: Work on the management and configuration of >>> service >>>>>>> functions in support of SFC components will certainly be >>> needed, >>>>>>> but first needs to be better understood and scoped. >>>>>>> >>>>>>> Proposed Milestones >>>>>>> >>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>> problem >>>>>>> statement and core use cases for Service Function Chaining >>>>>>> >>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>> for >>>>>>> management and configuration of SFC components >>>>>>> >>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>> architecture >>>>>>> for SFC >>>>>>> >>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>> function >>>>>>> chaining encapsulation protocol >>>>>>> >>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>> generic >>>>>>> service function chaining header encapsulation >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thomas >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Tue Nov 12 15:36:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8918111E8163 for ; Tue, 12 Nov 2013 15:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4DvuzAMKGjz for ; Tue, 12 Nov 2013 15:36:40 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0872911E8109 for ; Tue, 12 Nov 2013 15:36:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25789; q=dns/txt; s=iport; t=1384299400; x=1385509000; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=MONioCM1TFP2u57xyWF49IfymdsPywivgcgIUMUMKZc=; b=eMpCIfHfX621yiBBP1pRIq+BUqUeVAQNC8+mex+71jeR8Py07jSBV5p2 zLRbP6sO7sjXB25sLlMFnsYYy/wViIPwt9Fvb3k+Aq5NNpVice+baR4Lp 9+jqlY11c8NrppWUTQM0rmwqeOyIqUn+vAhiabAbUuA6g08t5UK2W7oys 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFADi7glKtJV2c/2dsb2JhbABQCoMHOFO/JYEkFnSCJQEBAQQBAQEXDRMrAgcEEwYBCBEBAwEBARUJCS4LFAMGCAIEAQkJCRKHVAMPDbU3HYlZjhwEBgaBCC0FAgQEhCcDlC6DYZIKgyaBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,688,1378857600"; d="scan'208";a="283979356" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 12 Nov 2013 23:36:15 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACNaEg8029798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 23:36:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 17:36:14 -0600 From: "Jim Guichard (jguichar)" To: "Pham, Chuong D" , "Joel M. Halpern" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Sumandra Majee , "Thomas Narten" , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAIAAXUUAgACPqYD//7IUgA== Date: Tue, 12 Nov 2013 23:36:13 +0000 Message-ID: In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C285C08FCB0@WSMSG3154V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 23:36:46 -0000 Yes, the example was not meant to be an exhaustive technical representation; rather than saying "something" can detect "something" and tell "someone" to send traffic to chain "a" or "b" I thought a high level example might be more helpful. On 11/12/13 6:15 PM, "Pham, Chuong D" wrote: >Hi all, > >In the example below, PCRF is a control plane element. It is not in the >path of user plane traffic (traversing the service functions). I am not >sure if the example is valid. However, if the example is meant to say in >SFC1, the DPI informs the PCRF of the ApplicationID (aka via Sd interface >of the "TDF") so that the PCRF then informs the ingress node (a PCEF) to >start steering traffic to SFC2 or SFC3 instead SFC1 then it is valid. In >this case, the DPI acts as an intelligence node supplying information to >the PCRF so that the PCRF can make a decision on which service chain will >be used for a subscriber's flow. > >The issue here is once the traffic is no longer passing the DPI (SFC1 is >no longer used), no further decision based on DPI can be made. >Another issue is by the time the DPI "understands" the ApplicationID and >inform the PCRF, the user has already established TCP (and perhaps >application layer) connection with the server. SCF2 and SFC3 will then be >a case of steering mid-flow which will break TCP and application layer >sessions. > >Also, I could consider SFC1 is a case of pre-steering mediation (to >decide whether SFC2 or SFC3 is to be used) rather than a case of >reclassification and branching. > >My example of a reclassification and branching would be a case where an >DDoS inspection node diverts a flow to a DDoS clearing node once DDoS >attacks have been detected. > >Regards, >Chuong > > >-----Original Message----- >From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Sent: Wednesday, 13 November 2013 1:41 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Current Proposed SFC charter > >Jim, thank you for a concrete example. >I would suggest that in the usual cases, there is a better way to handle >this than branching and rewriting at the PCRF. > >If the DPI engine or PCRF logic (whichever makes the decision) notifies >the control logic about the decision for the flow, then the ingress can >direct subsequent packets to the correct place, avoiding needless >processing of further packets in the DPI and PCRF logic. >Further, the needed control information can be passed to the optimization >or parental control so that it does not matter where the first packet is >sent, avoiding the need for the PCRF to understand how to direct packets >to service paths. > >Yours, >Joel > >On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >> Hi Kevin, >> >> Let me try and provide a concrete example to see if this answers your >> specific question: >> >> Use case: P-GW -> PCRF -> services applied to traffic based on >> applicationID and subscriberID. >> >> Instantiated as: >> >> SFC1: P-GW -> DPI -> PCRF >> SFC2: PCRF -> video-optimization -> metering -> FW >> SFC3: PCRF -> parental-control -> metering -> FW >> >> In this case DPI is performed on SFC1 and identifies applicationID. >> The applicationID is carried in the service encapsulation to PCRF. >> PCRF uses solution specific logic (identifies subscriber, applies >> policies, etc) and uses the result along with the applicationID >> received from DPI to select an outbound service chain, SFC2 or SFC3. >> Note that in this case branching occurs from SFC1 to either SFC2 or >>SFC3. >> >> >> >> >> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >> >>>> Yes, reclassification can change the service path and >>>> re-classification may happen at any node along a service path. >>> >>> Just to expand on that, going back to the original question about >>> service header encapsulation, is it intended that a chain that is >>> re-classified will get a new chain ID which fully describes a chain >>> that is a superset of the original chain ID, prior to DPI-based >>> re-classification? (assuming the goal is "a single chain ID that is >>> commonly understood along the entire service chain" >>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>> >>> And the applicable subset of the permutative list of service paths >>> would be configured at each appropriate service node? >>> e.g., ID 1: NAT + firewall + DPI >>> ID 2: NAT + firewall + DPI + AV >>> ID 3: NAT + firewall + DPI + AV + NAT >>> ID 4: NAT + firewall + DPI + NAT >>> ID 5: NAT + firewall + DPI + AV + LB >>> ID 6: NAT + firewall + DPI + LB >>> ID 7: NAT + firewall + DPI + LB + CACHE >>> ID 8: NAT + firewall + DPI + CACHE >>> ID 9: NAT + firewall + DPI + optimizer + LB >>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every >>> flow then be initially classified as ID 1, but eventually get >>> re-classified to ID 2-11, after the DPI phase? >>> >>> thanx. >>> >>> -- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> nsc@ietf.org >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >>>> >>>> >>>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>> >>>>> Hi Surendra, >>>>> >>>>> Classification may be out of scope, but the level of service that >>>>>is >>>>> applicable is dependent upon the level of classification that can >>>>>be >>>>> performed. An assumption of packet level encapsulation has >>>> implications >>>>> on the level of classification being performed? If the stated >>>>> goals >>>> are >>>>> for firewall and load balancer functionality, then the >>>>> application >>>> level >>>>> nature of those functions needs to be taken into account? If, on >>>>>the >>>>> other hand, the service function scope is limited due to >>>>> limitations >>>> in >>>>> classification, that would be and important piece of information? >>>>> >>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>> points >>>>> of the service paths seem like re-classification points? Is that >>>>>the >>>>> interpretation from the architecture perspective? Or is the >>>>>service >>>>> function chain classification exclusive of DPI functionality? >>>> I have not fully read that draft yet. But in general, as >>>> described in the arch draft, the collection of services form a >>>> graph, segments of which are service paths. Yes, reclassification >>>> can change the service path and re-classification may happen at any >>>> node along a service path. >>>> >>>> Surendra. >>>>> >>>>> thanx. >>>>> >>>>> -- Kevin J. Ma >>>>> >>>>>> -----Original Message----- >>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> nsc@ietf.org >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>> >>>>>> Kevin, >>>>>> >>>>>> Classification mechanism is outside the scope of SFC. It can be >>>>>> based >>>> on >>>>>> the packet or information not in the packet(environmental >>>>>> attributes >>>> for >>>>>> instance) or a combination thereof. What is important is that such >>>>>> classification aids in traffic selection and service path >>>>>> identification. >>>>>> It is no different from a policy in this regard except that the >>>> policy >>>>>> now >>>>>> specifies the service path. >>>>>> Further, classification is not limited to the network elements but >>>> the >>>>>> service functions as well. Some of this is described in the >>>> architecture >>>>>> drafts as well - >>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>> >>>>>> Surendra. >>>>>> >>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" wrote: >>>>>> >>>>>>> Hi Ron, >>>>>>> >>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >>>>>>> but >>>> I >>>>>>> had a similar question wrt bullet 11 in section 2 of the >>>>>>> problem >>>>>>> statement: >>>>>>> >>>>>>> 11. Per-Service (re)Classification: Classification occurs at >>>> each >>>>>>> service, independent from previously applied service >>>>>> functions. >>>>>>> These unrelated classification events consume resources >>>>>>>per >>>>>>> service. More importantly, the classification >>>> functionality >>>>>>> often differs per service function and service function >>>> cannot >>>>>>> leverage the results from other deployed network or >>>> service. >>>>>>> >>>>>>> as it relates to section 5.2 of the framework document: >>>>>>> >>>>>>> The SFC Classifier classifies packets based on (some of) the >>>>>> contents >>>>>>> of the packet header. Concretely, it classifies packets >>>>>>> based >>>> on >>>>>> the >>>>>>> possible combination of one or more header fields, such as >>>> source >>>>>>> address, destination address, DS field, protocol ID, source >>>>>>> port >>>>>> and >>>>>>> destination port numbers, and any other information. >>>>>>> >>>>>>> A packet-based classifier as described in the framework >>>>>>> document >>>>>> would >>>>>>> seem to be limited in what it can classify? The service function >>>>>>> identifier lookup does not seem to be a significant >>>>>>> optimization >>>> over >>>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>>> detail >>>>>>> wrt how classification information is determined and reused? >>>>>>> >>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>> encrypted >>>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>>> wondering >>>>>>> how independent HLS segment requests might be classified and >>>>>> associated? >>>>>>> Were these types of use cases discussed in the BoF? >>>>>>> >>>>>>> thanx. >>>>>>> >>>>>>> -- Kevin J. Ma >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Ron >>>>>>>> Parker >>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As was discussed in Vancouver, there are already many existing >>>> ways >>>>>> to >>>>>>>> accomplish service chaining. But none of them provide a >>>>>> sufficient >>>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>>> single >>>>>>>> service chain encapsulation will go a long way to ensuring these >>>>>> goals. >>>>>>>> It may not be the absolutely most efficient approach for every >>>>>> single >>>>>>>> network topology and every single use case, but its ubiquitous >>>> nature >>>>>>>> should improve its adoption. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>> However >>>>>> this >>>>>>>> could be augmented with classification result, again one more >>>>>> example. >>>>>>>> >>>>>>>>>> All flows from the same source IP do not necessarily follow >>>>>>>>>> the >>>>>> same >>>>>>>> chain. >>>>>>>> Correct. It is also not necessary that all transaction of the >>>>>>>> same >>>>>> flow >>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>> >>>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>>> >>>>>>>> Sumandra >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> The intention of service function chaining is to allow for >>>> operation >>>>>> at >>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>> transaction >>>>>>>> level (this is an implementation matter for the PDP). All >>>> flows >>>>>> from >>>>>>>> the same source IP do not necessarily follow the same chain. >>>> Source >>>>>>>> IP, >>>>>>>> therefore, does not identify the chain ID. Another intention >>>> of >>>>>>>> service function chaining is to operate over any network >>>>>>>> topology >>>> and >>>>>>>> not >>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>>> transport, it does not adequately identify the service chain, >>>> either. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Ron, >>>>>>>> >>>>>>>> The service header is meant to carry the context which can >>>>>>>> *also* >>>> be >>>>>>>> derived (for example use source ip and vlan to identify chainID >>>> and >>>>>>>> position) or encapsulated as part of another tunnel header. So >>>> this >>>>>>>> could >>>>>>>> be optional IMHO. >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Sumandra, >>>>>>>> >>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>> from >>>>>> SF >>>>>>>> to >>>>>>>> SF will look like: >>>>>>>> >>>>>>>> +------------------------+ >>>>>>>> | "transport" | >>>>>>>> +------------------------+ >>>>>>>> | service header | >>>>>>>> +------------------------+ >>>>>>>> | original IP header | >>>>>>>> +------------------------+ >>>>>>>> | | original IP payload >>>> | >>>>>>>> | | >>>>>>>> +------------------------+ >>>>>>>> >>>>>>>> Where service header contains, at a minimum, enough information >>>>>>>> to >>>>>> allow >>>>>>>> the packet to be propagated along the full length of the chain, >>>> and >>>>>>>> optionally, other metadata that enhances the operation of one or >>>> more >>>>>>>> service functions. >>>>>>>> >>>>>>>> And where "transport" could conceivably be any of, but not >>>> limited >>>>>> to: >>>>>>>> >>>>>>>> * Ethernet >>>>>>>> * Ethernet + LLC2 >>>>>>>> * Ethernet + MPLS >>>>>>>> * Ethernet + IP + GRE >>>>>>>> * Ethernet + IP +UDP >>>>>>>> >>>>>>>> >>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>> immutability, but rather to specify the packet that is >>>>>>>> propagated from preceding entity to succeeding entity, prior to >>>>>>>> encapsulation. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Sumandra Majee >>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service >>>>>>>> function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>> used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> [SM] What does it mean by a single service-level encapsulation, >>>>>>>> a >>>>>> new >>>>>>>> encapsulation format >>>>>>>> or an ability to select one encapsulation format >>>>>>>> that >>>>>> fits >>>>>>>> the >>>>>>>> need for a given service chain? >>>>>>>> The ability to select a specific encapsulation >>>>>>>> would >>>> be >>>> a >>>>>>>> management plane decision. >>>>>>>> There are quite a few existing encapsulation methods >>>> that >>>>>> can >>>>>>>> possibly be reused to provide >>>>>>>> context information between service nodes. I have >>>>>>>>seen >>>>>>>> mention >>>>>>>> of GRE, for HTTP based >>>>>>>> applications contexts are transferred via headers. >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>> Behalf >>>> Of >>>>>>>> Thomas Narten >>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>> To: nsc@ietf.org >>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Hi. >>>>>>>> >>>>>>>> Current charter can be found at >>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>> ietf-sfc/. >>>>>>>> >>>>>>>> It contains the revised management text as well as updated >>>>>> milestones. >>>>>>>> >>>>>>>> All known issues have been addressed. If there are any remaining >>>>>> issues, >>>>>>>> please speak up! >>>>>>>> >>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>> >>>>>>>> Networks, servers, storage technologies, and applications, have >>>> all >>>>>>>> undergone significant change in recent years with the >>>>>>>> introduction >>>> of >>>>>>>> virtualization, network overlays, and orchestration. Service >>>> delivery >>>>>> is >>>>>>>> currently both a technical and organizational challenge that >>>> involves >>>>>>>> significant modification to the network configuration. >>>>>>>> Services are typically implemented by the ordered combination of >>>>>>>> a number of service functions that are deployed at different >>>>>>>> points within >>>> the >>>>>>>> network. Today, a common deployment model has service functions >>>>>>>> physically inserted on the data forwarding path between >>>>>>>> communicating peers. >>>>>> Going >>>>>>>> forward, however, there is a desire to move to a different >>>>>>>> model, >>>>>> where >>>>>>>> service functions are not required to reside on the default data >>>> path >>>>>>>> and >>>>>>>> traffic is instead steered through services, wherever they are >>>>>> deployed. >>>>>>>> >>>>>>>> For a given service, the abstracted view of the required service >>>>>>>> functions and the order in which they are to be applied is >>>>>>>> called a Service Function Chain (SFC). Since a given service >>>>>>>> function may be available on >>>> more >>>>>>>> than >>>>>>>> one node within a network, a Service Function Chain is >>>> instantiated >>>>>> via >>>>>>>> the selection of specific service function instances and the >>>> network >>>>>>>> nodes >>>>>>>> on which they are provided, thereby forming a service topology: >>>>>>>> this is called a Service Function Path. The service functions >>>>>>>> may >>>> be >>>>>>>> applied at a specific layer within the network protocol stack >>>>>> (network >>>>>>>> layer, application layer, etc.). >>>>>>>> >>>>>>>> The Service Function Chaining (SFC) working group will develop >>>>>>>> new approaches to service delivery and deployment. It will >>>>>>>> produce a framework for service function chaining that includes >>>>>>>> the necessary >>>> protocols >>>>>> or >>>>>>>> protocol extensions to convey the service path and service path >>>>>>>> information to nodes that implement service functions, as well >>>>>>>> as mechanisms for steering traffic through service functions. >>>>>>>> The >>>>>> working >>>>>>>> group will also examine what information needs to be gathered >>>>>>>> from >>>>>> the >>>>>>>> network and service functions in support of service function >>>> chaining >>>>>>>> and >>>>>>>> how that information may be made available to nodes that >>>>>>>> implement >>>>>> the >>>>>>>> service functions. >>>>>>>> >>>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>>> >>>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>>> problem space to be addressed by the WG including example >>>> high- >>>>>>>> level use cases. Additionally, the WG will normalize >>>> nomenclature >>>>>>>> and definitions for service function chaining. >>>>>>>> >>>>>>>> 2) Architecture: This document will provide a description of the >>>>>>>> architectural building blocks and their relationships >>>> including >>>>>>>> interconnection, placement of capabilities, management, >>>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>>> requirements on the protocol mechanisms. >>>>>>>> >>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>>> will >>>>>>>> describe the single service-level data plane encapsulation >>>> format >>>>>>>> for >>>>>>>> conveying the service function chain and the service >>>>>>>> function >>>>>> path, >>>>>>>> and for communicating context information between nodes that >>>>>>>> implement service functions. It is intended that the >>>>>> encapsulation >>>>>>>> be agnostic to the layer at which it is applied and the >>>> service >>>>>> that >>>>>>>> is >>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>> used >>>> on >>>>>>>> a service function path realized at the network layer or at >>>> any >>>>>>>> other >>>>>>>> layer, and the same encapsulation will apply for the >>>> construction >>>>>> of >>>>>>>> service function paths regardless of the actual service. >>>>>>>> >>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>> developed >>>> to >>>>>>>> describe requirements and protocols necessary to convey >>>>>> information >>>>>>>> to service function implementation points. Where possible, >>>>>> existing >>>>>>>> IETF protocols will be used and extended. All protocol >>>> extensions >>>>>>>> work should be carried out in the working groups >>>>>>>> responsible >>>> for >>>>>> the >>>>>>>> protocols being modified in coordination with this working >>>> group, >>>>>>>> but >>>>>>>> may be done in this working group after agreement with all >>>>>>>>the >>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>> >>>>>>>> 5) Manageability: Work on the management and configuration of >>>> service >>>>>>>> functions in support of SFC components will certainly be >>>> needed, >>>>>>>> but first needs to be better understood and scoped. >>>>>>>> >>>>>>>> Proposed Milestones >>>>>>>> >>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>>> problem >>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>> >>>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>>> for >>>>>>>> management and configuration of SFC components >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>> architecture >>>>>>>> for SFC >>>>>>>> >>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>> function >>>>>>>> chaining encapsulation protocol >>>>>>>> >>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>>> generic >>>>>>>> service function chaining header encapsulation >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thomas >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> > From linda.dunbar@huawei.com Tue Nov 12 17:20:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662421E80AC for ; Tue, 12 Nov 2013 17:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9NS8av3v+9H for ; Tue, 12 Nov 2013 17:19:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC1321E809C for ; Tue, 12 Nov 2013 17:19:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE86598; Wed, 13 Nov 2013 01:19:55 +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, 13 Nov 2013 01:19:40 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 01:19:39 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 17:19:35 -0800 From: Linda Dunbar To: Jerome Moisand , "Joel M. Halpern" , "Jim Guichard (jguichar)" , "Kevin J Ma" , "Surendra Kumar (smkumar)" , Ron Parker , "Sumandra Majee" , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN+0+4iz5RRxkOCS0vXxMG0/5ohQBeAgAAOHICAACcJgIAAAa2AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAHlxAIAACW8AgAAH9wD//3uzQA== Date: Wed, 13 Nov 2013 01:19:34 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645C05D4F@dfweml509-mbx.china.huawei.com> References: <52823DF6.5050306@joelhalpern.com> <06825c9329714f04ac0ce09ae995f7ed@BN1PR05MB251.namprd05.prod.outlook.com> In-Reply-To: <06825c9329714f04ac0ce09ae995f7ed@BN1PR05MB251.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 01:20:06 -0000 Jerome is right, the actual data path do not go through the PCRF. PCRF is r= esponsible for giving policies to the P-GW.=20 The example given by Jim showing that PCRF is one of the service functions,= is confusing.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Jerome Moisand > Sent: Tuesday, November 12, 2013 9:09 AM > To: Joel M. Halpern; Jim Guichard (jguichar); Kevin J Ma; Surendra > Kumar (smkumar); Ron Parker; Sumandra Majee; Thomas Narten; > nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > No clue what you guys are discussing. >=20 > PCRF (when relevant for a given type of domain, e.g. mobile broadband) > has a role to play in service chaining for sure, but... A PCRF is a > control plane element, not a data plane element. It is not part of a > service chain, it would control (part of) it. >=20 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: Tuesday, November 12, 2013 9:41 AM > To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron > Parker; Sumandra Majee; Thomas Narten; nsc@ietf.org > Subject: Re: [nsc] Current Proposed SFC charter >=20 > Jim, thank you for a concrete example. > I would suggest that in the usual cases, there is a better way to > handle this than branching and rewriting at the PCRF. >=20 > If the DPI engine or PCRF logic (whichever makes the decision) notifies > the control logic about the decision for the flow, then the ingress can > direct subsequent packets to the correct place, avoiding needless > processing of further packets in the DPI and PCRF logic. > Further, the needed control information can be passed to the > optimization or parental control so that it does not matter where the > first packet is sent, avoiding the need for the PCRF to understand how > to direct packets to service paths. >=20 > Yours, > Joel >=20 > On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: > > Hi Kevin, > > > > Let me try and provide a concrete example to see if this answers your > > specific question: > > > > Use case: P-GW -> PCRF -> services applied to traffic based on > > applicationID and subscriberID. > > > > Instantiated as: > > > > SFC1: P-GW -> DPI -> PCRF > > SFC2: PCRF -> video-optimization -> metering -> FW > > SFC3: PCRF -> parental-control -> metering -> FW > > > > In this case DPI is performed on SFC1 and identifies applicationID. > > The applicationID is carried in the service encapsulation to PCRF. > > PCRF uses solution specific logic (identifies subscriber, applies > > policies, etc) and uses the result along with the applicationID > > received from DPI to select an outbound service chain, SFC2 or SFC3. > > Note that in this case branching occurs from SFC1 to either SFC2 or > SFC3. > > > > > > > > > > On 11/12/13 1:52 AM, "Kevin J Ma" wrote: > > > >>> Yes, reclassification can change the service path and > >>> re-classification may happen at any node along a service path. > >> > >> Just to expand on that, going back to the original question about > >> service header encapsulation, is it intended that a chain that is > >> re-classified will get a new chain ID which fully describes a chain > >> that is a superset of the original chain ID, prior to DPI-based > >> re-classification? (assuming the goal is "a single chain ID that is > >> commonly understood along the entire service chain" > >> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) > >> > >> And the applicable subset of the permutative list of service paths > >> would be configured at each appropriate service node? > >> e.g., ID 1: NAT + firewall + DPI > >> ID 2: NAT + firewall + DPI + AV > >> ID 3: NAT + firewall + DPI + AV + NAT > >> ID 4: NAT + firewall + DPI + NAT > >> ID 5: NAT + firewall + DPI + AV + LB > >> ID 6: NAT + firewall + DPI + LB > >> ID 7: NAT + firewall + DPI + LB + CACHE > >> ID 8: NAT + firewall + DPI + CACHE > >> ID 9: NAT + firewall + DPI + optimizer + LB > >> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE > >> ID 11: NAT + firewall + DPI + optimizer + CACHE Would every > >> flow then be initially classified as ID 1, but eventually get > >> re-classified to ID 2-11, after the DPI phase? > >> > >> thanx. > >> > >> -- Kevin J. Ma > >> > >>> -----Original Message----- > >>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >>> Sent: Tuesday, November 12, 2013 1:01 AM > >>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>> nsc@ietf.org > >>> Subject: Re: [nsc] Current Proposed SFC charter > >>> > >>> > >>> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: > >>> > >>>> Hi Surendra, > >>>> > >>>> Classification may be out of scope, but the level of service > that is > >>>> applicable is dependent upon the level of classification that > can be > >>>> performed. An assumption of packet level encapsulation has > >>> implications > >>>> on the level of classification being performed? If the stated > >>>> goals > >>> are > >>>> for firewall and load balancer functionality, then the > >>>> application > >>> level > >>>> nature of those functions needs to be taken into account? If, > on the > >>>> other hand, the service function scope is limited due to > >>>> limitations > >>> in > >>>> classification, that would be and important piece of information? > >>>> > >>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork > >>> points > >>>> of the service paths seem like re-classification points? Is > that the > >>>> interpretation from the architecture perspective? Or is the > service > >>>> function chain classification exclusive of DPI functionality? > >>> I have not fully read that draft yet. But in general, as > >>> described in the arch draft, the collection of services form a > >>> graph, segments of which are service paths. Yes, reclassification > >>> can change the service path and re-classification may happen at any > >>> node along a service path. > >>> > >>> Surendra. > >>>> > >>>> thanx. > >>>> > >>>> -- Kevin J. Ma > >>>> > >>>>> -----Original Message----- > >>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > >>>>> Sent: Tuesday, November 12, 2013 12:08 AM > >>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; > >>> nsc@ietf.org > >>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>> > >>>>> Kevin, > >>>>> > >>>>> Classification mechanism is outside the scope of SFC. It can be > >>>>> based > >>> on > >>>>> the packet or information not in the packet(environmental > >>>>> attributes > >>> for > >>>>> instance) or a combination thereof. What is important is that > such > >>>>> classification aids in traffic selection and service path > >>>>> identification. > >>>>> It is no different from a policy in this regard except that the > >>> policy > >>>>> now > >>>>> specifies the service path. > >>>>> Further, classification is not limited to the network elements > but > >>> the > >>>>> service functions as well. Some of this is described in the > >>> architecture > >>>>> drafts as well - > >>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". > >>>>> > >>>>> Surendra. > >>>>> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" > wrote: > >>>>> > >>>>>> Hi Ron, > >>>>>> > >>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, > >>>>>> but > >>> I > >>>>>> had a similar question wrt bullet 11 in section 2 of the > >>>>>> problem > >>>>>> statement: > >>>>>> > >>>>>> 11. Per-Service (re)Classification: Classification occurs > at > >>> each > >>>>>> service, independent from previously applied service > >>>>> functions. > >>>>>> These unrelated classification events consume resources > per > >>>>>> service. More importantly, the classification > >>> functionality > >>>>>> often differs per service function and service function > >>> cannot > >>>>>> leverage the results from other deployed network or > >>> service. > >>>>>> > >>>>>> as it relates to section 5.2 of the framework document: > >>>>>> > >>>>>> The SFC Classifier classifies packets based on (some of) the > >>>>> contents > >>>>>> of the packet header. Concretely, it classifies packets > >>>>>> based > >>> on > >>>>> the > >>>>>> possible combination of one or more header fields, such as > >>> source > >>>>>> address, destination address, DS field, protocol ID, source > >>>>>> port > >>>>> and > >>>>>> destination port numbers, and any other information. > >>>>>> > >>>>>> A packet-based classifier as described in the framework > >>>>>> document > >>>>> would > >>>>>> seem to be limited in what it can classify? The service > function > >>>>>> identifier lookup does not seem to be a significant > >>>>>> optimization > >>> over > >>>>>> a packet-based 5-tuple lookup? There seems to be some missing > >>> detail > >>>>>> wrt how classification information is determined and reused? > >>>>>> > >>>>>> When thinking about higher level services, e.g., HTTP and TLS > >>>>> encrypted > >>>>>> flows, a packet-based classifier seems inadequate? I was also > >>>>> wondering > >>>>>> how independent HLS segment requests might be classified and > >>>>> associated? > >>>>>> Were these types of use cases discussed in the BoF? > >>>>>> > >>>>>> thanx. > >>>>>> > >>>>>> -- Kevin J. Ma > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>>> Behalf > >>> Of > >>>>>>> Ron > >>>>>>> Parker > >>>>>>> Sent: Monday, November 11, 2013 10:16 PM > >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Sumandra, > >>>>>>> > >>>>>>> As was discussed in Vancouver, there are already many existing > >>> ways > >>>>> to > >>>>>>> accomplish service chaining. But none of them provide a > >>>>> sufficient > >>>>>>> combination of interoperability, flexibility, and resiliency. > A > >>>>> single > >>>>>>> service chain encapsulation will go a long way to ensuring > these > >>>>> goals. > >>>>>>> It may not be the absolutely most efficient approach for every > >>>>> single > >>>>>>> network topology and every single use case, but its ubiquitous > >>> nature > >>>>>>> should improve its adoption. > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>>> Sent: Monday, November 11, 2013 10:10 PM > >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Ron, > >>>>>>> > >>>>>>> Absolutely, that was an example of one type of derivation. > >>>>>>> However > >>>>> this > >>>>>>> could be augmented with classification result, again one more > >>>>> example. > >>>>>>> > >>>>>>>>> All flows from the same source IP do not necessarily follow > >>>>>>>>> the > >>>>> same > >>>>>>> chain. > >>>>>>> Correct. It is also not necessary that all transaction of the > >>>>>>> same > >>>>> flow > >>>>>>> follow the same chain either. So why stop at flow itself. > >>>>>>> > >>>>>>> Again the point here is that do we always need SFC header or > Not. > >>>>>>> > >>>>>>> Sumandra > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>>> Sent: Monday, November 11, 2013 7:02 PM > >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Sumandra, > >>>>>>> > >>>>>>> The intention of service function chaining is to allow for > >>> operation > >>>>> at > >>>>>>> the fully qualified flow level, or even finer grained at the > >>>>> transaction > >>>>>>> level (this is an implementation matter for the PDP). All > >>> flows > >>>>> from > >>>>>>> the same source IP do not necessarily follow the same chain. > >>> Source > >>>>>>> IP, > >>>>>>> therefore, does not identify the chain ID. Another > intention > >>> of > >>>>>>> service function chaining is to operate over any network > >>>>>>> topology > >>> and > >>>>>>> not > >>>>>>> be limited to a single LAN. Thus, while VLAN may be part of > the > >>>>>>> transport, it does not adequately identify the service chain, > >>> either. > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] > >>>>>>> Sent: Monday, November 11, 2013 9:56 PM > >>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org > >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Ron, > >>>>>>> > >>>>>>> The service header is meant to carry the context which can > >>>>>>> *also* > >>> be > >>>>>>> derived (for example use source ip and vlan to identify chainID > >>> and > >>>>>>> position) or encapsulated as part of another tunnel header. So > >>> this > >>>>>>> could > >>>>>>> be optional IMHO. > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >>>>>>> Sent: Monday, November 11, 2013 4:36 PM > >>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org > >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Sumandra, > >>>>>>> > >>>>>>> As I understand it, an SFC packet traversing from PDP to SF or > >>> from > >>>>> SF > >>>>>>> to > >>>>>>> SF will look like: > >>>>>>> > >>>>>>> +------------------------+ > >>>>>>> | "transport" | > >>>>>>> +------------------------+ > >>>>>>> | service header | > >>>>>>> +------------------------+ > >>>>>>> | original IP header | > >>>>>>> +------------------------+ > >>>>>>> | | original IP > payload > >>> | > >>>>>>> | | > >>>>>>> +------------------------+ > >>>>>>> > >>>>>>> Where service header contains, at a minimum, enough information > >>>>>>> to > >>>>> allow > >>>>>>> the packet to be propagated along the full length of the chain, > >>> and > >>>>>>> optionally, other metadata that enhances the operation of one > or > >>> more > >>>>>>> service functions. > >>>>>>> > >>>>>>> And where "transport" could conceivably be any of, but not > >>> limited > >>>>> to: > >>>>>>> > >>>>>>> * Ethernet > >>>>>>> * Ethernet + LLC2 > >>>>>>> * Ethernet + MPLS > >>>>>>> * Ethernet + IP + GRE > >>>>>>> * Ethernet + IP +UDP > >>>>>>> > >>>>>>> > >>>>>>> Also, "original" in the diagram above is not meant to imply > >>>>>>> immutability, but rather to specify the packet that is > >>>>>>> propagated from preceding entity to succeeding entity, prior to > >>>>>>> encapsulation. > >>>>>>> > >>>>>>> Ron > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>>> Behalf > >>> Of > >>>>>>> Sumandra Majee > >>>>>>> Sent: Monday, November 11, 2013 6:46 PM > >>>>>>> To: Thomas Narten; nsc@ietf.org > >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Generic Service Function Chaining Encapsulation: A document > will > >>>>>>> describe the single service-level data plane encapsulation > >>> format > >>>>>>> for > >>>>>>> conveying the service function chain and the service > >>>>>>> function > >>>>> path, > >>>>>>> and for communicating context information between nodes > that > >>>>>>> implement service functions. It is intended that the > >>>>> encapsulation > >>>>>>> be agnostic to the layer at which it is applied and the > >>> service > >>>>> that > >>>>>>> is > >>>>>>> being constructed. That is, the same encapsulation may be > >>>>>>> used > >>> on > >>>>>>> a service function path realized at the network layer or > at > >>> any > >>>>>>> other > >>>>>>> layer, and the same encapsulation will apply for the > >>> construction > >>>>> of > >>>>>>> service function paths regardless of the actual service. > >>>>>>> > >>>>>>> [SM] What does it mean by a single service-level encapsulation, > >>>>>>> a > >>>>> new > >>>>>>> encapsulation format > >>>>>>> or an ability to select one encapsulation format > >>>>>>> that > >>>>> fits > >>>>>>> the > >>>>>>> need for a given service chain? > >>>>>>> The ability to select a specific encapsulation > >>>>>>> would > >>> be > >>> a > >>>>>>> management plane decision. > >>>>>>> There are quite a few existing encapsulation methods > >>> that > >>>>> can > >>>>>>> possibly be reused to provide > >>>>>>> context information between service nodes. I have > seen > >>>>>>> mention > >>>>>>> of GRE, for HTTP based > >>>>>>> applications contexts are transferred via headers. > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On > >>>>>>> Behalf > >>> Of > >>>>>>> Thomas Narten > >>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM > >>>>>>> To: nsc@ietf.org > >>>>>>> Subject: [nsc] Current Proposed SFC charter > >>>>>>> > >>>>>>> Hi. > >>>>>>> > >>>>>>> Current charter can be found at > >>>>>>> https://datatracker.ietf.org/doc/charter- > >>>>>>> ietf-sfc/. > >>>>>>> > >>>>>>> It contains the revised management text as well as updated > >>>>> milestones. > >>>>>>> > >>>>>>> All known issues have been addressed. If there are any > remaining > >>>>> issues, > >>>>>>> please speak up! > >>>>>>> > >>>>>>> Charter charter-ietf-sfc-00-04 > >>>>>>> > >>>>>>> Networks, servers, storage technologies, and applications, have > >>> all > >>>>>>> undergone significant change in recent years with the > >>>>>>> introduction > >>> of > >>>>>>> virtualization, network overlays, and orchestration. Service > >>> delivery > >>>>> is > >>>>>>> currently both a technical and organizational challenge that > >>> involves > >>>>>>> significant modification to the network configuration. > >>>>>>> Services are typically implemented by the ordered combination > of > >>>>>>> a number of service functions that are deployed at different > >>>>>>> points within > >>> the > >>>>>>> network. Today, a common deployment model has service functions > >>>>>>> physically inserted on the data forwarding path between > >>>>>>> communicating peers. > >>>>> Going > >>>>>>> forward, however, there is a desire to move to a different > >>>>>>> model, > >>>>> where > >>>>>>> service functions are not required to reside on the default > data > >>> path > >>>>>>> and > >>>>>>> traffic is instead steered through services, wherever they are > >>>>> deployed. > >>>>>>> > >>>>>>> For a given service, the abstracted view of the required > service > >>>>>>> functions and the order in which they are to be applied is > >>>>>>> called a Service Function Chain (SFC). Since a given service > >>>>>>> function may be available on > >>> more > >>>>>>> than > >>>>>>> one node within a network, a Service Function Chain is > >>> instantiated > >>>>> via > >>>>>>> the selection of specific service function instances and the > >>> network > >>>>>>> nodes > >>>>>>> on which they are provided, thereby forming a service topology: > >>>>>>> this is called a Service Function Path. The service functions > >>>>>>> may > >>> be > >>>>>>> applied at a specific layer within the network protocol stack > >>>>> (network > >>>>>>> layer, application layer, etc.). > >>>>>>> > >>>>>>> The Service Function Chaining (SFC) working group will develop > >>>>>>> new approaches to service delivery and deployment. It will > >>>>>>> produce a framework for service function chaining that includes > >>>>>>> the necessary > >>> protocols > >>>>> or > >>>>>>> protocol extensions to convey the service path and service path > >>>>>>> information to nodes that implement service functions, as well > >>>>>>> as mechanisms for steering traffic through service functions. > >>>>>>> The > >>>>> working > >>>>>>> group will also examine what information needs to be gathered > >>>>>>> from > >>>>> the > >>>>>>> network and service functions in support of service function > >>> chaining > >>>>>>> and > >>>>>>> how that information may be made available to nodes that > >>>>>>> implement > >>>>> the > >>>>>>> service functions. > >>>>>>> > >>>>>>> Specifically, the SFC WG is chartered to deliver the following: > >>>>>>> > >>>>>>> 1) Problem Statement: This document will provide a summary of > the > >>>>>>> problem space to be addressed by the WG including example > >>> high- > >>>>>>> level use cases. Additionally, the WG will normalize > >>> nomenclature > >>>>>>> and definitions for service function chaining. > >>>>>>> > >>>>>>> 2) Architecture: This document will provide a description of > the > >>>>>>> architectural building blocks and their relationships > >>> including > >>>>>>> interconnection, placement of capabilities, management, > >>>>>>> diagnostics, design analysis, and security models, as well > as > >>>>>>> requirements on the protocol mechanisms. > >>>>>>> > >>>>>>> 3) Generic Service Function Chaining Encapsulation: A document > >>> will > >>>>>>> describe the single service-level data plane encapsulation > >>> format > >>>>>>> for > >>>>>>> conveying the service function chain and the service > >>>>>>> function > >>>>> path, > >>>>>>> and for communicating context information between nodes > that > >>>>>>> implement service functions. It is intended that the > >>>>> encapsulation > >>>>>>> be agnostic to the layer at which it is applied and the > >>> service > >>>>> that > >>>>>>> is > >>>>>>> being constructed. That is, the same encapsulation may be > >>>>>>> used > >>> on > >>>>>>> a service function path realized at the network layer or > at > >>> any > >>>>>>> other > >>>>>>> layer, and the same encapsulation will apply for the > >>> construction > >>>>> of > >>>>>>> service function paths regardless of the actual service. > >>>>>>> > >>>>>>> 4) Control Plane Mechanisms: A set of documents will be > >>>>>>> developed > >>> to > >>>>>>> describe requirements and protocols necessary to convey > >>>>> information > >>>>>>> to service function implementation points. Where possible, > >>>>> existing > >>>>>>> IETF protocols will be used and extended. All protocol > >>> extensions > >>>>>>> work should be carried out in the working groups > >>>>>>> responsible > >>> for > >>>>> the > >>>>>>> protocols being modified in coordination with this working > >>> group, > >>>>>>> but > >>>>>>> may be done in this working group after agreement with all > the > >>>>>>> relevant WG chairs and responsible ADs. > >>>>>>> > >>>>>>> 5) Manageability: Work on the management and configuration of > >>> service > >>>>>>> functions in support of SFC components will certainly be > >>> needed, > >>>>>>> but first needs to be better understood and scoped. > >>>>>>> > >>>>>>> Proposed Milestones > >>>>>>> > >>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the > >>>>> problem > >>>>>>> statement and core use cases for Service Function Chaining > >>>>>>> > >>>>>>> May 2014 Consult with OPS Area on possible charter > modifications > >>> for > >>>>>>> management and configuration of SFC components > >>>>>>> > >>>>>>> Jan 2015 Submit to IESG Informational document defining the > >>>>> architecture > >>>>>>> for SFC > >>>>>>> > >>>>>>> Jan 2015 Submit to IESG requirements for a generic service > >>> function > >>>>>>> chaining encapsulation protocol > >>>>>>> > >>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the > >>>>> generic > >>>>>>> service function chaining header encapsulation > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thomas > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> nsc mailing list > >>>>>>> nsc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>>> _______________________________________________ > >>>>>>> nsc mailing list > >>>>>>> nsc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>>> _______________________________________________ > >>>>>>> nsc mailing list > >>>>>>> nsc@ietf.org > >>>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>>>> _______________________________________________ > >>>>>> nsc mailing list > >>>>>> nsc@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/nsc > >>>> > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From hongyu.li@huawei.com Wed Nov 13 01:29:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F79721E808D for ; Wed, 13 Nov 2013 01:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDIwKEj7jmoB for ; Wed, 13 Nov 2013 01:28:56 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 090C521E80AE for ; Wed, 13 Nov 2013 01:28:54 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml203-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AOL96297; Wed, 13 Nov 2013 03:28:49 -0600 (CST) 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, 13 Nov 2013 09:28:11 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Nov 2013 09:28:26 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 17:28:20 +0800 From: "Hongyu Li (Julio)" To: Ron Parker , Kevin J Ma Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9nE/gbi+9tEGr7VYhI0C+3ZogM9+AgAAOHICAACcIgIAAAa2AgAACJYCAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAiG7Q//+h1oCAAcduYA== Date: Wed, 13 Nov 2013 09:28:19 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E996600@SZXEMA509-MBX.china.huawei.com> References: <291CC3F9E50E7641901A54E85D0977C6B028025F7C@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6B028025F80@MAILR002.mail.lan> <6EB34CB5D82C4645B826C56144826EA97DFDB484@szxeml560-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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Thomas Narten , "nsc@ietf.org" , "Surendra Kumar \(smkumar\)" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 09:29:01 -0000 Um9uLA0KDQpJIGFncmVlIHdpdGggSmltJ3MgZXhhbXBsZSBpbiBhbm90aGVyIGVtYWlsIHRoYXQg U0ZDMSBpcyBzdGl0Y2hlZCB0byBTRkMyIGFuZCBTRkMzLiBVc2luZyBkaWZmZXJlbnQgY2hhaW4g Zm9yIGJyYW5jaGVzIGlzIGVhc2llciBmb3IgcHJvdG9jb2wuIFRoZSBwcm92aXNpb25pbmcgaXMg Y29tcGxleCBmb3IgYSBicmFuY2hpbmcgY2FzZSBhbnl3YXkuDQoNCkhvbmd5dQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJA YWZmaXJtZWRuZXR3b3Jrcy5jb21dIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMg MTA6MTYgUE0NClRvOiBIb25neXUgTGkgKEp1bGlvKTsgS2V2aW4gSiBNYQ0KQ2M6IFRob21hcyBO YXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBTdW1hbmRyYSBN YWplZQ0KU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0K SG9uZ3l1LCANCg0KSSBhZ3JlZSBjb21wbGV0ZWx5IHRoYXQgcmUtY2xhc3NpZmljYXRpb24gaXMg bm90IGxpbWl0ZWQgdG8gRFBJLg0KDQpBbmQgYWxzbywgdGhhdCBhbiBhcmVhIGZvciB1cyB0byBl eHBsb3JlIGFzIGEgZ3JvdXAgaXMgaG93IHRvIHJlcHJlc2VudCB0aGUgc2VydmljZSBncmFwaC4g ICBEbyB3ZSB3YW50IHRvIHJlcHJlc2VudCBpdCBhcyBhIHByb3BlciBncmFwaCB3aXRoIGFuIGFk amFjZW5jeSBsaXN0IG9yIG90aGVyIHJlcHJlc2VudGF0aW9uYWwgbW9kZWw/ICAgT3IsIGRvIHdl IHdhbnQgdG8gcmVwcmVzZW50IGl0IGFzIGEgc2V0IG9mIGxpbmVhciBzZWdtZW50cyBhbmQgaWYg c28sIGhvdyBhcmUgdGhlIHNlZ21lbnRzIGNvbm5lY3RlZCBpbnRvIGEgZ3JhcGg/ICAgT3RoZXIg aWRlYXM/DQoNCiAgIFJvbg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSG9uZ3l1IExpIChKdWxpbykNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEz IDY6NTcgQU0NClRvOiBSb24gUGFya2VyOyBLZXZpbiBKIE1hDQpDYzogVGhvbWFzIE5hcnRlbjsg bnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFN1bWFuZHJhIE1hamVlDQpT dWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQpCcmFuY2hp bmcvZm9ya2luZyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgdG9waWMgb2YgU0ZDLiBBYm91dCB0aGUg cmUtY2xhc3NpZmljYXRpb24gcG9pbnQsIHByb2JhYmx5IHdlIHNoYWxsIG5vdCBsaW1pdCBpdCB0 byBEUEkuIEl0IGlzIGFsc28gcG9zc2libGUgdGhhdCBwYWNrZXRzIGdvIHRvIGRpZmZlcmVudCBi cmFuY2hlcyBhZnRlciBiZWVuIHByb2Nlc3NlZCBieSBhIGNlcnRhaW4gc2VydmljZSBmdW5jdGlv biwgZGVjaXNpb24gb2Ygd2hpY2ggYnJhbmNoZXMgdG8gZ28gaXMgbWFkZSBiYXNlZCBvbiB0aGUg cmVzdWx0IG9mIHNlcnZpY2UgZnVuY3Rpb24ncyBwcm9jZXNzLCBpLmUuIG5vdCBqdXN0IHJlLWNs YXNzaWZpY2F0aW9uIGJ5IERQSS4NCg0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIs IDIwMTMgNzo0NSBQTQ0KVG86IEtldmluIEogTWENCkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0 Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgU3VtYW5kcmEgTWFqZWUNClN1YmplY3Q6 IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoNCkhpLCBLZXZpbg0KDQpZ b3UgYXNrIGEgZ3JlYXQgcXVlc3Rpb24gYWJvdXQgYnJhbmNoaW5nIHRoZSBncmFwaC4gIFRoZSBk ZXRhaWxzIGFyb3VuZCBob3cgdG8gY29udmV5IHRoZSBzZWxlY3Rpb24gb2YgdGhlIHN1YnRyZWUv c3ViZ3JhcGggYXJlIHN0aWxsIHRvIGJlIGRlZmluZWQuICAgSXMgaXQgb25lIGNoYWluIGlkIGZv ciB0aGUgd2hvbGUgZ3JhcGg/ICAgRG9lcyBlYWNoIGJyYW5jaCBoYXZlIGl0cyBvd24gY2hhaW4g aWQ/ICAgU29tZSBjb21iaW5hdGlvbj8NCg0KICAgUm9uDQoNCk9uIE5vdiAxMiwgMjAxMywgYXQg MTo1MiBBTSwgIktldmluIEogTWEiIDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPiB3cm90ZToN Cg0KPj4gWWVzLCByZWNsYXNzaWZpY2F0aW9uIGNhbiBjaGFuZ2UgdGhlIHNlcnZpY2UgcGF0aCBh bmQgDQo+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2RlIGFsb25nIGEg c2VydmljZSBwYXRoLg0KPiANCj4gSnVzdCB0byBleHBhbmQgb24gdGhhdCwgZ29pbmcgYmFjayB0 byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gYWJvdXQgDQo+IHNlcnZpY2UgaGVhZGVyIGVuY2Fwc3Vs YXRpb24sIGlzIGl0IGludGVuZGVkIHRoYXQgYSBjaGFpbiB0aGF0IGlzIA0KPiByZS1jbGFzc2lm aWVkIHdpbGwgZ2V0IGEgbmV3IGNoYWluIElEIHdoaWNoIGZ1bGx5IGRlc2NyaWJlcyBhIGNoYWlu IA0KPiB0aGF0IGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFsIGNoYWluIElELCBwcmlvciB0 byBEUEktYmFzZWQgDQo+IHJlLWNsYXNzaWZpY2F0aW9uPyAgKGFzc3VtaW5nIHRoZSBnb2FsIGlz ICJhIHNpbmdsZSBjaGFpbiBJRCB0aGF0IGlzIA0KPiBjb21tb25seSB1bmRlcnN0b29kIGFsb25n IHRoZSBlbnRpcmUgc2VydmljZSBjaGFpbiINCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL25zYy9jdXJyZW50L21zZzAwNjM4Lmh0bWwpDQo+IA0KPiBBbmQgdGhlIGFwcGxp Y2FibGUgc3Vic2V0IG9mIHRoZSBwZXJtdXRhdGl2ZSBsaXN0IG9mIHNlcnZpY2UgcGF0aHMgDQo+ IHdvdWxkIGJlIGNvbmZpZ3VyZWQgYXQgZWFjaCBhcHByb3ByaWF0ZSBzZXJ2aWNlIG5vZGU/DQo+ IGUuZy4sIElEIDE6IE5BVCArIGZpcmV3YWxsICsgRFBJDQo+ICAgICAgSUQgMjogTkFUICsgZmly ZXdhbGwgKyBEUEkgKyBBVg0KPiAgICAgIElEIDM6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYg KyBOQVQNCj4gICAgICBJRCA0OiBOQVQgKyBmaXJld2FsbCArIERQSSArIE5BVA0KPiAgICAgIElE IDU6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBMQg0KPiAgICAgIElEIDY6IE5BVCArIGZp cmV3YWxsICsgRFBJICsgTEINCj4gICAgICBJRCA3OiBOQVQgKyBmaXJld2FsbCArIERQSSArIExC ICsgQ0FDSEUNCj4gICAgICBJRCA4OiBOQVQgKyBmaXJld2FsbCArIERQSSArIENBQ0hFDQo+ICAg ICAgSUQgOTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQg0KPiAgICAgIElE IDEwOiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIExCICsgQ0FDSEUNCj4gICAg ICBJRCAxMTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBDQUNIRSBXb3VsZCBl dmVyeSBmbG93IA0KPiB0aGVuIGJlIGluaXRpYWxseSBjbGFzc2lmaWVkIGFzIElEIDEsIGJ1dCBl dmVudHVhbGx5IGdldCByZS1jbGFzc2lmaWVkIA0KPiB0byBJRCAyLTExLCBhZnRlciB0aGUgRFBJ IHBoYXNlPw0KPiANCj4gdGhhbnguDQo+IA0KPiAtLSAgS2V2aW4gSi4gTWENCj4gDQo+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIp IFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAx MiwgMjAxMyAxOjAxIEFNDQo+PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBhcmtlcjsgU3VtYW5kcmEg TWFqZWU7IFRob21hcyBOYXJ0ZW47IA0KPj4gbnNjQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gDQo+PiANCj4+IA0KPj4+IE9u IDExLzExLzEzIDk6NDYgUE0sICJLZXZpbiBKIE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNv bT4gd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgU3VyZW5kcmEsDQo+Pj4gDQo+Pj4gQ2xhc3NpZmljYXRp b24gbWF5IGJlIG91dCBvZiBzY29wZSwgYnV0IHRoZSBsZXZlbCBvZiBzZXJ2aWNlIHRoYXQgaXMg DQo+Pj4gYXBwbGljYWJsZSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmlj YXRpb24gdGhhdCBjYW4gYmUgDQo+Pj4gcGVyZm9ybWVkLiAgQW4gYXNzdW1wdGlvbiBvZiBwYWNr ZXQgbGV2ZWwgZW5jYXBzdWxhdGlvbiBoYXMNCj4+IGltcGxpY2F0aW9ucw0KPj4+IG9uIHRoZSBs ZXZlbCBvZiBjbGFzc2lmaWNhdGlvbiBiZWluZyBwZXJmb3JtZWQ/ICBJZiB0aGUgc3RhdGVkIGdv YWxzDQo+PiBhcmUNCj4+PiBmb3IgZmlyZXdhbGwgYW5kIGxvYWQgYmFsYW5jZXIgZnVuY3Rpb25h bGl0eSwgdGhlbiB0aGUgYXBwbGljYXRpb24NCj4+IGxldmVsDQo+Pj4gbmF0dXJlIG9mIHRob3Nl IGZ1bmN0aW9ucyBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/ICBJZiwgb24gDQo+Pj4g dGhlIG90aGVyIGhhbmQsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHNjb3BlIGlzIGxpbWl0ZWQgZHVl IHRvIA0KPj4+IGxpbWl0YXRpb25zIGluIGNsYXNzaWZpY2F0aW9uLCB0aGF0IHdvdWxkIGJlIGFu ZCBpbXBvcnRhbnQgcGllY2Ugb2YgaW5mb3JtYXRpb24/DQo+Pj4gDQo+Pj4gV3J0IHNlY3Rpb24g NC40IG9mIGRyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcyB0aGUgZm9yayANCj4+ PiBwb2ludHMgb2YgdGhlIHNlcnZpY2UgcGF0aHMgc2VlbSBsaWtlIHJlLWNsYXNzaWZpY2F0aW9u IHBvaW50cz8gIElzIA0KPj4+IHRoYXQgdGhlIGludGVycHJldGF0aW9uIGZyb20gdGhlIGFyY2hp dGVjdHVyZSBwZXJzcGVjdGl2ZT8gIE9yIGlzIA0KPj4+IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNo YWluIGNsYXNzaWZpY2F0aW9uIGV4Y2x1c2l2ZSBvZiBEUEkgZnVuY3Rpb25hbGl0eT8NCj4+IDxT Sz4gSSBoYXZlIG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwg YXMgDQo+PiBkZXNjcmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9mIHNl cnZpY2VzIGZvcm0gYSBncmFwaCwgDQo+PiBzZWdtZW50cyBvZiB3aGljaCBhcmUgc2VydmljZSBw YXRocy4gWWVzLCByZWNsYXNzaWZpY2F0aW9uIGNhbiBjaGFuZ2UgDQo+PiB0aGUgc2VydmljZSBw YXRoIGFuZCByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2RlIGFsb25nIGEg c2VydmljZSBwYXRoLg0KPj4gDQo+PiBTdXJlbmRyYS4NCj4+PiANCj4+PiB0aGFueC4NCj4+PiAN Cj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+PiANCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4gRnJvbTogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBj aXNjby5jb21dDQo+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEyOjA4IEFN DQo+Pj4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFz IE5hcnRlbjsgDQo+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3Vy cmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+PiANCj4+Pj4gS2V2aW4sDQo+Pj4+IA0KPj4+ PiBDbGFzc2lmaWNhdGlvbiBtZWNoYW5pc20gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLiBJ dCBjYW4gYmUgDQo+Pj4+IGJhc2VkDQo+PiBvbg0KPj4+PiB0aGUgcGFja2V0IG9yIGluZm9ybWF0 aW9uIG5vdCBpbiB0aGUgcGFja2V0KGVudmlyb25tZW50YWwgDQo+Pj4+IGF0dHJpYnV0ZXMNCj4+ IGZvcg0KPj4+PiBpbnN0YW5jZSkgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlzIGlt cG9ydGFudCBpcyB0aGF0IHN1Y2ggDQo+Pj4+IGNsYXNzaWZpY2F0aW9uIGFpZHMgaW4gdHJhZmZp YyBzZWxlY3Rpb24gYW5kIHNlcnZpY2UgcGF0aCANCj4+Pj4gaWRlbnRpZmljYXRpb24uDQo+Pj4+ IEl0IGlzIG5vIGRpZmZlcmVudCBmcm9tIGEgcG9saWN5IGluIHRoaXMgcmVnYXJkIGV4Y2VwdCB0 aGF0IHRoZSANCj4+Pj4gcG9saWN5IG5vdyBzcGVjaWZpZXMgdGhlIHNlcnZpY2UgcGF0aC4NCj4+ Pj4gRnVydGhlciwgY2xhc3NpZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gdGhlIG5ldHdvcmsg ZWxlbWVudHMgYnV0IA0KPj4+PiB0aGUgc2VydmljZSBmdW5jdGlvbnMgYXMgd2VsbC4gU29tZSBv ZiB0aGlzIGlzIGRlc2NyaWJlZCBpbiB0aGUNCj4+IGFyY2hpdGVjdHVyZQ0KPj4+PiBkcmFmdHMg YXMgd2VsbCAtDQo+Pj4+ICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1x dWlubi1zZmMtYXJjaC8iLg0KPj4+PiANCj4+Pj4gU3VyZW5kcmEuDQo+Pj4+IA0KPj4+Pj4gT24g MTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiIDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29t PiB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gSGkgUm9uLA0KPj4+Pj4gDQo+Pj4+PiBJIHdhcyB1bmFi bGUgdG8gbWFrZSB0aGUgU0ZDIEJvRiBkdWUgdG8gYSBjb25mbGljdCB3aXRoIENETkksIGJ1dCAN Cj4+Pj4+IEkgaGFkIGEgc2ltaWxhciBxdWVzdGlvbiB3cnQgYnVsbGV0IDExIGluIHNlY3Rpb24g MiBvZiB0aGUgcHJvYmxlbQ0KPj4+Pj4gc3RhdGVtZW50Og0KPj4+Pj4gDQo+Pj4+PiAgIDExLiAg UGVyLVNlcnZpY2UgKHJlKUNsYXNzaWZpY2F0aW9uOiBDbGFzc2lmaWNhdGlvbiBvY2N1cnMgYXQg ZWFjaA0KPj4+Pj4gICAgICAgIHNlcnZpY2UsIGluZGVwZW5kZW50IGZyb20gcHJldmlvdXNseSBh cHBsaWVkIHNlcnZpY2UNCj4+Pj4gZnVuY3Rpb25zLg0KPj4+Pj4gICAgICAgIFRoZXNlIHVucmVs YXRlZCBjbGFzc2lmaWNhdGlvbiBldmVudHMgY29uc3VtZSByZXNvdXJjZXMgcGVyDQo+Pj4+PiAg ICAgICAgc2VydmljZS4gIE1vcmUgaW1wb3J0YW50bHksIHRoZSBjbGFzc2lmaWNhdGlvbiBmdW5j dGlvbmFsaXR5DQo+Pj4+PiAgICAgICAgb2Z0ZW4gZGlmZmVycyBwZXIgc2VydmljZSBmdW5jdGlv biBhbmQgc2VydmljZSBmdW5jdGlvbg0KPj4gY2Fubm90DQo+Pj4+PiAgICAgICAgbGV2ZXJhZ2Ug dGhlIHJlc3VsdHMgZnJvbSBvdGhlciBkZXBsb3llZCBuZXR3b3JrIG9yIHNlcnZpY2UuDQo+Pj4+ PiANCj4+Pj4+IGFzIGl0IHJlbGF0ZXMgdG8gc2VjdGlvbiA1LjIgb2YgdGhlIGZyYW1ld29yayBk b2N1bWVudDoNCj4+Pj4+IA0KPj4+Pj4gICBUaGUgU0ZDIENsYXNzaWZpZXIgY2xhc3NpZmllcyBw YWNrZXRzIGJhc2VkIG9uIChzb21lIG9mKSB0aGUNCj4+Pj4gY29udGVudHMNCj4+Pj4+ICAgb2Yg dGhlIHBhY2tldCBoZWFkZXIuICBDb25jcmV0ZWx5LCBpdCBjbGFzc2lmaWVzIHBhY2tldHMgYmFz ZWQgDQo+Pj4+PiBvbg0KPj4+PiB0aGUNCj4+Pj4+ICAgcG9zc2libGUgY29tYmluYXRpb24gb2Yg b25lIG9yIG1vcmUgaGVhZGVyIGZpZWxkcywgc3VjaCBhcyBzb3VyY2UNCj4+Pj4+ICAgYWRkcmVz cywgZGVzdGluYXRpb24gYWRkcmVzcywgRFMgZmllbGQsIHByb3RvY29sIElELCBzb3VyY2UgcG9y dA0KPj4+PiBhbmQNCj4+Pj4+ICAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBhbmQgYW55IG90 aGVyIGluZm9ybWF0aW9uLg0KPj4+Pj4gDQo+Pj4+PiBBIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVy IGFzIGRlc2NyaWJlZCBpbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50DQo+Pj4+IHdvdWxkDQo+Pj4+ PiBzZWVtIHRvIGJlIGxpbWl0ZWQgaW4gd2hhdCBpdCBjYW4gY2xhc3NpZnk/ICBUaGUgc2Vydmlj ZSBmdW5jdGlvbiANCj4+Pj4+IGlkZW50aWZpZXIgbG9va3VwIGRvZXMgbm90IHNlZW0gdG8gYmUg YSBzaWduaWZpY2FudCBvcHRpbWl6YXRpb24NCj4+IG92ZXINCj4+Pj4+IGEgcGFja2V0LWJhc2Vk IDUtdHVwbGUgbG9va3VwPyAgVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBtaXNzaW5nDQo+PiBkZXRh aWwNCj4+Pj4+IHdydCBob3cgY2xhc3NpZmljYXRpb24gaW5mb3JtYXRpb24gaXMgZGV0ZXJtaW5l ZCBhbmQgcmV1c2VkPw0KPj4+Pj4gDQo+Pj4+PiBXaGVuIHRoaW5raW5nIGFib3V0IGhpZ2hlciBs ZXZlbCBzZXJ2aWNlcywgZS5nLiwgSFRUUCBhbmQgVExTDQo+Pj4+IGVuY3J5cHRlZA0KPj4+Pj4g Zmxvd3MsIGEgcGFja2V0LWJhc2VkIGNsYXNzaWZpZXIgc2VlbXMgaW5hZGVxdWF0ZT8gIEkgd2Fz IGFsc28NCj4+Pj4gd29uZGVyaW5nDQo+Pj4+PiBob3cgaW5kZXBlbmRlbnQgSExTIHNlZ21lbnQg cmVxdWVzdHMgbWlnaHQgYmUgY2xhc3NpZmllZCBhbmQNCj4+Pj4gYXNzb2NpYXRlZD8NCj4+Pj4+ IFdlcmUgdGhlc2UgdHlwZXMgb2YgdXNlIGNhc2VzIGRpc2N1c3NlZCBpbiB0aGUgQm9GPw0KPj4+ Pj4gDQo+Pj4+PiB0aGFueC4NCj4+Pj4+IA0KPj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+PiAN Cj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IG5zYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+IEJl aGFsZg0KPj4gT2YNCj4+Pj4+PiBSb24NCj4+Pj4+PiBQYXJrZXINCj4+Pj4+PiBTZW50OiBNb25k YXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjE2IFBNDQo+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVl OyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10g Q3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+IA0KPj4+Pj4+IFN1bWFuZHJhLA0K Pj4+Pj4+IA0KPj4+Pj4+IEFzIHdhcyBkaXNjdXNzZWQgaW4gVmFuY291dmVyLCB0aGVyZSBhcmUg YWxyZWFkeSBtYW55IGV4aXN0aW5nIA0KPj4+Pj4+IHdheXMNCj4+Pj4gdG8NCj4+Pj4+PiBhY2Nv bXBsaXNoIHNlcnZpY2UgY2hhaW5pbmcuICAgICBCdXQgbm9uZSBvZiB0aGVtIHByb3ZpZGUgYQ0K Pj4+PiBzdWZmaWNpZW50DQo+Pj4+Pj4gY29tYmluYXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSwg ZmxleGliaWxpdHksIGFuZCByZXNpbGllbmN5LiAgIEENCj4+Pj4gc2luZ2xlDQo+Pj4+Pj4gc2Vy dmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdpbGwgZ28gYSBsb25nIHdheSB0byBlbnN1cmluZyB0 aGVzZQ0KPj4+PiBnb2Fscy4NCj4+Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBt b3N0IGVmZmljaWVudCBhcHByb2FjaCBmb3IgZXZlcnkNCj4+Pj4gc2luZ2xlDQo+Pj4+Pj4gbmV0 d29yayB0b3BvbG9neSBhbmQgZXZlcnkgc2luZ2xlIHVzZSBjYXNlLCBidXQgaXRzIHViaXF1aXRv dXMNCj4+IG5hdHVyZQ0KPj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4NCj4+Pj4+ PiANCj4+Pj4+PiAgIFJvbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVl QEY1LmNvbV0NCj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjEwIFBN DQo+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4+ Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+ Pj4gDQo+Pj4+Pj4gUm9uLA0KPj4+Pj4+IA0KPj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFu IGV4YW1wbGUgb2Ygb25lIHR5cGUgb2YgZGVyaXZhdGlvbi4gDQo+Pj4+Pj4gSG93ZXZlcg0KPj4+ PiB0aGlzDQo+Pj4+Pj4gY291bGQgYmUgYXVnbWVudGVkIHdpdGggY2xhc3NpZmljYXRpb24gcmVz dWx0LCBhZ2FpbiBvbmUgbW9yZQ0KPj4+PiBleGFtcGxlLg0KPj4+Pj4+IA0KPj4+Pj4+Pj4gQWxs IGZsb3dzIGZyb20gdGhlIHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSBmb2xsb3cg dGhlDQo+Pj4+IHNhbWUNCj4+Pj4+PiBjaGFpbi4NCj4+Pj4+PiBDb3JyZWN0LiBJdCBpcyBhbHNv IG5vdCBuZWNlc3NhcnkgdGhhdCBhbGwgdHJhbnNhY3Rpb24gb2YgdGhlIA0KPj4+Pj4+IHNhbWUN Cj4+Pj4gZmxvdw0KPj4+Pj4+IGZvbGxvdyB0aGUgc2FtZSBjaGFpbiBlaXRoZXIuIFNvIHdoeSBz dG9wIGF0IGZsb3cgaXRzZWxmLg0KPj4+Pj4+IA0KPj4+Pj4+IEFnYWluIHRoZSBwb2ludCBoZXJl IGlzIHRoYXQgZG8gd2UgYWx3YXlzIG5lZWQgU0ZDIGhlYWRlciBvciBOb3QuDQo+Pj4+Pj4gDQo+ Pj4+Pj4gU3VtYW5kcmENCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIw MTMgNzowMiBQTQ0KPj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNj QGlldGYub3JnDQo+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZD IGNoYXJ0ZXINCj4+Pj4+PiANCj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+PiANCj4+Pj4+PiBUaGUg aW50ZW50aW9uIG9mIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaXMgdG8gYWxsb3cgZm9yIA0K Pj4+Pj4+IG9wZXJhdGlvbg0KPj4+PiBhdA0KPj4+Pj4+IHRoZSBmdWxseSBxdWFsaWZpZWQgZmxv dyBsZXZlbCwgb3IgZXZlbiBmaW5lciBncmFpbmVkIGF0IHRoZQ0KPj4+PiB0cmFuc2FjdGlvbg0K Pj4+Pj4+IGxldmVsICh0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlciBmb3IgdGhlIFBE UCkuICAgICBBbGwgZmxvd3MNCj4+Pj4gZnJvbQ0KPj4+Pj4+IHRoZSBzYW1lIHNvdXJjZSBJUCBk byBub3QgbmVjZXNzYXJpbHkgZm9sbG93IHRoZSBzYW1lIGNoYWluLg0KPj4gU291cmNlDQo+Pj4+ Pj4gSVAsDQo+Pj4+Pj4gdGhlcmVmb3JlLCAgZG9lcyBub3QgaWRlbnRpZnkgdGhlIGNoYWluIElE LiAgICBBbm90aGVyIGludGVudGlvbiBvZg0KPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgaXMgdG8gb3BlcmF0ZSBvdmVyIGFueSBuZXR3b3JrIHRvcG9sb2d5DQo+PiBhbmQNCj4+Pj4+ PiBub3QNCj4+Pj4+PiBiZSBsaW1pdGVkIHRvIGEgc2luZ2xlIExBTi4gICBUaHVzLCB3aGlsZSBW TEFOIG1heSBiZSBwYXJ0IG9mIHRoZQ0KPj4+Pj4+IHRyYW5zcG9ydCwgaXQgZG9lcyBub3QgYWRl cXVhdGVseSBpZGVudGlmeSB0aGUgc2VydmljZSBjaGFpbiwNCj4+IGVpdGhlci4NCj4+Pj4+PiAN Cj4+Pj4+PiAgIFJvbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1 LmNvbV0NCj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDk6NTYgUE0NCj4+ Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4g U3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+PiAN Cj4+Pj4+PiBSb24sDQo+Pj4+Pj4gDQo+Pj4+Pj4gVGhlIHNlcnZpY2UgaGVhZGVyIGlzIG1lYW50 IHRvIGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoIGNhbiAqYWxzbyogDQo+Pj4+Pj4gYmUgZGVyaXZl ZCAoZm9yIGV4YW1wbGUgdXNlIHNvdXJjZSBpcCBhbmQgdmxhbiB0byBpZGVudGlmeSANCj4+Pj4+ PiBjaGFpbklEIGFuZA0KPj4+Pj4+IHBvc2l0aW9uKSBvciBlbmNhcHN1bGF0ZWQgYXMgcGFydCBv ZiBhbm90aGVyIHR1bm5lbCBoZWFkZXIuIFNvIA0KPj4+Pj4+IHRoaXMgY291bGQgYmUgb3B0aW9u YWwgSU1ITy4NCj4+Pj4+PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tXQ0KPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgNDozNiBQTQ0KPj4+ Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+ Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ PiANCj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+PiANCj4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQs IGFuIFNGQyBwYWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0byBTRiBvciANCj4+Pj4+PiBmcm9t DQo+Pj4+IFNGDQo+Pj4+Pj4gdG8NCj4+Pj4+PiBTRiB3aWxsIGxvb2sgbGlrZToNCj4+Pj4+PiAN Cj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+IHwgICAgICAgICJ0cmFu c3BvcnQiICAgICAgICAgfA0KPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ Pj4gfCAgICAgIHNlcnZpY2UgaGVhZGVyICAgIHwNCj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPj4+Pj4+IHwgICBvcmlnaW5hbCBJUCBoZWFkZXIgIHwNCj4+Pj4+PiArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgIG9yaWdpbmFsIElQIHBheWxvYWQgIHwNCj4+Pj4+PiB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsNCj4+Pj4+PiANCj4+Pj4+PiBXaGVyZSBzZXJ2aWNlIGhlYWRlciBjb250YWlu cywgYXQgYSBtaW5pbXVtLCBlbm91Z2ggaW5mb3JtYXRpb24gDQo+Pj4+Pj4gdG8NCj4+Pj4gYWxs b3cNCj4+Pj4+PiB0aGUgcGFja2V0IHRvIGJlIHByb3BhZ2F0ZWQgYWxvbmcgdGhlIGZ1bGwgbGVu Z3RoIG9mIHRoZSBjaGFpbiwgDQo+Pj4+Pj4gYW5kIG9wdGlvbmFsbHksIG90aGVyIG1ldGFkYXRh IHRoYXQgZW5oYW5jZXMgdGhlIG9wZXJhdGlvbiBvZiBvbmUgDQo+Pj4+Pj4gb3INCj4+IG1vcmUN Cj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+PiANCj4+Pj4+PiBBbmQgd2hlcmUgInRy YW5zcG9ydCIgY291bGQgY29uY2VpdmFibHkgYmUgYW55IG9mLCBidXQgbm90IA0KPj4+Pj4+IGxp bWl0ZWQNCj4+Pj4gdG86DQo+Pj4+Pj4gDQo+Pj4+Pj4gKiBFdGhlcm5ldA0KPj4+Pj4+ICogRXRo ZXJuZXQgKyBMTEMyDQo+Pj4+Pj4gKiBFdGhlcm5ldCArIE1QTFMNCj4+Pj4+PiAqIEV0aGVybmV0 ICsgSVAgKyBHUkUNCj4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgK1VEUA0KPj4+Pj4+IA0KPj4+Pj4+ IA0KPj4+Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRpYWdyYW0gYWJvdmUgaXMgbm90IG1l YW50IHRvIGltcGx5IA0KPj4+Pj4+IGltbXV0YWJpbGl0eSwgYnV0IHJhdGhlciB0byBzcGVjaWZ5 IHRoZSBwYWNrZXQgdGhhdCBpcyBwcm9wYWdhdGVkIA0KPj4+Pj4+IGZyb20gcHJlY2VkaW5nIGVu dGl0eSB0byBzdWNjZWVkaW5nIGVudGl0eSwgcHJpb3IgdG8gDQo+Pj4+Pj4gZW5jYXBzdWxhdGlv bi4NCj4+Pj4+PiANCj4+Pj4+PiAgIFJvbg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+Pj4+Pj4gQmVoYWxmDQo+PiBPZg0K Pj4+Pj4+IFN1bWFuZHJhIE1hamVlDQo+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwg MjAxMyA2OjQ2IFBNDQo+Pj4+Pj4gVG86IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4+ Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+ Pj4gDQo+Pj4+Pj4gR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIEVuY2Fwc3VsYXRp b246IEEgZG9jdW1lbnQgd2lsbA0KPj4+Pj4+ICAgIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2Vydmlj ZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24NCj4+IGZvcm1hdA0KPj4+Pj4+IGZvcg0K Pj4+Pj4+ICAgIGNvbnZleWluZyB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBhbmQgdGhlIHNl cnZpY2UgZnVuY3Rpb24NCj4+Pj4gcGF0aCwNCj4+Pj4+PiAgICBhbmQgZm9yIGNvbW11bmljYXRp bmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQNCj4+Pj4+PiAgICBpbXBs ZW1lbnQgc2VydmljZSBmdW5jdGlvbnMuIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlDQo+Pj4+IGVu Y2Fwc3VsYXRpb24NCj4+Pj4+PiAgICBiZSBhZ25vc3RpYyB0byB0aGUgbGF5ZXIgYXQgd2hpY2gg aXQgaXMgYXBwbGllZCBhbmQgdGhlIA0KPj4+Pj4+IHNlcnZpY2UNCj4+Pj4gdGhhdA0KPj4+Pj4+ IGlzDQo+Pj4+Pj4gICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1lIGVuY2Fw c3VsYXRpb24gbWF5IGJlIHVzZWQNCj4+IG9uDQo+Pj4+Pj4gICAgYSBzZXJ2aWNlIGZ1bmN0aW9u IHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgb3IgYXQgDQo+Pj4+Pj4gYW55IG90 aGVyDQo+Pj4+Pj4gICAgbGF5ZXIsIGFuZCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBw bHkgZm9yIHRoZQ0KPj4gY29uc3RydWN0aW9uDQo+Pj4+IG9mDQo+Pj4+Pj4gICAgc2VydmljZSBm dW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCj4+Pj4+PiAN Cj4+Pj4+PiBbU01dIFdoYXQgZG9lcyBpdCBtZWFuIGJ5IGEgc2luZ2xlIHNlcnZpY2UtbGV2ZWwg ZW5jYXBzdWxhdGlvbiwgYQ0KPj4+PiBuZXcNCj4+Pj4+PiBlbmNhcHN1bGF0aW9uIGZvcm1hdA0K Pj4+Pj4+ICAgICAgICAgICAgb3IgYW4gYWJpbGl0eSB0byBzZWxlY3Qgb25lIGVuY2Fwc3VsYXRp b24gZm9ybWF0IHRoYXQNCj4+Pj4gZml0cw0KPj4+Pj4+IHRoZQ0KPj4+Pj4+IG5lZWQgZm9yIGEg Z2l2ZW4gc2VydmljZSBjaGFpbj8NCj4+Pj4+PiAgICAgICAgICAgVGhlIGFiaWxpdHkgdG8gc2Vs ZWN0IGEgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbiAgd291bGQgDQo+Pj4+Pj4gYmUNCj4+IGENCj4+ Pj4+PiBtYW5hZ2VtZW50IHBsYW5lIGRlY2lzaW9uLg0KPj4+Pj4+ICAgICAgICAgIFRoZXJlIGFy ZSBxdWl0ZSBhIGZldyBleGlzdGluZyBlbmNhcHN1bGF0aW9uIG1ldGhvZHMgDQo+Pj4+Pj4gdGhh dA0KPj4+PiBjYW4NCj4+Pj4+PiBwb3NzaWJseSBiZSByZXVzZWQgdG8gcHJvdmlkZQ0KPj4+Pj4+ ICAgICAgICAgIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMuIEkg aGF2ZSBzZWVuDQo+Pj4+Pj4gbWVudGlvbg0KPj4+Pj4+IG9mIEdSRSwgZm9yIEhUVFAgYmFzZWQN Cj4+Pj4+PiAgICAgICAgICBhcHBsaWNhdGlvbnMgY29udGV4dHMgYXJlIHRyYW5zZmVycmVkIHZp YSBoZWFkZXJzLg0KPj4+Pj4+IA0KPj4+Pj4+IA0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91 bmNlc0BpZXRmLm9yZ10gT24gDQo+Pj4+Pj4gQmVoYWxmDQo+PiBPZg0KPj4+Pj4+IFRob21hcyBO YXJ0ZW4NCj4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA2LCAyMDEzIDExOjA3IEFN DQo+Pj4+Pj4gVG86IG5zY0BpZXRmLm9yZw0KPj4+Pj4+IFN1YmplY3Q6IFtuc2NdIEN1cnJlbnQg UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+PiANCj4+Pj4+PiBIaS4NCj4+Pj4+PiANCj4+Pj4+ PiBDdXJyZW50IGNoYXJ0ZXIgY2FuIGJlIGZvdW5kIGF0DQo+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci0NCj4+Pj4+PiBpZXRmLXNmYy8uDQo+Pj4+Pj4gDQo+ Pj4+Pj4gSXQgY29udGFpbnMgdGhlIHJldmlzZWQgbWFuYWdlbWVudCB0ZXh0IGFzIHdlbGwgYXMg dXBkYXRlZA0KPj4+PiBtaWxlc3RvbmVzLg0KPj4+Pj4+IA0KPj4+Pj4+IEFsbCBrbm93biBpc3N1 ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gSWYgdGhlcmUgYXJlIGFueSByZW1haW5pbmcNCj4+Pj4g aXNzdWVzLA0KPj4+Pj4+IHBsZWFzZSBzcGVhayB1cCENCj4+Pj4+PiANCj4+Pj4+PiBDaGFydGVy IGNoYXJ0ZXItaWV0Zi1zZmMtMDAtMDQNCj4+Pj4+PiANCj4+Pj4+PiBOZXR3b3Jrcywgc2VydmVy cywgc3RvcmFnZSB0ZWNobm9sb2dpZXMsIGFuZCBhcHBsaWNhdGlvbnMsIGhhdmUgDQo+Pj4+Pj4g YWxsIHVuZGVyZ29uZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gcmVjZW50IHllYXJzIHdpdGggdGhl IA0KPj4+Pj4+IGludHJvZHVjdGlvbg0KPj4gb2YNCj4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0 d29yayBvdmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24uIFNlcnZpY2UNCj4+IGRlbGl2ZXJ5DQo+ Pj4+IGlzDQo+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlv bmFsIGNoYWxsZW5nZSB0aGF0DQo+PiBpbnZvbHZlcw0KPj4+Pj4+IHNpZ25pZmljYW50IG1vZGlm aWNhdGlvbiB0byB0aGUgbmV0d29yayBjb25maWd1cmF0aW9uLg0KPj4+Pj4+IFNlcnZpY2VzIGFy ZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQgY29tYmluYXRpb24gb2YgDQo+ Pj4+Pj4gYSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgZGVwbG95ZWQgYXQg ZGlmZmVyZW50IA0KPj4+Pj4+IHBvaW50cyB3aXRoaW4NCj4+IHRoZQ0KPj4+Pj4+IG5ldHdvcmsu IFRvZGF5LCBhIGNvbW1vbiBkZXBsb3ltZW50IG1vZGVsIGhhcyBzZXJ2aWNlIGZ1bmN0aW9ucyAN Cj4+Pj4+PiBwaHlzaWNhbGx5IGluc2VydGVkIG9uIHRoZSBkYXRhIGZvcndhcmRpbmcgcGF0aCBi ZXR3ZWVuIA0KPj4+Pj4+IGNvbW11bmljYXRpbmcgcGVlcnMuDQo+Pj4+IEdvaW5nDQo+Pj4+Pj4g Zm9yd2FyZCwgaG93ZXZlciwgdGhlcmUgaXMgYSBkZXNpcmUgdG8gbW92ZSB0byBhIGRpZmZlcmVu dCBtb2RlbCwNCj4+Pj4gd2hlcmUNCj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgbm90IHJl cXVpcmVkIHRvIHJlc2lkZSBvbiB0aGUgZGVmYXVsdCBkYXRhDQo+PiBwYXRoDQo+Pj4+Pj4gYW5k DQo+Pj4+Pj4gdHJhZmZpYyBpcyBpbnN0ZWFkIHN0ZWVyZWQgdGhyb3VnaCBzZXJ2aWNlcywgd2hl cmV2ZXIgdGhleSBhcmUNCj4+Pj4gZGVwbG95ZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gRm9yIGEgZ2l2 ZW4gc2VydmljZSwgdGhlIGFic3RyYWN0ZWQgdmlldyBvZiB0aGUgcmVxdWlyZWQgc2VydmljZSAN Cj4+Pj4+PiBmdW5jdGlvbnMgYW5kIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IGFyZSB0byBiZSBh cHBsaWVkIGlzIGNhbGxlZCANCj4+Pj4+PiBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQyku IFNpbmNlIGEgZ2l2ZW4gc2VydmljZSBmdW5jdGlvbiANCj4+Pj4+PiBtYXkgYmUgYXZhaWxhYmxl IG9uIG1vcmUgdGhhbiBvbmUgbm9kZSB3aXRoaW4gYSBuZXR3b3JrLCBhIA0KPj4+Pj4+IFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW4gaXMgaW5zdGFudGlhdGVkDQo+Pj4+IHZpYQ0KPj4+Pj4+IHRoZSBz ZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgYW5kIHRoZSAN Cj4+Pj4+PiBuZXR3b3JrIG5vZGVzIG9uIHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVkLCB0aGVyZWJ5 IGZvcm1pbmcgYSANCj4+Pj4+PiBzZXJ2aWNlIHRvcG9sb2d5Og0KPj4+Pj4+IHRoaXMgaXMgY2Fs bGVkIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoLiBUaGUgc2VydmljZSBmdW5jdGlvbnMgbWF5IA0K Pj4+Pj4+IGJlIGFwcGxpZWQgYXQgYSBzcGVjaWZpYyBsYXllciB3aXRoaW4gdGhlIG5ldHdvcmsg cHJvdG9jb2wgc3RhY2sNCj4+Pj4gKG5ldHdvcmsNCj4+Pj4+PiBsYXllciwgYXBwbGljYXRpb24g bGF5ZXIsIGV0Yy4pLg0KPj4+Pj4+IA0KPj4+Pj4+IFRoZSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nIChTRkMpIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXZlbG9wIA0KPj4+Pj4+IG5ldyBhcHByb2Fj aGVzIHRvIHNlcnZpY2UgZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuIEl0IHdpbGwgDQo+Pj4+Pj4g cHJvZHVjZSBhIGZyYW1ld29yayBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyB0aGF0IGlu Y2x1ZGVzIA0KPj4+Pj4+IHRoZSBuZWNlc3NhcnkgcHJvdG9jb2xzDQo+Pj4+IG9yDQo+Pj4+Pj4g cHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBjb252ZXkgdGhlIHNlcnZpY2UgcGF0aCBhbmQgc2Vydmlj ZSBwYXRoIA0KPj4+Pj4+IGluZm9ybWF0aW9uIHRvIG5vZGVzIHRoYXQgaW1wbGVtZW50IHNlcnZp Y2UgZnVuY3Rpb25zLCBhcyB3ZWxsIGFzIA0KPj4+Pj4+IG1lY2hhbmlzbXMgZm9yIHN0ZWVyaW5n IHRyYWZmaWMgdGhyb3VnaCBzZXJ2aWNlIGZ1bmN0aW9ucy4gVGhlDQo+Pj4+IHdvcmtpbmcNCj4+ Pj4+PiBncm91cCB3aWxsIGFsc28gZXhhbWluZSB3aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJl IGdhdGhlcmVkIA0KPj4+Pj4+IGZyb20NCj4+Pj4gdGhlDQo+Pj4+Pj4gbmV0d29yayBhbmQgc2Vy dmljZSBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBzZXJ2aWNlIGZ1bmN0aW9uDQo+PiBjaGFpbmlu Zw0KPj4+Pj4+IGFuZA0KPj4+Pj4+IGhvdyB0aGF0IGluZm9ybWF0aW9uIG1heSBiZSBtYWRlIGF2 YWlsYWJsZSB0byBub2RlcyB0aGF0IA0KPj4+Pj4+IGltcGxlbWVudA0KPj4+PiB0aGUNCj4+Pj4+ PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+PiANCj4+Pj4+PiBTcGVjaWZpY2FsbHksIHRoZSBT RkMgV0cgaXMgY2hhcnRlcmVkIHRvIGRlbGl2ZXIgdGhlIGZvbGxvd2luZzoNCj4+Pj4+PiANCj4+ Pj4+PiAxKSBQcm9ibGVtIFN0YXRlbWVudDogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSBz dW1tYXJ5IG9mIHRoZQ0KPj4+Pj4+ICAgIHByb2JsZW0gc3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5 IHRoZSBXRyBpbmNsdWRpbmcgZXhhbXBsZSBoaWdoLQ0KPj4+Pj4+ICAgIGxldmVsIHVzZSBjYXNl cy4gQWRkaXRpb25hbGx5LCB0aGUgV0cgd2lsbCBub3JtYWxpemUNCj4+IG5vbWVuY2xhdHVyZQ0K Pj4+Pj4+ICAgIGFuZCBkZWZpbml0aW9ucyBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4N Cj4+Pj4+PiANCj4+Pj4+PiAyKSBBcmNoaXRlY3R1cmU6IFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92 aWRlIGEgZGVzY3JpcHRpb24gb2YgdGhlDQo+Pj4+Pj4gICAgYXJjaGl0ZWN0dXJhbCBidWlsZGlu ZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMgaW5jbHVkaW5nDQo+Pj4+Pj4gICAgaW50 ZXJjb25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVzLCBtYW5hZ2VtZW50LA0KPj4+ Pj4+ICAgIGRpYWdub3N0aWNzLCBkZXNpZ24gYW5hbHlzaXMsIGFuZCBzZWN1cml0eSBtb2RlbHMs IGFzIHdlbGwgYXMNCj4+Pj4+PiAgICByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sIG1lY2hh bmlzbXMuDQo+Pj4+Pj4gDQo+Pj4+Pj4gMykgR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu aW5nIEVuY2Fwc3VsYXRpb246IEEgZG9jdW1lbnQgd2lsbA0KPj4+Pj4+ICAgIGRlc2NyaWJlIHRo ZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24NCj4+IGZvcm1h dA0KPj4+Pj4+IGZvcg0KPj4+Pj4+ICAgIGNvbnZleWluZyB0aGUgc2VydmljZSBmdW5jdGlvbiBj aGFpbiBhbmQgdGhlIHNlcnZpY2UgZnVuY3Rpb24NCj4+Pj4gcGF0aCwNCj4+Pj4+PiAgICBhbmQg Zm9yIGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQN Cj4+Pj4+PiAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMuIEl0IGlzIGludGVuZGVkIHRo YXQgdGhlDQo+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+Pj4+PiAgICBiZSBhZ25vc3RpYyB0byB0aGUg bGF5ZXIgYXQgd2hpY2ggaXQgaXMgYXBwbGllZCBhbmQgdGhlIA0KPj4+Pj4+IHNlcnZpY2UNCj4+ Pj4gdGhhdA0KPj4+Pj4+IGlzDQo+Pj4+Pj4gICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMs IHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gbWF5IGJlIHVzZWQNCj4+IG9uDQo+Pj4+Pj4gICAgYSBz ZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgb3IgYXQg DQo+Pj4+Pj4gYW55IG90aGVyDQo+Pj4+Pj4gICAgbGF5ZXIsIGFuZCB0aGUgc2FtZSBlbmNhcHN1 bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4gY29uc3RydWN0aW9uDQo+Pj4+IG9mDQo+Pj4+ Pj4gICAgc2VydmljZSBmdW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2Vy dmljZS4NCj4+Pj4+PiANCj4+Pj4+PiA0KSBDb250cm9sIFBsYW5lIE1lY2hhbmlzbXM6IEEgc2V0 IG9mIGRvY3VtZW50cyB3aWxsIGJlIGRldmVsb3BlZCB0bw0KPj4+Pj4+ICAgIGRlc2NyaWJlIHJl cXVpcmVtZW50cyBhbmQgcHJvdG9jb2xzIG5lY2Vzc2FyeSB0byBjb252ZXkNCj4+Pj4gaW5mb3Jt YXRpb24NCj4+Pj4+PiAgICB0byBzZXJ2aWNlIGZ1bmN0aW9uIGltcGxlbWVudGF0aW9uIHBvaW50 cy4gV2hlcmUgcG9zc2libGUsDQo+Pj4+IGV4aXN0aW5nDQo+Pj4+Pj4gICAgSUVURiBwcm90b2Nv bHMgd2lsbCBiZSB1c2VkIGFuZCBleHRlbmRlZC4gQWxsIHByb3RvY29sDQo+PiBleHRlbnNpb25z DQo+Pj4+Pj4gICAgd29yayBzaG91bGQgYmUgY2FycmllZCBvdXQgaW4gdGhlIHdvcmtpbmcgZ3Jv dXBzIHJlc3BvbnNpYmxlIA0KPj4+Pj4+IGZvcg0KPj4+PiB0aGUNCj4+Pj4+PiAgICBwcm90b2Nv bHMgYmVpbmcgbW9kaWZpZWQgaW4gY29vcmRpbmF0aW9uIHdpdGggdGhpcyB3b3JraW5nDQo+PiBn cm91cCwNCj4+Pj4+PiBidXQNCj4+Pj4+PiAgICBtYXkgYmUgZG9uZSBpbiB0aGlzIHdvcmtpbmcg Z3JvdXAgYWZ0ZXIgYWdyZWVtZW50IHdpdGggYWxsIHRoZQ0KPj4+Pj4+ICAgIHJlbGV2YW50IFdH IGNoYWlycyBhbmQgcmVzcG9uc2libGUgQURzLg0KPj4+Pj4+IA0KPj4+Pj4+IDUpIE1hbmFnZWFi aWxpdHk6IFdvcmsgb24gdGhlIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YNCj4+IHNl cnZpY2UNCj4+Pj4+PiAgICBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBTRkMgY29tcG9uZW50cyB3 aWxsIGNlcnRhaW5seSBiZSBuZWVkZWQsDQo+Pj4+Pj4gICAgYnV0IGZpcnN0IG5lZWRzIHRvIGJl IGJldHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gUHJvcG9zZWQg TWlsZXN0b25lcw0KPj4+Pj4+IA0KPj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNHIEluZm9y bWF0aW9uYWwgZG9jdW1lbnQocykgZGVmaW5pbmcgdGhlDQo+Pj4+IHByb2JsZW0NCj4+Pj4+PiBz dGF0ZW1lbnQgYW5kIGNvcmUgdXNlIGNhc2VzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5n DQo+Pj4+Pj4gDQo+Pj4+Pj4gTWF5IDIwMTQgQ29uc3VsdCB3aXRoIE9QUyBBcmVhIG9uIHBvc3Np YmxlIGNoYXJ0ZXIgbW9kaWZpY2F0aW9ucyANCj4+Pj4+PiBmb3IgbWFuYWdlbWVudCBhbmQgY29u ZmlndXJhdGlvbiBvZiBTRkMgY29tcG9uZW50cw0KPj4+Pj4+IA0KPj4+Pj4+IEphbiAyMDE1IFN1 Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcgdGhlDQo+Pj4+IGFy Y2hpdGVjdHVyZQ0KPj4+Pj4+IGZvciBTRkMNCj4+Pj4+PiANCj4+Pj4+PiBKYW4gMjAxNSBTdWJt aXQgdG8gSUVTRyByZXF1aXJlbWVudHMgZm9yIGEgZ2VuZXJpYyBzZXJ2aWNlIA0KPj4+Pj4+IGZ1 bmN0aW9uIGNoYWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCj4+Pj4+PiANCj4+Pj4+PiBB dWcgMjAxNSBTdWJtaXQgdG8gSUVTRyBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWlu ZyB0aGUNCj4+Pj4gZ2VuZXJpYw0KPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaGVh ZGVyIGVuY2Fwc3VsYXRpb24NCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiANCj4+ Pj4+PiANCj4+Pj4+PiBUaG9tYXMNCj4+Pj4+PiANCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBu c2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+ PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnNjDQo+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uc2MNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpuc2MgbWFpbGluZyBsaXN0DQpuc2NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo= From hongyu.li@huawei.com Wed Nov 13 02:13:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE6511E8180 for ; Wed, 13 Nov 2013 02:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5IpmaSsehxWu for ; Wed, 13 Nov 2013 02:13:39 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1C61F11E812D for ; Wed, 13 Nov 2013 02:13:26 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml203-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWY94396; Wed, 13 Nov 2013 04:13:21 -0600 (CST) 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, 13 Nov 2013 10:11:54 +0000 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; Wed, 13 Nov 2013 10:12:09 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 18:12:03 +0800 From: "Hongyu Li (Julio)" To: David Allan I , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhNOKetVd+0mYdBTNJtPCzpoi7T2A Date: Wed, 13 Nov 2013 10:12:02 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.114.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 10:13:43 -0000 TWF5IEkgc3VnZ2VzdCBzdW1tYXJ5IG9mIG15IHZpZXdzIGhlcmU6DQoNCjEuIEJyYW5jaCBpcyBh IHNvcnQgb2YgdXNlIGNhc2Ugb3Igc2NlbmFyaW8sIHdoaWxlIHJlY2xhc3NpZmljYXRpb24gaXMg YSB3YXkgdG8gc29sdmUgdGhlIHByb2JsZW0uDQoyLiBTZXJ2aWNlIEZ1bmN0aW9ucyBzaG91bGQg YmUgZGVjb3VwbGVkIHdpdGggdGhlIGNoYWluIGl0c2VsZi4NCglNZWFuaW5nLCBhIFNGIHNoYWxs IG5vdCAqZGlyZWN0bHkqIGltcGFjdCB0aGUgZm9yd2FyZGluZyBvZiBwYWNrZXRzIGluIGEgY2hh aW4uIEJyYW5jaGluZyBzaG91bGQgYmUgcGVyZm9ybWVkIGJ5IGNoYWluIGZvcndhcmRpbmcgbm9k ZXMsIHBvc3NpYmx5IHVuZGVyIGNvbnRyb2wgb2YgYSBjb250cm9sIG5vZGUuIFRoZSByZWFzb24g Zm9yIHRoaXMgaXMgaW4gTkZWIHdvcmxkLCBzZXJ2aWNlIGZ1bmN0aW9ucyBtYXkgY29tZSBmcm9t IGEgdGhpcmQgcGFydHksIHdoaWxlIGNoYWluIGlzIHByb3ZpZGVkIGJ5IHRoZSBpbmZyYXN0cnVj dHVyZSBvZiB0aGUgbmV0d29yay4gVGhlcmUgbXVzdCBiZSBhIGN1c2hpb24gYXZvaWRpbmcgYSBz ZXJ2aWNlIGZ1bmN0aW9uIG9wZXJhdGluZyBpbmZyYXN0cnVjdHVyZSBkaXJlY3RseS4NCjMuIChS ZSljbGFzc2lmaWNhdGlvbiBpcyBiYXNlZCBvbiBpbmZvIGluIGEgcGFja2V0Lg0KCVRoaXMgaXMg dmVyeSBnZW5lcmFsLiBTdWNoIGluZm8gY291bGQgYmUgTDJ+TDcgZGVyaXZlZCBmcm9tIGEgdXNl cidzIHBhY2tldCwgYXMgd2VsbCBhcyBzb21lIGluZm8gbGlrZSBtZXRhZGF0YSBpbiBhIFNGQyBo ZWFkZXIuIEFzIGNsYXNzaWZpY2F0aW9uIGlzIG91dCBvZiBzY29wZSBvZiBTRkMsIHdlIGRvbid0 IGhhdmUgdG8gcHJvdmlkZSB0b28gbXVjaCBkZXRhaWxzIG9mIGhvdyB0byBkbyBjbGFzc2lmaWNh dGlvbi4NCjQuIENoYWluIHNlZ21lbnRzIHN0aXRjaGluZyBpcyByZWxhdGl2ZWx5IGEgZWFzeSB3 YXkgZm9yIGJyYW5jaGluZy4gQ29tcGFyZWQgd2l0aCBjaGFpbnMgYW5kIHN1YmNoYWlucywgd2hp Y2ggbWF5IHJlcXVpcmUgYSBtb3JlIGNvbXBsZXggaGVhZGVyIGFuZCBmb3J3YXJkaW5nIGNhcGFi aWxpdGllcy4NCg0KTXkgdHdvIGNlbnRzLg0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQgQWxsYW4gSQ0KU2VudDogV2VkbmVzZGF5LCBOb3Zl bWJlciAxMywgMjAxMyAzOjA0IEFNDQpUbzogbnNjQGlldGYub3JnDQpTdWJqZWN0OiBbbnNjXSBG VzogcmUgY2xhc3NpZmljYXRpb24gJiBicmFuY2hpbmcsIHdhczogQ3VycmVudCBQcm9wb3NlZCBT RkMgY2hhcnRlcg0KDQpIaToNCihyZXNlbmQgd2l0aCByZWNpcGllbnQgbGlzdCBjbGVhbmVkIHVw KQ0KDQpJIGFncmVlIHdlIGFyZSBkaXNjdXNzaW5nIG11bHRpcGxlIGNvbmNlcHRzLCBjbGFzc2lm aWNhdGlvbiBhbmQgZmxvdy1zdWJzZXR0aW5nLiBQZXJoYXBzIG1vcmUgOy0pDQoNCkRlZmluaW5n IGEgZmxvdyBzdWJzZXQgY2FuIGJlIGEgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9uLCBidXQgaXQg aXMgbm90IHRoZSBleGNsdXNpdmUgbWVjaGFuaXNtLiBCcmFuY2hpbmcgaXMgYSBtZWNoYW5pc20g Ynkgd2hpY2ggZmxvdyBzdWJzZXRzIGFyZSBleHBvc2VkIGFuZCBtYXBwZWQgdG8gYSBzZXQgb2Yg c3ViY2hhaW5zIHN1Y2ggdGhhdCBpdCBjYW4gYmUgaWRlbnRpZmllZCBpbiB0aGUgZGF0YXBsYW5l Li4uDQoNClRoYXQncyB0aGUgdmlldyBmcm9tIGhlcmUNCkRhdmUNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBMYWtlIChkbGFrZSkNClNlbnQ6IFR1ZXNk YXksIE5vdmVtYmVyIDEyLCAyMDEzIDEwOjUxIEFNDQpUbzogSmltIEd1aWNoYXJkIChqZ3VpY2hh cik7IEtldmluIEogTWE7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsgTGlu ZGEgRHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKQ0KQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRm Lm9yZzsgU3VtYW5kcmEgTWFqZWUNClN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQoNClVuZGVyc3Rvb2QgLSBtYXliZSBqdXN0IGEgbGl0dGxlIGxvY2FsaXNl ZCB3YXJtaW5nIG9mIHRoZSBzZWEgdGhlbiA/ICAgQnV0IEkgc3RpbGwgdGhpbmsgd2UgbmVlZCB0 byBjb25zaWRlciB3aGVyZSBhbmQgaG93IHBvbGljeSBpcyBkZWZpbmVkL3NldCBldmVuIGZvciB0 aGUgc2luZ2xlLWRvbWFpbiBpbnN0YW5jZS4NCg0KSSBkb24ndCB0aGluayB3ZSBjYW4gYXNzdW1l IHRoYXQgYW55IEwxLTMgZGV2aWNlIHdpbGwgYmUgYWJsZSB0byBkZXRlcm1pbmUgbXVjaCB1c2Vm dWwgaW5mb3JtYXRpb24gZnJvbSB0aGUgZGF0YS1wbGFuZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQpTZW50OiAxMiBOb3ZlbWJl ciAyMDEzIDEwOjQ0DQpUbzogRGF2aWQgTGFrZSAoZGxha2UpOyBLZXZpbiBKIE1hOyBTdXJlbmRy YSBLdW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IExpbmRhIER1bmJhcjsgSG9uZ3l1IExpIChK dWxpbykNCkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQpT dWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQpBcyBkaXNj dXNzZWQgZHVyaW5nIHRoZSBCT0Ygb3VyIGluaXRpYWwgd29yayBpcyBzaW5nbGUgYWRtaW5pc3Ry YXRpdmUgZG9tYWluIGZvciBzb21lIG9mIHRoZSB2ZXJ5IHJlYXNvbnMgeW91IHBvaW50IG91dC4g V2UgbmVlZCB0byBrZWVwIGZvY3VzZWQgd2l0aG91dCB0cnlpbmcgdG8gYm9pbCB0aGUgb2NlYW4g cmlnaHQgb2ZmIHRoZSBiYXQuDQoNCk9uIDExLzEyLzEzIDE6MzYgUE0sICJEYXZpZCBMYWtlIChk bGFrZSkiIDxkbGFrZUBjaXNjby5jb20+IHdyb3RlOg0KDQo+RXhhY3RseS4gIEJ1dCBob3cgY2Fu IG5ldHdvcmstY29tcG9uZW50cyAidGVybWluYXRlIiBhbiBhcHBsaWNhdGlvbiA/Pz8/DQo+DQo+ SSB0aGluayB3ZSBuZWVkIGEgZ29vZCB1bmRlcnN0YW5kaW5nIG9mIGEgcmVjdXJzaXZlIHBvbGlj eSBtZWNoYW5pc20gDQo+KHJlY3Vyc2l2ZSBiZWNhdXNlIGEgdXNlci1sYW5kIGFwcGxpY2F0aW9u IHdpbGwgcmlkZSB3aXRoIGEgc3BlY2lmaWMgDQo+cG9saWN5IGFjcm9zcyBwb3RlbnRpYWxseSBk aWZmZXJlbnQgc2V0cyBvZiBjYXJyaWVyIHBvbGljaWVzKS4NCj4NCj5JIGhhdGUgdG8gYnJpbmcg dGhpcyB1cCBub3csIGJ1dCB3ZSBhbHNvIG5lZWQgdG8gdGhpbmsgYWJvdXQgdGhpcyANCj5tdWx0 aS1kb21haW4gaXNzdWUgLSBpZiBJIHNldCBhIHBvbGljeSBhcyBhIHVzZXIsIGNoYW5jZXMgYXJl IEkgd2lsbCBiZSANCj5jcm9zc2luZyBzZXZlcmFsIGRvbWFpbiBib3VuZGFyaWVzLiAgQXJlIHdl IGV4cGVjdGluZyB0aGUgc2VydmljZSANCj5oZWFkZXJzIHRvIGRlZmluZSB0aGUgc2VydmljZSBj aGFpbmluZyBmb3IgdGhlIGR1cmF0aW9uIG9mIHRoZSBlbnRpcmUgDQo+ZmxvdyBhY3Jvc3MgYWxs IGRvbWFpbnMsIG9yIGp1c3QgYWNyb3NzIGEgc2luZ2xlIG9uZSA/DQo+DQo+SW4gd2hpY2ggY2Fz ZSwgZG8gSSBoYXZlIHRvIHJlLXNldCBwb2xpY3kgYXMgSSB0cmF2ZXJzZSBkb21haW5zICBhbmQN Cj53aGVyZSBkb2VzIHRoYXQgcG9saWN5IGdldCBzZXQgPyAgIEl0IHdvdWxkIGJlIG11Y2ggYmV0 dGVyIHRvIHNldCBwb2xpY3kNCj5vbmNlIGJhc2VkIG9uIEw1LTcgbmVlZHMsIGFuZCBoYXZlIHRo YXQgaW5zdGFudGlhdGVkIGFjcm9zcyB0aGUgDQo+bXVsdGlwbGUgZG9tYWlucy4NCj4NCj5BZ2Fp biwgdGhpcyBhcHBlYXJzIHRvIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNGQywgYnV0IHByZXR0 eSByZWxldmFudCANCj50byBob3cgaXQgd291bGQgb3BlcmF0ZSBpbiB0aGUgcmVhbCB3b3JsZC4N Cj4NCj5EYXZpZA0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogS2V2aW4g SiBNYSBbbWFpbHRvOmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb21dDQo+U2VudDogMTIgTm92ZW1i ZXIgMjAxMyAxMDoyNw0KPlRvOiBEYXZpZCBMYWtlIChkbGFrZSk7IFN1cmVuZHJhIEt1bWFyIChz bWt1bWFyKTsgUm9uIFBhcmtlcjsgTGluZGEgDQo+RHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKQ0K PkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+U3ViamVj dDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4NCj4+IEluIHRob3Nl IGNpcmN1bXN0YW5jZXMsIG9ubHkgdGhlIGVuZCBhcHBsaWNhdGlvbnMgdGhlbXNlbHZlcyBvciBh IA0KPj4gcmVhc29uYWJseSBicm9hZC1icnVzaGVkIGNsYXNzaWZpY2F0aW9uIChyZWFsbHkgdHJh ZmZpYyBzdGVlcmluZyANCj4+IGJhc2VkIG9uIHdoYXQgd2UgY2FuIHNlZSBhdCBpbmdyZXNzKSBp cyBnb2luZyB0byBiZSB1c2VmdWwgLSBpcyBUSEFUIA0KPj4gd2hhdCB3ZSdyZSBhaW1pbmcgZm9y IGhlcmUgPw0KPg0KPkkgd291bGQgY2VydGFpbmx5IGhvcGUgbm90LCBidXQgdGhhdCBoYXMgYmVl biBteSBjb25jZXJuIGFzIHdlbGwuDQo+QXBwbGljYXRpb24gbGF5ZXIgdGVybWluYXRpb24gYW5k IHJlLWNsYXNzaWZpY2F0aW9uIHNlZW1zIGEgbXVzdD8NCj4NCj4tLSAgS2V2aW4gSi4gTWENCj4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBEYXZpZCBMYWtlIChkbGFr ZSkgW21haWx0bzpkbGFrZUBjaXNjby5jb21dDQo+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAx MiwgMjAxMyAxOjAwIFBNDQo+PiBUbzogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBSb24gUGFy a2VyOyBLZXZpbiBKIE1hOyBMaW5kYSBEdW5iYXI7IA0KPj4gSG9uZ3l1IExpIChKdWxpbykNCj4+ IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+PiBTdWJq ZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4NCj4+IFBvbGlj eSBtYXkgYmUgb3V0c2lkZSBvZiB0aGUgc2NvcGUgb2YgU0ZDLCBidXQgd2l0aG91dCBzdHJvbmcg bWFwcGluZyANCj4+IGJldHdlZW4gUG9saWN5IGFuZCB0aGUgaW5zZXJ0ZWQgU2VydmljZSBIZWFk ZXIocyksIHdlIHJ1bi10aGUtcmlzayBvZiANCj4+IGxpbWl0aW5nIHRoZSBlZmZpY2FjeSBvZiB0 aGUgcHJvdG9jb2wgSU1PLg0KPj4NCj4+IEZvciBleGFtcGxlLCBpbiBhIHdvcmxkIHdoZXJlIHRo ZSBuZXR3b3JrIGhhcyAiZ29uZSBkYXJrLCIgKGFzIHBlciANCj4+IHRoZSBJRVRGIFRlY2huaWNh bCBQbGVuYXJ5ID86LSkgKSB3aGF0IGlzIG91ciBhYmlsaXR5IHRvIGRldGVybWluZSANCj4+IHBv bGljeSBiYXNlZCBvbiBEUEkgb2YgcGFja2V0cy1pbi1mbGlnaHQgPw0KPj4NCj4+IEluIHRob3Nl IGNpcmN1bXN0YW5jZXMsIG9ubHkgdGhlIGVuZCBhcHBsaWNhdGlvbnMgdGhlbXNlbHZlcyBvciBh IA0KPj4gcmVhc29uYWJseSBicm9hZC1icnVzaGVkIGNsYXNzaWZpY2F0aW9uIChyZWFsbHkgdHJh ZmZpYyBzdGVlcmluZyANCj4+IGJhc2VkIG9uIHdoYXQgd2UgY2FuIHNlZSBhdCBpbmdyZXNzKSBp cyBnb2luZyB0byBiZSB1c2VmdWwgLSBpcyBUSEFUIA0KPj4gd2hhdCB3ZSdyZSBhaW1pbmcgZm9y IGhlcmUgPw0KPj4NCj4+IERhdmlkDQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiANCj4+IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKQ0KPj4gU2VudDog MTIgTm92ZW1iZXIgMjAxMyAwOToyNg0KPj4gVG86IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IExp bmRhIER1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NA aWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4NCj4+IFJvbiwNCj4+DQo+PiBDbGFzc2lmaWNhdGlvbiBv ZiB0cmFmZmljIGlzIHdlbGwgdW5kZXJzdG9vZCBhbmQgd2UgZG8gbm90IGhhdmUgdG8gDQo+PiBy ZWRlZmluZSBpdCAtIGl0J3MgYmVlbiBhcm91bmQgZm9yIGFsbCB0aGUgdGltZSBtaWRkbGUgYm94 ZXMgaGF2ZSANCj4+IGJlZW4gb3IgZm9yIHRoYXQgbWF0dGVyIHRoZSBMMi9MMyBkZXZpY2VzLiBB bGwgd2UgYXJlIHRhbGtpbmcgYWJvdXQgDQo+PiBpcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUg Y2xhc3NpZmljYXRpb24gdG8gYnJhbmNoaW5nIGluIFNGQy4NCj4+DQo+PiBZb3UgYXJlIHJpZ2h0 LCBpdCBpcyBhbGwgYWJvdXQgcG9saWN5IHdoaWNoIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNG Qy4NCj4+DQo+PiBTdXJlbmRyYS4NCj4+DQo+PiBPbiAxMS8xMi8xMyA3OjUzIEFNLCAiUm9uIFBh cmtlciIgPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+DQo+Pndyb3RlOg0KPj4NCj4+ ID5JIHRoaW5rIHRoZSBsYWNrIG9mIGRlZmluaXRpb24gb2YgInJlY2xhc3NpZmljYXRpb24iIG1h eSBiZSBjYXVzaW5nDQo+PnNvbWUNCj4+ID5taXN1bmRlcnN0YW5kaW5ncyBoZXJlLiAgICBBIGJy YW5jaCB3b3VsZCBvY2N1ciBmb3Igc29tZSBwb2xpY3ktZHJpdmVuDQo+PiA+cmVhc29uIGJhc2Vk IG9uIHRoZSBiZWhhdmlvciBhbmQgY29uY2x1c2lvbnMgb2YgdGhlIHNlcnZpY2UgZnVuY3Rpb24s DQo+PiA+aXRzZWxmLiAgIFRoZSBncmFwaCB3b3VsZCByZXByZXNlbnQgdGhlIGZhY3QgdGhhdCB0 aGVyZSBpcyBhIGJyYW5jaA0KPj4gPnBvaW50LCBidXQgdGhlIHNlcnZpY2UgZnVuY3Rpb24sIGl0 c2VsZiwgYmVpbmcgYXdhcmUgdGhhdCBpdCBpcyBhIA0KPj4gPmJyYW5jaGluZyBwb2ludCB3b3Vs ZCBjb250YWluIHRoZSBwb2xpY3kgYW5kIGxvZ2ljIHRvIGRlY2lkZSBvbiB3aGljaA0KPj4gPmJy YW5jaCB0byB0YWtlLiAgIFNwZWNpZnlpbmcgdGhhdCBwb2xpY3kgYW5kIGxvZ2ljIGlzIG91dCBv ZiBzY29wZSwNCj4+SU1PLg0KPj4gPg0KPj4gPiAgIFJvbg0KPj4gPg0KPj4gPg0KPj4gPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+RnJvbTogS2V2aW4gSiBNYSBbbWFpbHRvOmtldmlu Lm1hQGF6dWtpc3lzdGVtcy5jb21dDQo+PiA+U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIw MTMgMTA6NDkgQU0NCj4+ID5UbzogTGluZGEgRHVuYmFyOyBSb24gUGFya2VyOyBIb25neXUgTGkg KEp1bGlvKQ0KPj4gPkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1 bWFyIChzbWt1bWFyKTsgU3VtYW5kcmEgDQo+PiA+TWFqZWUNCj4+ID5TdWJqZWN0OiBSRTogW25z Y10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPg0KPj4gPkhpIExpbmRhLA0KPj4g Pg0KPj4gPiAgQXJlIHlvdSBzYXlpbmcgdGhhdCBhIGJyYW5jaGluZyBwb2ludCBpcyAibmV2ZXIi IGEgDQo+PiA+IHJlY2xhc3NpZmljYXRpb24gcG9pbnQsIG9yIGFyZSB5b3Ugc2F5aW5nIHRoYXQg YSBicmFuY2hpbmcgcG9pbnQgImRvZXMgbm90IGhhdmUgdG8gYmUiDQo+PiA+ICBhIHJlY2xhc3Np ZmljYXRpb24gcG9pbnQ/DQo+PiA+DQo+PiA+ICBJIHRoaW5rIHRoaXMgaXMgYW4gaW1wb3J0YW50 IGRpc3RpbmN0aW9uIHRoYXQgbmVlZHMgdG8gYmUgY2xhcmlmaWVkLg0KPj4gPiAgSWYgYnJhbmNo aW5nIGlzIG5ldmVyIHJlY2xhc3NpZmljYXRpb24sIHRoZW4gdGhlIG1lYW5pbmcgb2YgYSANCj4+ ID4gY2hhaW4gaXMgZGlmZmVyZW50IHRoYW4gSSBvcmlnaW5hbGx5IGluZmVycmVkLiAgSWYgdGhl IGNoYWluIGlzIGEgDQo+PiA+IHRyZWUgd2l0aCBvdGhlciAiYnJhbmNoaW5nIiBwb2ludHMgaW4g aXQsIHRoZW4gdGhhdCBsaW1pdHMgdGhlIA0KPj4gPiBzY29wZSBvZiB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgZ29hbHMuDQo+PiA+DQo+PiA+ICBXaGlsZSB0aGlzIGNvdWxkIGJlIGEgZGVnZW5lcmF0 ZSBjYXNlLCBhbmQgYW55IGltcGxlbWVudGF0aW9uIA0KPj4gPiBjb3VsZCBkZWZpbmUgYmFkIHNl cnZpY2UgY2hhaW5zLCBpcyBpdCB0aGUgaW50ZW50IG9mIFNGQyB0byBvbmx5IA0KPj4gPiBsb29r IGF0IHRoZSBzaW1wbGVyIHBhY2tldC1sZXZlbCBjbGFzc2lmaWNhdGlvbiBjYXNlcywgb3IgaXMg aXQgdGhlIA0KPj4gPiBpbnRlbnQgdG8gY29uc2lkZXIgdGhlIGNhc2Ugd2hlcmUgYSBicmFuY2hp bmcgcG9pbnQgaXMgdmlld2VkIGFzIGEgDQo+PiA+IHJlLWNsYXNzaWZpY2F0aW9uIHBvaW50Pw0K Pj4gPg0KPj4gPnRoYW54Lg0KPj4gPg0KPj4gPi0tICBLZXZpbiBKLiBNYQ0KPj4gPg0KPj4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZyb206IExpbmRhIER1bmJhciBbbWFp bHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KPj4gPj4gU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMTIsIDIwMTMgMTA6MzQgQU0NCj4+ID4+IFRvOiBSb24gUGFya2VyOyBIb25neXUgTGkgKEp1 bGlvKTsgS2V2aW4gSiBNYQ0KPj4gPj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsg U3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyANCj4+ID4+IFN1bWFuZHJhIE1hamVlDQo+PiA+PiBT dWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4NCj4+ ID4+IFJvbiwNCj4+ID4+DQo+PiA+PiBGaXJzdCwgd2FudCB0byBtYWtlIGl0IGNsZWFyIHRoYXQg ImJyYW5jaGluZyIgIT0gcmVjbGFzc2lmaWNhdGlvbiwgDQo+PiA+PmFncmVlPw0KPj4gPj4NCj4+ ID4+IFNlY29uZCwgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGJyYW5jaGluZyAob3Igc2VydmljZSBn cmFwaCkgY2FuIGJlIA0KPj4gPj4gaW4gYSBmb3JtIG9mIGxvZ2ljIG9uIGEgc2VydmljZSBmdW5j dGlvbi4gU29tZSBzZXJ2aWNlIGZ1bmN0aW9ucywgDQo+PiA+PiBlc3BlY2lhbGx5IEw3IGJhc2Vk LCBjYW4gdXNlIHZhbHVlIGluIGEgRGF0YWJhc2UgdG8gZGV0ZXJtaW5lIHdoYXQgDQo+PiA+PiBp cyB0aGUgbmV4dCBzZXJ2aWNlIGZ1bmN0aW9uLg0KPj4gPj4NCj4+ID4+IExpbmRhDQo+PiA+Pg0K Pj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiBGcm9tOiBuc2MtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+ID4+ID4g QmVoYWxmIE9mIFJvbiBQYXJrZXINCj4+ID4+ID4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIs IDIwMTMgODoxNiBBTQ0KPj4gPj4gPiBUbzogSG9uZ3l1IExpIChKdWxpbyk7IEtldmluIEogTWEN Cj4+ID4+ID4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VyZW5kcmEgS3VtYXIg KHNta3VtYXIpOyANCj4+ID4+ID4gU3VtYW5kcmEgTWFqZWUNCj4+ID4+ID4gU3ViamVjdDogUmU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4NCj4+ID4+ID4gSG9u Z3l1LA0KPj4gPj4gPg0KPj4gPj4gPiBJIGFncmVlIGNvbXBsZXRlbHkgdGhhdCByZS1jbGFzc2lm aWNhdGlvbiBpcyBub3QgbGltaXRlZCB0byBEUEkuDQo+PiA+PiA+DQo+PiA+PiA+IEFuZCBhbHNv LCB0aGF0IGFuIGFyZWEgZm9yIHVzIHRvIGV4cGxvcmUgYXMgYSBncm91cCBpcyBob3cgdG8NCj4+ ID4+cmVwcmVzZW50DQo+PiA+PiA+IHRoZSBzZXJ2aWNlIGdyYXBoLiAgIERvIHdlIHdhbnQgdG8g cmVwcmVzZW50IGl0IGFzIGEgcHJvcGVyIGdyYXBoDQo+PiB3aXRoDQo+PiA+PiA+IGFuIGFkamFj ZW5jeSBsaXN0IG9yIG90aGVyIHJlcHJlc2VudGF0aW9uYWwgbW9kZWw/ICAgT3IsIGRvIHdlIHdh bnQNCj4+IHRvDQo+PiA+PiA+IHJlcHJlc2VudCBpdCBhcyBhIHNldCBvZiBsaW5lYXIgc2VnbWVu dHMgYW5kIGlmIHNvLCBob3cgYXJlIHRoZQ0KPj4gPj4gPiBzZWdtZW50cyBjb25uZWN0ZWQgaW50 byBhIGdyYXBoPyAgIE90aGVyIGlkZWFzPw0KPj4gPj4gPg0KPj4gPj4gPiAgICBSb24NCj4+ID4+ ID4NCj4+ID4+ID4NCj4+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4g RnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10g T24gDQo+PiA+PiA+IEJlaGFsZiBPZiBIb25neXUgTGkgKEp1bGlvKQ0KPj4gPj4gPiBTZW50OiBU dWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyA2OjU3IEFNDQo+PiA+PiA+IFRvOiBSb24gUGFya2Vy OyBLZXZpbiBKIE1hDQo+PiA+PiA+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1 cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+PiA+PiA+IFN1bWFuZHJhIE1hamVlDQo+PiA+PiA+ IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ DQo+PiA+PiA+IEJyYW5jaGluZy9mb3JraW5nIGlzIGEgdmVyeSBpbnRlcmVzdGluZyB0b3BpYyBv ZiBTRkMuIEFib3V0IHRoZQ0KPj4gPj4gPiByZS0gY2xhc3NpZmljYXRpb24gcG9pbnQsIHByb2Jh Ymx5IHdlIHNoYWxsIG5vdCBsaW1pdCBpdCB0byBEUEkuDQo+PiA+PiA+IEl0IGlzIGFsc28gcG9z c2libGUgdGhhdCBwYWNrZXRzIGdvIHRvIGRpZmZlcmVudCBicmFuY2hlcyBhZnRlciANCj4+ID4+ ID4gYmVlbiBwcm9jZXNzZWQgYnkgYSBjZXJ0YWluIHNlcnZpY2UgZnVuY3Rpb24sIGRlY2lzaW9u IG9mIHdoaWNoIA0KPj4gPj4gPiBicmFuY2hlcyB0byBnbyBpcyBtYWRlIGJhc2VkIG9uIHRoZSBy ZXN1bHQgb2Ygc2VydmljZSBmdW5jdGlvbidzIA0KPj4gPj4gPiBwcm9jZXNzLCBpLmUuIG5vdCBq dXN0IHJlLSBjbGFzc2lmaWNhdGlvbiBieSBEUEkuDQo+PiA+PiA+DQo+PiA+PiA+IEhvbmd5dQ0K Pj4gPj4gPg0KPj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiBGcm9t OiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiAN Cj4+ID4+ID4gQmVoYWxmIE9mIFJvbiBQYXJrZXINCj4+ID4+ID4gU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMTIsIDIwMTMgNzo0NSBQTQ0KPj4gPj4gPiBUbzogS2V2aW4gSiBNYQ0KPj4gPj4gPiBD YzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7 IA0KPj4gPj4gPiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiBTdWJqZWN0OiBSZTogW25zY10gQ3Vy cmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPg0KPj4gPj4gPiBIaSwgS2V2aW4NCj4+ ID4+ID4NCj4+ID4+ID4gWW91IGFzayBhIGdyZWF0IHF1ZXN0aW9uIGFib3V0IGJyYW5jaGluZyB0 aGUgZ3JhcGguICBUaGUgZGV0YWlscyANCj4+ID4+ID4gYXJvdW5kIGhvdyB0byBjb252ZXkgdGhl IHNlbGVjdGlvbiBvZiB0aGUgc3VidHJlZS9zdWJncmFwaCBhcmUgDQo+PiA+PiA+IHN0aWxsDQo+ PiA+PnRvIGJlDQo+PiA+PiA+IGRlZmluZWQuICAgSXMgaXQgb25lIGNoYWluIGlkIGZvciB0aGUg d2hvbGUgZ3JhcGg/ICAgRG9lcyBlYWNoDQo+PmJyYW5jaA0KPj4gPj4gPiBoYXZlIGl0cyBvd24g Y2hhaW4gaWQ/ICAgU29tZSBjb21iaW5hdGlvbj8NCj4+ID4+ID4NCj4+ID4+ID4gICAgUm9uDQo+ PiA+PiA+DQo+PiA+PiA+IE9uIE5vdiAxMiwgMjAxMywgYXQgMTo1MiBBTSwgIktldmluIEogTWEi DQo+PiA+PiA+IDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0KPj4gPj4gPiB3cm90ZToNCj4+ ID4+ID4NCj4+ID4+ID4gPj4gWWVzLCByZWNsYXNzaWZpY2F0aW9uIGNhbiBjaGFuZ2UgdGhlIHNl cnZpY2UgcGF0aCBhbmQgDQo+PiA+PiA+ID4+IHJlLWNsYXNzaWZpY2F0aW9uIG1heSBoYXBwZW4g YXQgYW55IG5vZGUgYWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+PiA+PiA+ID4NCj4+ID4+ID4gPiBK dXN0IHRvIGV4cGFuZCBvbiB0aGF0LCBnb2luZyBiYWNrIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlv biANCj4+ID4+ID4gPiBhYm91dCBzZXJ2aWNlIGhlYWRlciBlbmNhcHN1bGF0aW9uLCBpcyBpdCBp bnRlbmRlZCB0aGF0IGEgDQo+PiA+PiA+ID4gY2hhaW4gdGhhdCBpcyByZS1jbGFzc2lmaWVkIHdp bGwgZ2V0IGEgbmV3IGNoYWluIElEIHdoaWNoIA0KPj4gPj4gPiA+IGZ1bGx5IGRlc2NyaWJlcyBh IGNoYWluIHRoYXQgaXMgYSBzdXBlcnNldCBvZiB0aGUgb3JpZ2luYWwgDQo+PiA+PiA+ID4gY2hh aW4gSUQsIHByaW9yIHRvIERQSS1iYXNlZCByZS1jbGFzc2lmaWNhdGlvbj8gIChhc3N1bWluZyB0 aGUgDQo+PiA+PiA+ID4gZ29hbCBpcyAiYSBzaW5nbGUgY2hhaW4gSUQgdGhhdCBpcyBjb21tb25s eSB1bmRlcnN0b29kIGFsb25nIA0KPj4gPj4gPiA+IHRoZSBlbnRpcmUgc2VydmljZQ0KPj4gY2hh aW4iDQo+PiA+PiA+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25zYy9j dXJyZW50L21zZzAwNjM4Lmh0bWwNCj4+ID4+ID4gPiApDQo+PiA+PiA+ID4NCj4+ID4+ID4gPiBB bmQgdGhlIGFwcGxpY2FibGUgc3Vic2V0IG9mIHRoZSBwZXJtdXRhdGl2ZSBsaXN0IG9mIHNlcnZp Y2UgDQo+PiA+PiA+ID4gcGF0aHMgd291bGQgYmUgY29uZmlndXJlZCBhdCBlYWNoIGFwcHJvcHJp YXRlIHNlcnZpY2Ugbm9kZT8NCj4+ID4+ID4gPiBlLmcuLCBJRCAxOiBOQVQgKyBmaXJld2FsbCAr IERQSQ0KPj4gPj4gPiA+ICAgICAgSUQgMjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBVg0KPj4g Pj4gPiA+ICAgICAgSUQgMzogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViArIE5BVA0KPj4gPj4g PiA+ICAgICAgSUQgNDogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBOQVQNCj4+ID4+ID4gPiAgICAg IElEIDU6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBMQg0KPj4gPj4gPiA+ICAgICAgSUQg NjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBMQg0KPj4gPj4gPiA+ICAgICAgSUQgNzogTkFUICsg ZmlyZXdhbGwgKyBEUEkgKyBMQiArIENBQ0hFDQo+PiA+PiA+ID4gICAgICBJRCA4OiBOQVQgKyBm aXJld2FsbCArIERQSSArIENBQ0hFDQo+PiA+PiA+ID4gICAgICBJRCA5OiBOQVQgKyBmaXJld2Fs bCArIERQSSArIG9wdGltaXplciArIExCDQo+PiA+PiA+ID4gICAgICBJRCAxMDogTkFUICsgZmly ZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQiArIENBQ0hFDQo+PiA+PiA+ID4gICAgICBJRCAx MTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBDQUNIRSBXb3VsZCANCj4+ID4+ ID4gPiBldmVyeSBmbG93IHRoZW4gYmUgaW5pdGlhbGx5IGNsYXNzaWZpZWQgYXMgSUQgMSwgYnV0 IA0KPj4gPj4gPiA+IGV2ZW50dWFsbHkgZ2V0IHJlLQ0KPj4gPj4gPiBjbGFzc2lmaWVkDQo+PiA+ PiA+ID4gdG8gSUQgMi0xMSwgYWZ0ZXIgdGhlIERQSSBwaGFzZT8NCj4+ID4+ID4gPg0KPj4gPj4g PiA+IHRoYW54Lg0KPj4gPj4gPiA+DQo+PiA+PiA+ID4gLS0gIEtldmluIEouIE1hDQo+PiA+PiA+ ID4NCj4+ID4+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4gRnJv bTogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+ PiA+PiA+ID4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDE6MDEgQU0NCj4+ID4+ ID4gPj4gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMg TmFydGVuOyANCj4+ID4+ID4gPj4gbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+IFN1YmplY3Q6IFJl OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+DQo+PiA+PiA+ ID4+DQo+PiA+PiA+ID4+DQo+PiA+PiA+ID4+PiBPbiAxMS8xMS8xMyA5OjQ2IFBNLCAiS2V2aW4g SiBNYSIgDQo+PiA+PiA+ID4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+ID4+d3Jv dGU6DQo+PiA+PiA+ID4+Pg0KPj4gPj4gPiA+Pj4gSGkgU3VyZW5kcmEsDQo+PiA+PiA+ID4+Pg0K Pj4gPj4gPiA+Pj4gQ2xhc3NpZmljYXRpb24gbWF5IGJlIG91dCBvZiBzY29wZSwgYnV0IHRoZSBs ZXZlbCBvZiBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4gdGhhdA0KPj4gPj4gPiBpcw0KPj4gPj4gPiA+ Pj4gYXBwbGljYWJsZSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRp b24gDQo+PiA+PiA+ID4+PiB0aGF0IGNhbg0KPj4gPj4gPiBiZQ0KPj4gPj4gPiA+Pj4gcGVyZm9y bWVkLiAgQW4gYXNzdW1wdGlvbiBvZiBwYWNrZXQgbGV2ZWwgZW5jYXBzdWxhdGlvbiBoYXMNCj4+ ID4+ID4gPj4gaW1wbGljYXRpb25zDQo+PiA+PiA+ID4+PiBvbiB0aGUgbGV2ZWwgb2YgY2xhc3Np ZmljYXRpb24gYmVpbmcgcGVyZm9ybWVkPyAgSWYgdGhlIA0KPj4gPj4gPiA+Pj4gc3RhdGVkDQo+ PiA+PiA+IGdvYWxzDQo+PiA+PiA+ID4+IGFyZQ0KPj4gPj4gPiA+Pj4gZm9yIGZpcmV3YWxsIGFu ZCBsb2FkIGJhbGFuY2VyIGZ1bmN0aW9uYWxpdHksIHRoZW4gdGhlIA0KPj4gPj4gPiA+Pj4gYXBw bGljYXRpb24NCj4+ID4+ID4gPj4gbGV2ZWwNCj4+ID4+ID4gPj4+IG5hdHVyZSBvZiB0aG9zZSBm dW5jdGlvbnMgbmVlZHMgdG8gYmUgdGFrZW4gaW50byBhY2NvdW50Pw0KPj4gPj4gPiA+Pj4gSWYs IG9uIHRoZSBvdGhlciBoYW5kLCB0aGUgc2VydmljZSBmdW5jdGlvbiBzY29wZSBpcyBsaW1pdGVk IA0KPj4gPj4gPiA+Pj4gZHVlIHRvIGxpbWl0YXRpb25zIGluIGNsYXNzaWZpY2F0aW9uLCB0aGF0 IHdvdWxkIGJlIGFuZCANCj4+ID4+ID4gPj4+IGltcG9ydGFudCBwaWVjZSBvZg0KPj4gPj4gPiBp bmZvcm1hdGlvbj8NCj4+ID4+ID4gPj4+DQo+PiA+PiA+ID4+PiBXcnQgc2VjdGlvbiA0LjQgb2Yg ZHJhZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzIHRoZSANCj4+ID4+ID4gPj4+IGZv cmsgcG9pbnRzIG9mIHRoZSBzZXJ2aWNlIHBhdGhzIHNlZW0gbGlrZSByZS1jbGFzc2lmaWNhdGlv bg0KPj4gcG9pbnRzPw0KPj4gPj4gPiA+Pj4gSXMgdGhhdCB0aGUgaW50ZXJwcmV0YXRpb24gZnJv bSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlPw0KPj4gPj4gPiA+Pj4gT3IgaXMgdGhlIHNl cnZpY2UgZnVuY3Rpb24gY2hhaW4gY2xhc3NpZmljYXRpb24gZXhjbHVzaXZlIG9mIA0KPj4gPj4g PiA+Pj4gRFBJDQo+PiA+PiA+IGZ1bmN0aW9uYWxpdHk/DQo+PiA+PiA+ID4+IDxTSz4gSSBoYXZl IG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwgYXMgDQo+PiA+ PiA+ID4+IGRlc2NyaWJlZCBpbiB0aGUgYXJjaCBkcmFmdCwgdGhlIGNvbGxlY3Rpb24gb2Ygc2Vy dmljZXMgZm9ybSANCj4+ID4+ID4gPj4gYSBncmFwaCwgc2VnbWVudHMgb2Ygd2hpY2ggYXJlIHNl cnZpY2UgcGF0aHMuIFllcywgDQo+PiA+PiA+ID4+IHJlY2xhc3NpZmljYXRpb24gY2FuDQo+PiA+ PiA+IGNoYW5nZQ0KPj4gPj4gPiA+PiB0aGUgc2VydmljZSBwYXRoIGFuZCByZS1jbGFzc2lmaWNh dGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2RlIA0KPj4gPj4gPiA+PiBhbG9uZw0KPj4gPj4gPiBh IHNlcnZpY2UgcGF0aC4NCj4+ID4+ID4gPj4NCj4+ID4+ID4gPj4gU3VyZW5kcmEuDQo+PiA+PiA+ ID4+Pg0KPj4gPj4gPiA+Pj4gdGhhbnguDQo+PiA+PiA+ID4+Pg0KPj4gPj4gPiA+Pj4gLS0gIEtl dmluIEouIE1hDQo+PiA+PiA+ID4+Pg0KPj4gPj4gPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiA+PiA+ID4+Pj4gRnJvbTogU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWls dG86c21rdW1hckBjaXNjby5jb21dDQo+PiA+PiA+ID4+Pj4gU2VudDogVHVlc2RheSwgTm92ZW1i ZXIgMTIsIDIwMTMgMTI6MDggQU0NCj4+ID4+ID4gPj4+PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBh cmtlcjsgU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47IA0KPj4gPj4gPiA+Pj4+IG5zY0Bp ZXRmLm9yZw0KPj4gPj4gPiA+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4NCj4+ID4+ID4gPj4+PiBLZXZpbiwNCj4+ID4+ID4g Pj4+Pg0KPj4gPj4gPiA+Pj4+IENsYXNzaWZpY2F0aW9uIG1lY2hhbmlzbSBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiBTRkMuIEl0IA0KPj4gPj4gPiA+Pj4+IGNhbiBiZSBiYXNlZA0KPj4gPj4gPiA+ PiBvbg0KPj4gPj4gPiA+Pj4+IHRoZSBwYWNrZXQgb3IgaW5mb3JtYXRpb24gbm90IGluIHRoZSBw YWNrZXQoZW52aXJvbm1lbnRhbCANCj4+ID4+ID4gPj4+PiBhdHRyaWJ1dGVzDQo+PiA+PiA+ID4+ IGZvcg0KPj4gPj4gPiA+Pj4+IGluc3RhbmNlKSBvciBhIGNvbWJpbmF0aW9uIHRoZXJlb2YuIFdo YXQgaXMgaW1wb3J0YW50IGlzIA0KPj4gPj4gPiA+Pj4+IHRoYXQgc3VjaCBjbGFzc2lmaWNhdGlv biBhaWRzIGluIHRyYWZmaWMgc2VsZWN0aW9uIGFuZCANCj4+ID4+ID4gPj4+PiBzZXJ2aWNlIHBh dGggaWRlbnRpZmljYXRpb24uDQo+PiA+PiA+ID4+Pj4gSXQgaXMgbm8gZGlmZmVyZW50IGZyb20g YSBwb2xpY3kgaW4gdGhpcyByZWdhcmQgZXhjZXB0IHRoYXQgDQo+PiA+PiA+ID4+Pj4gdGhlIHBv bGljeSBub3cgc3BlY2lmaWVzIHRoZSBzZXJ2aWNlIHBhdGguDQo+PiA+PiA+ID4+Pj4gRnVydGhl ciwgY2xhc3NpZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gdGhlIG5ldHdvcmsgDQo+PiA+PiA+ ID4+Pj4gZWxlbWVudHMgYnV0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcyB3ZWxsLiBTb21lIG9m IHRoaXMgaXMgDQo+PiA+PiA+ID4+Pj4gZGVzY3JpYmVkIGluIHRoZQ0KPj4gPj4gPiA+PiBhcmNo aXRlY3R1cmUNCj4+ID4+ID4gPj4+PiBkcmFmdHMgYXMgd2VsbCAtDQo+PiA+PiA+ID4+Pj4gImh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLyIuDQo+ PiA+PiA+ID4+Pj4NCj4+ID4+ID4gPj4+PiBTdXJlbmRyYS4NCj4+ID4+ID4gPj4+Pg0KPj4gPj4g PiA+Pj4+PiBPbiAxMS8xMS8xMyA3OjMzIFBNLCAiS2V2aW4gSiBNYSINCj4+ID4+ID4gPj4+Pj4g PGtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+DQo+PiA+PiA+IHdyb3RlOg0KPj4gPj4gPiA+Pj4+ Pg0KPj4gPj4gPiA+Pj4+PiBIaSBSb24sDQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IEkg d2FzIHVuYWJsZSB0byBtYWtlIHRoZSBTRkMgQm9GIGR1ZSB0byBhIGNvbmZsaWN0IHdpdGggDQo+ PiA+PiA+ID4+Pj4+IENETkksIGJ1dCBJIGhhZCBhIHNpbWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxl dCAxMSBpbiANCj4+ID4+ID4gPj4+Pj4gc2VjdGlvbg0KPj4gPj4gPiA+Pj4+PiAyIG9mIHRoZQ0K Pj4gPj4gPiBwcm9ibGVtDQo+PiA+PiA+ID4+Pj4+IHN0YXRlbWVudDoNCj4+ID4+ID4gPj4+Pj4N Cj4+ID4+ID4gPj4+Pj4gICAxMS4gIFBlci1TZXJ2aWNlIChyZSlDbGFzc2lmaWNhdGlvbjogQ2xh c3NpZmljYXRpb24gDQo+PiA+PiA+ID4+Pj4+IG9jY3VycyBhdA0KPj4gPj4gPiBlYWNoDQo+PiA+ PiA+ID4+Pj4+ICAgICAgICBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZpb3VzbHkgYXBw bGllZCANCj4+ID4+ID4gPj4+Pj4gc2VydmljZQ0KPj4gPj4gPiA+Pj4+IGZ1bmN0aW9ucy4NCj4+ ID4+ID4gPj4+Pj4gICAgICAgIFRoZXNlIHVucmVsYXRlZCBjbGFzc2lmaWNhdGlvbiBldmVudHMg Y29uc3VtZSANCj4+ID4+ID4gPj4+Pj4gcmVzb3VyY2VzDQo+PiA+PiA+IHBlcg0KPj4gPj4gPiA+ Pj4+PiAgICAgICAgc2VydmljZS4gIE1vcmUgaW1wb3J0YW50bHksIHRoZSBjbGFzc2lmaWNhdGlv bg0KPj4gPj4gPiBmdW5jdGlvbmFsaXR5DQo+PiA+PiA+ID4+Pj4+ICAgICAgICBvZnRlbiBkaWZm ZXJzIHBlciBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+PiBmdW5j dGlvbg0KPj4gPj4gPiA+PiBjYW5ub3QNCj4+ID4+ID4gPj4+Pj4gICAgICAgIGxldmVyYWdlIHRo ZSByZXN1bHRzIGZyb20gb3RoZXIgZGVwbG95ZWQgbmV0d29yayBvcg0KPj4gPj4gPiBzZXJ2aWNl Lg0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiBhcyBpdCByZWxhdGVzIHRvIHNlY3Rpb24g NS4yIG9mIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQ6DQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+ Pj4+ICAgVGhlIFNGQyBDbGFzc2lmaWVyIGNsYXNzaWZpZXMgcGFja2V0cyBiYXNlZCBvbiAoc29t ZSBvZikgDQo+PiA+PiA+ID4+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+IGNvbnRlbnRzDQo+PiA+PiA+ ID4+Pj4+ICAgb2YgdGhlIHBhY2tldCBoZWFkZXIuICBDb25jcmV0ZWx5LCBpdCBjbGFzc2lmaWVz IHBhY2tldHMgDQo+PiA+PiA+ID4+Pj4+IGJhc2VkIG9uDQo+PiA+PiA+ID4+Pj4gdGhlDQo+PiA+ PiA+ID4+Pj4+ICAgcG9zc2libGUgY29tYmluYXRpb24gb2Ygb25lIG9yIG1vcmUgaGVhZGVyIGZp ZWxkcywgc3VjaCANCj4+ID4+ID4gPj4+Pj4gYXMNCj4+ID4+ID4gc291cmNlDQo+PiA+PiA+ID4+ Pj4+ICAgYWRkcmVzcywgZGVzdGluYXRpb24gYWRkcmVzcywgRFMgZmllbGQsIHByb3RvY29sIElE LCANCj4+ID4+ID4gPj4+Pj4gc291cmNlDQo+PiA+PiA+IHBvcnQNCj4+ID4+ID4gPj4+PiBhbmQN Cj4+ID4+ID4gPj4+Pj4gICBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMsIGFuZCBhbnkgb3RoZXIg aW5mb3JtYXRpb24uDQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IEEgcGFja2V0LWJhc2Vk IGNsYXNzaWZpZXIgYXMgZGVzY3JpYmVkIGluIHRoZSBmcmFtZXdvcmsgDQo+PiA+PiA+ID4+Pj4+ IGRvY3VtZW50DQo+PiA+PiA+ID4+Pj4gd291bGQNCj4+ID4+ID4gPj4+Pj4gc2VlbSB0byBiZSBs aW1pdGVkIGluIHdoYXQgaXQgY2FuIGNsYXNzaWZ5PyAgVGhlIHNlcnZpY2UgDQo+PiA+PiA+ID4+ Pj4+IGZ1bmN0aW9uIGlkZW50aWZpZXIgbG9va3VwIGRvZXMgbm90IHNlZW0gdG8gYmUgYSANCj4+ ID4+ID4gPj4+Pj4gc2lnbmlmaWNhbnQgb3B0aW1pemF0aW9uDQo+PiA+PiA+ID4+IG92ZXINCj4+ ID4+ID4gPj4+Pj4gYSBwYWNrZXQtYmFzZWQgNS10dXBsZSBsb29rdXA/ICBUaGVyZSBzZWVtcyB0 byBiZSBzb21lIA0KPj4gPj4gPiA+Pj4+PiBtaXNzaW5nDQo+PiA+PiA+ID4+IGRldGFpbA0KPj4g Pj4gPiA+Pj4+PiB3cnQgaG93IGNsYXNzaWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIGRldGVybWlu ZWQgYW5kIHJldXNlZD8NCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4gPj4+Pj4gV2hlbiB0aGlua2lu ZyBhYm91dCBoaWdoZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhUVFAgYW5kIA0KPj4gPj4gPiA+ Pj4+PiBUTFMNCj4+ID4+ID4gPj4+PiBlbmNyeXB0ZWQNCj4+ID4+ID4gPj4+Pj4gZmxvd3MsIGEg cGFja2V0LWJhc2VkIGNsYXNzaWZpZXIgc2VlbXMgaW5hZGVxdWF0ZT8gIEkgd2FzIA0KPj4gPj4g PiA+Pj4+PiBhbHNvDQo+PiA+PiA+ID4+Pj4gd29uZGVyaW5nDQo+PiA+PiA+ID4+Pj4+IGhvdyBp bmRlcGVuZGVudCBITFMgc2VnbWVudCByZXF1ZXN0cyBtaWdodCBiZSBjbGFzc2lmaWVkIA0KPj4g Pj4gPiA+Pj4+PiBhbmQNCj4+ID4+ID4gPj4+PiBhc3NvY2lhdGVkPw0KPj4gPj4gPiA+Pj4+PiBX ZXJlIHRoZXNlIHR5cGVzIG9mIHVzZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJvRj8NCj4+ID4+ ID4gPj4+Pj4NCj4+ID4+ID4gPj4+Pj4gdGhhbnguDQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+ Pj4+IC0tICBLZXZpbiBKLiBNYQ0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIA0KPj4gPj4gPiA+Pj4+Pj4gT24g QmVoYWxmDQo+PiA+PiA+ID4+IE9mDQo+PiA+PiA+ID4+Pj4+PiBSb24NCj4+ID4+ID4gPj4+Pj4+ IFBhcmtlcg0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyAx MDoxNiBQTQ0KPj4gPj4gPiA+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMgTmFydGVu OyBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50 IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gU3Vt YW5kcmEsDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQXMgd2FzIGRpc2N1c3NlZCBp biBWYW5jb3V2ZXIsIHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgDQo+PiA+PiA+ID4+Pj4+PiBleGlz dGluZyB3YXlzDQo+PiA+PiA+ID4+Pj4gdG8NCj4+ID4+ID4gPj4+Pj4+IGFjY29tcGxpc2ggc2Vy dmljZSBjaGFpbmluZy4gICAgIEJ1dCBub25lIG9mIHRoZW0gcHJvdmlkZSBhDQo+PiA+PiA+ID4+ Pj4gc3VmZmljaWVudA0KPj4gPj4gPiA+Pj4+Pj4gY29tYmluYXRpb24gb2YgaW50ZXJvcGVyYWJp bGl0eSwgZmxleGliaWxpdHksIGFuZA0KPj5yZXNpbGllbmN5Lg0KPj4gPj4gPiBBDQo+PiA+PiA+ ID4+Pj4gc2luZ2xlDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGNoYWluIGVuY2Fwc3VsYXRpb24g d2lsbCBnbyBhIGxvbmcgd2F5IHRvIA0KPj4gPj4gPiA+Pj4+Pj4gZW5zdXJpbmcgdGhlc2UNCj4+ ID4+ID4gPj4+PiBnb2Fscy4NCj4+ID4+ID4gPj4+Pj4+IEl0ICBtYXkgbm90IGJlIHRoZSBhYnNv bHV0ZWx5IG1vc3QgZWZmaWNpZW50IGFwcHJvYWNoIGZvciANCj4+ID4+ID4gPj4+Pj4+IGV2ZXJ5 DQo+PiA+PiA+ID4+Pj4gc2luZ2xlDQo+PiA+PiA+ID4+Pj4+PiBuZXR3b3JrIHRvcG9sb2d5IGFu ZCBldmVyeSBzaW5nbGUgdXNlIGNhc2UsIGJ1dCBpdHMgDQo+PiA+PiA+ID4+Pj4+PiB1YmlxdWl0 b3VzDQo+PiA+PiA+ID4+IG5hdHVyZQ0KPj4gPj4gPiA+Pj4+Pj4gc2hvdWxkIGltcHJvdmUgaXRz IGFkb3B0aW9uLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ICAgUm9uDQo+PiA+PiA+ ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMu TWFqZWVARjUuY29tXQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwg MjAxMyAxMDoxMCBQTQ0KPj4gPj4gPiA+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0 ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJl bnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBS b24sDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQWJzb2x1dGVseSwgdGhhdCB3YXMg YW4gZXhhbXBsZSBvZiBvbmUgdHlwZSBvZiBkZXJpdmF0aW9uLg0KPj4gPj4gPiA+Pj4+Pj4gSG93 ZXZlcg0KPj4gPj4gPiA+Pj4+IHRoaXMNCj4+ID4+ID4gPj4+Pj4+IGNvdWxkIGJlIGF1Z21lbnRl ZCB3aXRoIGNsYXNzaWZpY2F0aW9uIHJlc3VsdCwgYWdhaW4gb25lIA0KPj4gPj4gPiA+Pj4+Pj4g bW9yZQ0KPj4gPj4gPiA+Pj4+IGV4YW1wbGUuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4+PiBBbGwgZmxvd3MgZnJvbSB0aGUgc2FtZSBzb3VyY2UgSVAgZG8gbm90IG5lY2Vzc2FyaWx5 IA0KPj4gPj4gPiA+Pj4+Pj4+PiBmb2xsb3cNCj4+ID4+ID4gdGhlDQo+PiA+PiA+ID4+Pj4gc2Ft ZQ0KPj4gPj4gPiA+Pj4+Pj4gY2hhaW4uDQo+PiA+PiA+ID4+Pj4+PiBDb3JyZWN0LiBJdCBpcyBh bHNvIG5vdCBuZWNlc3NhcnkgdGhhdCBhbGwgdHJhbnNhY3Rpb24gb2YgDQo+PiA+PiA+ID4+Pj4+ PiB0aGUgc2FtZQ0KPj4gPj4gPiA+Pj4+IGZsb3cNCj4+ID4+ID4gPj4+Pj4+IGZvbGxvdyB0aGUg c2FtZSBjaGFpbiBlaXRoZXIuIFNvIHdoeSBzdG9wIGF0IGZsb3cgaXRzZWxmLg0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFnYWluIHRoZSBwb2ludCBoZXJlIGlzIHRoYXQgZG8gd2Ug YWx3YXlzIG5lZWQgU0ZDIGhlYWRlciANCj4+ID4+ID4gPj4+Pj4+IG9yDQo+PiA+Pk5vdC4NCj4+ ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYQ0KPj4gPj4gPiA+Pj4+Pj4NCj4+ ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gPj4gPiA+Pj4+Pj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb21dDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDEx LCAyMDEzIDc6MDIgUE0NCj4+ID4+ID4gPj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFz IE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10g Q3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+ Pj4+IFN1bWFuZHJhLA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFRoZSBpbnRlbnRp b24gb2Ygc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBhbGxvdyANCj4+ID4+ID4gPj4+ Pj4+IGZvciBvcGVyYXRpb24NCj4+ID4+ID4gPj4+PiBhdA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIGZ1 bGx5IHF1YWxpZmllZCBmbG93IGxldmVsLCBvciBldmVuIGZpbmVyIGdyYWluZWQgYXQgDQo+PiA+ PiA+ID4+Pj4+PiB0aGUNCj4+ID4+ID4gPj4+PiB0cmFuc2FjdGlvbg0KPj4gPj4gPiA+Pj4+Pj4g bGV2ZWwgKHRoaXMgaXMgYW4gaW1wbGVtZW50YXRpb24gbWF0dGVyIGZvciB0aGUgUERQKS4NCj4+ QWxsDQo+PiA+PiA+IGZsb3dzDQo+PiA+PiA+ID4+Pj4gZnJvbQ0KPj4gPj4gPiA+Pj4+Pj4gdGhl IHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSBmb2xsb3cgdGhlIHNhbWUgY2hhaW4u DQo+PiA+PiA+ID4+IFNvdXJjZQ0KPj4gPj4gPiA+Pj4+Pj4gSVAsDQo+PiA+PiA+ID4+Pj4+PiB0 aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlmeSB0aGUgY2hhaW4gSUQuICAgIEFub3RoZXINCj4+ ID4+aW50ZW50aW9uDQo+PiA+PiA+IG9mDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29yaw0KPj4gPj4gPiB0b3BvbG9n eQ0KPj4gPj4gPiA+PiBhbmQNCj4+ID4+ID4gPj4+Pj4+IG5vdA0KPj4gPj4gPiA+Pj4+Pj4gYmUg bGltaXRlZCB0byBhIHNpbmdsZSBMQU4uICAgVGh1cywgd2hpbGUgVkxBTiBtYXkgYmUgcGFydA0K Pj5vZg0KPj4gPj4gPiB0aGUNCj4+ID4+ID4gPj4+Pj4+IHRyYW5zcG9ydCwgaXQgZG9lcyBub3Qg YWRlcXVhdGVseSBpZGVudGlmeSB0aGUgc2VydmljZSANCj4+ID4+ID4gPj4+Pj4+IGNoYWluLA0K Pj4gPj4gPiA+PiBlaXRoZXIuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24N Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IFN1bWFuZHJhIE1hamVlIFtt YWlsdG86Uy5NYWplZUBGNS5jb21dDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVt YmVyIDExLCAyMDEzIDk6NTYgUE0NCj4+ID4+ID4gPj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9t YXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNj XSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+ Pj4+Pj4gUm9uLA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFRoZSBzZXJ2aWNlIGhl YWRlciBpcyBtZWFudCB0byBjYXJyeSB0aGUgY29udGV4dCB3aGljaCANCj4+ID4+ID4gPj4+Pj4+ IGNhbg0KPj4gPj4gPiAqYWxzbyoNCj4+ID4+ID4gPj4+Pj4+IGJlIGRlcml2ZWQgKGZvciBleGFt cGxlIHVzZSBzb3VyY2UgaXAgYW5kIHZsYW4gdG8gDQo+PiA+PiA+ID4+Pj4+PiBpZGVudGlmeSBj aGFpbklEIGFuZA0KPj4gPj4gPiA+Pj4+Pj4gcG9zaXRpb24pIG9yIGVuY2Fwc3VsYXRlZCBhcyBw YXJ0IG9mIGFub3RoZXIgdHVubmVsIGhlYWRlci4NCj4+ID4+ID4gPj4+Pj4+IFNvIHRoaXMgY291 bGQgYmUgb3B0aW9uYWwgSU1ITy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogUm9uIFBhcmtlciBb bWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+PiA+PiA+ID4+Pj4+PiBT ZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDQ6MzYgUE0NCj4+ID4+ID4gPj4+Pj4+IFRv OiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+ Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhLA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ ID4+ID4gPj4+Pj4+IEFzIEkgdW5kZXJzdGFuZCBpdCwgYW4gU0ZDIHBhY2tldCB0cmF2ZXJzaW5n IGZyb20gUERQIHRvIA0KPj4gPj4gPiA+Pj4+Pj4gU0Ygb3IgZnJvbQ0KPj4gPj4gPiA+Pj4+IFNG DQo+PiA+PiA+ID4+Pj4+PiB0bw0KPj4gPj4gPiA+Pj4+Pj4gU0Ygd2lsbCBsb29rIGxpa2U6DQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cj4+ID4+ID4gPj4+Pj4+IHwgICAgICAgICJ0cmFuc3BvcnQiICAgICAgICAgfA0KPj4gPj4gPiA+ Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ID4+ID4gPj4+Pj4+IHwgICAgICBz ZXJ2aWNlIGhlYWRlciAgICB8DQo+PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KPj4gPj4gPiA+Pj4+Pj4gfCAgIG9yaWdpbmFsIElQIGhlYWRlciAgfA0KPj4gPj4gPiA+ Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ID4+ID4gPj4+Pj4+IHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIG9yaWdpbmFsIElQIA0KPj4gPj4g PiA+Pj4+Pj4gfCBwYXlsb2FkDQo+PiA+PiA+IHwNCj4+ID4+ID4gPj4+Pj4+IHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gV2hlcmUg c2VydmljZSBoZWFkZXIgY29udGFpbnMsIGF0IGEgbWluaW11bSwgZW5vdWdoIA0KPj4gPj4gPiA+ Pj4+Pj4gaW5mb3JtYXRpb24gdG8NCj4+ID4+ID4gPj4+PiBhbGxvdw0KPj4gPj4gPiA+Pj4+Pj4g dGhlIHBhY2tldCB0byBiZSBwcm9wYWdhdGVkIGFsb25nIHRoZSBmdWxsIGxlbmd0aCBvZiB0aGUg DQo+PiA+PiA+ID4+Pj4+PiBjaGFpbiwgYW5kIG9wdGlvbmFsbHksIG90aGVyIG1ldGFkYXRhIHRo YXQgZW5oYW5jZXMgdGhlIA0KPj4gPj4gPiA+Pj4+Pj4gb3BlcmF0aW9uIG9mDQo+PiA+PiA+IG9u ZQ0KPj4gPj4gPiA+Pj4+Pj4gb3INCj4+ID4+ID4gPj4gbW9yZQ0KPj4gPj4gPiA+Pj4+Pj4gc2Vy dmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQW5kIHdoZXJl ICJ0cmFuc3BvcnQiIGNvdWxkIGNvbmNlaXZhYmx5IGJlIGFueSBvZiwgYnV0IA0KPj4gPj4gPiA+ Pj4+Pj4gbm90IGxpbWl0ZWQNCj4+ID4+ID4gPj4+PiB0bzoNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+PiAqIEV0aGVybmV0DQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0ICsgTExDMg0K Pj4gPj4gPiA+Pj4+Pj4gKiBFdGhlcm5ldCArIE1QTFMNCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJu ZXQgKyBJUCArIEdSRQ0KPj4gPj4gPiA+Pj4+Pj4gKiBFdGhlcm5ldCArIElQICtVRFANCj4+ID4+ ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQWxzbywgIm9yaWdpbmFs IiBpbiB0aGUgZGlhZ3JhbSBhYm92ZSBpcyBub3QgbWVhbnQgdG8gDQo+PiA+PiA+ID4+Pj4+PiBp bXBseSBpbW11dGFiaWxpdHksIGJ1dCByYXRoZXIgdG8gc3BlY2lmeSB0aGUgcGFja2V0IHRoYXQg DQo+PiA+PiA+ID4+Pj4+PiBpcw0KPj4gPj4gPiBwcm9wYWdhdGVkDQo+PiA+PiA+ID4+Pj4+PiBm cm9tIHByZWNlZGluZyBlbnRpdHkgdG8gc3VjY2VlZGluZyBlbnRpdHksIHByaW9yIHRvIA0KPj4g Pj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbi4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+ PiAgIFJvbg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogbnNjLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gDQo+PiA+PiA+ID4+Pj4+ PiBPbiBCZWhhbGYNCj4+ID4+ID4gPj4gT2YNCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhIE1hamVl DQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDY6NDYgUE0N Cj4+ID4+ID4gPj4+Pj4+IFRvOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4g Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENo YWluaW5nIEVuY2Fwc3VsYXRpb246IEEgDQo+PiA+PiA+ID4+Pj4+PiBkb2N1bWVudA0KPj4gPj53 aWxsDQo+PiA+PiA+ID4+Pj4+PiAgICBkZXNjcmliZSB0aGUgc2luZ2xlIHNlcnZpY2UtbGV2ZWwg ZGF0YSBwbGFuZSANCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+ID4+ID4gPj4gZm9y bWF0DQo+PiA+PiA+ID4+Pj4+PiBmb3INCj4+ID4+ID4gPj4+Pj4+ICAgIGNvbnZleWluZyB0aGUg c2VydmljZSBmdW5jdGlvbiBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBm dW5jdGlvbg0KPj4gPj4gPiA+Pj4+IHBhdGgsDQo+PiA+PiA+ID4+Pj4+PiAgICBhbmQgZm9yIGNv bW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIA0KPj4gPj4gPiA+Pj4+Pj4g bm9kZXMNCj4+IHRoYXQNCj4+ID4+ID4gPj4+Pj4+ICAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0 aW9ucy4gSXQgaXMgaW50ZW5kZWQgdGhhdCB0aGUNCj4+ID4+ID4gPj4+PiBlbmNhcHN1bGF0aW9u DQo+PiA+PiA+ID4+Pj4+PiAgICBiZSBhZ25vc3RpYyB0byB0aGUgbGF5ZXIgYXQgd2hpY2ggaXQg aXMgYXBwbGllZCBhbmQgDQo+PiA+PiA+ID4+Pj4+PiB0aGUgc2VydmljZQ0KPj4gPj4gPiA+Pj4+ IHRoYXQNCj4+ID4+ID4gPj4+Pj4+IGlzDQo+PiA+PiA+ID4+Pj4+PiAgICBiZWluZyBjb25zdHJ1 Y3RlZC4gVGhhdCBpcywgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiBtYXkgDQo+PiA+PiA+ID4+Pj4+ PiBiZQ0KPj4gPj4gPiB1c2VkDQo+PiA+PiA+ID4+IG9uDQo+PiA+PiA+ID4+Pj4+PiAgICBhIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yayBsYXllciANCj4+ID4+ ID4gPj4+Pj4+IG9yIGF0IGFueSBvdGhlcg0KPj4gPj4gPiA+Pj4+Pj4gICAgbGF5ZXIsIGFuZCB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4gPj4gPiA+PiBjb25z dHJ1Y3Rpb24NCj4+ID4+ID4gPj4+PiBvZg0KPj4gPj4gPiA+Pj4+Pj4gICAgc2VydmljZSBmdW5j dGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCj4+ID4+ID4gPj4+ Pj4+DQo+PiA+PiA+ID4+Pj4+PiBbU01dIFdoYXQgZG9lcyBpdCBtZWFuIGJ5IGEgc2luZ2xlIHNl cnZpY2UtbGV2ZWwgDQo+PiA+PiA+ID4+Pj4+PiBlbmNhcHN1bGF0aW9uLA0KPj4gPj4gPiBhDQo+ PiA+PiA+ID4+Pj4gbmV3DQo+PiA+PiA+ID4+Pj4+PiBlbmNhcHN1bGF0aW9uIGZvcm1hdA0KPj4g Pj4gPiA+Pj4+Pj4gICAgICAgICAgICBvciBhbiBhYmlsaXR5IHRvIHNlbGVjdCBvbmUgZW5jYXBz dWxhdGlvbiANCj4+ID4+ID4gPj4+Pj4+IGZvcm1hdCB0aGF0DQo+PiA+PiA+ID4+Pj4gZml0cw0K Pj4gPj4gPiA+Pj4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4+PiBuZWVkIGZvciBhIGdpdmVuIHNlcnZp Y2UgY2hhaW4/DQo+PiA+PiA+ID4+Pj4+PiAgICAgICAgICAgVGhlIGFiaWxpdHkgdG8gc2VsZWN0 IGEgc3BlY2lmaWMgZW5jYXBzdWxhdGlvbiANCj4+ID4+ID4gPj4+Pj4+IHdvdWxkIGJlDQo+PiA+ PiA+ID4+IGENCj4+ID4+ID4gPj4+Pj4+IG1hbmFnZW1lbnQgcGxhbmUgZGVjaXNpb24uDQo+PiA+ PiA+ID4+Pj4+PiAgICAgICAgICBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgZXhpc3RpbmcgZW5jYXBz dWxhdGlvbiANCj4+ID4+ID4gPj4+Pj4+IG1ldGhvZHMgdGhhdA0KPj4gPj4gPiA+Pj4+IGNhbg0K Pj4gPj4gPiA+Pj4+Pj4gcG9zc2libHkgYmUgcmV1c2VkIHRvIHByb3ZpZGUNCj4+ID4+ID4gPj4+ Pj4+ICAgICAgICAgIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMu IEkgaGF2ZQ0KPj4gPj4gPiBzZWVuDQo+PiA+PiA+ID4+Pj4+PiBtZW50aW9uDQo+PiA+PiA+ID4+ Pj4+PiBvZiBHUkUsIGZvciBIVFRQIGJhc2VkDQo+PiA+PiA+ID4+Pj4+PiAgICAgICAgICBhcHBs aWNhdGlvbnMgY29udGV4dHMgYXJlIHRyYW5zZmVycmVkIHZpYSBoZWFkZXJzLg0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gDQo+PiA+PiA+ID4+Pj4+PiBPbiBCZWhhbGYNCj4+ID4+ ID4gPj4gT2YNCj4+ID4+ID4gPj4+Pj4+IFRob21hcyBOYXJ0ZW4NCj4+ID4+ID4gPj4+Pj4+IFNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMTE6MDcgQU0NCj4+ID4+ID4gPj4+Pj4+ IFRvOiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFtuc2NdIEN1cnJlbnQg UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBIaS4N Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBDdXJyZW50IGNoYXJ0ZXIgY2FuIGJlIGZv dW5kIGF0DQo+PiA+PiA+ID4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9j aGFydGVyLQ0KPj4gPj4gPiA+Pj4+Pj4gaWV0Zi1zZmMvLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ ID4gPj4+Pj4+IEl0IGNvbnRhaW5zIHRoZSByZXZpc2VkIG1hbmFnZW1lbnQgdGV4dCBhcyB3ZWxs IGFzIA0KPj4gPj4gPiA+Pj4+Pj4gdXBkYXRlZA0KPj4gPj4gPiA+Pj4+IG1pbGVzdG9uZXMuDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQWxsIGtub3duIGlzc3VlcyBoYXZlIGJlZW4g YWRkcmVzc2VkLiBJZiB0aGVyZSBhcmUgYW55IA0KPj4gPj4gPiA+Pj4+Pj4gcmVtYWluaW5nDQo+ PiA+PiA+ID4+Pj4gaXNzdWVzLA0KPj4gPj4gPiA+Pj4+Pj4gcGxlYXNlIHNwZWFrIHVwIQ0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IENoYXJ0ZXIgY2hhcnRlci1pZXRmLXNmYy0wMC0w NA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IE5ldHdvcmtzLCBzZXJ2ZXJzLCBzdG9y YWdlIHRlY2hub2xvZ2llcywgYW5kIA0KPj4gPj4gPiA+Pj4+Pj4gYXBwbGljYXRpb25zLCBoYXZl IGFsbCB1bmRlcmdvbmUgc2lnbmlmaWNhbnQgY2hhbmdlIGluIA0KPj4gPj4gPiA+Pj4+Pj4gcmVj ZW50IHllYXJzIHdpdGggdGhlIGludHJvZHVjdGlvbg0KPj4gPj4gPiA+PiBvZg0KPj4gPj4gPiA+ Pj4+Pj4gdmlydHVhbGl6YXRpb24sIG5ldHdvcmsgb3ZlcmxheXMsIGFuZCBvcmNoZXN0cmF0aW9u Lg0KPj4gPj4gPiA+Pj4+Pj4gU2VydmljZQ0KPj4gPj4gPiA+PiBkZWxpdmVyeQ0KPj4gPj4gPiA+ Pj4+IGlzDQo+PiA+PiA+ID4+Pj4+PiBjdXJyZW50bHkgYm90aCBhIHRlY2huaWNhbCBhbmQgb3Jn YW5pemF0aW9uYWwgY2hhbGxlbmdlIA0KPj4gPj4gPiA+Pj4+Pj4gdGhhdA0KPj4gPj4gPiA+PiBp bnZvbHZlcw0KPj4gPj4gPiA+Pj4+Pj4gc2lnbmlmaWNhbnQgbW9kaWZpY2F0aW9uIHRvIHRoZSBu ZXR3b3JrIGNvbmZpZ3VyYXRpb24uDQo+PiA+PiA+ID4+Pj4+PiBTZXJ2aWNlcyBhcmUgdHlwaWNh bGx5IGltcGxlbWVudGVkIGJ5IHRoZSBvcmRlcmVkIA0KPj4gPj4gPiA+Pj4+Pj4gY29tYmluYXRp b24gb2YgYSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgDQo+PiA+PiA+ID4+ Pj4+PiBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcG9pbnRzIHdpdGhpbg0KPj4gPj4gPiA+PiB0aGUN Cj4+ID4+ID4gPj4+Pj4+IG5ldHdvcmsuIFRvZGF5LCBhIGNvbW1vbiBkZXBsb3ltZW50IG1vZGVs IGhhcyBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb25zIHBoeXNpY2FsbHkgaW5zZXJ0 ZWQgb24gdGhlIGRhdGEgZm9yd2FyZGluZyBwYXRoIA0KPj4gPj4gPiA+Pj4+Pj4gYmV0d2VlbiBj b21tdW5pY2F0aW5nIHBlZXJzLg0KPj4gPj4gPiA+Pj4+IEdvaW5nDQo+PiA+PiA+ID4+Pj4+PiBm b3J3YXJkLCBob3dldmVyLCB0aGVyZSBpcyBhIGRlc2lyZSB0byBtb3ZlIHRvIGEgDQo+PiA+PiA+ ID4+Pj4+PiBkaWZmZXJlbnQgbW9kZWwsDQo+PiA+PiA+ID4+Pj4gd2hlcmUNCj4+ID4+ID4gPj4+ Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBub3QgcmVxdWlyZWQgdG8gcmVzaWRlIG9uIHRoZSAN Cj4+ID4+ID4gPj4+Pj4+IGRlZmF1bHQgZGF0YQ0KPj4gPj4gPiA+PiBwYXRoDQo+PiA+PiA+ID4+ Pj4+PiBhbmQNCj4+ID4+ID4gPj4+Pj4+IHRyYWZmaWMgaXMgaW5zdGVhZCBzdGVlcmVkIHRocm91 Z2ggc2VydmljZXMsIHdoZXJldmVyIA0KPj4gPj4gPiA+Pj4+Pj4gdGhleSBhcmUNCj4+ID4+ID4g Pj4+PiBkZXBsb3llZC4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBGb3IgYSBnaXZl biBzZXJ2aWNlLCB0aGUgYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSByZXF1aXJlZCANCj4+ID4+ID4g Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCB0aGUgb3JkZXIgaW4gd2hpY2ggdGhleSBhcmUg dG8gYmUgDQo+PiA+PiA+ID4+Pj4+PiBhcHBsaWVkIGlzDQo+PiA+PiA+IGNhbGxlZA0KPj4gPj4g PiA+Pj4+Pj4gYSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpLiBTaW5jZSBhIGdpdmVuIHNl cnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbiBtYXkgYmUgYXZhaWxhYmxlIG9uIG1vcmUg dGhhbiBvbmUgbm9kZSB3aXRoaW4gYSANCj4+ID4+ID4gPj4+Pj4+IG5ldHdvcmssIGEgU2Vydmlj ZSBGdW5jdGlvbiBDaGFpbiBpcyBpbnN0YW50aWF0ZWQNCj4+ID4+ID4gPj4+PiB2aWENCj4+ID4+ ID4gPj4+Pj4+IHRoZSBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0 YW5jZXMgYW5kIA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhl eSBhcmUgcHJvdmlkZWQsIHRoZXJlYnkgDQo+PiA+PiA+ID4+Pj4+PiBmb3JtaW5nIGEgc2Vydmlj ZSB0b3BvbG9neToNCj4+ID4+ID4gPj4+Pj4+IHRoaXMgaXMgY2FsbGVkIGEgU2VydmljZSBGdW5j dGlvbiBQYXRoLiBUaGUgc2VydmljZSANCj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9ucw0KPj4gPj4g PiBtYXkNCj4+ID4+ID4gPj4+Pj4+IGJlIGFwcGxpZWQgYXQgYSBzcGVjaWZpYyBsYXllciB3aXRo aW4gdGhlIG5ldHdvcmsgDQo+PiA+PiA+ID4+Pj4+PiBwcm90b2NvbCBzdGFjaw0KPj4gPj4gPiA+ Pj4+IChuZXR3b3JrDQo+PiA+PiA+ID4+Pj4+PiBsYXllciwgYXBwbGljYXRpb24gbGF5ZXIsIGV0 Yy4pLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFRoZSBTZXJ2aWNlIEZ1bmN0aW9u IENoYWluaW5nIChTRkMpIHdvcmtpbmcgZ3JvdXAgd2lsbCANCj4+ID4+ID4gPj4+Pj4+IGRldmVs b3AgbmV3IGFwcHJvYWNoZXMgdG8gc2VydmljZSBkZWxpdmVyeSBhbmQgZGVwbG95bWVudC4NCj4+ ID4+ID4gPj4+Pj4+IEl0IHdpbGwgcHJvZHVjZSBhIGZyYW1ld29yayBmb3Igc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZyANCj4+ID4+ID4gPj4+Pj4+IHRoYXQgaW5jbHVkZXMgdGhlIG5lY2Vzc2Fy eSBwcm90b2NvbHMNCj4+ID4+ID4gPj4+PiBvcg0KPj4gPj4gPiA+Pj4+Pj4gcHJvdG9jb2wgZXh0 ZW5zaW9ucyB0byBjb252ZXkgdGhlIHNlcnZpY2UgcGF0aCBhbmQgDQo+PiA+PiA+ID4+Pj4+PiBz ZXJ2aWNlIHBhdGggaW5mb3JtYXRpb24gdG8gbm9kZXMgdGhhdCBpbXBsZW1lbnQgc2VydmljZSAN Cj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9ucywgYXMgd2VsbA0KPj4gPj4gPiBhcw0KPj4gPj4gPiA+ Pj4+Pj4gbWVjaGFuaXNtcyBmb3Igc3RlZXJpbmcgdHJhZmZpYyB0aHJvdWdoIHNlcnZpY2UgZnVu Y3Rpb25zLg0KPj4gPj4gPiA+Pj4+Pj4gVGhlDQo+PiA+PiA+ID4+Pj4gd29ya2luZw0KPj4gPj4g PiA+Pj4+Pj4gZ3JvdXAgd2lsbCBhbHNvIGV4YW1pbmUgd2hhdCBpbmZvcm1hdGlvbiBuZWVkcyB0 byBiZSANCj4+ID4+ID4gPj4+Pj4+IGdhdGhlcmVkIGZyb20NCj4+ID4+ID4gPj4+PiB0aGUNCj4+ ID4+ID4gPj4+Pj4+IG5ldHdvcmsgYW5kIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2Yg c2VydmljZSANCj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9uDQo+PiA+PiA+ID4+IGNoYWluaW5nDQo+ PiA+PiA+ID4+Pj4+PiBhbmQNCj4+ID4+ID4gPj4+Pj4+IGhvdyB0aGF0IGluZm9ybWF0aW9uIG1h eSBiZSBtYWRlIGF2YWlsYWJsZSB0byBub2RlcyB0aGF0IA0KPj4gPj4gPiA+Pj4+Pj4gaW1wbGVt ZW50DQo+PiA+PiA+ID4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucy4N Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBTcGVjaWZpY2FsbHksIHRoZSBTRkMgV0cg aXMgY2hhcnRlcmVkIHRvIGRlbGl2ZXIgdGhlDQo+PiBmb2xsb3dpbmc6DQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gMSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IFRoaXMgZG9jdW1lbnQgd2ls bCBwcm92aWRlIGEgDQo+PiA+PiA+ID4+Pj4+PiBzdW1tYXJ5IG9mDQo+PiA+PiA+IHRoZQ0KPj4g Pj4gPiA+Pj4+Pj4gICAgcHJvYmxlbSBzcGFjZSB0byBiZSBhZGRyZXNzZWQgYnkgdGhlIFdHIGlu Y2x1ZGluZyANCj4+ID4+ID4gPj4+Pj4+IGV4YW1wbGUNCj4+ID4+ID4gaGlnaC0NCj4+ID4+ID4g Pj4+Pj4+ICAgIGxldmVsIHVzZSBjYXNlcy4gQWRkaXRpb25hbGx5LCB0aGUgV0cgd2lsbCBub3Jt YWxpemUNCj4+ID4+ID4gPj4gbm9tZW5jbGF0dXJlDQo+PiA+PiA+ID4+Pj4+PiAgICBhbmQgZGVm aW5pdGlvbnMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcuDQo+PiA+PiA+ID4+Pj4+Pg0K Pj4gPj4gPiA+Pj4+Pj4gMikgQXJjaGl0ZWN0dXJlOiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlk ZSBhIGRlc2NyaXB0aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gb2YNCj4+ID4+dGhlDQo+PiA+PiA+ID4+ Pj4+PiAgICBhcmNoaXRlY3R1cmFsIGJ1aWxkaW5nIGJsb2NrcyBhbmQgdGhlaXIgcmVsYXRpb25z aGlwcw0KPj4gPj4gPiBpbmNsdWRpbmcNCj4+ID4+ID4gPj4+Pj4+ICAgIGludGVyY29ubmVjdGlv biwgcGxhY2VtZW50IG9mIGNhcGFiaWxpdGllcywgbWFuYWdlbWVudCwNCj4+ID4+ID4gPj4+Pj4+ ICAgIGRpYWdub3N0aWNzLCBkZXNpZ24gYW5hbHlzaXMsIGFuZCBzZWN1cml0eSBtb2RlbHMsIGFz IA0KPj4gPj4gPiA+Pj4+Pj4gd2VsbA0KPj4gPj5hcw0KPj4gPj4gPiA+Pj4+Pj4gICAgcmVxdWly ZW1lbnRzIG9uIHRoZSBwcm90b2NvbCBtZWNoYW5pc21zLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ ID4gPj4+Pj4+IDMpIEdlbmVyaWMgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBFbmNhcHN1bGF0 aW9uOiBBIA0KPj4gPj4gPiA+Pj4+Pj4gZG9jdW1lbnQNCj4+ID4+ID4gd2lsbA0KPj4gPj4gPiA+ Pj4+Pj4gICAgZGVzY3JpYmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgDQo+ PiA+PiA+ID4+Pj4+PiBlbmNhcHN1bGF0aW9uDQo+PiA+PiA+ID4+IGZvcm1hdA0KPj4gPj4gPiA+ Pj4+Pj4gZm9yDQo+PiA+PiA+ID4+Pj4+PiAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rp b24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb24NCj4+ID4+ ID4gPj4+PiBwYXRoLA0KPj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNv bnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiANCj4+ID4+ID4gPj4+Pj4+IG5vZGVzDQo+PiB0aGF0 DQo+PiA+PiA+ID4+Pj4+PiAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMuIEl0IGlzIGlu dGVuZGVkIHRoYXQgdGhlDQo+PiA+PiA+ID4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4gPj4gPiA+Pj4+ Pj4gICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQgYW5k IA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIHNlcnZpY2UNCj4+ID4+ID4gPj4+PiB0aGF0DQo+PiA+PiA+ ID4+Pj4+PiBpcw0KPj4gPj4gPiA+Pj4+Pj4gICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMs IHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gbWF5IA0KPj4gPj4gPiA+Pj4+Pj4gYmUNCj4+ID4+ID4g dXNlZA0KPj4gPj4gPiA+PiBvbg0KPj4gPj4gPiA+Pj4+Pj4gICAgYSBzZXJ2aWNlIGZ1bmN0aW9u IHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgDQo+PiA+PiA+ID4+Pj4+PiBvciBh dCBhbnkgb3RoZXINCj4+ID4+ID4gPj4+Pj4+ICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBz dWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUNCj4+ID4+ID4gPj4gY29uc3RydWN0aW9uDQo+PiA+ PiA+ID4+Pj4gb2YNCj4+ID4+ID4gPj4+Pj4+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMgcmVn YXJkbGVzcyBvZiB0aGUgYWN0dWFsIHNlcnZpY2UuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+ Pj4+Pj4gNCkgQ29udHJvbCBQbGFuZSBNZWNoYW5pc21zOiBBIHNldCBvZiBkb2N1bWVudHMgd2ls bCBiZQ0KPj4gPj4gPiBkZXZlbG9wZWQgdG8NCj4+ID4+ID4gPj4+Pj4+ICAgIGRlc2NyaWJlIHJl cXVpcmVtZW50cyBhbmQgcHJvdG9jb2xzIG5lY2Vzc2FyeSB0byANCj4+ID4+ID4gPj4+Pj4+IGNv bnZleQ0KPj4gPj4gPiA+Pj4+IGluZm9ybWF0aW9uDQo+PiA+PiA+ID4+Pj4+PiAgICB0byBzZXJ2 aWNlIGZ1bmN0aW9uIGltcGxlbWVudGF0aW9uIHBvaW50cy4gV2hlcmUgDQo+PiA+PiA+ID4+Pj4+ PiBwb3NzaWJsZSwNCj4+ID4+ID4gPj4+PiBleGlzdGluZw0KPj4gPj4gPiA+Pj4+Pj4gICAgSUVU RiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIGFuZCBleHRlbmRlZC4gQWxsIHByb3RvY29sDQo+PiA+ PiA+ID4+IGV4dGVuc2lvbnMNCj4+ID4+ID4gPj4+Pj4+ICAgIHdvcmsgc2hvdWxkIGJlIGNhcnJp ZWQgb3V0IGluIHRoZSB3b3JraW5nIGdyb3VwcyANCj4+ID4+ID4gPj4+Pj4+IHJlc3BvbnNpYmxl IGZvcg0KPj4gPj4gPiA+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgcHJvdG9jb2xzIGJlaW5n IG1vZGlmaWVkIGluIGNvb3JkaW5hdGlvbiB3aXRoIHRoaXMgDQo+PiA+PiA+ID4+Pj4+PiB3b3Jr aW5nDQo+PiA+PiA+ID4+IGdyb3VwLA0KPj4gPj4gPiA+Pj4+Pj4gYnV0DQo+PiA+PiA+ID4+Pj4+ PiAgICBtYXkgYmUgZG9uZSBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgYWZ0ZXIgYWdyZWVtZW50IHdp dGggDQo+PiA+PiA+ID4+Pj4+PiBhbGwNCj4+ID4+ID4gdGhlDQo+PiA+PiA+ID4+Pj4+PiAgICBy ZWxldmFudCBXRyBjaGFpcnMgYW5kIHJlc3BvbnNpYmxlIEFEcy4NCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+PiA1KSBNYW5hZ2VhYmlsaXR5OiBXb3JrIG9uIHRoZSBtYW5hZ2VtZW50IGFu ZCANCj4+ID4+ID4gPj4+Pj4+IGNvbmZpZ3VyYXRpb24gb2YNCj4+ID4+ID4gPj4gc2VydmljZQ0K Pj4gPj4gPiA+Pj4+Pj4gICAgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2YgU0ZDIGNvbXBvbmVudHMg d2lsbCBjZXJ0YWlubHkgDQo+PiA+PiA+ID4+Pj4+PiBiZQ0KPj4gPj4gPiBuZWVkZWQsDQo+PiA+ PiA+ID4+Pj4+PiAgICBidXQgZmlyc3QgbmVlZHMgdG8gYmUgYmV0dGVyIHVuZGVyc3Rvb2QgYW5k IHNjb3BlZC4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBQcm9wb3NlZCBNaWxlc3Rv bmVzDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQXByIDIwMTQgU3VibWl0IHRvIElF U0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudChzKSANCj4+ID4+ID4gPj4+Pj4+IGRlZmluaW5nIHRo ZQ0KPj4gPj4gPiA+Pj4+IHByb2JsZW0NCj4+ID4+ID4gPj4+Pj4+IHN0YXRlbWVudCBhbmQgY29y ZSB1c2UgY2FzZXMgZm9yIFNlcnZpY2UgRnVuY3Rpb24gDQo+PiA+PiA+ID4+Pj4+PiBDaGFpbmlu Zw0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IE1heSAyMDE0IENvbnN1bHQgd2l0aCBP UFMgQXJlYSBvbiBwb3NzaWJsZSBjaGFydGVyIA0KPj4gPj4gPiA+Pj4+Pj4gbW9kaWZpY2F0aW9u cyBmb3IgbWFuYWdlbWVudCBhbmQgY29uZmlndXJhdGlvbiBvZiBTRkMgDQo+PiA+PiA+ID4+Pj4+ PiBjb21wb25lbnRzDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gSmFuIDIwMTUgU3Vi bWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudCBkZWZpbmluZyANCj4+ID4+ID4gPj4+ Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+IGFyY2hpdGVjdHVyZQ0KPj4gPj4gPiA+Pj4+Pj4gZm9yIFNG Qw0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNH IHJlcXVpcmVtZW50cyBmb3IgYSBnZW5lcmljIA0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZyBlbmNhcHN1bGF0aW9uIHByb3RvY29sDQo+PiA+PiA+ID4+Pj4+Pg0KPj4g Pj4gPiA+Pj4+Pj4gQXVnIDIwMTUgU3VibWl0IHRvIElFU0cgU3RhbmRhcmRzIFRyYWNrIGRvY3Vt ZW50IA0KPj4gPj4gPiA+Pj4+Pj4gc3BlY2lmeWluZyB0aGUNCj4+ID4+ID4gPj4+PiBnZW5lcmlj DQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGhlYWRlciBlbmNhcHN1 bGF0aW9uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFRob21hcw0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+ PiA+ID4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ID4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPiA+Pj4+Pj4gbnNjIG1haWxp bmcgbGlzdA0KPj4gPj4gPiA+Pj4+Pj4gbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4gPj4gPiA+Pj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gPj4+ Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gPj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4gPj4g PiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ ID4gPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+ID4gPj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiA+Pj4+PiBuc2NAaWV0Zi5v cmcNCj4+ID4+ID4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u c2MNCj4+ID4+ID4gPg0KPj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gPj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+IG5zY0BpZXRm Lm9yZw0KPj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K Pj4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gPj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4gPj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPiBuc2MgbWFp bGluZyBsaXN0DQo+PiA+PiA+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiBuc2NAaWV0 Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uc2MgbWFpbGlu ZyBsaXN0DQo+bnNjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uc2MNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpuc2MgbWFpbGluZyBsaXN0DQpuc2NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo= From david.i.allan@ericsson.com Wed Nov 13 07:45:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737B021E80AE for ; Wed, 13 Nov 2013 07:45:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.872 X-Spam-Level: X-Spam-Status: No, score=-1.872 tagged_above=-999 required=5 tests=[AWL=0.727, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBN08Y2-9GSU for ; Wed, 13 Nov 2013 07:45:27 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB021E8063 for ; Wed, 13 Nov 2013 07:45:27 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-d8-52839e8d6ae8 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 68.4E.04556.D8E93825; Wed, 13 Nov 2013 16:45:18 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Wed, 13 Nov 2013 10:45:17 -0500 From: David Allan I To: "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO4Fj+iBkfX7fLf02lvFYuCvTIzZojTSqw Date: Wed, 13 Nov 2013 15:45:16 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUyuXRPuG7fvOYgg69nJSw2TFnCZnF83342 ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJXx8n8DS8Gf5cwVF34aNzD2zGXuYuTkkBAw kdiy9xMbhC0mceHeeiCbi0NI4AijxJ2JXSwgCSGB5YwSnf81QWw2AQOJPf+/MILYIgK+Evcu 9IM1CwtESRxuecIGEY+WeD7/AguEbSSxfOptdhCbRUBV4u7KA0wgNi9Q78PGN0wQy2YySlx/ /wWsgVMgTOL47d1gNiPQRd9PrQFrYBYQl7j1ZD4TxKUCEkv2nIf6QFTi5eN/rBC2ssSSJ/uB ejmA6jUl1u/Sh2hVlJjS/ZAdYq+gxMmZT1gmMIrOQjJ1FkLHLCQds5B0LGBkWcXIUVqcWpab bmS4iREYDcck2Bx3MC74ZHmIUZqDRUmc98tb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFIN jKUTPz6LWCGy4TafV639sznMr/XOsdyuk1j/K73KzUTUr+aOR7P58anLphkdv5Rg8fnbNKtV 30UqrmX6BSupVi9UypylphxpOMPg9NRk9aO8W/ktap+qV3IefvxkznmN3vlbm85ubtqTnre6 bAuP+i63r08UmGP3ms667dtZ7L7+9cVj4Xy9FUosxRmJhlrMRcWJAE1CUbhUAgAA Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 15:45:32 -0000 SEkgSG9uZ3l1Og0KDQpJIHRoaW5rIHdlIHdpbGwgaGF2ZSBzY2VuYXJpb3Mgd2hlcmUgYSBzZXJ2 aWNlIGZ1bmN0aW9uIGFwcGVhcnMgaW4gbW9yZSB0aGFuIG9uZSBjaGFpbiwgYXMgd291bGQgYmUg dGhlIGNhc2UsIGZvciBleGFtcGxlLCBpZiBzb21lIGZsb3dzIGNvdWxkIGR5bmFtaWNhbGx5IGJ5 cGFzcyBEUEkgYnV0IHN0aWxsIG5lZWRlZCB0byB0cmFuc2l0IGEgY29tbW9uIHNldCBvZiBzdGF0 ZWZ1bCBzZXJ2aWNlIGZ1bmN0aW9ucy4uLg0KDQpPbmNlIHlvdSBwb3N0dWxhdGUgYSBzZXJ2aWNl IGZ1bmN0aW9uIGluc3RhbmNlIGFwcGVhcmluZyBpbiBtb3JlIHRoYW4gb25lIGNoYWluLCBpdCBz ZWVtcyBhcnRpZmljaWFsbHkgcmVzdHJpY3RpdmUgbm90IHRvIHBlcm1pdCBzdWNoIGEgZnVuY3Rp b24gdG8gYWxzbyBpbXBsZW1lbnQgYnJhbmNoaW5nLCBhbGwgdGhlIGNvbnRyb2wgc3RydWN0dXJl cyB3b3VsZCBhbHJlYWR5IGJlIHRoZXJlLg0KDQpSZ2RzDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBIb25neXUgTGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBo dWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIwMTMgMjoxMiBBTQ0K VG86IERhdmlkIEFsbGFuIEk7IG5zY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtuc2NdIEZXOiBy ZSBjbGFzc2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50IFByb3Bvc2VkIFNGQyBj aGFydGVyDQoNCk1heSBJIHN1Z2dlc3Qgc3VtbWFyeSBvZiBteSB2aWV3cyBoZXJlOg0KDQoxLiBC cmFuY2ggaXMgYSBzb3J0IG9mIHVzZSBjYXNlIG9yIHNjZW5hcmlvLCB3aGlsZSByZWNsYXNzaWZp Y2F0aW9uIGlzIGEgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLg0KMi4gU2VydmljZSBGdW5jdGlv bnMgc2hvdWxkIGJlIGRlY291cGxlZCB3aXRoIHRoZSBjaGFpbiBpdHNlbGYuDQoJTWVhbmluZywg YSBTRiBzaGFsbCBub3QgKmRpcmVjdGx5KiBpbXBhY3QgdGhlIGZvcndhcmRpbmcgb2YgcGFja2V0 cyBpbiBhIGNoYWluLiBCcmFuY2hpbmcgc2hvdWxkIGJlIHBlcmZvcm1lZCBieSBjaGFpbiBmb3J3 YXJkaW5nIG5vZGVzLCBwb3NzaWJseSB1bmRlciBjb250cm9sIG9mIGEgY29udHJvbCBub2RlLiBU aGUgcmVhc29uIGZvciB0aGlzIGlzIGluIE5GViB3b3JsZCwgc2VydmljZSBmdW5jdGlvbnMgbWF5 IGNvbWUgZnJvbSBhIHRoaXJkIHBhcnR5LCB3aGlsZSBjaGFpbiBpcyBwcm92aWRlZCBieSB0aGUg aW5mcmFzdHJ1Y3R1cmUgb2YgdGhlIG5ldHdvcmsuIFRoZXJlIG11c3QgYmUgYSBjdXNoaW9uIGF2 b2lkaW5nIGEgc2VydmljZSBmdW5jdGlvbiBvcGVyYXRpbmcgaW5mcmFzdHJ1Y3R1cmUgZGlyZWN0 bHkuDQozLiAoUmUpY2xhc3NpZmljYXRpb24gaXMgYmFzZWQgb24gaW5mbyBpbiBhIHBhY2tldC4N CglUaGlzIGlzIHZlcnkgZ2VuZXJhbC4gU3VjaCBpbmZvIGNvdWxkIGJlIEwyfkw3IGRlcml2ZWQg ZnJvbSBhIHVzZXIncyBwYWNrZXQsIGFzIHdlbGwgYXMgc29tZSBpbmZvIGxpa2UgbWV0YWRhdGEg aW4gYSBTRkMgaGVhZGVyLiBBcyBjbGFzc2lmaWNhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgb2YgU0ZD LCB3ZSBkb24ndCBoYXZlIHRvIHByb3ZpZGUgdG9vIG11Y2ggZGV0YWlscyBvZiBob3cgdG8gZG8g Y2xhc3NpZmljYXRpb24uDQo0LiBDaGFpbiBzZWdtZW50cyBzdGl0Y2hpbmcgaXMgcmVsYXRpdmVs eSBhIGVhc3kgd2F5IGZvciBicmFuY2hpbmcuIENvbXBhcmVkIHdpdGggY2hhaW5zIGFuZCBzdWJj aGFpbnMsIHdoaWNoIG1heSByZXF1aXJlIGEgbW9yZSBjb21wbGV4IGhlYWRlciBhbmQgZm9yd2Fy ZGluZyBjYXBhYmlsaXRpZXMuDQpNeSB0d28gY2VudHMuDQpIb25neXUNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBBbGxhbiBJDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDEzLCAyMDEzIDM6MDQgQU0NClRvOiBuc2NAaWV0Zi5vcmcNClN1YmplY3Q6 IFtuc2NdIEZXOiByZSBjbGFzc2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50IFBy b3Bvc2VkIFNGQyBjaGFydGVyDQoNCkhpOg0KKHJlc2VuZCB3aXRoIHJlY2lwaWVudCBsaXN0IGNs ZWFuZWQgdXApDQoNCkkgYWdyZWUgd2UgYXJlIGRpc2N1c3NpbmcgbXVsdGlwbGUgY29uY2VwdHMs IGNsYXNzaWZpY2F0aW9uIGFuZCBmbG93LXN1YnNldHRpbmcuIFBlcmhhcHMgbW9yZSA7LSkNCg0K RGVmaW5pbmcgYSBmbG93IHN1YnNldCBjYW4gYmUgYSByZXN1bHQgb2YgY2xhc3NpZmljYXRpb24s IGJ1dCBpdCBpcyBub3QgdGhlIGV4Y2x1c2l2ZSBtZWNoYW5pc20uIEJyYW5jaGluZyBpcyBhIG1l Y2hhbmlzbSBieSB3aGljaCBmbG93IHN1YnNldHMgYXJlIGV4cG9zZWQgYW5kIG1hcHBlZCB0byBh IHNldCBvZiBzdWJjaGFpbnMgc3VjaCB0aGF0IGl0IGNhbiBiZSBpZGVudGlmaWVkIGluIHRoZSBk YXRhcGxhbmUuLi4NCg0KVGhhdCdzIHRoZSB2aWV3IGZyb20gaGVyZQ0KRGF2ZQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpu c2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIExha2UgKGRsYWtlKQ0KU2Vu dDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTA6NTEgQU0NClRvOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKTsgS2V2aW4gSiBNYTsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBSb24gUGFy a2VyOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQpDYzogVGhvbWFzIE5hcnRlbjsg bnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQg UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KVW5kZXJzdG9vZCAtIG1heWJlIGp1c3QgYSBsaXR0bGUg bG9jYWxpc2VkIHdhcm1pbmcgb2YgdGhlIHNlYSB0aGVuID8gICBCdXQgSSBzdGlsbCB0aGluayB3 ZSBuZWVkIHRvIGNvbnNpZGVyIHdoZXJlIGFuZCBob3cgcG9saWN5IGlzIGRlZmluZWQvc2V0IGV2 ZW4gZm9yIHRoZSBzaW5nbGUtZG9tYWluIGluc3RhbmNlLg0KDQpJIGRvbid0IHRoaW5rIHdlIGNh biBhc3N1bWUgdGhhdCBhbnkgTDEtMyBkZXZpY2Ugd2lsbCBiZSBhYmxlIHRvIGRldGVybWluZSBt dWNoIHVzZWZ1bCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBkYXRhLXBsYW5lLg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikNClNlbnQ6IDEy IE5vdmVtYmVyIDIwMTMgMTA6NDQNClRvOiBEYXZpZCBMYWtlIChkbGFrZSk7IEtldmluIEogTWE7 IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsgTGluZGEgRHVuYmFyOyBIb25n eXUgTGkgKEp1bGlvKQ0KQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VtYW5kcmEg TWFqZWUNClN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoN CkFzIGRpc2N1c3NlZCBkdXJpbmcgdGhlIEJPRiBvdXIgaW5pdGlhbCB3b3JrIGlzIHNpbmdsZSBh ZG1pbmlzdHJhdGl2ZSBkb21haW4gZm9yIHNvbWUgb2YgdGhlIHZlcnkgcmVhc29ucyB5b3UgcG9p bnQgb3V0LiBXZSBuZWVkIHRvIGtlZXAgZm9jdXNlZCB3aXRob3V0IHRyeWluZyB0byBib2lsIHRo ZSBvY2VhbiByaWdodCBvZmYgdGhlIGJhdC4NCg0KT24gMTEvMTIvMTMgMTozNiBQTSwgIkRhdmlk IExha2UgKGRsYWtlKSIgPGRsYWtlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5FeGFjdGx5LiAgQnV0 IGhvdyBjYW4gbmV0d29yay1jb21wb25lbnRzICJ0ZXJtaW5hdGUiIGFuIGFwcGxpY2F0aW9uID8/ Pz8NCj4NCj5JIHRoaW5rIHdlIG5lZWQgYSBnb29kIHVuZGVyc3RhbmRpbmcgb2YgYSByZWN1cnNp dmUgcG9saWN5IG1lY2hhbmlzbSANCj4ocmVjdXJzaXZlIGJlY2F1c2UgYSB1c2VyLWxhbmQgYXBw bGljYXRpb24gd2lsbCByaWRlIHdpdGggYSBzcGVjaWZpYyANCj5wb2xpY3kgYWNyb3NzIHBvdGVu dGlhbGx5IGRpZmZlcmVudCBzZXRzIG9mIGNhcnJpZXIgcG9saWNpZXMpLg0KPg0KPkkgaGF0ZSB0 byBicmluZyB0aGlzIHVwIG5vdywgYnV0IHdlIGFsc28gbmVlZCB0byB0aGluayBhYm91dCB0aGlz IA0KPm11bHRpLWRvbWFpbiBpc3N1ZSAtIGlmIEkgc2V0IGEgcG9saWN5IGFzIGEgdXNlciwgY2hh bmNlcyBhcmUgSSB3aWxsIGJlIA0KPmNyb3NzaW5nIHNldmVyYWwgZG9tYWluIGJvdW5kYXJpZXMu ICBBcmUgd2UgZXhwZWN0aW5nIHRoZSBzZXJ2aWNlIA0KPmhlYWRlcnMgdG8gZGVmaW5lIHRoZSBz ZXJ2aWNlIGNoYWluaW5nIGZvciB0aGUgZHVyYXRpb24gb2YgdGhlIGVudGlyZSANCj5mbG93IGFj cm9zcyBhbGwgZG9tYWlucywgb3IganVzdCBhY3Jvc3MgYSBzaW5nbGUgb25lID8NCj4NCj5JbiB3 aGljaCBjYXNlLCBkbyBJIGhhdmUgdG8gcmUtc2V0IHBvbGljeSBhcyBJIHRyYXZlcnNlIGRvbWFp bnMgIGFuZA0KPndoZXJlIGRvZXMgdGhhdCBwb2xpY3kgZ2V0IHNldCA/ICAgSXQgd291bGQgYmUg bXVjaCBiZXR0ZXIgdG8gc2V0IHBvbGljeQ0KPm9uY2UgYmFzZWQgb24gTDUtNyBuZWVkcywgYW5k IGhhdmUgdGhhdCBpbnN0YW50aWF0ZWQgYWNyb3NzIHRoZSANCj5tdWx0aXBsZSBkb21haW5zLg0K Pg0KPkFnYWluLCB0aGlzIGFwcGVhcnMgdG8gYmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLCBi dXQgcHJldHR5IHJlbGV2YW50IA0KPnRvIGhvdyBpdCB3b3VsZCBvcGVyYXRlIGluIHRoZSByZWFs IHdvcmxkLg0KPg0KPkRhdmlkDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9t OiBLZXZpbiBKIE1hIFttYWlsdG86a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCj5TZW50OiAx MiBOb3ZlbWJlciAyMDEzIDEwOjI3DQo+VG86IERhdmlkIExha2UgKGRsYWtlKTsgU3VyZW5kcmEg S3VtYXIgKHNta3VtYXIpOyBSb24gUGFya2VyOyBMaW5kYSANCj5EdW5iYXI7IEhvbmd5dSBMaSAo SnVsaW8pDQo+Q2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VtYW5kcmEgTWFqZWUN Cj5TdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPg0KPj4g SW4gdGhvc2UgY2lyY3Vtc3RhbmNlcywgb25seSB0aGUgZW5kIGFwcGxpY2F0aW9ucyB0aGVtc2Vs dmVzIG9yIGEgDQo+PiByZWFzb25hYmx5IGJyb2FkLWJydXNoZWQgY2xhc3NpZmljYXRpb24gKHJl YWxseSB0cmFmZmljIHN0ZWVyaW5nIA0KPj4gYmFzZWQgb24gd2hhdCB3ZSBjYW4gc2VlIGF0IGlu Z3Jlc3MpIGlzIGdvaW5nIHRvIGJlIHVzZWZ1bCAtIGlzIFRIQVQgDQo+PiB3aGF0IHdlJ3JlIGFp bWluZyBmb3IgaGVyZSA/DQo+DQo+SSB3b3VsZCBjZXJ0YWlubHkgaG9wZSBub3QsIGJ1dCB0aGF0 IGhhcyBiZWVuIG15IGNvbmNlcm4gYXMgd2VsbC4NCj5BcHBsaWNhdGlvbiBsYXllciB0ZXJtaW5h dGlvbiBhbmQgcmUtY2xhc3NpZmljYXRpb24gc2VlbXMgYSBtdXN0Pw0KPg0KPi0tICBLZXZpbiBK LiBNYQ0KPg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IERhdmlkIExh a2UgKGRsYWtlKSBbbWFpbHRvOmRsYWtlQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFR1ZXNkYXksIE5v dmVtYmVyIDEyLCAyMDEzIDE6MDAgUE0NCj4+IFRvOiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7 IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IExpbmRhIER1bmJhcjsgDQo+PiBIb25neXUgTGkgKEp1 bGlvKQ0KPj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VtYW5kcmEgTWFqZWUN Cj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pg0K Pj4gUG9saWN5IG1heSBiZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBTRkMsIGJ1dCB3aXRob3V0 IHN0cm9uZyBtYXBwaW5nIA0KPj4gYmV0d2VlbiBQb2xpY3kgYW5kIHRoZSBpbnNlcnRlZCBTZXJ2 aWNlIEhlYWRlcihzKSwgd2UgcnVuLXRoZS1yaXNrIG9mIA0KPj4gbGltaXRpbmcgdGhlIGVmZmlj YWN5IG9mIHRoZSBwcm90b2NvbCBJTU8uDQo+Pg0KPj4gRm9yIGV4YW1wbGUsIGluIGEgd29ybGQg d2hlcmUgdGhlIG5ldHdvcmsgaGFzICJnb25lIGRhcmssIiAoYXMgcGVyIA0KPj4gdGhlIElFVEYg VGVjaG5pY2FsIFBsZW5hcnkgPzotKSApIHdoYXQgaXMgb3VyIGFiaWxpdHkgdG8gZGV0ZXJtaW5l IA0KPj4gcG9saWN5IGJhc2VkIG9uIERQSSBvZiBwYWNrZXRzLWluLWZsaWdodCA/DQo+Pg0KPj4g SW4gdGhvc2UgY2lyY3Vtc3RhbmNlcywgb25seSB0aGUgZW5kIGFwcGxpY2F0aW9ucyB0aGVtc2Vs dmVzIG9yIGEgDQo+PiByZWFzb25hYmx5IGJyb2FkLWJydXNoZWQgY2xhc3NpZmljYXRpb24gKHJl YWxseSB0cmFmZmljIHN0ZWVyaW5nIA0KPj4gYmFzZWQgb24gd2hhdCB3ZSBjYW4gc2VlIGF0IGlu Z3Jlc3MpIGlzIGdvaW5nIHRvIGJlIHVzZWZ1bCAtIGlzIFRIQVQgDQo+PiB3aGF0IHdlJ3JlIGFp bWluZyBmb3IgaGVyZSA/DQo+Pg0KPj4gRGF2aWQNCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPj4gU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpDQo+ PiBTZW50OiAxMiBOb3ZlbWJlciAyMDEzIDA5OjI2DQo+PiBUbzogUm9uIFBhcmtlcjsgS2V2aW4g SiBNYTsgTGluZGEgRHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKQ0KPj4gQ2M6IFRob21hcyBOYXJ0 ZW47IG5zY0BpZXRmLm9yZzsgU3VtYW5kcmEgTWFqZWUNCj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBD dXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pg0KPj4gUm9uLA0KPj4NCj4+IENsYXNzaWZp Y2F0aW9uIG9mIHRyYWZmaWMgaXMgd2VsbCB1bmRlcnN0b29kIGFuZCB3ZSBkbyBub3QgaGF2ZSB0 byANCj4+IHJlZGVmaW5lIGl0IC0gaXQncyBiZWVuIGFyb3VuZCBmb3IgYWxsIHRoZSB0aW1lIG1p ZGRsZSBib3hlcyBoYXZlIA0KPj4gYmVlbiBvciBmb3IgdGhhdCBtYXR0ZXIgdGhlIEwyL0wzIGRl dmljZXMuIEFsbCB3ZSBhcmUgdGFsa2luZyBhYm91dCANCj4+IGlzIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoZSBjbGFzc2lmaWNhdGlvbiB0byBicmFuY2hpbmcgaW4gU0ZDLg0KPj4NCj4+IFlvdSBh cmUgcmlnaHQsIGl0IGlzIGFsbCBhYm91dCBwb2xpY3kgd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgU0ZDLg0KPj4NCj4+IFN1cmVuZHJhLg0KPj4NCj4+IE9uIDExLzEyLzEzIDc6NTMgQU0s ICJSb24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj4+d3JvdGU6 DQo+Pg0KPj4gPkkgdGhpbmsgdGhlIGxhY2sgb2YgZGVmaW5pdGlvbiBvZiAicmVjbGFzc2lmaWNh dGlvbiIgbWF5IGJlIGNhdXNpbmcNCj4+c29tZQ0KPj4gPm1pc3VuZGVyc3RhbmRpbmdzIGhlcmUu ICAgIEEgYnJhbmNoIHdvdWxkIG9jY3VyIGZvciBzb21lIHBvbGljeS1kcml2ZW4NCj4+ID5yZWFz b24gYmFzZWQgb24gdGhlIGJlaGF2aW9yIGFuZCBjb25jbHVzaW9ucyBvZiB0aGUgc2VydmljZSBm dW5jdGlvbiwNCj4+ID5pdHNlbGYuICAgVGhlIGdyYXBoIHdvdWxkIHJlcHJlc2VudCB0aGUgZmFj dCB0aGF0IHRoZXJlIGlzIGEgYnJhbmNoDQo+PiA+cG9pbnQsIGJ1dCB0aGUgc2VydmljZSBmdW5j dGlvbiwgaXRzZWxmLCBiZWluZyBhd2FyZSB0aGF0IGl0IGlzIGEgDQo+PiA+YnJhbmNoaW5nIHBv aW50IHdvdWxkIGNvbnRhaW4gdGhlIHBvbGljeSBhbmQgbG9naWMgdG8gZGVjaWRlIG9uIHdoaWNo DQo+PiA+YnJhbmNoIHRvIHRha2UuICAgU3BlY2lmeWluZyB0aGF0IHBvbGljeSBhbmQgbG9naWMg aXMgb3V0IG9mIHNjb3BlLA0KPj5JTU8uDQo+PiA+DQo+PiA+ICAgUm9uDQo+PiA+DQo+PiA+DQo+ PiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID5Gcm9tOiBLZXZpbiBKIE1hIFttYWls dG86a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCj4+ID5TZW50OiBUdWVzZGF5LCBOb3ZlbWJl ciAxMiwgMjAxMyAxMDo0OSBBTQ0KPj4gPlRvOiBMaW5kYSBEdW5iYXI7IFJvbiBQYXJrZXI7IEhv bmd5dSBMaSAoSnVsaW8pDQo+PiA+Q2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3Vy ZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBTdW1hbmRyYSANCj4+ID5NYWplZQ0KPj4gPlN1YmplY3Q6 IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+DQo+PiA+SGkgTGlu ZGEsDQo+PiA+DQo+PiA+ICBBcmUgeW91IHNheWluZyB0aGF0IGEgYnJhbmNoaW5nIHBvaW50IGlz ICJuZXZlciIgYSANCj4+ID4gcmVjbGFzc2lmaWNhdGlvbiBwb2ludCwgb3IgYXJlIHlvdSBzYXlp bmcgdGhhdCBhIGJyYW5jaGluZyBwb2ludCAiZG9lcyBub3QgaGF2ZSB0byBiZSINCj4+ID4gIGEg cmVjbGFzc2lmaWNhdGlvbiBwb2ludD8NCj4+ID4NCj4+ID4gIEkgdGhpbmsgdGhpcyBpcyBhbiBp bXBvcnRhbnQgZGlzdGluY3Rpb24gdGhhdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQuDQo+PiA+ICBJ ZiBicmFuY2hpbmcgaXMgbmV2ZXIgcmVjbGFzc2lmaWNhdGlvbiwgdGhlbiB0aGUgbWVhbmluZyBv ZiBhIA0KPj4gPiBjaGFpbiBpcyBkaWZmZXJlbnQgdGhhbiBJIG9yaWdpbmFsbHkgaW5mZXJyZWQu ICBJZiB0aGUgY2hhaW4gaXMgYSANCj4+ID4gdHJlZSB3aXRoIG90aGVyICJicmFuY2hpbmciIHBv aW50cyBpbiBpdCwgdGhlbiB0aGF0IGxpbWl0cyB0aGUgDQo+PiA+IHNjb3BlIG9mIHRoZSBwcm9i bGVtIHN0YXRlbWVudCBnb2Fscy4NCj4+ID4NCj4+ID4gIFdoaWxlIHRoaXMgY291bGQgYmUgYSBk ZWdlbmVyYXRlIGNhc2UsIGFuZCBhbnkgaW1wbGVtZW50YXRpb24gDQo+PiA+IGNvdWxkIGRlZmlu ZSBiYWQgc2VydmljZSBjaGFpbnMsIGlzIGl0IHRoZSBpbnRlbnQgb2YgU0ZDIHRvIG9ubHkgDQo+ PiA+IGxvb2sgYXQgdGhlIHNpbXBsZXIgcGFja2V0LWxldmVsIGNsYXNzaWZpY2F0aW9uIGNhc2Vz LCBvciBpcyBpdCB0aGUgDQo+PiA+IGludGVudCB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBh IGJyYW5jaGluZyBwb2ludCBpcyB2aWV3ZWQgYXMgYSANCj4+ID4gcmUtY2xhc3NpZmljYXRpb24g cG9pbnQ/DQo+PiA+DQo+PiA+dGhhbnguDQo+PiA+DQo+PiA+LS0gIEtldmluIEouIE1hDQo+PiA+ DQo+PiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gRnJvbTogTGluZGEgRHVu YmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+PiA+PiBTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAxMiwgMjAxMyAxMDozNCBBTQ0KPj4gPj4gVG86IFJvbiBQYXJrZXI7IEhvbmd5 dSBMaSAoSnVsaW8pOyBLZXZpbiBKIE1hDQo+PiA+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGll dGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IA0KPj4gPj4gU3VtYW5kcmEgTWFqZWUN Cj4+ID4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ PiA+Pg0KPj4gPj4gUm9uLA0KPj4gPj4NCj4+ID4+IEZpcnN0LCB3YW50IHRvIG1ha2UgaXQgY2xl YXIgdGhhdCAiYnJhbmNoaW5nIiAhPSByZWNsYXNzaWZpY2F0aW9uLCANCj4+ID4+YWdyZWU/DQo+ PiA+Pg0KPj4gPj4gU2Vjb25kLCB0aGUgcmVwcmVzZW50YXRpb24gb2YgYnJhbmNoaW5nIChvciBz ZXJ2aWNlIGdyYXBoKSBjYW4gYmUgDQo+PiA+PiBpbiBhIGZvcm0gb2YgbG9naWMgb24gYSBzZXJ2 aWNlIGZ1bmN0aW9uLiBTb21lIHNlcnZpY2UgZnVuY3Rpb25zLCANCj4+ID4+IGVzcGVjaWFsbHkg TDcgYmFzZWQsIGNhbiB1c2UgdmFsdWUgaW4gYSBEYXRhYmFzZSB0byBkZXRlcm1pbmUgd2hhdCAN Cj4+ID4+IGlzIHRoZSBuZXh0IHNlcnZpY2UgZnVuY3Rpb24uDQo+PiA+Pg0KPj4gPj4gTGluZGEN Cj4+ID4+DQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+IEZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0K Pj4gPj4gPiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4gPj4gPiBTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAxMiwgMjAxMyA4OjE2IEFNDQo+PiA+PiA+IFRvOiBIb25neXUgTGkgKEp1bGlvKTsgS2V2 aW4gSiBNYQ0KPj4gPj4gPiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRy YSBLdW1hciAoc21rdW1hcik7IA0KPj4gPj4gPiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiBTdWJq ZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPg0KPj4g Pj4gPiBIb25neXUsDQo+PiA+PiA+DQo+PiA+PiA+IEkgYWdyZWUgY29tcGxldGVseSB0aGF0IHJl LWNsYXNzaWZpY2F0aW9uIGlzIG5vdCBsaW1pdGVkIHRvIERQSS4NCj4+ID4+ID4NCj4+ID4+ID4g QW5kIGFsc28sIHRoYXQgYW4gYXJlYSBmb3IgdXMgdG8gZXhwbG9yZSBhcyBhIGdyb3VwIGlzIGhv dyB0bw0KPj4gPj5yZXByZXNlbnQNCj4+ID4+ID4gdGhlIHNlcnZpY2UgZ3JhcGguICAgRG8gd2Ug d2FudCB0byByZXByZXNlbnQgaXQgYXMgYSBwcm9wZXIgZ3JhcGgNCj4+IHdpdGgNCj4+ID4+ID4g YW4gYWRqYWNlbmN5IGxpc3Qgb3Igb3RoZXIgcmVwcmVzZW50YXRpb25hbCBtb2RlbD8gICBPciwg ZG8gd2Ugd2FudA0KPj4gdG8NCj4+ID4+ID4gcmVwcmVzZW50IGl0IGFzIGEgc2V0IG9mIGxpbmVh ciBzZWdtZW50cyBhbmQgaWYgc28sIGhvdyBhcmUgdGhlDQo+PiA+PiA+IHNlZ21lbnRzIGNvbm5l Y3RlZCBpbnRvIGEgZ3JhcGg/ICAgT3RoZXIgaWRlYXM/DQo+PiA+PiA+DQo+PiA+PiA+ICAgIFJv bg0KPj4gPj4gPg0KPj4gPj4gPg0KPj4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gPj4gPiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGll dGYub3JnXSBPbiANCj4+ID4+ID4gQmVoYWxmIE9mIEhvbmd5dSBMaSAoSnVsaW8pDQo+PiA+PiA+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDY6NTcgQU0NCj4+ID4+ID4gVG86IFJv biBQYXJrZXI7IEtldmluIEogTWENCj4+ID4+ID4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRm Lm9yZzsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyANCj4+ID4+ID4gU3VtYW5kcmEgTWFqZWUN Cj4+ID4+ID4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXIN Cj4+ID4+ID4NCj4+ID4+ID4gQnJhbmNoaW5nL2ZvcmtpbmcgaXMgYSB2ZXJ5IGludGVyZXN0aW5n IHRvcGljIG9mIFNGQy4gQWJvdXQgdGhlDQo+PiA+PiA+IHJlLSBjbGFzc2lmaWNhdGlvbiBwb2lu dCwgcHJvYmFibHkgd2Ugc2hhbGwgbm90IGxpbWl0IGl0IHRvIERQSS4NCj4+ID4+ID4gSXQgaXMg YWxzbyBwb3NzaWJsZSB0aGF0IHBhY2tldHMgZ28gdG8gZGlmZmVyZW50IGJyYW5jaGVzIGFmdGVy IA0KPj4gPj4gPiBiZWVuIHByb2Nlc3NlZCBieSBhIGNlcnRhaW4gc2VydmljZSBmdW5jdGlvbiwg ZGVjaXNpb24gb2Ygd2hpY2ggDQo+PiA+PiA+IGJyYW5jaGVzIHRvIGdvIGlzIG1hZGUgYmFzZWQg b24gdGhlIHJlc3VsdCBvZiBzZXJ2aWNlIGZ1bmN0aW9uJ3MgDQo+PiA+PiA+IHByb2Nlc3MsIGku ZS4gbm90IGp1c3QgcmUtIGNsYXNzaWZpY2F0aW9uIGJ5IERQSS4NCj4+ID4+ID4NCj4+ID4+ID4g SG9uZ3l1DQo+PiA+PiA+DQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+ PiA+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIA0KPj4gPj4gPiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4gPj4gPiBTZW50OiBUdWVz ZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyA3OjQ1IFBNDQo+PiA+PiA+IFRvOiBLZXZpbiBKIE1hDQo+ PiA+PiA+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChz bWt1bWFyKTsgDQo+PiA+PiA+IFN1bWFuZHJhIE1hamVlDQo+PiA+PiA+IFN1YmplY3Q6IFJlOiBb bnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+DQo+PiA+PiA+IEhpLCBL ZXZpbg0KPj4gPj4gPg0KPj4gPj4gPiBZb3UgYXNrIGEgZ3JlYXQgcXVlc3Rpb24gYWJvdXQgYnJh bmNoaW5nIHRoZSBncmFwaC4gIFRoZSBkZXRhaWxzIA0KPj4gPj4gPiBhcm91bmQgaG93IHRvIGNv bnZleSB0aGUgc2VsZWN0aW9uIG9mIHRoZSBzdWJ0cmVlL3N1YmdyYXBoIGFyZSANCj4+ID4+ID4g c3RpbGwNCj4+ID4+dG8gYmUNCj4+ID4+ID4gZGVmaW5lZC4gICBJcyBpdCBvbmUgY2hhaW4gaWQg Zm9yIHRoZSB3aG9sZSBncmFwaD8gICBEb2VzIGVhY2gNCj4+YnJhbmNoDQo+PiA+PiA+IGhhdmUg aXRzIG93biBjaGFpbiBpZD8gICBTb21lIGNvbWJpbmF0aW9uPw0KPj4gPj4gPg0KPj4gPj4gPiAg ICBSb24NCj4+ID4+ID4NCj4+ID4+ID4gT24gTm92IDEyLCAyMDEzLCBhdCAxOjUyIEFNLCAiS2V2 aW4gSiBNYSINCj4+ID4+ID4gPGtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+DQo+PiA+PiA+IHdy b3RlOg0KPj4gPj4gPg0KPj4gPj4gPiA+PiBZZXMsIHJlY2xhc3NpZmljYXRpb24gY2FuIGNoYW5n ZSB0aGUgc2VydmljZSBwYXRoIGFuZCANCj4+ID4+ID4gPj4gcmUtY2xhc3NpZmljYXRpb24gbWF5 IGhhcHBlbiBhdCBhbnkgbm9kZSBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+ID4+ID4gPg0KPj4g Pj4gPiA+IEp1c3QgdG8gZXhwYW5kIG9uIHRoYXQsIGdvaW5nIGJhY2sgdG8gdGhlIG9yaWdpbmFs IHF1ZXN0aW9uIA0KPj4gPj4gPiA+IGFib3V0IHNlcnZpY2UgaGVhZGVyIGVuY2Fwc3VsYXRpb24s IGlzIGl0IGludGVuZGVkIHRoYXQgYSANCj4+ID4+ID4gPiBjaGFpbiB0aGF0IGlzIHJlLWNsYXNz aWZpZWQgd2lsbCBnZXQgYSBuZXcgY2hhaW4gSUQgd2hpY2ggDQo+PiA+PiA+ID4gZnVsbHkgZGVz Y3JpYmVzIGEgY2hhaW4gdGhhdCBpcyBhIHN1cGVyc2V0IG9mIHRoZSBvcmlnaW5hbCANCj4+ID4+ ID4gPiBjaGFpbiBJRCwgcHJpb3IgdG8gRFBJLWJhc2VkIHJlLWNsYXNzaWZpY2F0aW9uPyAgKGFz c3VtaW5nIHRoZSANCj4+ID4+ID4gPiBnb2FsIGlzICJhIHNpbmdsZSBjaGFpbiBJRCB0aGF0IGlz IGNvbW1vbmx5IHVuZGVyc3Rvb2QgYWxvbmcgDQo+PiA+PiA+ID4gdGhlIGVudGlyZSBzZXJ2aWNl DQo+PiBjaGFpbiINCj4+ID4+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbnNjL2N1cnJlbnQvbXNnMDA2MzguaHRtbA0KPj4gPj4gPiA+ICkNCj4+ID4+ID4gPg0KPj4g Pj4gPiA+IEFuZCB0aGUgYXBwbGljYWJsZSBzdWJzZXQgb2YgdGhlIHBlcm11dGF0aXZlIGxpc3Qg b2Ygc2VydmljZSANCj4+ID4+ID4gPiBwYXRocyB3b3VsZCBiZSBjb25maWd1cmVkIGF0IGVhY2gg YXBwcm9wcmlhdGUgc2VydmljZSBub2RlPw0KPj4gPj4gPiA+IGUuZy4sIElEIDE6IE5BVCArIGZp cmV3YWxsICsgRFBJDQo+PiA+PiA+ID4gICAgICBJRCAyOiBOQVQgKyBmaXJld2FsbCArIERQSSAr IEFWDQo+PiA+PiA+ID4gICAgICBJRCAzOiBOQVQgKyBmaXJld2FsbCArIERQSSArIEFWICsgTkFU DQo+PiA+PiA+ID4gICAgICBJRCA0OiBOQVQgKyBmaXJld2FsbCArIERQSSArIE5BVA0KPj4gPj4g PiA+ICAgICAgSUQgNTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViArIExCDQo+PiA+PiA+ID4g ICAgICBJRCA2OiBOQVQgKyBmaXJld2FsbCArIERQSSArIExCDQo+PiA+PiA+ID4gICAgICBJRCA3 OiBOQVQgKyBmaXJld2FsbCArIERQSSArIExCICsgQ0FDSEUNCj4+ID4+ID4gPiAgICAgIElEIDg6 IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQ0FDSEUNCj4+ID4+ID4gPiAgICAgIElEIDk6IE5BVCAr IGZpcmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgTEINCj4+ID4+ID4gPiAgICAgIElEIDEwOiBO QVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIExCICsgQ0FDSEUNCj4+ID4+ID4gPiAg ICAgIElEIDExOiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIENBQ0hFIFdvdWxk IA0KPj4gPj4gPiA+IGV2ZXJ5IGZsb3cgdGhlbiBiZSBpbml0aWFsbHkgY2xhc3NpZmllZCBhcyBJ RCAxLCBidXQgDQo+PiA+PiA+ID4gZXZlbnR1YWxseSBnZXQgcmUtDQo+PiA+PiA+IGNsYXNzaWZp ZWQNCj4+ID4+ID4gPiB0byBJRCAyLTExLCBhZnRlciB0aGUgRFBJIHBoYXNlPw0KPj4gPj4gPiA+ DQo+PiA+PiA+ID4gdGhhbnguDQo+PiA+PiA+ID4NCj4+ID4+ID4gPiAtLSAgS2V2aW4gSi4gTWEN Cj4+ID4+ID4gPg0KPj4gPj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4g PiA+PiBGcm9tOiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgW21haWx0bzpzbWt1bWFyQGNpc2Nv LmNvbV0NCj4+ID4+ID4gPj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTowMSBB TQ0KPj4gPj4gPiA+PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBhcmtlcjsgU3VtYW5kcmEgTWFqZWU7 IFRob21hcyBOYXJ0ZW47IA0KPj4gPj4gPiA+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4gU3Vi amVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4N Cj4+ID4+ID4gPj4NCj4+ID4+ID4gPj4NCj4+ID4+ID4gPj4+IE9uIDExLzExLzEzIDk6NDYgUE0s ICJLZXZpbiBKIE1hIiANCj4+ID4+ID4gPj4+IDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0K Pj4gPj53cm90ZToNCj4+ID4+ID4gPj4+DQo+PiA+PiA+ID4+PiBIaSBTdXJlbmRyYSwNCj4+ID4+ ID4gPj4+DQo+PiA+PiA+ID4+PiBDbGFzc2lmaWNhdGlvbiBtYXkgYmUgb3V0IG9mIHNjb3BlLCBi dXQgdGhlIGxldmVsIG9mIHNlcnZpY2UgDQo+PiA+PiA+ID4+PiB0aGF0DQo+PiA+PiA+IGlzDQo+ PiA+PiA+ID4+PiBhcHBsaWNhYmxlIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBsZXZlbCBvZiBjbGFz c2lmaWNhdGlvbiANCj4+ID4+ID4gPj4+IHRoYXQgY2FuDQo+PiA+PiA+IGJlDQo+PiA+PiA+ID4+ PiBwZXJmb3JtZWQuICBBbiBhc3N1bXB0aW9uIG9mIHBhY2tldCBsZXZlbCBlbmNhcHN1bGF0aW9u IGhhcw0KPj4gPj4gPiA+PiBpbXBsaWNhdGlvbnMNCj4+ID4+ID4gPj4+IG9uIHRoZSBsZXZlbCBv ZiBjbGFzc2lmaWNhdGlvbiBiZWluZyBwZXJmb3JtZWQ/ICBJZiB0aGUgDQo+PiA+PiA+ID4+PiBz dGF0ZWQNCj4+ID4+ID4gZ29hbHMNCj4+ID4+ID4gPj4gYXJlDQo+PiA+PiA+ID4+PiBmb3IgZmly ZXdhbGwgYW5kIGxvYWQgYmFsYW5jZXIgZnVuY3Rpb25hbGl0eSwgdGhlbiB0aGUgDQo+PiA+PiA+ ID4+PiBhcHBsaWNhdGlvbg0KPj4gPj4gPiA+PiBsZXZlbA0KPj4gPj4gPiA+Pj4gbmF0dXJlIG9m IHRob3NlIGZ1bmN0aW9ucyBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/DQo+PiA+PiA+ ID4+PiBJZiwgb24gdGhlIG90aGVyIGhhbmQsIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHNjb3BlIGlz IGxpbWl0ZWQgDQo+PiA+PiA+ID4+PiBkdWUgdG8gbGltaXRhdGlvbnMgaW4gY2xhc3NpZmljYXRp b24sIHRoYXQgd291bGQgYmUgYW5kIA0KPj4gPj4gPiA+Pj4gaW1wb3J0YW50IHBpZWNlIG9mDQo+ PiA+PiA+IGluZm9ybWF0aW9uPw0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+IFdydCBzZWN0aW9u IDQuNCBvZiBkcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMgdGhlIA0KPj4gPj4g PiA+Pj4gZm9yayBwb2ludHMgb2YgdGhlIHNlcnZpY2UgcGF0aHMgc2VlbSBsaWtlIHJlLWNsYXNz aWZpY2F0aW9uDQo+PiBwb2ludHM/DQo+PiA+PiA+ID4+PiBJcyB0aGF0IHRoZSBpbnRlcnByZXRh dGlvbiBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmU/DQo+PiA+PiA+ID4+PiBPciBp cyB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBjbGFzc2lmaWNhdGlvbiBleGNsdXNpdmUgb2Yg DQo+PiA+PiA+ID4+PiBEUEkNCj4+ID4+ID4gZnVuY3Rpb25hbGl0eT8NCj4+ID4+ID4gPj4gPFNL PiBJIGhhdmUgbm90IGZ1bGx5IHJlYWQgdGhhdCBkcmFmdCB5ZXQuIEJ1dCBpbiBnZW5lcmFsLCBh cyANCj4+ID4+ID4gPj4gZGVzY3JpYmVkIGluIHRoZSBhcmNoIGRyYWZ0LCB0aGUgY29sbGVjdGlv biBvZiBzZXJ2aWNlcyBmb3JtIA0KPj4gPj4gPiA+PiBhIGdyYXBoLCBzZWdtZW50cyBvZiB3aGlj aCBhcmUgc2VydmljZSBwYXRocy4gWWVzLCANCj4+ID4+ID4gPj4gcmVjbGFzc2lmaWNhdGlvbiBj YW4NCj4+ID4+ID4gY2hhbmdlDQo+PiA+PiA+ID4+IHRoZSBzZXJ2aWNlIHBhdGggYW5kIHJlLWNs YXNzaWZpY2F0aW9uIG1heSBoYXBwZW4gYXQgYW55IG5vZGUgDQo+PiA+PiA+ID4+IGFsb25nDQo+ PiA+PiA+IGEgc2VydmljZSBwYXRoLg0KPj4gPj4gPiA+Pg0KPj4gPj4gPiA+PiBTdXJlbmRyYS4N Cj4+ID4+ID4gPj4+DQo+PiA+PiA+ID4+PiB0aGFueC4NCj4+ID4+ID4gPj4+DQo+PiA+PiA+ID4+ PiAtLSAgS2V2aW4gSi4gTWENCj4+ID4+ID4gPj4+DQo+PiA+PiA+ID4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+PiBGcm9tOiBTdXJlbmRyYSBLdW1hciAoc21rdW1h cikgW21haWx0bzpzbWt1bWFyQGNpc2NvLmNvbV0NCj4+ID4+ID4gPj4+PiBTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAxMiwgMjAxMyAxMjowOCBBTQ0KPj4gPj4gPiA+Pj4+IFRvOiBLZXZpbiBKIE1h OyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgDQo+PiA+PiA+ID4+ Pj4gbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQg UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pg0KPj4gPj4gPiA+Pj4+IEtldmluLA0K Pj4gPj4gPiA+Pj4+DQo+PiA+PiA+ID4+Pj4gQ2xhc3NpZmljYXRpb24gbWVjaGFuaXNtIGlzIG91 dHNpZGUgdGhlIHNjb3BlIG9mIFNGQy4gSXQgDQo+PiA+PiA+ID4+Pj4gY2FuIGJlIGJhc2VkDQo+ PiA+PiA+ID4+IG9uDQo+PiA+PiA+ID4+Pj4gdGhlIHBhY2tldCBvciBpbmZvcm1hdGlvbiBub3Qg aW4gdGhlIHBhY2tldChlbnZpcm9ubWVudGFsIA0KPj4gPj4gPiA+Pj4+IGF0dHJpYnV0ZXMNCj4+ ID4+ID4gPj4gZm9yDQo+PiA+PiA+ID4+Pj4gaW5zdGFuY2UpIG9yIGEgY29tYmluYXRpb24gdGhl cmVvZi4gV2hhdCBpcyBpbXBvcnRhbnQgaXMgDQo+PiA+PiA+ID4+Pj4gdGhhdCBzdWNoIGNsYXNz aWZpY2F0aW9uIGFpZHMgaW4gdHJhZmZpYyBzZWxlY3Rpb24gYW5kIA0KPj4gPj4gPiA+Pj4+IHNl cnZpY2UgcGF0aCBpZGVudGlmaWNhdGlvbi4NCj4+ID4+ID4gPj4+PiBJdCBpcyBubyBkaWZmZXJl bnQgZnJvbSBhIHBvbGljeSBpbiB0aGlzIHJlZ2FyZCBleGNlcHQgdGhhdCANCj4+ID4+ID4gPj4+ PiB0aGUgcG9saWN5IG5vdyBzcGVjaWZpZXMgdGhlIHNlcnZpY2UgcGF0aC4NCj4+ID4+ID4gPj4+ PiBGdXJ0aGVyLCBjbGFzc2lmaWNhdGlvbiBpcyBub3QgbGltaXRlZCB0byB0aGUgbmV0d29yayAN Cj4+ID4+ID4gPj4+PiBlbGVtZW50cyBidXQgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwu IFNvbWUgb2YgdGhpcyBpcyANCj4+ID4+ID4gPj4+PiBkZXNjcmliZWQgaW4gdGhlDQo+PiA+PiA+ ID4+IGFyY2hpdGVjdHVyZQ0KPj4gPj4gPiA+Pj4+IGRyYWZ0cyBhcyB3ZWxsIC0NCj4+ID4+ID4g Pj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFy Y2gvIi4NCj4+ID4+ID4gPj4+Pg0KPj4gPj4gPiA+Pj4+IFN1cmVuZHJhLg0KPj4gPj4gPiA+Pj4+ DQo+PiA+PiA+ID4+Pj4+IE9uIDExLzExLzEzIDc6MzMgUE0sICJLZXZpbiBKIE1hIg0KPj4gPj4g PiA+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+ID4+ID4gd3JvdGU6DQo+PiA+ PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IEhpIFJvbiwNCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4g Pj4+Pj4gSSB3YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNGQyBCb0YgZHVlIHRvIGEgY29uZmxpY3Qg d2l0aCANCj4+ID4+ID4gPj4+Pj4gQ0ROSSwgYnV0IEkgaGFkIGEgc2ltaWxhciBxdWVzdGlvbiB3 cnQgYnVsbGV0IDExIGluIA0KPj4gPj4gPiA+Pj4+PiBzZWN0aW9uDQo+PiA+PiA+ID4+Pj4+IDIg b2YgdGhlDQo+PiA+PiA+IHByb2JsZW0NCj4+ID4+ID4gPj4+Pj4gc3RhdGVtZW50Og0KPj4gPj4g PiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiAgIDExLiAgUGVyLVNlcnZpY2UgKHJlKUNsYXNzaWZpY2F0 aW9uOiBDbGFzc2lmaWNhdGlvbiANCj4+ID4+ID4gPj4+Pj4gb2NjdXJzIGF0DQo+PiA+PiA+IGVh Y2gNCj4+ID4+ID4gPj4+Pj4gICAgICAgIHNlcnZpY2UsIGluZGVwZW5kZW50IGZyb20gcHJldmlv dXNseSBhcHBsaWVkIA0KPj4gPj4gPiA+Pj4+PiBzZXJ2aWNlDQo+PiA+PiA+ID4+Pj4gZnVuY3Rp b25zLg0KPj4gPj4gPiA+Pj4+PiAgICAgICAgVGhlc2UgdW5yZWxhdGVkIGNsYXNzaWZpY2F0aW9u IGV2ZW50cyBjb25zdW1lIA0KPj4gPj4gPiA+Pj4+PiByZXNvdXJjZXMNCj4+ID4+ID4gcGVyDQo+ PiA+PiA+ID4+Pj4+ICAgICAgICBzZXJ2aWNlLiAgTW9yZSBpbXBvcnRhbnRseSwgdGhlIGNsYXNz aWZpY2F0aW9uDQo+PiA+PiA+IGZ1bmN0aW9uYWxpdHkNCj4+ID4+ID4gPj4+Pj4gICAgICAgIG9m dGVuIGRpZmZlcnMgcGVyIHNlcnZpY2UgZnVuY3Rpb24gYW5kIHNlcnZpY2UgDQo+PiA+PiA+ID4+ Pj4+IGZ1bmN0aW9uDQo+PiA+PiA+ID4+IGNhbm5vdA0KPj4gPj4gPiA+Pj4+PiAgICAgICAgbGV2 ZXJhZ2UgdGhlIHJlc3VsdHMgZnJvbSBvdGhlciBkZXBsb3llZCBuZXR3b3JrIG9yDQo+PiA+PiA+ IHNlcnZpY2UuDQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IGFzIGl0IHJlbGF0ZXMgdG8g c2VjdGlvbiA1LjIgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudDoNCj4+ID4+ID4gPj4+Pj4NCj4+ ID4+ID4gPj4+Pj4gICBUaGUgU0ZDIENsYXNzaWZpZXIgY2xhc3NpZmllcyBwYWNrZXRzIGJhc2Vk IG9uIChzb21lIG9mKSANCj4+ID4+ID4gPj4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4gY29udGVudHMN Cj4+ID4+ID4gPj4+Pj4gICBvZiB0aGUgcGFja2V0IGhlYWRlci4gIENvbmNyZXRlbHksIGl0IGNs YXNzaWZpZXMgcGFja2V0cyANCj4+ID4+ID4gPj4+Pj4gYmFzZWQgb24NCj4+ID4+ID4gPj4+PiB0 aGUNCj4+ID4+ID4gPj4+Pj4gICBwb3NzaWJsZSBjb21iaW5hdGlvbiBvZiBvbmUgb3IgbW9yZSBo ZWFkZXIgZmllbGRzLCBzdWNoIA0KPj4gPj4gPiA+Pj4+PiBhcw0KPj4gPj4gPiBzb3VyY2UNCj4+ ID4+ID4gPj4+Pj4gICBhZGRyZXNzLCBkZXN0aW5hdGlvbiBhZGRyZXNzLCBEUyBmaWVsZCwgcHJv dG9jb2wgSUQsIA0KPj4gPj4gPiA+Pj4+PiBzb3VyY2UNCj4+ID4+ID4gcG9ydA0KPj4gPj4gPiA+ Pj4+IGFuZA0KPj4gPj4gPiA+Pj4+PiAgIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVycywgYW5kIGFu eSBvdGhlciBpbmZvcm1hdGlvbi4NCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4gPj4+Pj4gQSBwYWNr ZXQtYmFzZWQgY2xhc3NpZmllciBhcyBkZXNjcmliZWQgaW4gdGhlIGZyYW1ld29yayANCj4+ID4+ ID4gPj4+Pj4gZG9jdW1lbnQNCj4+ID4+ID4gPj4+PiB3b3VsZA0KPj4gPj4gPiA+Pj4+PiBzZWVt IHRvIGJlIGxpbWl0ZWQgaW4gd2hhdCBpdCBjYW4gY2xhc3NpZnk/ICBUaGUgc2VydmljZSANCj4+ ID4+ID4gPj4+Pj4gZnVuY3Rpb24gaWRlbnRpZmllciBsb29rdXAgZG9lcyBub3Qgc2VlbSB0byBi ZSBhIA0KPj4gPj4gPiA+Pj4+PiBzaWduaWZpY2FudCBvcHRpbWl6YXRpb24NCj4+ID4+ID4gPj4g b3Zlcg0KPj4gPj4gPiA+Pj4+PiBhIHBhY2tldC1iYXNlZCA1LXR1cGxlIGxvb2t1cD8gIFRoZXJl IHNlZW1zIHRvIGJlIHNvbWUgDQo+PiA+PiA+ID4+Pj4+IG1pc3NpbmcNCj4+ID4+ID4gPj4gZGV0 YWlsDQo+PiA+PiA+ID4+Pj4+IHdydCBob3cgY2xhc3NpZmljYXRpb24gaW5mb3JtYXRpb24gaXMg ZGV0ZXJtaW5lZCBhbmQgcmV1c2VkPw0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiBXaGVu IHRoaW5raW5nIGFib3V0IGhpZ2hlciBsZXZlbCBzZXJ2aWNlcywgZS5nLiwgSFRUUCBhbmQgDQo+ PiA+PiA+ID4+Pj4+IFRMUw0KPj4gPj4gPiA+Pj4+IGVuY3J5cHRlZA0KPj4gPj4gPiA+Pj4+PiBm bG93cywgYSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBzZWVtcyBpbmFkZXF1YXRlPyAgSSB3YXMg DQo+PiA+PiA+ID4+Pj4+IGFsc28NCj4+ID4+ID4gPj4+PiB3b25kZXJpbmcNCj4+ID4+ID4gPj4+ Pj4gaG93IGluZGVwZW5kZW50IEhMUyBzZWdtZW50IHJlcXVlc3RzIG1pZ2h0IGJlIGNsYXNzaWZp ZWQgDQo+PiA+PiA+ID4+Pj4+IGFuZA0KPj4gPj4gPiA+Pj4+IGFzc29jaWF0ZWQ/DQo+PiA+PiA+ ID4+Pj4+IFdlcmUgdGhlc2UgdHlwZXMgb2YgdXNlIGNhc2VzIGRpc2N1c3NlZCBpbiB0aGUgQm9G Pw0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiB0aGFueC4NCj4+ID4+ID4gPj4+Pj4NCj4+ ID4+ID4gPj4+Pj4gLS0gIEtldmluIEouIE1hDQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogbnNjLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gDQo+PiA+PiA+ID4+ Pj4+PiBPbiBCZWhhbGYNCj4+ID4+ID4gPj4gT2YNCj4+ID4+ID4gPj4+Pj4+IFJvbg0KPj4gPj4g PiA+Pj4+Pj4gUGFya2VyDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDEx LCAyMDEzIDEwOjE2IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21h cyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2Nd IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+ Pj4+PiBTdW1hbmRyYSwNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBcyB3YXMgZGlz Y3Vzc2VkIGluIFZhbmNvdXZlciwgdGhlcmUgYXJlIGFscmVhZHkgbWFueSANCj4+ID4+ID4gPj4+ Pj4+IGV4aXN0aW5nIHdheXMNCj4+ID4+ID4gPj4+PiB0bw0KPj4gPj4gPiA+Pj4+Pj4gYWNjb21w bGlzaCBzZXJ2aWNlIGNoYWluaW5nLiAgICAgQnV0IG5vbmUgb2YgdGhlbSBwcm92aWRlIGENCj4+ ID4+ID4gPj4+PiBzdWZmaWNpZW50DQo+PiA+PiA+ID4+Pj4+PiBjb21iaW5hdGlvbiBvZiBpbnRl cm9wZXJhYmlsaXR5LCBmbGV4aWJpbGl0eSwgYW5kDQo+PnJlc2lsaWVuY3kuDQo+PiA+PiA+IEEN Cj4+ID4+ID4gPj4+PiBzaW5nbGUNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgY2hhaW4gZW5jYXBz dWxhdGlvbiB3aWxsIGdvIGEgbG9uZyB3YXkgdG8gDQo+PiA+PiA+ID4+Pj4+PiBlbnN1cmluZyB0 aGVzZQ0KPj4gPj4gPiA+Pj4+IGdvYWxzLg0KPj4gPj4gPiA+Pj4+Pj4gSXQgIG1heSBub3QgYmUg dGhlIGFic29sdXRlbHkgbW9zdCBlZmZpY2llbnQgYXBwcm9hY2ggZm9yIA0KPj4gPj4gPiA+Pj4+ Pj4gZXZlcnkNCj4+ID4+ID4gPj4+PiBzaW5nbGUNCj4+ID4+ID4gPj4+Pj4+IG5ldHdvcmsgdG9w b2xvZ3kgYW5kIGV2ZXJ5IHNpbmdsZSB1c2UgY2FzZSwgYnV0IGl0cyANCj4+ID4+ID4gPj4+Pj4+ IHViaXF1aXRvdXMNCj4+ID4+ID4gPj4gbmF0dXJlDQo+PiA+PiA+ID4+Pj4+PiBzaG91bGQgaW1w cm92ZSBpdHMgYWRvcHRpb24uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24N Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IFN1bWFuZHJhIE1hamVlIFtt YWlsdG86Uy5NYWplZUBGNS5jb21dDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVt YmVyIDExLCAyMDEzIDEwOjEwIFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhv bWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW25z Y10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4g Pj4+Pj4+IFJvbiwNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBYnNvbHV0ZWx5LCB0 aGF0IHdhcyBhbiBleGFtcGxlIG9mIG9uZSB0eXBlIG9mIGRlcml2YXRpb24uDQo+PiA+PiA+ID4+ Pj4+PiBIb3dldmVyDQo+PiA+PiA+ID4+Pj4gdGhpcw0KPj4gPj4gPiA+Pj4+Pj4gY291bGQgYmUg YXVnbWVudGVkIHdpdGggY2xhc3NpZmljYXRpb24gcmVzdWx0LCBhZ2FpbiBvbmUgDQo+PiA+PiA+ ID4+Pj4+PiBtb3JlDQo+PiA+PiA+ID4+Pj4gZXhhbXBsZS4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVj ZXNzYXJpbHkgDQo+PiA+PiA+ID4+Pj4+Pj4+IGZvbGxvdw0KPj4gPj4gPiB0aGUNCj4+ID4+ID4g Pj4+PiBzYW1lDQo+PiA+PiA+ID4+Pj4+PiBjaGFpbi4NCj4+ID4+ID4gPj4+Pj4+IENvcnJlY3Qu IEl0IGlzIGFsc28gbm90IG5lY2Vzc2FyeSB0aGF0IGFsbCB0cmFuc2FjdGlvbiBvZiANCj4+ID4+ ID4gPj4+Pj4+IHRoZSBzYW1lDQo+PiA+PiA+ID4+Pj4gZmxvdw0KPj4gPj4gPiA+Pj4+Pj4gZm9s bG93IHRoZSBzYW1lIGNoYWluIGVpdGhlci4gU28gd2h5IHN0b3AgYXQgZmxvdyBpdHNlbGYuDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQWdhaW4gdGhlIHBvaW50IGhlcmUgaXMgdGhh dCBkbyB3ZSBhbHdheXMgbmVlZCBTRkMgaGVhZGVyIA0KPj4gPj4gPiA+Pj4+Pj4gb3INCj4+ID4+ Tm90Lg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhDQo+PiA+PiA+ID4+ Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+ID4+ID4gPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92 ZW1iZXIgMTEsIDIwMTMgNzowMiBQTQ0KPj4gPj4gPiA+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVl OyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJF OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4g Pj4gPiA+Pj4+Pj4gU3VtYW5kcmEsDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gVGhl IGludGVudGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHRvIGFsbG93IA0KPj4g Pj4gPiA+Pj4+Pj4gZm9yIG9wZXJhdGlvbg0KPj4gPj4gPiA+Pj4+IGF0DQo+PiA+PiA+ID4+Pj4+ PiB0aGUgZnVsbHkgcXVhbGlmaWVkIGZsb3cgbGV2ZWwsIG9yIGV2ZW4gZmluZXIgZ3JhaW5lZCBh dCANCj4+ID4+ID4gPj4+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+IHRyYW5zYWN0aW9uDQo+PiA+PiA+ ID4+Pj4+PiBsZXZlbCAodGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIgZm9yIHRoZSBQ RFApLg0KPj5BbGwNCj4+ID4+ID4gZmxvd3MNCj4+ID4+ID4gPj4+PiBmcm9tDQo+PiA+PiA+ID4+ Pj4+PiB0aGUgc2FtZSBzb3VyY2UgSVAgZG8gbm90IG5lY2Vzc2FyaWx5IGZvbGxvdyB0aGUgc2Ft ZSBjaGFpbi4NCj4+ID4+ID4gPj4gU291cmNlDQo+PiA+PiA+ID4+Pj4+PiBJUCwNCj4+ID4+ID4g Pj4+Pj4+IHRoZXJlZm9yZSwgIGRvZXMgbm90IGlkZW50aWZ5IHRoZSBjaGFpbiBJRC4gICAgQW5v dGhlcg0KPj4gPj5pbnRlbnRpb24NCj4+ID4+ID4gb2YNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2Ug ZnVuY3Rpb24gY2hhaW5pbmcgaXMgdG8gb3BlcmF0ZSBvdmVyIGFueSBuZXR3b3JrDQo+PiA+PiA+ IHRvcG9sb2d5DQo+PiA+PiA+ID4+IGFuZA0KPj4gPj4gPiA+Pj4+Pj4gbm90DQo+PiA+PiA+ID4+ Pj4+PiBiZSBsaW1pdGVkIHRvIGEgc2luZ2xlIExBTi4gICBUaHVzLCB3aGlsZSBWTEFOIG1heSBi ZSBwYXJ0DQo+Pm9mDQo+PiA+PiA+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gdHJhbnNwb3J0LCBpdCBk b2VzIG5vdCBhZGVxdWF0ZWx5IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4g Y2hhaW4sDQo+PiA+PiA+ID4+IGVpdGhlci4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+ PiAgIFJvbg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogU3VtYW5kcmEg TWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0NCj4+ID4+ID4gPj4+Pj4+IFNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMTEsIDIwMTMgOTo1NiBQTQ0KPj4gPj4gPiA+Pj4+Pj4gVG86IFJvbiBQYXJr ZXI7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDog UkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+PiBSb24sDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gVGhlIHNl cnZpY2UgaGVhZGVyIGlzIG1lYW50IHRvIGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoIA0KPj4gPj4g PiA+Pj4+Pj4gY2FuDQo+PiA+PiA+ICphbHNvKg0KPj4gPj4gPiA+Pj4+Pj4gYmUgZGVyaXZlZCAo Zm9yIGV4YW1wbGUgdXNlIHNvdXJjZSBpcCBhbmQgdmxhbiB0byANCj4+ID4+ID4gPj4+Pj4+IGlk ZW50aWZ5IGNoYWluSUQgYW5kDQo+PiA+PiA+ID4+Pj4+PiBwb3NpdGlvbikgb3IgZW5jYXBzdWxh dGVkIGFzIHBhcnQgb2YgYW5vdGhlciB0dW5uZWwgaGVhZGVyLg0KPj4gPj4gPiA+Pj4+Pj4gU28g dGhpcyBjb3VsZCBiZSBvcHRpb25hbCBJTUhPLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+ Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBSb24g UGFya2VyIFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+ID4+ID4g Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgNDozNiBQTQ0KPj4gPj4gPiA+ Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+ ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFy dGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gU3VtYW5kcmEsDQo+PiA+PiA+ID4+ Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQXMgSSB1bmRlcnN0YW5kIGl0LCBhbiBTRkMgcGFja2V0IHRy YXZlcnNpbmcgZnJvbSBQRFAgdG8gDQo+PiA+PiA+ID4+Pj4+PiBTRiBvciBmcm9tDQo+PiA+PiA+ ID4+Pj4gU0YNCj4+ID4+ID4gPj4+Pj4+IHRvDQo+PiA+PiA+ID4+Pj4+PiBTRiB3aWxsIGxvb2sg bGlrZToNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPj4gPj4gPiA+Pj4+Pj4gfCAgICAgICAgInRyYW5zcG9ydCIgICAgICAgICB8DQo+ PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gPj4gPiA+Pj4+Pj4g fCAgICAgIHNlcnZpY2UgaGVhZGVyICAgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgb3JpZ2luYWwgSVAgaGVhZGVyICB8DQo+ PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gPj4gPiA+Pj4+Pj4g fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgb3JpZ2luYWwgSVAg DQo+PiA+PiA+ID4+Pj4+PiB8IHBheWxvYWQNCj4+ID4+ID4gfA0KPj4gPj4gPiA+Pj4+Pj4gfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gPj4gPiA+Pj4+Pj4g Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+ PiBXaGVyZSBzZXJ2aWNlIGhlYWRlciBjb250YWlucywgYXQgYSBtaW5pbXVtLCBlbm91Z2ggDQo+ PiA+PiA+ID4+Pj4+PiBpbmZvcm1hdGlvbiB0bw0KPj4gPj4gPiA+Pj4+IGFsbG93DQo+PiA+PiA+ ID4+Pj4+PiB0aGUgcGFja2V0IHRvIGJlIHByb3BhZ2F0ZWQgYWxvbmcgdGhlIGZ1bGwgbGVuZ3Ro IG9mIHRoZSANCj4+ID4+ID4gPj4+Pj4+IGNoYWluLCBhbmQgb3B0aW9uYWxseSwgb3RoZXIgbWV0 YWRhdGEgdGhhdCBlbmhhbmNlcyB0aGUgDQo+PiA+PiA+ID4+Pj4+PiBvcGVyYXRpb24gb2YNCj4+ ID4+ID4gb25lDQo+PiA+PiA+ID4+Pj4+PiBvcg0KPj4gPj4gPiA+PiBtb3JlDQo+PiA+PiA+ID4+ Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBB bmQgd2hlcmUgInRyYW5zcG9ydCIgY291bGQgY29uY2VpdmFibHkgYmUgYW55IG9mLCBidXQgDQo+ PiA+PiA+ID4+Pj4+PiBub3QgbGltaXRlZA0KPj4gPj4gPiA+Pj4+IHRvOg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQNCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQg KyBMTEMyDQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0ICsgTVBMUw0KPj4gPj4gPiA+Pj4+Pj4g KiBFdGhlcm5ldCArIElQICsgR1JFDQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgK1VE UA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBbHNvLCAi b3JpZ2luYWwiIGluIHRoZSBkaWFncmFtIGFib3ZlIGlzIG5vdCBtZWFudCB0byANCj4+ID4+ID4g Pj4+Pj4+IGltcGx5IGltbXV0YWJpbGl0eSwgYnV0IHJhdGhlciB0byBzcGVjaWZ5IHRoZSBwYWNr ZXQgdGhhdCANCj4+ID4+ID4gPj4+Pj4+IGlzDQo+PiA+PiA+IHByb3BhZ2F0ZWQNCj4+ID4+ID4g Pj4+Pj4+IGZyb20gcHJlY2VkaW5nIGVudGl0eSB0byBzdWNjZWVkaW5nIGVudGl0eSwgcHJpb3Ig dG8gDQo+PiA+PiA+ID4+Pj4+PiBlbmNhcHN1bGF0aW9uLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ ID4gPj4+Pj4+ICAgUm9uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4g Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSANCj4+ID4+ ID4gPj4+Pj4+IE9uIEJlaGFsZg0KPj4gPj4gPiA+PiBPZg0KPj4gPj4gPiA+Pj4+Pj4gU3VtYW5k cmEgTWFqZWUNCj4+ID4+ID4gPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMg Njo0NiBQTQ0KPj4gPj4gPiA+Pj4+Pj4gVG86IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0K Pj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNo YXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBHZW5lcmljIFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSANCj4+ID4+ID4gPj4+Pj4+IGRvY3VtZW50 DQo+PiA+PndpbGwNCj4+ID4+ID4gPj4+Pj4+ICAgIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2Vydmlj ZS1sZXZlbCBkYXRhIHBsYW5lIA0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4gPj4g PiA+PiBmb3JtYXQNCj4+ID4+ID4gPj4+Pj4+IGZvcg0KPj4gPj4gPiA+Pj4+Pj4gICAgY29udmV5 aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0aGUgc2VydmljZSANCj4+ID4+ID4g Pj4+Pj4+IGZ1bmN0aW9uDQo+PiA+PiA+ID4+Pj4gcGF0aCwNCj4+ID4+ID4gPj4+Pj4+ICAgIGFu ZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gDQo+PiA+PiA+ ID4+Pj4+PiBub2Rlcw0KPj4gdGhhdA0KPj4gPj4gPiA+Pj4+Pj4gICAgaW1wbGVtZW50IHNlcnZp Y2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0KPj4gPj4gPiA+Pj4+IGVuY2Fw c3VsYXRpb24NCj4+ID4+ID4gPj4+Pj4+ICAgIGJlIGFnbm9zdGljIHRvIHRoZSBsYXllciBhdCB3 aGljaCBpdCBpcyBhcHBsaWVkIGFuZCANCj4+ID4+ID4gPj4+Pj4+IHRoZSBzZXJ2aWNlDQo+PiA+ PiA+ID4+Pj4gdGhhdA0KPj4gPj4gPiA+Pj4+Pj4gaXMNCj4+ID4+ID4gPj4+Pj4+ICAgIGJlaW5n IGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1heSANCj4+ID4+ ID4gPj4+Pj4+IGJlDQo+PiA+PiA+IHVzZWQNCj4+ID4+ID4gPj4gb24NCj4+ID4+ID4gPj4+Pj4+ ICAgIGEgc2VydmljZSBmdW5jdGlvbiBwYXRoIHJlYWxpemVkIGF0IHRoZSBuZXR3b3JrIGxheWVy IA0KPj4gPj4gPiA+Pj4+Pj4gb3IgYXQgYW55IG90aGVyDQo+PiA+PiA+ID4+Pj4+PiAgICBsYXll ciwgYW5kIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBmb3IgdGhlDQo+PiA+PiA+ ID4+IGNvbnN0cnVjdGlvbg0KPj4gPj4gPiA+Pj4+IG9mDQo+PiA+PiA+ID4+Pj4+PiAgICBzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbCBzZXJ2aWNlLg0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFtTTV0gV2hhdCBkb2VzIGl0IG1lYW4gYnkgYSBz aW5nbGUgc2VydmljZS1sZXZlbCANCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24sDQo+PiA+ PiA+IGENCj4+ID4+ID4gPj4+PiBuZXcNCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24gZm9y bWF0DQo+PiA+PiA+ID4+Pj4+PiAgICAgICAgICAgIG9yIGFuIGFiaWxpdHkgdG8gc2VsZWN0IG9u ZSBlbmNhcHN1bGF0aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gZm9ybWF0IHRoYXQNCj4+ID4+ID4gPj4+ PiBmaXRzDQo+PiA+PiA+ID4+Pj4+PiB0aGUNCj4+ID4+ID4gPj4+Pj4+IG5lZWQgZm9yIGEgZ2l2 ZW4gc2VydmljZSBjaGFpbj8NCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgICBUaGUgYWJpbGl0eSB0 byBzZWxlY3QgYSBzcGVjaWZpYyBlbmNhcHN1bGF0aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gd291bGQg YmUNCj4+ID4+ID4gPj4gYQ0KPj4gPj4gPiA+Pj4+Pj4gbWFuYWdlbWVudCBwbGFuZSBkZWNpc2lv bi4NCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgIFRoZXJlIGFyZSBxdWl0ZSBhIGZldyBleGlzdGlu ZyBlbmNhcHN1bGF0aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gbWV0aG9kcyB0aGF0DQo+PiA+PiA+ID4+ Pj4gY2FuDQo+PiA+PiA+ID4+Pj4+PiBwb3NzaWJseSBiZSByZXVzZWQgdG8gcHJvdmlkZQ0KPj4g Pj4gPiA+Pj4+Pj4gICAgICAgICAgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuICAgc2Vydmlj ZSBub2Rlcy4gSSBoYXZlDQo+PiA+PiA+IHNlZW4NCj4+ID4+ID4gPj4+Pj4+IG1lbnRpb24NCj4+ ID4+ID4gPj4+Pj4+IG9mIEdSRSwgZm9yIEhUVFAgYmFzZWQNCj4+ID4+ID4gPj4+Pj4+ICAgICAg ICAgIGFwcGxpY2F0aW9ucyBjb250ZXh0cyBhcmUgdHJhbnNmZXJyZWQgdmlhIGhlYWRlcnMuDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSANCj4+ID4+ID4gPj4+Pj4+IE9uIEJlaGFs Zg0KPj4gPj4gPiA+PiBPZg0KPj4gPj4gPiA+Pj4+Pj4gVGhvbWFzIE5hcnRlbg0KPj4gPj4gPiA+ Pj4+Pj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwNiwgMjAxMyAxMTowNyBBTQ0KPj4gPj4g PiA+Pj4+Pj4gVG86IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogW25zY10g Q3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+ Pj4+IEhpLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEN1cnJlbnQgY2hhcnRlciBj YW4gYmUgZm91bmQgYXQNCj4+ID4+ID4gPj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2NoYXJ0ZXItDQo+PiA+PiA+ID4+Pj4+PiBpZXRmLXNmYy8uDQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gSXQgY29udGFpbnMgdGhlIHJldmlzZWQgbWFuYWdlbWVudCB0ZXh0 IGFzIHdlbGwgYXMgDQo+PiA+PiA+ID4+Pj4+PiB1cGRhdGVkDQo+PiA+PiA+ID4+Pj4gbWlsZXN0 b25lcy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBbGwga25vd24gaXNzdWVzIGhh dmUgYmVlbiBhZGRyZXNzZWQuIElmIHRoZXJlIGFyZSBhbnkgDQo+PiA+PiA+ID4+Pj4+PiByZW1h aW5pbmcNCj4+ID4+ID4gPj4+PiBpc3N1ZXMsDQo+PiA+PiA+ID4+Pj4+PiBwbGVhc2Ugc3BlYWsg dXAhDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQ2hhcnRlciBjaGFydGVyLWlldGYt c2ZjLTAwLTA0DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gTmV0d29ya3MsIHNlcnZl cnMsIHN0b3JhZ2UgdGVjaG5vbG9naWVzLCBhbmQgDQo+PiA+PiA+ID4+Pj4+PiBhcHBsaWNhdGlv bnMsIGhhdmUgYWxsIHVuZGVyZ29uZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gDQo+PiA+PiA+ID4+ Pj4+PiByZWNlbnQgeWVhcnMgd2l0aCB0aGUgaW50cm9kdWN0aW9uDQo+PiA+PiA+ID4+IG9mDQo+ PiA+PiA+ID4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9yY2hl c3RyYXRpb24uDQo+PiA+PiA+ID4+Pj4+PiBTZXJ2aWNlDQo+PiA+PiA+ID4+IGRlbGl2ZXJ5DQo+ PiA+PiA+ID4+Pj4gaXMNCj4+ID4+ID4gPj4+Pj4+IGN1cnJlbnRseSBib3RoIGEgdGVjaG5pY2Fs IGFuZCBvcmdhbml6YXRpb25hbCBjaGFsbGVuZ2UgDQo+PiA+PiA+ID4+Pj4+PiB0aGF0DQo+PiA+ PiA+ID4+IGludm9sdmVzDQo+PiA+PiA+ID4+Pj4+PiBzaWduaWZpY2FudCBtb2RpZmljYXRpb24g dG8gdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbi4NCj4+ID4+ID4gPj4+Pj4+IFNlcnZpY2VzIGFy ZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQgDQo+PiA+PiA+ID4+Pj4+PiBj b21iaW5hdGlvbiBvZiBhIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSANCj4+ ID4+ID4gPj4+Pj4+IGRlcGxveWVkIGF0IGRpZmZlcmVudCBwb2ludHMgd2l0aGluDQo+PiA+PiA+ ID4+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEgY29tbW9uIGRlcGxveW1l bnQgbW9kZWwgaGFzIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbnMgcGh5c2ljYWxs eSBpbnNlcnRlZCBvbiB0aGUgZGF0YSBmb3J3YXJkaW5nIHBhdGggDQo+PiA+PiA+ID4+Pj4+PiBi ZXR3ZWVuIGNvbW11bmljYXRpbmcgcGVlcnMuDQo+PiA+PiA+ID4+Pj4gR29pbmcNCj4+ID4+ID4g Pj4+Pj4+IGZvcndhcmQsIGhvd2V2ZXIsIHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdG8gYSAN Cj4+ID4+ID4gPj4+Pj4+IGRpZmZlcmVudCBtb2RlbCwNCj4+ID4+ID4gPj4+PiB3aGVyZQ0KPj4g Pj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byByZXNpZGUg b24gdGhlIA0KPj4gPj4gPiA+Pj4+Pj4gZGVmYXVsdCBkYXRhDQo+PiA+PiA+ID4+IHBhdGgNCj4+ ID4+ID4gPj4+Pj4+IGFuZA0KPj4gPj4gPiA+Pj4+Pj4gdHJhZmZpYyBpcyBpbnN0ZWFkIHN0ZWVy ZWQgdGhyb3VnaCBzZXJ2aWNlcywgd2hlcmV2ZXIgDQo+PiA+PiA+ID4+Pj4+PiB0aGV5IGFyZQ0K Pj4gPj4gPiA+Pj4+IGRlcGxveWVkLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEZv ciBhIGdpdmVuIHNlcnZpY2UsIHRoZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlIHJlcXVpcmVkIA0K Pj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgYW5kIHRoZSBvcmRlciBpbiB3aGljaCB0 aGV5IGFyZSB0byBiZSANCj4+ID4+ID4gPj4+Pj4+IGFwcGxpZWQgaXMNCj4+ID4+ID4gY2FsbGVk DQo+PiA+PiA+ID4+Pj4+PiBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQykuIFNpbmNlIGEg Z2l2ZW4gc2VydmljZSANCj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9uIG1heSBiZSBhdmFpbGFibGUg b24gbW9yZSB0aGFuIG9uZSBub2RlIHdpdGhpbiBhIA0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yaywg YSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIGlzIGluc3RhbnRpYXRlZA0KPj4gPj4gPiA+Pj4+IHZp YQ0KPj4gPj4gPiA+Pj4+Pj4gdGhlIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlcyBhbmQgDQo+PiA+PiA+ID4+Pj4+PiB0aGUgbmV0d29yayBub2RlcyBvbiB3 aGljaCB0aGV5IGFyZSBwcm92aWRlZCwgdGhlcmVieSANCj4+ID4+ID4gPj4+Pj4+IGZvcm1pbmcg YSBzZXJ2aWNlIHRvcG9sb2d5Og0KPj4gPj4gPiA+Pj4+Pj4gdGhpcyBpcyBjYWxsZWQgYSBTZXJ2 aWNlIEZ1bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb25z DQo+PiA+PiA+IG1heQ0KPj4gPj4gPiA+Pj4+Pj4gYmUgYXBwbGllZCBhdCBhIHNwZWNpZmljIGxh eWVyIHdpdGhpbiB0aGUgbmV0d29yayANCj4+ID4+ID4gPj4+Pj4+IHByb3RvY29sIHN0YWNrDQo+ PiA+PiA+ID4+Pj4gKG5ldHdvcmsNCj4+ID4+ID4gPj4+Pj4+IGxheWVyLCBhcHBsaWNhdGlvbiBs YXllciwgZXRjLikuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gVGhlIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgd29ya2luZyBncm91cCB3aWxsIA0KPj4gPj4gPiA+Pj4+ Pj4gZGV2ZWxvcCBuZXcgYXBwcm9hY2hlcyB0byBzZXJ2aWNlIGRlbGl2ZXJ5IGFuZCBkZXBsb3lt ZW50Lg0KPj4gPj4gPiA+Pj4+Pj4gSXQgd2lsbCBwcm9kdWNlIGEgZnJhbWV3b3JrIGZvciBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluaW5nIA0KPj4gPj4gPiA+Pj4+Pj4gdGhhdCBpbmNsdWRlcyB0aGUg bmVjZXNzYXJ5IHByb3RvY29scw0KPj4gPj4gPiA+Pj4+IG9yDQo+PiA+PiA+ID4+Pj4+PiBwcm90 b2NvbCBleHRlbnNpb25zIHRvIGNvbnZleSB0aGUgc2VydmljZSBwYXRoIGFuZCANCj4+ID4+ID4g Pj4+Pj4+IHNlcnZpY2UgcGF0aCBpbmZvcm1hdGlvbiB0byBub2RlcyB0aGF0IGltcGxlbWVudCBz ZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb25zLCBhcyB3ZWxsDQo+PiA+PiA+IGFzDQo+ PiA+PiA+ID4+Pj4+PiBtZWNoYW5pc21zIGZvciBzdGVlcmluZyB0cmFmZmljIHRocm91Z2ggc2Vy dmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+Pj4+PiBUaGUNCj4+ID4+ID4gPj4+PiB3b3JraW5n DQo+PiA+PiA+ID4+Pj4+PiBncm91cCB3aWxsIGFsc28gZXhhbWluZSB3aGF0IGluZm9ybWF0aW9u IG5lZWRzIHRvIGJlIA0KPj4gPj4gPiA+Pj4+Pj4gZ2F0aGVyZWQgZnJvbQ0KPj4gPj4gPiA+Pj4+ IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yayBhbmQgc2VydmljZSBmdW5jdGlvbnMgaW4gc3Vw cG9ydCBvZiBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb24NCj4+ID4+ID4gPj4gY2hh aW5pbmcNCj4+ID4+ID4gPj4+Pj4+IGFuZA0KPj4gPj4gPiA+Pj4+Pj4gaG93IHRoYXQgaW5mb3Jt YXRpb24gbWF5IGJlIG1hZGUgYXZhaWxhYmxlIHRvIG5vZGVzIHRoYXQgDQo+PiA+PiA+ID4+Pj4+ PiBpbXBsZW1lbnQNCj4+ID4+ID4gPj4+PiB0aGUNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVu Y3Rpb25zLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFNwZWNpZmljYWxseSwgdGhl IFNGQyBXRyBpcyBjaGFydGVyZWQgdG8gZGVsaXZlciB0aGUNCj4+IGZvbGxvd2luZzoNCj4+ID4+ ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAxKSBQcm9ibGVtIFN0YXRlbWVudDogVGhpcyBkb2N1 bWVudCB3aWxsIHByb3ZpZGUgYSANCj4+ID4+ID4gPj4+Pj4+IHN1bW1hcnkgb2YNCj4+ID4+ID4g dGhlDQo+PiA+PiA+ID4+Pj4+PiAgICBwcm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0 aGUgV0cgaW5jbHVkaW5nIA0KPj4gPj4gPiA+Pj4+Pj4gZXhhbXBsZQ0KPj4gPj4gPiBoaWdoLQ0K Pj4gPj4gPiA+Pj4+Pj4gICAgbGV2ZWwgdXNlIGNhc2VzLiBBZGRpdGlvbmFsbHksIHRoZSBXRyB3 aWxsIG5vcm1hbGl6ZQ0KPj4gPj4gPiA+PiBub21lbmNsYXR1cmUNCj4+ID4+ID4gPj4+Pj4+ICAg IGFuZCBkZWZpbml0aW9ucyBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4NCj4+ID4+ID4g Pj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAyKSBBcmNoaXRlY3R1cmU6IFRoaXMgZG9jdW1lbnQgd2ls bCBwcm92aWRlIGEgZGVzY3JpcHRpb24gDQo+PiA+PiA+ID4+Pj4+PiBvZg0KPj4gPj50aGUNCj4+ ID4+ID4gPj4+Pj4+ICAgIGFyY2hpdGVjdHVyYWwgYnVpbGRpbmcgYmxvY2tzIGFuZCB0aGVpciBy ZWxhdGlvbnNoaXBzDQo+PiA+PiA+IGluY2x1ZGluZw0KPj4gPj4gPiA+Pj4+Pj4gICAgaW50ZXJj b25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVzLCBtYW5hZ2VtZW50LA0KPj4gPj4g PiA+Pj4+Pj4gICAgZGlhZ25vc3RpY3MsIGRlc2lnbiBhbmFseXNpcywgYW5kIHNlY3VyaXR5IG1v ZGVscywgYXMgDQo+PiA+PiA+ID4+Pj4+PiB3ZWxsDQo+PiA+PmFzDQo+PiA+PiA+ID4+Pj4+PiAg ICByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gMykgR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIEVu Y2Fwc3VsYXRpb246IEEgDQo+PiA+PiA+ID4+Pj4+PiBkb2N1bWVudA0KPj4gPj4gPiB3aWxsDQo+ PiA+PiA+ID4+Pj4+PiAgICBkZXNjcmliZSB0aGUgc2luZ2xlIHNlcnZpY2UtbGV2ZWwgZGF0YSBw bGFuZSANCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+ID4+ID4gPj4gZm9ybWF0DQo+ PiA+PiA+ID4+Pj4+PiBmb3INCj4+ID4+ID4gPj4+Pj4+ICAgIGNvbnZleWluZyB0aGUgc2Vydmlj ZSBmdW5jdGlvbiBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlv bg0KPj4gPj4gPiA+Pj4+IHBhdGgsDQo+PiA+PiA+ID4+Pj4+PiAgICBhbmQgZm9yIGNvbW11bmlj YXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIA0KPj4gPj4gPiA+Pj4+Pj4gbm9kZXMN Cj4+IHRoYXQNCj4+ID4+ID4gPj4+Pj4+ICAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4g SXQgaXMgaW50ZW5kZWQgdGhhdCB0aGUNCj4+ID4+ID4gPj4+PiBlbmNhcHN1bGF0aW9uDQo+PiA+ PiA+ID4+Pj4+PiAgICBiZSBhZ25vc3RpYyB0byB0aGUgbGF5ZXIgYXQgd2hpY2ggaXQgaXMgYXBw bGllZCBhbmQgDQo+PiA+PiA+ID4+Pj4+PiB0aGUgc2VydmljZQ0KPj4gPj4gPiA+Pj4+IHRoYXQN Cj4+ID4+ID4gPj4+Pj4+IGlzDQo+PiA+PiA+ID4+Pj4+PiAgICBiZWluZyBjb25zdHJ1Y3RlZC4g VGhhdCBpcywgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiBtYXkgDQo+PiA+PiA+ID4+Pj4+PiBiZQ0K Pj4gPj4gPiB1c2VkDQo+PiA+PiA+ID4+IG9uDQo+PiA+PiA+ID4+Pj4+PiAgICBhIHNlcnZpY2Ug ZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yayBsYXllciANCj4+ID4+ID4gPj4+ Pj4+IG9yIGF0IGFueSBvdGhlcg0KPj4gPj4gPiA+Pj4+Pj4gICAgbGF5ZXIsIGFuZCB0aGUgc2Ft ZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4gPj4gPiA+PiBjb25zdHJ1Y3Rp b24NCj4+ID4+ID4gPj4+PiBvZg0KPj4gPj4gPiA+Pj4+Pj4gICAgc2VydmljZSBmdW5jdGlvbiBw YXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+PiA0KSBDb250cm9sIFBsYW5lIE1lY2hhbmlzbXM6IEEgc2V0IG9mIGRvY3Vt ZW50cyB3aWxsIGJlDQo+PiA+PiA+IGRldmVsb3BlZCB0bw0KPj4gPj4gPiA+Pj4+Pj4gICAgZGVz Y3JpYmUgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbHMgbmVjZXNzYXJ5IHRvIA0KPj4gPj4gPiA+ Pj4+Pj4gY29udmV5DQo+PiA+PiA+ID4+Pj4gaW5mb3JtYXRpb24NCj4+ID4+ID4gPj4+Pj4+ICAg IHRvIHNlcnZpY2UgZnVuY3Rpb24gaW1wbGVtZW50YXRpb24gcG9pbnRzLiBXaGVyZSANCj4+ID4+ ID4gPj4+Pj4+IHBvc3NpYmxlLA0KPj4gPj4gPiA+Pj4+IGV4aXN0aW5nDQo+PiA+PiA+ID4+Pj4+ PiAgICBJRVRGIHByb3RvY29scyB3aWxsIGJlIHVzZWQgYW5kIGV4dGVuZGVkLiBBbGwgcHJvdG9j b2wNCj4+ID4+ID4gPj4gZXh0ZW5zaW9ucw0KPj4gPj4gPiA+Pj4+Pj4gICAgd29yayBzaG91bGQg YmUgY2FycmllZCBvdXQgaW4gdGhlIHdvcmtpbmcgZ3JvdXBzIA0KPj4gPj4gPiA+Pj4+Pj4gcmVz cG9uc2libGUgZm9yDQo+PiA+PiA+ID4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4+PiAgICBwcm90b2Nv bHMgYmVpbmcgbW9kaWZpZWQgaW4gY29vcmRpbmF0aW9uIHdpdGggdGhpcyANCj4+ID4+ID4gPj4+ Pj4+IHdvcmtpbmcNCj4+ID4+ID4gPj4gZ3JvdXAsDQo+PiA+PiA+ID4+Pj4+PiBidXQNCj4+ID4+ ID4gPj4+Pj4+ICAgIG1heSBiZSBkb25lIGluIHRoaXMgd29ya2luZyBncm91cCBhZnRlciBhZ3Jl ZW1lbnQgd2l0aCANCj4+ID4+ID4gPj4+Pj4+IGFsbA0KPj4gPj4gPiB0aGUNCj4+ID4+ID4gPj4+ Pj4+ICAgIHJlbGV2YW50IFdHIGNoYWlycyBhbmQgcmVzcG9uc2libGUgQURzLg0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IDUpIE1hbmFnZWFiaWxpdHk6IFdvcmsgb24gdGhlIG1hbmFn ZW1lbnQgYW5kIA0KPj4gPj4gPiA+Pj4+Pj4gY29uZmlndXJhdGlvbiBvZg0KPj4gPj4gPiA+PiBz ZXJ2aWNlDQo+PiA+PiA+ID4+Pj4+PiAgICBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBTRkMgY29t cG9uZW50cyB3aWxsIGNlcnRhaW5seSANCj4+ID4+ID4gPj4+Pj4+IGJlDQo+PiA+PiA+IG5lZWRl ZCwNCj4+ID4+ID4gPj4+Pj4+ICAgIGJ1dCBmaXJzdCBuZWVkcyB0byBiZSBiZXR0ZXIgdW5kZXJz dG9vZCBhbmQgc2NvcGVkLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFByb3Bvc2Vk IE1pbGVzdG9uZXMNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBcHIgMjAxNCBTdWJt aXQgdG8gSUVTRyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50KHMpIA0KPj4gPj4gPiA+Pj4+Pj4gZGVm aW5pbmcgdGhlDQo+PiA+PiA+ID4+Pj4gcHJvYmxlbQ0KPj4gPj4gPiA+Pj4+Pj4gc3RhdGVtZW50 IGFuZCBjb3JlIHVzZSBjYXNlcyBmb3IgU2VydmljZSBGdW5jdGlvbiANCj4+ID4+ID4gPj4+Pj4+ IENoYWluaW5nDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gTWF5IDIwMTQgQ29uc3Vs dCB3aXRoIE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNoYXJ0ZXIgDQo+PiA+PiA+ID4+Pj4+PiBtb2Rp ZmljYXRpb25zIGZvciBtYW5hZ2VtZW50IGFuZCBjb25maWd1cmF0aW9uIG9mIFNGQyANCj4+ID4+ ID4gPj4+Pj4+IGNvbXBvbmVudHMNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBKYW4g MjAxNSBTdWJtaXQgdG8gSUVTRyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IGRlZmluaW5nIA0KPj4g Pj4gPiA+Pj4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4gYXJjaGl0ZWN0dXJlDQo+PiA+PiA+ID4+Pj4+ PiBmb3IgU0ZDDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gSmFuIDIwMTUgU3VibWl0 IHRvIElFU0cgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVyaWMgDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCj4+ID4+ID4gPj4+ Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBdWcgMjAxNSBTdWJtaXQgdG8gSUVTRyBTdGFuZGFyZHMgVHJh Y2sgZG9jdW1lbnQgDQo+PiA+PiA+ID4+Pj4+PiBzcGVjaWZ5aW5nIHRoZQ0KPj4gPj4gPiA+Pj4+ IGdlbmVyaWMNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaGVhZGVy IGVuY2Fwc3VsYXRpb24NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gVGhv bWFzDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gPj4+Pj4+IG5zYyBtYWlsaW5nIGxp c3QNCj4+ID4+ID4gPj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+Pj4+PiBu c2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+ID4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+ Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ID4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g Pj4gPiA+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiA+Pj4+Pj4gbnNjQGlldGYub3Jn DQo+PiA+PiA+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPj4gPj4gPiA+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPj4gPiA+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+ID4+Pj4+IG5z Y0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPj4gPj4gPiA+DQo+PiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4g bnNjQGlldGYub3JnDQo+PiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbnNjDQo+PiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiA+PiA+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gbnNjQGlldGYub3JnDQo+ PiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gbnNjQGlldGYub3JnDQo+PiA+PiA+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pg0KPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ IG5zY0BpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u c2MNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5z YyBtYWlsaW5nIGxpc3QNCj5uc2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From S.Majee@f5.com Wed Nov 13 12:30:15 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E2921E80C0 for ; Wed, 13 Nov 2013 12:30:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sSzMiFw6K5Z for ; Wed, 13 Nov 2013 12:30:11 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id D411811E8107 for ; Wed, 13 Nov 2013 12:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1384374611; x=1415910611; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=vAj7Xs98onlvNtXlvyO0ASPvXmJa0Bv7GEMp7qjQBjY=; b=Y5JcdtAP6/8zybUS5y7XYxKOLmqvEqEgBeDxDoxk9s3BR3Y3sxzCETnX 6sIdOI5GFnkZrpZkZRGUyOhkN9dONlCf2t08YIdstsZXCSCf9tHSdPtdm kGEMm0MDJEIeMj7zDNIG2tOgZDuLq83e1c/i5QE/mqPOF8qteIiBsFOAa s=; X-IronPort-AV: E=Sophos;i="4.93,693,1378857600"; d="scan'208";a="86810624" X-IPAS-Result: AqQEAKPgg1LAqArr/2dsb2JhbABPCoM/U78sgT50giUBAQEBAwEBARcBHysCBwQTBgEIDQEDAQMBAQEKCwkJLgsUAwQBAQUEAQQBCQkIAYgFwBsXjhwEAQUGgQIGNAQEgxaBEQOULopGjk+BaAEIOQ Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 13 Nov 2013 20:30:09 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 13 Nov 2013 12:30:08 -0800 From: Sumandra Majee To: Dave Dolson , "nsc@ietf.org" Thread-Topic: [nsc] Classification and Brancing NOT Current Proposed SFC charter Thread-Index: Ac7gryNZ0siVpiX7QaS76hwysoaJiw== Date: Wed, 13 Nov 2013 20:30:07 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E4160988491AFFC@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [nsc] FW: Classification and Brancing NOT Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 20:30:15 -0000 Cleaned up the TO list, so it doesn't bounce. Sorry if this is duplicate. -----Original Message----- From: Sumandra Majee=20 Sent: Tuesday, November 12, 2013 9:36 PM To: Dave Dolson; Jim Guichard (jguichar); David Lake (dlake); Kevin J Ma; S= urendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org Subject: RE: [nsc] Current Proposed SFC charter I think there is great simplicity to be had by limiting the path selection = to the ingress node (i.e., the one who first puts the SFC header on). [SM] I would tend to agree that initial path selection should begin at ingr= ess. However an application classification is a continuous process. It coul= d take a few packets on the response side to classify if this is a video, t= he type, coded rate and tie this with device screen size which could then s= elect a proper video optimizer. Such device would also hold on to the respo= nse as opposed streaming, to make this content available to the optimizer. = It could use the HTTP redirect method but that does waste RAN bandwidth. Mi= nor implementation detail not really important for WG I think there is a general confusion or may be it is mine only, a) What are the classification point and by classification I don't mean D= PI and signatures. It could be dst port or dst_ip address. Say a service is= aware of IP pools used by a popular music streaming service and it could t= hen add this extra classification result. This could be encap modification = or could trigger a new tunnel to some other service endpoint.=20 b) Is SFC inline network element? The question around Sd interface to PCRF= suggests that it is. However there would be less control over data when it= is out of band, that is simply the unfortunate truth about network real es= tate. c) Chain. How do we create these chain, graphs that are pre created. I can= argue that with increasing number of nodes that will be messy. Another opt= ion is to create a few useful chains and allow nodes to branch off to a dif= ferent node forward or JMP to a new chainID. This could limit the number of= configs object. This also implies that policy is distributed around ... wh= at? Regards. Sumandra ________________________________________ From: Dave Dolson [ddolson@sandvine.com] Sent: Tuesday, November 12, 2013 11:48 AM To: Jim Guichard (jguichar); David Lake (dlake); Kevin J Ma; Surendra Kumar= (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter I think there is great simplicity to be had by limiting the path selection = to the ingress node (i.e., the one who first puts the SFC header on). I believe this because of the requirement of many layer4-7 devices to see s= ymmetric paths. (e.g., {DPI2, NAT7, ContentControl11} on the way out and {C= ontentControll11, NAT7, DPI2} on the way back) I think it will be really hard to manage this if each device in the chain c= an select an arbitrary (policy-selected) next-hop. I think each packet's ne= xt hop and ID needs to determined by the received ID. Otherwise, I'm curious how others see the symmetric path problem being mana= ged? (Apologies if I'm mangling the terminology) David Dolson Software Architect, Sandvine Inc. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Tuesday, November 12, 2013 2:01 PM To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter The assumption is that classification may be performed at the network and/o= r application layer and that classification will be based on policy of some= description. When we work through control plane aspects of the SFC charter= presumably what policy needs to be generated and by what to where is part = of the work item. Further, branching will occur because of a reclassificati= on but reclassification may or may not force a branch from one chain to ano= ther. On 11/12/13 1:51 PM, "David Lake (dlake)" wrote: >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is=20 >defined/set even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to=20 >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative=20 >domain for some of the very reasons you point out. We need to keep=20 >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism=20 >>(recursive because a user-land application will ride with a specific=20 >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this=20 >>multi-domain issue - if I set a policy as a user, chances are I will=20 >>be crossing several domain boundaries. Are we expecting the service=20 >>headers to define the service chaining for the duration of the entire=20 >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the=20 >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty=20 >>relevant to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong=20 >>> mapping between Policy and the inserted Service Header(s), we=20 >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per=20 >>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to=20 >>> redefine it - it's been around for all the time middle boxes have=20 >>> been or for that matter the L2/L3 devices. All we are talking about=20 >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of=20 >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a=20 >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a=20 >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a=20 >>> > chain is different than I originally inferred. If the chain is a=20 >>> > tree with other "branching" points in it, then that limits the=20 >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation=20 >>> > could define bad service chains, is it the intent of SFC to only=20 >>> > look at the simpler packet-level classification cases, or is it=20 >>> > the intent to consider the case where a branching point is viewed=20 >>> > as a re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D=20 >>> >>reclassification, agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be=20 >>> >> in a form of logic on a service function. Some service functions,=20 >>> >> especially L7 based, can use value in a Database to determine=20 >>> >> what is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after=20 >>> >> > been processed by a certain service function, decision of which=20 >>> >> > branches to go is made based on the result of service=20 >>> >> > function's process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The=20 >>> >> > details around how to convey the selection of the=20 >>> >> > subtree/subgraph are still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and=20 >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question=20 >>> >> > > about service header encapsulation, is it intended that a=20 >>> >> > > chain that is re-classified will get a new chain ID which=20 >>> >> > > fully describes a chain that is a superset of the original=20 >>> >> > > chain ID, prior to DPI-based re-classification? (assuming=20 >>> >> > > the goal is "a single chain ID that is commonly understood=20 >>> >> > > along the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>> >> > > l >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service=20 >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>> >> > > every flow then be initially classified as ID 1, but=20 >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of=20 >>> >> > >>> service that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification=20 >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the=20 >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the=20 >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is=20 >>> >> > >>> limited due to limitations in classification, that would be=20 >>> >> > >>> and important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >>> >> > >>> fork points of the service paths seem like=20 >>> >> > >>> re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive=20 >>> >> > >>> of DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general,=20 >>> >> > >> as described in the arch draft, the collection of services=20 >>> >> > >> form a graph, segments of which are service paths. Yes,=20 >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any=20 >>> >> > >> node along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental=20 >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is=20 >>> >> > >>>> that such classification aids in traffic selection and=20 >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except=20 >>> >> > >>>> that the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network=20 >>> >> > >>>> elements but the service functions as well. Some of this=20 >>> >> > >>>> is described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied=20 >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume=20 >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service=20 >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network=20 >>> >> > >>>>> or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some=20 >>> >> > >>>>> of) the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies=20 >>> >> > >>>>> packets based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such=20 >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID,=20 >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework=20 >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service=20 >>> >> > >>>>> function identifier lookup does not seem to be a=20 >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified=20 >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to=20 >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach=20 >>> >> > >>>>>> for every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its=20 >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one=20 >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction=20 >>> >> > >>>>>> of the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC=20 >>> >> > >>>>>> header or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow=20 >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service=20 >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which=20 >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to=20 >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP=20 >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the=20 >>> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >>> >> > >>>>>> imply immutability, but rather to specify the packet=20 >>> >> > >>>>>> that is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation=20 >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation=20 >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation=20 >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as=20 >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>> >> > >>>>>> applications, have all undergone significant change in=20 >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge=20 >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered=20 >>> >> > >>>>>> combination of a number of service functions that are=20 >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service=20 >>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>> >> > >>>>>> path between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the=20 >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>> >> > >>>>>> service functions and the order in which they are to be=20 >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>> >> > >>>>>> function may be available on more than one node within a=20 >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and=20 >>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function=20 >>> >> > >>>>>> chaining that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>> >> > >>>>>> description of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>> >> > >>>>>> protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement=20 >>> >> > >>>>>> with all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From niulehong@huawei.com Wed Nov 13 17:30:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E2F921E8098 for ; Wed, 13 Nov 2013 17:30:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.789 X-Spam-Level: ** X-Spam-Status: No, score=2.789 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8AHnDsJL-IP for ; Wed, 13 Nov 2013 17:29:56 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B27211E8121 for ; Wed, 13 Nov 2013 17:29:54 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAG33084; Thu, 14 Nov 2013 01:29:51 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 01:28:50 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 01:29:47 +0000 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.231]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 09:29:35 +0800 From: Niulehong To: David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQAA72NwAAC6NWAAAkKmLQ Date: Thu, 14 Nov 2013 01:29:34 +0000 Message-ID: <4040FE44D74FA042A7C2595F696FD1227FA10CA3@SZXEMA502-MBS.china.huawei.com> References: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.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.66.98.253] Content-Type: multipart/alternative; boundary="_000_4040FE44D74FA042A7C2595F696FD1227FA10CA3SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nsc] =?gb2312?b?tPC4tDogIEZXOiAgcmUgY2xhc3NpZmljYXRpb24gJiBicmFu?= =?gb2312?b?Y2hpbmcsIHdhczogQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg==?= X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 01:30:01 -0000 --_000_4040FE44D74FA042A7C2595F696FD1227FA10CA3SZXEMA502MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRGF2aWQsDQoNClNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2Ugc2VydmluZyBtdWx0aXBsZSBz ZXJ2aWNlIGNoYWlucyBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgYnJhbmNoaW5nIGZ1bmN0aW9uLg0K DQpGb3IgdGhlIGZvcm1lciAsIHBhY2tldKGvcyBwYXRoIGlkKCBzZXJ2aWNlIGNoYWluaW5nIGlk KSBmaWVsZCBvZiB0aGUgc2VydmljZSBjaGFpbmluZyBoZWFkZXIgaXMgbm90IGNoYW5nZWQgd2hp bGUgd2hvbGUgc3BlY2lmaWMgc2VydmljZSBjaGFpbqGvcyBwYWNrZXRzIHBhc3NpbmcgdGhyb3Vn aCB0aGUgc2VydmljZSBmdW5jdGlvbi4gVGhhdCBsaWtlcyBwYXJhbGxlbCByYWlsd2F5cyBwYXRo IHRocm91Z2ggdGhlIHJhaWx3YXkgc3RhdGlvbi4NCg0KRm9yIHRoZSBsYXRlciwgIGFmdGVyIHNl cnZpY2UgZnVuY3Rpb24gcHJvY2Vzc2luZywgcGFja2V0cyBiZWxvbmdzIHRvIHRoZSBzYW1lIHNl cnZpY2UgY2hhaW4gd2lsbCBiZSBjaGFuZ2VkIGFib3V0IHRoZWlyIGNvbW1vbiBwYXRoIGlkIHZh bHVlIHRvIHNldmVyYWwgZGlmZmVyZW50IHBhdGggaWQgdmFsdWVzIGFjY29yZGluZyB0aGUgc2Vy dmljZSBmdW5jdGlvbqGvcyBkZWNpc2lvbi4gVGhhdCBsaWtlcyBvbmUgcmFpbHdheSBmb3JrcyBz ZXZlcmFsIHJhaWx3YXlzIGFmdGVyIHRoZSByYWlsd2F5IHN0YXRpb24uDQoNCg0KDQpCZXN0IFJl Z2FyZHMNCg0KTGVob25nIE5pdQ0KDQoNCg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjL OiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSC0+rHt IERhdmlkIEFsbGFuIEkNCreiy83KsbzkOiAyMDEzxOoxMdTCMTPI1SAyMzo0NQ0KytW8/sjLOiBI b25neXUgTGkgKEp1bGlvKTsgbnNjQGlldGYub3JnDQrW98ziOiBSZTogW25zY10gRlc6IHJlIGNs YXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0 ZXINCg0KDQoNCkhJIEhvbmd5dToNCg0KDQoNCkkgdGhpbmsgd2Ugd2lsbCBoYXZlIHNjZW5hcmlv cyB3aGVyZSBhIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFycyBpbiBtb3JlIHRoYW4gb25lIGNoYWlu LCBhcyB3b3VsZCBiZSB0aGUgY2FzZSwgZm9yIGV4YW1wbGUsIGlmIHNvbWUgZmxvd3MgY291bGQg ZHluYW1pY2FsbHkgYnlwYXNzIERQSSBidXQgc3RpbGwgbmVlZGVkIHRvIHRyYW5zaXQgYSBjb21t b24gc2V0IG9mIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25zLi4uDQoNCg0KDQpPbmNlIHlvdSBw b3N0dWxhdGUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIGFwcGVhcmluZyBpbiBtb3JlIHRo YW4gb25lIGNoYWluLCBpdCBzZWVtcyBhcnRpZmljaWFsbHkgcmVzdHJpY3RpdmUgbm90IHRvIHBl cm1pdCBzdWNoIGEgZnVuY3Rpb24gdG8gYWxzbyBpbXBsZW1lbnQgYnJhbmNoaW5nLCBhbGwgdGhl IGNvbnRyb2wgc3RydWN0dXJlcyB3b3VsZCBhbHJlYWR5IGJlIHRoZXJlLg0KDQoNCg0KUmdkcw0K DQpEYXZlDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBIb25neXUg TGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KDQpTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDEzLCAyMDEzIDI6MTIgQU0NCg0KVG86IERhdmlkIEFsbGFuIEk7IG5zY0Bp ZXRmLm9yZzxtYWlsdG86bnNjQGlldGYub3JnPg0KDQpTdWJqZWN0OiBSRTogW25zY10gRlc6IHJl IGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNo YXJ0ZXINCg0KDQoNCk1heSBJIHN1Z2dlc3Qgc3VtbWFyeSBvZiBteSB2aWV3cyBoZXJlOg0KDQoN Cg0KMS4gQnJhbmNoIGlzIGEgc29ydCBvZiB1c2UgY2FzZSBvciBzY2VuYXJpbywgd2hpbGUgcmVj bGFzc2lmaWNhdGlvbiBpcyBhIHdheSB0byBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KMi4gU2Vydmlj ZSBGdW5jdGlvbnMgc2hvdWxkIGJlIGRlY291cGxlZCB3aXRoIHRoZSBjaGFpbiBpdHNlbGYuDQoN CiAgICAgICAgIE1lYW5pbmcsIGEgU0Ygc2hhbGwgbm90ICpkaXJlY3RseSogaW1wYWN0IHRoZSBm b3J3YXJkaW5nIG9mIHBhY2tldHMgaW4gYSBjaGFpbi4gQnJhbmNoaW5nIHNob3VsZCBiZSBwZXJm b3JtZWQgYnkgY2hhaW4gZm9yd2FyZGluZyBub2RlcywgcG9zc2libHkgdW5kZXIgY29udHJvbCBv ZiBhIGNvbnRyb2wgbm9kZS4gVGhlIHJlYXNvbiBmb3IgdGhpcyBpcyBpbiBORlYgd29ybGQsIHNl cnZpY2UgZnVuY3Rpb25zIG1heSBjb21lIGZyb20gYSB0aGlyZCBwYXJ0eSwgd2hpbGUgY2hhaW4g aXMgcHJvdmlkZWQgYnkgdGhlIGluZnJhc3RydWN0dXJlIG9mIHRoZSBuZXR3b3JrLiBUaGVyZSBt dXN0IGJlIGEgY3VzaGlvbiBhdm9pZGluZyBhIHNlcnZpY2UgZnVuY3Rpb24gb3BlcmF0aW5nIGlu ZnJhc3RydWN0dXJlIGRpcmVjdGx5Lg0KDQozLiAoUmUpY2xhc3NpZmljYXRpb24gaXMgYmFzZWQg b24gaW5mbyBpbiBhIHBhY2tldC4NCg0KICAgICAgICAgVGhpcyBpcyB2ZXJ5IGdlbmVyYWwuIFN1 Y2ggaW5mbyBjb3VsZCBiZSBMMn5MNyBkZXJpdmVkIGZyb20gYSB1c2VyJ3MgcGFja2V0LCBhcyB3 ZWxsIGFzIHNvbWUgaW5mbyBsaWtlIG1ldGFkYXRhIGluIGEgU0ZDIGhlYWRlci4gQXMgY2xhc3Np ZmljYXRpb24gaXMgb3V0IG9mIHNjb3BlIG9mIFNGQywgd2UgZG9uJ3QgaGF2ZSB0byBwcm92aWRl IHRvbyBtdWNoIGRldGFpbHMgb2YgaG93IHRvIGRvIGNsYXNzaWZpY2F0aW9uLg0KDQo0LiBDaGFp biBzZWdtZW50cyBzdGl0Y2hpbmcgaXMgcmVsYXRpdmVseSBhIGVhc3kgd2F5IGZvciBicmFuY2hp bmcuIENvbXBhcmVkIHdpdGggY2hhaW5zIGFuZCBzdWJjaGFpbnMsIHdoaWNoIG1heSByZXF1aXJl IGEgbW9yZSBjb21wbGV4IGhlYWRlciBhbmQgZm9yd2FyZGluZyBjYXBhYmlsaXRpZXMuDQoNCk15 IHR3byBjZW50cy4NCg0KSG9uZ3l1DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K DQpGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZpZCBBbGxhbiBJ DQoNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIwMTMgMzowNCBBTQ0KDQpUbzogbnNj QGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFtuc2NdIEZXOiByZSBj bGFzc2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFy dGVyDQoNCg0KDQpIaToNCg0KKHJlc2VuZCB3aXRoIHJlY2lwaWVudCBsaXN0IGNsZWFuZWQgdXAp DQoNCg0KDQpJIGFncmVlIHdlIGFyZSBkaXNjdXNzaW5nIG11bHRpcGxlIGNvbmNlcHRzLCBjbGFz c2lmaWNhdGlvbiBhbmQgZmxvdy1zdWJzZXR0aW5nLiBQZXJoYXBzIG1vcmUgOy0pDQoNCg0KDQpE ZWZpbmluZyBhIGZsb3cgc3Vic2V0IGNhbiBiZSBhIHJlc3VsdCBvZiBjbGFzc2lmaWNhdGlvbiwg YnV0IGl0IGlzIG5vdCB0aGUgZXhjbHVzaXZlIG1lY2hhbmlzbS4gQnJhbmNoaW5nIGlzIGEgbWVj aGFuaXNtIGJ5IHdoaWNoIGZsb3cgc3Vic2V0cyBhcmUgZXhwb3NlZCBhbmQgbWFwcGVkIHRvIGEg c2V0IG9mIHN1YmNoYWlucyBzdWNoIHRoYXQgaXQgY2FuIGJlIGlkZW50aWZpZWQgaW4gdGhlIGRh dGFwbGFuZS4uLg0KDQoNCg0KVGhhdCdzIHRoZSB2aWV3IGZyb20gaGVyZQ0KDQpEYXZlDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBEYXZpZCBMYWtlIChkbGFrZSkNCg0KU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMTIsIDIwMTMgMTA6NTEgQU0NCg0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBL ZXZpbiBKIE1hOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IExpbmRhIER1 bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCg0KQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9y ZzxtYWlsdG86bnNjQGlldGYub3JnPjsgU3VtYW5kcmEgTWFqZWUNCg0KU3ViamVjdDogUmU6IFtu c2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KDQoNClVuZGVyc3Rvb2QgLSBtYXli ZSBqdXN0IGEgbGl0dGxlIGxvY2FsaXNlZCB3YXJtaW5nIG9mIHRoZSBzZWEgdGhlbiA/ICAgQnV0 IEkgc3RpbGwgdGhpbmsgd2UgbmVlZCB0byBjb25zaWRlciB3aGVyZSBhbmQgaG93IHBvbGljeSBp cyBkZWZpbmVkL3NldCBldmVuIGZvciB0aGUgc2luZ2xlLWRvbWFpbiBpbnN0YW5jZS4NCg0KDQoN CkkgZG9uJ3QgdGhpbmsgd2UgY2FuIGFzc3VtZSB0aGF0IGFueSBMMS0zIGRldmljZSB3aWxsIGJl IGFibGUgdG8gZGV0ZXJtaW5lIG11Y2ggdXNlZnVsIGluZm9ybWF0aW9uIGZyb20gdGhlIGRhdGEt cGxhbmUuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBKaW0gR3Vp Y2hhcmQgKGpndWljaGFyKQ0KDQpTZW50OiAxMiBOb3ZlbWJlciAyMDEzIDEwOjQ0DQoNClRvOiBE YXZpZCBMYWtlIChkbGFrZSk7IEtldmluIEogTWE7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsg Um9uIFBhcmtlcjsgTGluZGEgRHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKQ0KDQpDYzogVGhvbWFz IE5hcnRlbjsgbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+OyBTdW1hbmRyYSBNYWpl ZQ0KDQpTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQoN Cg0KQXMgZGlzY3Vzc2VkIGR1cmluZyB0aGUgQk9GIG91ciBpbml0aWFsIHdvcmsgaXMgc2luZ2xl IGFkbWluaXN0cmF0aXZlIGRvbWFpbiBmb3Igc29tZSBvZiB0aGUgdmVyeSByZWFzb25zIHlvdSBw b2ludCBvdXQuIFdlIG5lZWQgdG8ga2VlcCBmb2N1c2VkIHdpdGhvdXQgdHJ5aW5nIHRvIGJvaWwg dGhlIG9jZWFuIHJpZ2h0IG9mZiB0aGUgYmF0Lg0KDQoNCg0KT24gMTEvMTIvMTMgMTozNiBQTSwg IkRhdmlkIExha2UgKGRsYWtlKSIgPGRsYWtlQGNpc2NvLmNvbTxtYWlsdG86ZGxha2VAY2lzY28u Y29tPj4gd3JvdGU6DQoNCg0KDQo+RXhhY3RseS4gIEJ1dCBob3cgY2FuIG5ldHdvcmstY29tcG9u ZW50cyAidGVybWluYXRlIiBhbiBhcHBsaWNhdGlvbiA/Pz8/DQoNCj4NCg0KPkkgdGhpbmsgd2Ug bmVlZCBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiBhIHJlY3Vyc2l2ZSBwb2xpY3kgbWVjaGFuaXNt DQoNCj4ocmVjdXJzaXZlIGJlY2F1c2UgYSB1c2VyLWxhbmQgYXBwbGljYXRpb24gd2lsbCByaWRl IHdpdGggYSBzcGVjaWZpYw0KDQo+cG9saWN5IGFjcm9zcyBwb3RlbnRpYWxseSBkaWZmZXJlbnQg c2V0cyBvZiBjYXJyaWVyIHBvbGljaWVzKS4NCg0KPg0KDQo+SSBoYXRlIHRvIGJyaW5nIHRoaXMg dXAgbm93LCBidXQgd2UgYWxzbyBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMNCg0KPm11bHRpLWRv bWFpbiBpc3N1ZSAtIGlmIEkgc2V0IGEgcG9saWN5IGFzIGEgdXNlciwgY2hhbmNlcyBhcmUgSSB3 aWxsIGJlDQoNCj5jcm9zc2luZyBzZXZlcmFsIGRvbWFpbiBib3VuZGFyaWVzLiAgQXJlIHdlIGV4 cGVjdGluZyB0aGUgc2VydmljZQ0KDQo+aGVhZGVycyB0byBkZWZpbmUgdGhlIHNlcnZpY2UgY2hh aW5pbmcgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgZW50aXJlDQoNCj5mbG93IGFjcm9zcyBhbGwg ZG9tYWlucywgb3IganVzdCBhY3Jvc3MgYSBzaW5nbGUgb25lID8NCg0KPg0KDQo+SW4gd2hpY2gg Y2FzZSwgZG8gSSBoYXZlIHRvIHJlLXNldCBwb2xpY3kgYXMgSSB0cmF2ZXJzZSBkb21haW5zICBh bmQNCg0KPndoZXJlIGRvZXMgdGhhdCBwb2xpY3kgZ2V0IHNldCA/ICAgSXQgd291bGQgYmUgbXVj aCBiZXR0ZXIgdG8gc2V0IHBvbGljeQ0KDQo+b25jZSBiYXNlZCBvbiBMNS03IG5lZWRzLCBhbmQg aGF2ZSB0aGF0IGluc3RhbnRpYXRlZCBhY3Jvc3MgdGhlDQoNCj5tdWx0aXBsZSBkb21haW5zLg0K DQo+DQoNCj5BZ2FpbiwgdGhpcyBhcHBlYXJzIHRvIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNG QywgYnV0IHByZXR0eSByZWxldmFudA0KDQo+dG8gaG93IGl0IHdvdWxkIG9wZXJhdGUgaW4gdGhl IHJlYWwgd29ybGQuDQoNCj4NCg0KPkRhdmlkDQoNCj4NCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQoNCj5Gcm9tOiBLZXZpbiBKIE1hIFttYWlsdG86a2V2aW4ubWFAYXp1a2lzeXN0ZW1z LmNvbV0NCg0KPlNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMTA6MjcNCg0KPlRvOiBEYXZpZCBMYWtl IChkbGFrZSk7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsgTGluZGENCg0K PkR1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCg0KPkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0 Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz47IFN1bWFuZHJhIE1hamVlDQoNCj5TdWJqZWN0OiBS RTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQo+DQoNCj4+IEluIHRob3Nl IGNpcmN1bXN0YW5jZXMsIG9ubHkgdGhlIGVuZCBhcHBsaWNhdGlvbnMgdGhlbXNlbHZlcyBvciBh DQoNCj4+IHJlYXNvbmFibHkgYnJvYWQtYnJ1c2hlZCBjbGFzc2lmaWNhdGlvbiAocmVhbGx5IHRy YWZmaWMgc3RlZXJpbmcNCg0KPj4gYmFzZWQgb24gd2hhdCB3ZSBjYW4gc2VlIGF0IGluZ3Jlc3Mp IGlzIGdvaW5nIHRvIGJlIHVzZWZ1bCAtIGlzIFRIQVQNCg0KPj4gd2hhdCB3ZSdyZSBhaW1pbmcg Zm9yIGhlcmUgPw0KDQo+DQoNCj5JIHdvdWxkIGNlcnRhaW5seSBob3BlIG5vdCwgYnV0IHRoYXQg aGFzIGJlZW4gbXkgY29uY2VybiBhcyB3ZWxsLg0KDQo+QXBwbGljYXRpb24gbGF5ZXIgdGVybWlu YXRpb24gYW5kIHJlLWNsYXNzaWZpY2F0aW9uIHNlZW1zIGEgbXVzdD8NCg0KPg0KDQo+LS0gIEtl dmluIEouIE1hDQoNCj4NCg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4gRnJv bTogRGF2aWQgTGFrZSAoZGxha2UpIFttYWlsdG86ZGxha2VAY2lzY28uY29tXQ0KDQo+PiBTZW50 OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxOjAwIFBNDQoNCj4+IFRvOiBTdXJlbmRyYSBL dW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IExpbmRhIER1bmJhcjsNCg0K Pj4gSG9uZ3l1IExpIChKdWxpbykNCg0KPj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9y ZzxtYWlsdG86bnNjQGlldGYub3JnPjsgU3VtYW5kcmEgTWFqZWUNCg0KPj4gU3ViamVjdDogUkU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KPj4NCg0KPj4gUG9saWN5IG1h eSBiZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBTRkMsIGJ1dCB3aXRob3V0IHN0cm9uZyBtYXBw aW5nDQoNCj4+IGJldHdlZW4gUG9saWN5IGFuZCB0aGUgaW5zZXJ0ZWQgU2VydmljZSBIZWFkZXIo cyksIHdlIHJ1bi10aGUtcmlzayBvZg0KDQo+PiBsaW1pdGluZyB0aGUgZWZmaWNhY3kgb2YgdGhl IHByb3RvY29sIElNTy4NCg0KPj4NCg0KPj4gRm9yIGV4YW1wbGUsIGluIGEgd29ybGQgd2hlcmUg dGhlIG5ldHdvcmsgaGFzICJnb25lIGRhcmssIiAoYXMgcGVyDQoNCj4+IHRoZSBJRVRGIFRlY2hu aWNhbCBQbGVuYXJ5ID86LSkgKSB3aGF0IGlzIG91ciBhYmlsaXR5IHRvIGRldGVybWluZQ0KDQo+ PiBwb2xpY3kgYmFzZWQgb24gRFBJIG9mIHBhY2tldHMtaW4tZmxpZ2h0ID8NCg0KPj4NCg0KPj4g SW4gdGhvc2UgY2lyY3Vtc3RhbmNlcywgb25seSB0aGUgZW5kIGFwcGxpY2F0aW9ucyB0aGVtc2Vs dmVzIG9yIGENCg0KPj4gcmVhc29uYWJseSBicm9hZC1icnVzaGVkIGNsYXNzaWZpY2F0aW9uIChy ZWFsbHkgdHJhZmZpYyBzdGVlcmluZw0KDQo+PiBiYXNlZCBvbiB3aGF0IHdlIGNhbiBzZWUgYXQg aW5ncmVzcykgaXMgZ29pbmcgdG8gYmUgdXNlZnVsIC0gaXMgVEhBVA0KDQo+PiB3aGF0IHdlJ3Jl IGFpbWluZyBmb3IgaGVyZSA/DQoNCj4+DQoNCj4+IERhdmlkDQoNCj4+DQoNCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpuc2MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mDQoNCj4+IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKQ0KDQo+PiBTZW50OiAxMiBO b3ZlbWJlciAyMDEzIDA5OjI2DQoNCj4+IFRvOiBSb24gUGFya2VyOyBLZXZpbiBKIE1hOyBMaW5k YSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQoNCj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NA aWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz47IFN1bWFuZHJhIE1hamVlDQoNCj4+IFN1Ympl Y3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoNCj4+DQoNCj4+IFJv biwNCg0KPj4NCg0KPj4gQ2xhc3NpZmljYXRpb24gb2YgdHJhZmZpYyBpcyB3ZWxsIHVuZGVyc3Rv b2QgYW5kIHdlIGRvIG5vdCBoYXZlIHRvDQoNCj4+IHJlZGVmaW5lIGl0IC0gaXQncyBiZWVuIGFy b3VuZCBmb3IgYWxsIHRoZSB0aW1lIG1pZGRsZSBib3hlcyBoYXZlDQoNCj4+IGJlZW4gb3IgZm9y IHRoYXQgbWF0dGVyIHRoZSBMMi9MMyBkZXZpY2VzLiBBbGwgd2UgYXJlIHRhbGtpbmcgYWJvdXQN Cg0KPj4gaXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGNsYXNzaWZpY2F0aW9uIHRvIGJyYW5j aGluZyBpbiBTRkMuDQoNCj4+DQoNCj4+IFlvdSBhcmUgcmlnaHQsIGl0IGlzIGFsbCBhYm91dCBw b2xpY3kgd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLg0KDQo+Pg0KDQo+PiBTdXJl bmRyYS4NCg0KPj4NCg0KPj4gT24gMTEvMTIvMTMgNzo1MyBBTSwgIlJvbiBQYXJrZXIiIDxSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tPj4NCg0KPj53cm90ZToNCg0KPj4NCg0KPj4gPkkgdGhpbmsgdGhlIGxhY2sgb2Yg ZGVmaW5pdGlvbiBvZiAicmVjbGFzc2lmaWNhdGlvbiIgbWF5IGJlIGNhdXNpbmcNCg0KPj5zb21l DQoNCj4+ID5taXN1bmRlcnN0YW5kaW5ncyBoZXJlLiAgICBBIGJyYW5jaCB3b3VsZCBvY2N1ciBm b3Igc29tZSBwb2xpY3ktZHJpdmVuDQoNCj4+ID5yZWFzb24gYmFzZWQgb24gdGhlIGJlaGF2aW9y IGFuZCBjb25jbHVzaW9ucyBvZiB0aGUgc2VydmljZSBmdW5jdGlvbiwNCg0KPj4gPml0c2VsZi4g ICBUaGUgZ3JhcGggd291bGQgcmVwcmVzZW50IHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBicmFu Y2gNCg0KPj4gPnBvaW50LCBidXQgdGhlIHNlcnZpY2UgZnVuY3Rpb24sIGl0c2VsZiwgYmVpbmcg YXdhcmUgdGhhdCBpdCBpcyBhDQoNCj4+ID5icmFuY2hpbmcgcG9pbnQgd291bGQgY29udGFpbiB0 aGUgcG9saWN5IGFuZCBsb2dpYyB0byBkZWNpZGUgb24gd2hpY2gNCg0KPj4gPmJyYW5jaCB0byB0 YWtlLiAgIFNwZWNpZnlpbmcgdGhhdCBwb2xpY3kgYW5kIGxvZ2ljIGlzIG91dCBvZiBzY29wZSwN Cg0KPj5JTU8uDQoNCj4+ID4NCg0KPj4gPiAgIFJvbg0KDQo+PiA+DQoNCj4+ID4NCg0KPj4gPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+ID5Gcm9tOiBLZXZpbiBKIE1hIFttYWlsdG86 a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCg0KPj4gPlNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDEyLCAyMDEzIDEwOjQ5IEFNDQoNCj4+ID5UbzogTGluZGEgRHVuYmFyOyBSb24gUGFya2VyOyBI b25neXUgTGkgKEp1bGlvKQ0KDQo+PiA+Q2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzxt YWlsdG86bnNjQGlldGYub3JnPjsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBTdW1hbmRyYQ0K DQo+PiA+TWFqZWUNCg0KPj4gPlN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNG QyBjaGFydGVyDQoNCj4+ID4NCg0KPj4gPkhpIExpbmRhLA0KDQo+PiA+DQoNCj4+ID4gIEFyZSB5 b3Ugc2F5aW5nIHRoYXQgYSBicmFuY2hpbmcgcG9pbnQgaXMgIm5ldmVyIiBhDQoNCj4+ID4gcmVj bGFzc2lmaWNhdGlvbiBwb2ludCwgb3IgYXJlIHlvdSBzYXlpbmcgdGhhdCBhIGJyYW5jaGluZyBw b2ludCAiZG9lcyBub3QgaGF2ZSB0byBiZSINCg0KPj4gPiAgYSByZWNsYXNzaWZpY2F0aW9uIHBv aW50Pw0KDQo+PiA+DQoNCj4+ID4gIEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQgZGlzdGlu Y3Rpb24gdGhhdCBuZWVkcyB0byBiZSBjbGFyaWZpZWQuDQoNCj4+ID4gIElmIGJyYW5jaGluZyBp cyBuZXZlciByZWNsYXNzaWZpY2F0aW9uLCB0aGVuIHRoZSBtZWFuaW5nIG9mIGENCg0KPj4gPiBj aGFpbiBpcyBkaWZmZXJlbnQgdGhhbiBJIG9yaWdpbmFsbHkgaW5mZXJyZWQuICBJZiB0aGUgY2hh aW4gaXMgYQ0KDQo+PiA+IHRyZWUgd2l0aCBvdGhlciAiYnJhbmNoaW5nIiBwb2ludHMgaW4gaXQs IHRoZW4gdGhhdCBsaW1pdHMgdGhlDQoNCj4+ID4gc2NvcGUgb2YgdGhlIHByb2JsZW0gc3RhdGVt ZW50IGdvYWxzLg0KDQo+PiA+DQoNCj4+ID4gIFdoaWxlIHRoaXMgY291bGQgYmUgYSBkZWdlbmVy YXRlIGNhc2UsIGFuZCBhbnkgaW1wbGVtZW50YXRpb24NCg0KPj4gPiBjb3VsZCBkZWZpbmUgYmFk IHNlcnZpY2UgY2hhaW5zLCBpcyBpdCB0aGUgaW50ZW50IG9mIFNGQyB0byBvbmx5DQoNCj4+ID4g bG9vayBhdCB0aGUgc2ltcGxlciBwYWNrZXQtbGV2ZWwgY2xhc3NpZmljYXRpb24gY2FzZXMsIG9y IGlzIGl0IHRoZQ0KDQo+PiA+IGludGVudCB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIGJy YW5jaGluZyBwb2ludCBpcyB2aWV3ZWQgYXMgYQ0KDQo+PiA+IHJlLWNsYXNzaWZpY2F0aW9uIHBv aW50Pw0KDQo+PiA+DQoNCj4+ID50aGFueC4NCg0KPj4gPg0KDQo+PiA+LS0gIEtldmluIEouIE1h DQoNCj4+ID4NCg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4gPj4gRnJv bTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQoNCj4+ID4+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEwOjM0IEFNDQoNCj4+ID4+IFRvOiBS b24gUGFya2VyOyBIb25neXUgTGkgKEp1bGlvKTsgS2V2aW4gSiBNYQ0KDQo+PiA+PiBDYzogVGhv bWFzIE5hcnRlbjsgbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+OyBTdXJlbmRyYSBL dW1hciAoc21rdW1hcik7DQoNCj4+ID4+IFN1bWFuZHJhIE1hamVlDQoNCj4+ID4+IFN1YmplY3Q6 IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoNCj4+ID4+DQoNCj4+ID4+ IFJvbiwNCg0KPj4gPj4NCg0KPj4gPj4gRmlyc3QsIHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0 ICJicmFuY2hpbmciICE9IHJlY2xhc3NpZmljYXRpb24sDQoNCj4+ID4+YWdyZWU/DQoNCj4+ID4+ DQoNCj4+ID4+IFNlY29uZCwgdGhlIHJlcHJlc2VudGF0aW9uIG9mIGJyYW5jaGluZyAob3Igc2Vy dmljZSBncmFwaCkgY2FuIGJlDQoNCj4+ID4+IGluIGEgZm9ybSBvZiBsb2dpYyBvbiBhIHNlcnZp Y2UgZnVuY3Rpb24uIFNvbWUgc2VydmljZSBmdW5jdGlvbnMsDQoNCj4+ID4+IGVzcGVjaWFsbHkg TDcgYmFzZWQsIGNhbiB1c2UgdmFsdWUgaW4gYSBEYXRhYmFzZSB0byBkZXRlcm1pbmUgd2hhdA0K DQo+PiA+PiBpcyB0aGUgbmV4dCBzZXJ2aWNlIGZ1bmN0aW9uLg0KDQo+PiA+Pg0KDQo+PiA+PiBM aW5kYQ0KDQo+PiA+Pg0KDQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+ ID4+ID4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYu b3JnPiBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0KDQo+PiA+PiA+IEJlaGFsZiBP ZiBSb24gUGFya2VyDQoNCj4+ID4+ID4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMg ODoxNiBBTQ0KDQo+PiA+PiA+IFRvOiBIb25neXUgTGkgKEp1bGlvKTsgS2V2aW4gSiBNYQ0KDQo+ PiA+PiA+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9y Zz47IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsNCg0KPj4gPj4gPiBTdW1hbmRyYSBNYWplZQ0K DQo+PiA+PiA+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVy DQoNCj4+ID4+ID4NCg0KPj4gPj4gPiBIb25neXUsDQoNCj4+ID4+ID4NCg0KPj4gPj4gPiBJIGFn cmVlIGNvbXBsZXRlbHkgdGhhdCByZS1jbGFzc2lmaWNhdGlvbiBpcyBub3QgbGltaXRlZCB0byBE UEkuDQoNCj4+ID4+ID4NCg0KPj4gPj4gPiBBbmQgYWxzbywgdGhhdCBhbiBhcmVhIGZvciB1cyB0 byBleHBsb3JlIGFzIGEgZ3JvdXAgaXMgaG93IHRvDQoNCj4+ID4+cmVwcmVzZW50DQoNCj4+ID4+ ID4gdGhlIHNlcnZpY2UgZ3JhcGguICAgRG8gd2Ugd2FudCB0byByZXByZXNlbnQgaXQgYXMgYSBw cm9wZXIgZ3JhcGgNCg0KPj4gd2l0aA0KDQo+PiA+PiA+IGFuIGFkamFjZW5jeSBsaXN0IG9yIG90 aGVyIHJlcHJlc2VudGF0aW9uYWwgbW9kZWw/ICAgT3IsIGRvIHdlIHdhbnQNCg0KPj4gdG8NCg0K Pj4gPj4gPiByZXByZXNlbnQgaXQgYXMgYSBzZXQgb2YgbGluZWFyIHNlZ21lbnRzIGFuZCBpZiBz bywgaG93IGFyZSB0aGUNCg0KPj4gPj4gPiBzZWdtZW50cyBjb25uZWN0ZWQgaW50byBhIGdyYXBo PyAgIE90aGVyIGlkZWFzPw0KDQo+PiA+PiA+DQoNCj4+ID4+ID4gICAgUm9uDQoNCj4+ID4+ID4N Cg0KPj4gPj4gPg0KDQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+ID4+ ID4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3Jn PiBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0KDQo+PiA+PiA+IEJlaGFsZiBPZiBI b25neXUgTGkgKEp1bGlvKQ0KDQo+PiA+PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAy MDEzIDY6NTcgQU0NCg0KPj4gPj4gPiBUbzogUm9uIFBhcmtlcjsgS2V2aW4gSiBNYQ0KDQo+PiA+ PiA+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz47 IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsNCg0KPj4gPj4gPiBTdW1hbmRyYSBNYWplZQ0KDQo+ PiA+PiA+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoN Cj4+ID4+ID4NCg0KPj4gPj4gPiBCcmFuY2hpbmcvZm9ya2luZyBpcyBhIHZlcnkgaW50ZXJlc3Rp bmcgdG9waWMgb2YgU0ZDLiBBYm91dCB0aGUNCg0KPj4gPj4gPiByZS0gY2xhc3NpZmljYXRpb24g cG9pbnQsIHByb2JhYmx5IHdlIHNoYWxsIG5vdCBsaW1pdCBpdCB0byBEUEkuDQoNCj4+ID4+ID4g SXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IHBhY2tldHMgZ28gdG8gZGlmZmVyZW50IGJyYW5jaGVz IGFmdGVyDQoNCj4+ID4+ID4gYmVlbiBwcm9jZXNzZWQgYnkgYSBjZXJ0YWluIHNlcnZpY2UgZnVu Y3Rpb24sIGRlY2lzaW9uIG9mIHdoaWNoDQoNCj4+ID4+ID4gYnJhbmNoZXMgdG8gZ28gaXMgbWFk ZSBiYXNlZCBvbiB0aGUgcmVzdWx0IG9mIHNlcnZpY2UgZnVuY3Rpb24ncw0KDQo+PiA+PiA+IHBy b2Nlc3MsIGkuZS4gbm90IGp1c3QgcmUtIGNsYXNzaWZpY2F0aW9uIGJ5IERQSS4NCg0KPj4gPj4g Pg0KDQo+PiA+PiA+IEhvbmd5dQ0KDQo+PiA+PiA+DQoNCj4+ID4+ID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCg0KPj4gPj4gPiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bnNjLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQoN Cj4+ID4+ID4gQmVoYWxmIE9mIFJvbiBQYXJrZXINCg0KPj4gPj4gPiBTZW50OiBUdWVzZGF5LCBO b3ZlbWJlciAxMiwgMjAxMyA3OjQ1IFBNDQoNCj4+ID4+ID4gVG86IEtldmluIEogTWENCg0KPj4g Pj4gPiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+ OyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7DQoNCj4+ID4+ID4gU3VtYW5kcmEgTWFqZWUNCg0K Pj4gPj4gPiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0K DQo+PiA+PiA+DQoNCj4+ID4+ID4gSGksIEtldmluDQoNCj4+ID4+ID4NCg0KPj4gPj4gPiBZb3Ug YXNrIGEgZ3JlYXQgcXVlc3Rpb24gYWJvdXQgYnJhbmNoaW5nIHRoZSBncmFwaC4gIFRoZSBkZXRh aWxzDQoNCj4+ID4+ID4gYXJvdW5kIGhvdyB0byBjb252ZXkgdGhlIHNlbGVjdGlvbiBvZiB0aGUg c3VidHJlZS9zdWJncmFwaCBhcmUNCg0KPj4gPj4gPiBzdGlsbA0KDQo+PiA+PnRvIGJlDQoNCj4+ ID4+ID4gZGVmaW5lZC4gICBJcyBpdCBvbmUgY2hhaW4gaWQgZm9yIHRoZSB3aG9sZSBncmFwaD8g ICBEb2VzIGVhY2gNCg0KPj5icmFuY2gNCg0KPj4gPj4gPiBoYXZlIGl0cyBvd24gY2hhaW4gaWQ/ ICAgU29tZSBjb21iaW5hdGlvbj8NCg0KPj4gPj4gPg0KDQo+PiA+PiA+ICAgIFJvbg0KDQo+PiA+ PiA+DQoNCj4+ID4+ID4gT24gTm92IDEyLCAyMDEzLCBhdCAxOjUyIEFNLCAiS2V2aW4gSiBNYSIN Cg0KPj4gPj4gPiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbTxtYWlsdG86a2V2aW4ubWFAYXp1 a2lzeXN0ZW1zLmNvbT4+DQoNCj4+ID4+ID4gd3JvdGU6DQoNCj4+ID4+ID4NCg0KPj4gPj4gPiA+ PiBZZXMsIHJlY2xhc3NpZmljYXRpb24gY2FuIGNoYW5nZSB0aGUgc2VydmljZSBwYXRoIGFuZA0K DQo+PiA+PiA+ID4+IHJlLWNsYXNzaWZpY2F0aW9uIG1heSBoYXBwZW4gYXQgYW55IG5vZGUgYWxv bmcgYSBzZXJ2aWNlIHBhdGguDQoNCj4+ID4+ID4gPg0KDQo+PiA+PiA+ID4gSnVzdCB0byBleHBh bmQgb24gdGhhdCwgZ29pbmcgYmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24NCg0KPj4gPj4g PiA+IGFib3V0IHNlcnZpY2UgaGVhZGVyIGVuY2Fwc3VsYXRpb24sIGlzIGl0IGludGVuZGVkIHRo YXQgYQ0KDQo+PiA+PiA+ID4gY2hhaW4gdGhhdCBpcyByZS1jbGFzc2lmaWVkIHdpbGwgZ2V0IGEg bmV3IGNoYWluIElEIHdoaWNoDQoNCj4+ID4+ID4gPiBmdWxseSBkZXNjcmliZXMgYSBjaGFpbiB0 aGF0IGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFsDQoNCj4+ID4+ID4gPiBjaGFpbiBJRCwg cHJpb3IgdG8gRFBJLWJhc2VkIHJlLWNsYXNzaWZpY2F0aW9uPyAgKGFzc3VtaW5nIHRoZQ0KDQo+ PiA+PiA+ID4gZ29hbCBpcyAiYSBzaW5nbGUgY2hhaW4gSUQgdGhhdCBpcyBjb21tb25seSB1bmRl cnN0b29kIGFsb25nDQoNCj4+ID4+ID4gPiB0aGUgZW50aXJlIHNlcnZpY2UNCg0KPj4gY2hhaW4i DQoNCj4+ID4+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnNjL2N1 cnJlbnQvbXNnMDA2MzguaHRtbA0KDQo+PiA+PiA+ID4gKQ0KDQo+PiA+PiA+ID4NCg0KPj4gPj4g PiA+IEFuZCB0aGUgYXBwbGljYWJsZSBzdWJzZXQgb2YgdGhlIHBlcm11dGF0aXZlIGxpc3Qgb2Yg c2VydmljZQ0KDQo+PiA+PiA+ID4gcGF0aHMgd291bGQgYmUgY29uZmlndXJlZCBhdCBlYWNoIGFw cHJvcHJpYXRlIHNlcnZpY2Ugbm9kZT8NCg0KPj4gPj4gPiA+IGUuZy4sIElEIDE6IE5BVCArIGZp cmV3YWxsICsgRFBJDQoNCj4+ID4+ID4gPiAgICAgIElEIDI6IE5BVCArIGZpcmV3YWxsICsgRFBJ ICsgQVYNCg0KPj4gPj4gPiA+ICAgICAgSUQgMzogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViAr IE5BVA0KDQo+PiA+PiA+ID4gICAgICBJRCA0OiBOQVQgKyBmaXJld2FsbCArIERQSSArIE5BVA0K DQo+PiA+PiA+ID4gICAgICBJRCA1OiBOQVQgKyBmaXJld2FsbCArIERQSSArIEFWICsgTEINCg0K Pj4gPj4gPiA+ICAgICAgSUQgNjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBMQg0KDQo+PiA+PiA+ ID4gICAgICBJRCA3OiBOQVQgKyBmaXJld2FsbCArIERQSSArIExCICsgQ0FDSEUNCg0KPj4gPj4g PiA+ICAgICAgSUQgODogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBDQUNIRQ0KDQo+PiA+PiA+ID4g ICAgICBJRCA5OiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIExCDQoNCj4+ID4+ ID4gPiAgICAgIElEIDEwOiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIExCICsg Q0FDSEUNCg0KPj4gPj4gPiA+ICAgICAgSUQgMTE6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0 aW1pemVyICsgQ0FDSEUgV291bGQNCg0KPj4gPj4gPiA+IGV2ZXJ5IGZsb3cgdGhlbiBiZSBpbml0 aWFsbHkgY2xhc3NpZmllZCBhcyBJRCAxLCBidXQNCg0KPj4gPj4gPiA+IGV2ZW50dWFsbHkgZ2V0 IHJlLQ0KDQo+PiA+PiA+IGNsYXNzaWZpZWQNCg0KPj4gPj4gPiA+IHRvIElEIDItMTEsIGFmdGVy IHRoZSBEUEkgcGhhc2U/DQoNCj4+ID4+ID4gPg0KDQo+PiA+PiA+ID4gdGhhbnguDQoNCj4+ID4+ ID4gPg0KDQo+PiA+PiA+ID4gLS0gIEtldmluIEouIE1hDQoNCj4+ID4+ID4gPg0KDQo+PiA+PiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4+ID4+ID4gPj4gRnJvbTogU3VyZW5k cmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQoNCj4+ID4+ID4g Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTowMSBBTQ0KDQo+PiA+PiA+ID4+ IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRl bjsNCg0KPj4gPj4gPiA+PiBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz4NCg0KPj4g Pj4gPiA+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0K DQo+PiA+PiA+ID4+DQoNCj4+ID4+ID4gPj4NCg0KPj4gPj4gPiA+Pg0KDQo+PiA+PiA+ID4+PiBP biAxMS8xMS8xMyA5OjQ2IFBNLCAiS2V2aW4gSiBNYSINCg0KPj4gPj4gPiA+Pj4gPGtldmluLm1h QGF6dWtpc3lzdGVtcy5jb208bWFpbHRvOmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+Pg0KDQo+ PiA+Pndyb3RlOg0KDQo+PiA+PiA+ID4+Pg0KDQo+PiA+PiA+ID4+PiBIaSBTdXJlbmRyYSwNCg0K Pj4gPj4gPiA+Pj4NCg0KPj4gPj4gPiA+Pj4gQ2xhc3NpZmljYXRpb24gbWF5IGJlIG91dCBvZiBz Y29wZSwgYnV0IHRoZSBsZXZlbCBvZiBzZXJ2aWNlDQoNCj4+ID4+ID4gPj4+IHRoYXQNCg0KPj4g Pj4gPiBpcw0KDQo+PiA+PiA+ID4+PiBhcHBsaWNhYmxlIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBs ZXZlbCBvZiBjbGFzc2lmaWNhdGlvbg0KDQo+PiA+PiA+ID4+PiB0aGF0IGNhbg0KDQo+PiA+PiA+ IGJlDQoNCj4+ID4+ID4gPj4+IHBlcmZvcm1lZC4gIEFuIGFzc3VtcHRpb24gb2YgcGFja2V0IGxl dmVsIGVuY2Fwc3VsYXRpb24gaGFzDQoNCj4+ID4+ID4gPj4gaW1wbGljYXRpb25zDQoNCj4+ID4+ ID4gPj4+IG9uIHRoZSBsZXZlbCBvZiBjbGFzc2lmaWNhdGlvbiBiZWluZyBwZXJmb3JtZWQ/ICBJ ZiB0aGUNCg0KPj4gPj4gPiA+Pj4gc3RhdGVkDQoNCj4+ID4+ID4gZ29hbHMNCg0KPj4gPj4gPiA+ PiBhcmUNCg0KPj4gPj4gPiA+Pj4gZm9yIGZpcmV3YWxsIGFuZCBsb2FkIGJhbGFuY2VyIGZ1bmN0 aW9uYWxpdHksIHRoZW4gdGhlDQoNCj4+ID4+ID4gPj4+IGFwcGxpY2F0aW9uDQoNCj4+ID4+ID4g Pj4gbGV2ZWwNCg0KPj4gPj4gPiA+Pj4gbmF0dXJlIG9mIHRob3NlIGZ1bmN0aW9ucyBuZWVkcyB0 byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/DQoNCj4+ID4+ID4gPj4+IElmLCBvbiB0aGUgb3RoZXIg aGFuZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gc2NvcGUgaXMgbGltaXRlZA0KDQo+PiA+PiA+ID4+ PiBkdWUgdG8gbGltaXRhdGlvbnMgaW4gY2xhc3NpZmljYXRpb24sIHRoYXQgd291bGQgYmUgYW5k DQoNCj4+ID4+ID4gPj4+IGltcG9ydGFudCBwaWVjZSBvZg0KDQo+PiA+PiA+IGluZm9ybWF0aW9u Pw0KDQo+PiA+PiA+ID4+Pg0KDQo+PiA+PiA+ID4+PiBXcnQgc2VjdGlvbiA0LjQgb2YgZHJhZnQt bGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzIHRoZQ0KDQo+PiA+PiA+ID4+PiBmb3JrIHBv aW50cyBvZiB0aGUgc2VydmljZSBwYXRocyBzZWVtIGxpa2UgcmUtY2xhc3NpZmljYXRpb24NCg0K Pj4gcG9pbnRzPw0KDQo+PiA+PiA+ID4+PiBJcyB0aGF0IHRoZSBpbnRlcnByZXRhdGlvbiBmcm9t IHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmU/DQoNCj4+ID4+ID4gPj4+IE9yIGlzIHRoZSBz ZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGNsYXNzaWZpY2F0aW9uIGV4Y2x1c2l2ZSBvZg0KDQo+PiA+ PiA+ID4+PiBEUEkNCg0KPj4gPj4gPiBmdW5jdGlvbmFsaXR5Pw0KDQo+PiA+PiA+ID4+IDxTSz4g SSBoYXZlIG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwgYXMN Cg0KPj4gPj4gPiA+PiBkZXNjcmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9u IG9mIHNlcnZpY2VzIGZvcm0NCg0KPj4gPj4gPiA+PiBhIGdyYXBoLCBzZWdtZW50cyBvZiB3aGlj aCBhcmUgc2VydmljZSBwYXRocy4gWWVzLA0KDQo+PiA+PiA+ID4+IHJlY2xhc3NpZmljYXRpb24g Y2FuDQoNCj4+ID4+ID4gY2hhbmdlDQoNCj4+ID4+ID4gPj4gdGhlIHNlcnZpY2UgcGF0aCBhbmQg cmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZQ0KDQo+PiA+PiA+ID4+IGFs b25nDQoNCj4+ID4+ID4gYSBzZXJ2aWNlIHBhdGguDQoNCj4+ID4+ID4gPj4NCg0KPj4gPj4gPiA+ PiBTdXJlbmRyYS4NCg0KPj4gPj4gPiA+Pj4NCg0KPj4gPj4gPiA+Pj4gdGhhbnguDQoNCj4+ID4+ ID4gPj4+DQoNCj4+ID4+ID4gPj4+IC0tICBLZXZpbiBKLiBNYQ0KDQo+PiA+PiA+ID4+Pg0KDQo+ PiA+PiA+ID4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4gPj4gPiA+Pj4+IEZy b206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0K DQo+PiA+PiA+ID4+Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTI6MDggQU0N Cg0KPj4gPj4gPiA+Pj4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWpl ZTsgVGhvbWFzIE5hcnRlbjsNCg0KPj4gPj4gPiA+Pj4+IG5zY0BpZXRmLm9yZzxtYWlsdG86bnNj QGlldGYub3JnPg0KDQo+PiA+PiA+ID4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCg0KPj4gPj4gPiA+Pj4+DQoNCj4+ID4+ID4gPj4+PiBLZXZpbiwN Cg0KPj4gPj4gPiA+Pj4+DQoNCj4+ID4+ID4gPj4+PiBDbGFzc2lmaWNhdGlvbiBtZWNoYW5pc20g aXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLiBJdA0KDQo+PiA+PiA+ID4+Pj4gY2FuIGJlIGJh c2VkDQoNCj4+ID4+ID4gPj4gb24NCg0KPj4gPj4gPiA+Pj4+IHRoZSBwYWNrZXQgb3IgaW5mb3Jt YXRpb24gbm90IGluIHRoZSBwYWNrZXQoZW52aXJvbm1lbnRhbA0KDQo+PiA+PiA+ID4+Pj4gYXR0 cmlidXRlcw0KDQo+PiA+PiA+ID4+IGZvcg0KDQo+PiA+PiA+ID4+Pj4gaW5zdGFuY2UpIG9yIGEg Y29tYmluYXRpb24gdGhlcmVvZi4gV2hhdCBpcyBpbXBvcnRhbnQgaXMNCg0KPj4gPj4gPiA+Pj4+ IHRoYXQgc3VjaCBjbGFzc2lmaWNhdGlvbiBhaWRzIGluIHRyYWZmaWMgc2VsZWN0aW9uIGFuZA0K DQo+PiA+PiA+ID4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpY2F0aW9uLg0KDQo+PiA+PiA+ID4+ Pj4gSXQgaXMgbm8gZGlmZmVyZW50IGZyb20gYSBwb2xpY3kgaW4gdGhpcyByZWdhcmQgZXhjZXB0 IHRoYXQNCg0KPj4gPj4gPiA+Pj4+IHRoZSBwb2xpY3kgbm93IHNwZWNpZmllcyB0aGUgc2Vydmlj ZSBwYXRoLg0KDQo+PiA+PiA+ID4+Pj4gRnVydGhlciwgY2xhc3NpZmljYXRpb24gaXMgbm90IGxp bWl0ZWQgdG8gdGhlIG5ldHdvcmsNCg0KPj4gPj4gPiA+Pj4+IGVsZW1lbnRzIGJ1dCB0aGUgc2Vy dmljZSBmdW5jdGlvbnMgYXMgd2VsbC4gU29tZSBvZiB0aGlzIGlzDQoNCj4+ID4+ID4gPj4+PiBk ZXNjcmliZWQgaW4gdGhlDQoNCj4+ID4+ID4gPj4gYXJjaGl0ZWN0dXJlDQoNCj4+ID4+ID4gPj4+ PiBkcmFmdHMgYXMgd2VsbCAtDQoNCj4+ID4+ID4gPj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFyY2gvIi4NCg0KPj4gPj4gPiA+Pj4+DQoNCj4+ ID4+ID4gPj4+PiBTdXJlbmRyYS4NCg0KPj4gPj4gPiA+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4gT24g MTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiDQoNCj4+ID4+ID4gPj4+Pj4gPGtldmluLm1h QGF6dWtpc3lzdGVtcy5jb208bWFpbHRvOmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+Pg0KDQo+ PiA+PiA+IHdyb3RlOg0KDQo+PiA+PiA+ID4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4gSGkgUm9uLA0K DQo+PiA+PiA+ID4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4gSSB3YXMgdW5hYmxlIHRvIG1ha2UgdGhl IFNGQyBCb0YgZHVlIHRvIGEgY29uZmxpY3Qgd2l0aA0KDQo+PiA+PiA+ID4+Pj4+IENETkksIGJ1 dCBJIGhhZCBhIHNpbWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxldCAxMSBpbg0KDQo+PiA+PiA+ID4+ Pj4+IHNlY3Rpb24NCg0KPj4gPj4gPiA+Pj4+PiAyIG9mIHRoZQ0KDQo+PiA+PiA+IHByb2JsZW0N Cg0KPj4gPj4gPiA+Pj4+PiBzdGF0ZW1lbnQ6DQoNCj4+ID4+ID4gPj4+Pj4NCg0KPj4gPj4gPiA+ Pj4+PiAgIDExLiAgUGVyLVNlcnZpY2UgKHJlKUNsYXNzaWZpY2F0aW9uOiBDbGFzc2lmaWNhdGlv bg0KDQo+PiA+PiA+ID4+Pj4+IG9jY3VycyBhdA0KDQo+PiA+PiA+IGVhY2gNCg0KPj4gPj4gPiA+ Pj4+PiAgICAgICAgc2VydmljZSwgaW5kZXBlbmRlbnQgZnJvbSBwcmV2aW91c2x5IGFwcGxpZWQN Cg0KPj4gPj4gPiA+Pj4+PiBzZXJ2aWNlDQoNCj4+ID4+ID4gPj4+PiBmdW5jdGlvbnMuDQoNCj4+ ID4+ID4gPj4+Pj4gICAgICAgIFRoZXNlIHVucmVsYXRlZCBjbGFzc2lmaWNhdGlvbiBldmVudHMg Y29uc3VtZQ0KDQo+PiA+PiA+ID4+Pj4+IHJlc291cmNlcw0KDQo+PiA+PiA+IHBlcg0KDQo+PiA+ PiA+ID4+Pj4+ICAgICAgICBzZXJ2aWNlLiAgTW9yZSBpbXBvcnRhbnRseSwgdGhlIGNsYXNzaWZp Y2F0aW9uDQoNCj4+ID4+ID4gZnVuY3Rpb25hbGl0eQ0KDQo+PiA+PiA+ID4+Pj4+ICAgICAgICBv ZnRlbiBkaWZmZXJzIHBlciBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCBzZXJ2aWNlDQoNCj4+ID4+ID4g Pj4+Pj4gZnVuY3Rpb24NCg0KPj4gPj4gPiA+PiBjYW5ub3QNCg0KPj4gPj4gPiA+Pj4+PiAgICAg ICAgbGV2ZXJhZ2UgdGhlIHJlc3VsdHMgZnJvbSBvdGhlciBkZXBsb3llZCBuZXR3b3JrIG9yDQoN Cj4+ID4+ID4gc2VydmljZS4NCg0KPj4gPj4gPiA+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+IGFzIGl0 IHJlbGF0ZXMgdG8gc2VjdGlvbiA1LjIgb2YgdGhlIGZyYW1ld29yayBkb2N1bWVudDoNCg0KPj4g Pj4gPiA+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+ICAgVGhlIFNGQyBDbGFzc2lmaWVyIGNsYXNzaWZp ZXMgcGFja2V0cyBiYXNlZCBvbiAoc29tZSBvZikNCg0KPj4gPj4gPiA+Pj4+PiB0aGUNCg0KPj4g Pj4gPiA+Pj4+IGNvbnRlbnRzDQoNCj4+ID4+ID4gPj4+Pj4gICBvZiB0aGUgcGFja2V0IGhlYWRl ci4gIENvbmNyZXRlbHksIGl0IGNsYXNzaWZpZXMgcGFja2V0cw0KDQo+PiA+PiA+ID4+Pj4+IGJh c2VkIG9uDQoNCj4+ID4+ID4gPj4+PiB0aGUNCg0KPj4gPj4gPiA+Pj4+PiAgIHBvc3NpYmxlIGNv bWJpbmF0aW9uIG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsIHN1Y2gNCg0KPj4gPj4gPiA+ Pj4+PiBhcw0KDQo+PiA+PiA+IHNvdXJjZQ0KDQo+PiA+PiA+ID4+Pj4+ICAgYWRkcmVzcywgZGVz dGluYXRpb24gYWRkcmVzcywgRFMgZmllbGQsIHByb3RvY29sIElELA0KDQo+PiA+PiA+ID4+Pj4+ IHNvdXJjZQ0KDQo+PiA+PiA+IHBvcnQNCg0KPj4gPj4gPiA+Pj4+IGFuZA0KDQo+PiA+PiA+ID4+ Pj4+ICAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBhbmQgYW55IG90aGVyIGluZm9ybWF0aW9u Lg0KDQo+PiA+PiA+ID4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4gQSBwYWNrZXQtYmFzZWQgY2xhc3Np ZmllciBhcyBkZXNjcmliZWQgaW4gdGhlIGZyYW1ld29yaw0KDQo+PiA+PiA+ID4+Pj4+IGRvY3Vt ZW50DQoNCj4+ID4+ID4gPj4+PiB3b3VsZA0KDQo+PiA+PiA+ID4+Pj4+IHNlZW0gdG8gYmUgbGlt aXRlZCBpbiB3aGF0IGl0IGNhbiBjbGFzc2lmeT8gIFRoZSBzZXJ2aWNlDQoNCj4+ID4+ID4gPj4+ Pj4gZnVuY3Rpb24gaWRlbnRpZmllciBsb29rdXAgZG9lcyBub3Qgc2VlbSB0byBiZSBhDQoNCj4+ ID4+ID4gPj4+Pj4gc2lnbmlmaWNhbnQgb3B0aW1pemF0aW9uDQoNCj4+ID4+ID4gPj4gb3Zlcg0K DQo+PiA+PiA+ID4+Pj4+IGEgcGFja2V0LWJhc2VkIDUtdHVwbGUgbG9va3VwPyAgVGhlcmUgc2Vl bXMgdG8gYmUgc29tZQ0KDQo+PiA+PiA+ID4+Pj4+IG1pc3NpbmcNCg0KPj4gPj4gPiA+PiBkZXRh aWwNCg0KPj4gPj4gPiA+Pj4+PiB3cnQgaG93IGNsYXNzaWZpY2F0aW9uIGluZm9ybWF0aW9uIGlz IGRldGVybWluZWQgYW5kIHJldXNlZD8NCg0KPj4gPj4gPiA+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+ IFdoZW4gdGhpbmtpbmcgYWJvdXQgaGlnaGVyIGxldmVsIHNlcnZpY2VzLCBlLmcuLCBIVFRQIGFu ZA0KDQo+PiA+PiA+ID4+Pj4+IFRMUw0KDQo+PiA+PiA+ID4+Pj4gZW5jcnlwdGVkDQoNCj4+ID4+ ID4gPj4+Pj4gZmxvd3MsIGEgcGFja2V0LWJhc2VkIGNsYXNzaWZpZXIgc2VlbXMgaW5hZGVxdWF0 ZT8gIEkgd2FzDQoNCj4+ID4+ID4gPj4+Pj4gYWxzbw0KDQo+PiA+PiA+ID4+Pj4gd29uZGVyaW5n DQoNCj4+ID4+ID4gPj4+Pj4gaG93IGluZGVwZW5kZW50IEhMUyBzZWdtZW50IHJlcXVlc3RzIG1p Z2h0IGJlIGNsYXNzaWZpZWQNCg0KPj4gPj4gPiA+Pj4+PiBhbmQNCg0KPj4gPj4gPiA+Pj4+IGFz c29jaWF0ZWQ/DQoNCj4+ID4+ID4gPj4+Pj4gV2VyZSB0aGVzZSB0eXBlcyBvZiB1c2UgY2FzZXMg ZGlzY3Vzc2VkIGluIHRoZSBCb0Y/DQoNCj4+ID4+ID4gPj4+Pj4NCg0KPj4gPj4gPiA+Pj4+PiB0 aGFueC4NCg0KPj4gPj4gPiA+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0K DQo+PiA+PiA+ID4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQoNCj4+ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpu c2MtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10NCg0KPj4g Pj4gPiA+Pj4+Pj4gT24gQmVoYWxmDQoNCj4+ID4+ID4gPj4gT2YNCg0KPj4gPj4gPiA+Pj4+Pj4g Um9uDQoNCj4+ID4+ID4gPj4+Pj4+IFBhcmtlcg0KDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25k YXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjE2IFBNDQoNCj4+ID4+ID4gPj4+Pj4+IFRvOiBTdW1h bmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5v cmc+DQoNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJh LA0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBBcyB3YXMgZGlzY3Vzc2VkIGlu IFZhbmNvdXZlciwgdGhlcmUgYXJlIGFscmVhZHkgbWFueQ0KDQo+PiA+PiA+ID4+Pj4+PiBleGlz dGluZyB3YXlzDQoNCj4+ID4+ID4gPj4+PiB0bw0KDQo+PiA+PiA+ID4+Pj4+PiBhY2NvbXBsaXNo IHNlcnZpY2UgY2hhaW5pbmcuICAgICBCdXQgbm9uZSBvZiB0aGVtIHByb3ZpZGUgYQ0KDQo+PiA+ PiA+ID4+Pj4gc3VmZmljaWVudA0KDQo+PiA+PiA+ID4+Pj4+PiBjb21iaW5hdGlvbiBvZiBpbnRl cm9wZXJhYmlsaXR5LCBmbGV4aWJpbGl0eSwgYW5kDQoNCj4+cmVzaWxpZW5jeS4NCg0KPj4gPj4g PiBBDQoNCj4+ID4+ID4gPj4+PiBzaW5nbGUNCg0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBjaGFp biBlbmNhcHN1bGF0aW9uIHdpbGwgZ28gYSBsb25nIHdheSB0bw0KDQo+PiA+PiA+ID4+Pj4+PiBl bnN1cmluZyB0aGVzZQ0KDQo+PiA+PiA+ID4+Pj4gZ29hbHMuDQoNCj4+ID4+ID4gPj4+Pj4+IEl0 ICBtYXkgbm90IGJlIHRoZSBhYnNvbHV0ZWx5IG1vc3QgZWZmaWNpZW50IGFwcHJvYWNoIGZvcg0K DQo+PiA+PiA+ID4+Pj4+PiBldmVyeQ0KDQo+PiA+PiA+ID4+Pj4gc2luZ2xlDQoNCj4+ID4+ID4g Pj4+Pj4+IG5ldHdvcmsgdG9wb2xvZ3kgYW5kIGV2ZXJ5IHNpbmdsZSB1c2UgY2FzZSwgYnV0IGl0 cw0KDQo+PiA+PiA+ID4+Pj4+PiB1YmlxdWl0b3VzDQoNCj4+ID4+ID4gPj4gbmF0dXJlDQoNCj4+ ID4+ID4gPj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4NCg0KPj4gPj4gPiA+Pj4+ Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+ Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4g Pj4gPiA+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0N Cg0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyAxMDoxMCBQ TQ0KDQo+PiA+PiA+ID4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhvbWFzIE5hcnRlbjsgbnNjQGll dGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJF OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoNCj4+ID4+ID4gPj4+Pj4+DQoN Cj4+ID4+ID4gPj4+Pj4+IFJvbiwNCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4g QWJzb2x1dGVseSwgdGhhdCB3YXMgYW4gZXhhbXBsZSBvZiBvbmUgdHlwZSBvZiBkZXJpdmF0aW9u Lg0KDQo+PiA+PiA+ID4+Pj4+PiBIb3dldmVyDQoNCj4+ID4+ID4gPj4+PiB0aGlzDQoNCj4+ID4+ ID4gPj4+Pj4+IGNvdWxkIGJlIGF1Z21lbnRlZCB3aXRoIGNsYXNzaWZpY2F0aW9uIHJlc3VsdCwg YWdhaW4gb25lDQoNCj4+ID4+ID4gPj4+Pj4+IG1vcmUNCg0KPj4gPj4gPiA+Pj4+IGV4YW1wbGUu DQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+Pj4gQWxsIGZsb3dzIGZyb20gdGhl IHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseQ0KDQo+PiA+PiA+ID4+Pj4+Pj4+IGZv bGxvdw0KDQo+PiA+PiA+IHRoZQ0KDQo+PiA+PiA+ID4+Pj4gc2FtZQ0KDQo+PiA+PiA+ID4+Pj4+ PiBjaGFpbi4NCg0KPj4gPj4gPiA+Pj4+Pj4gQ29ycmVjdC4gSXQgaXMgYWxzbyBub3QgbmVjZXNz YXJ5IHRoYXQgYWxsIHRyYW5zYWN0aW9uIG9mDQoNCj4+ID4+ID4gPj4+Pj4+IHRoZSBzYW1lDQoN Cj4+ID4+ID4gPj4+PiBmbG93DQoNCj4+ID4+ID4gPj4+Pj4+IGZvbGxvdyB0aGUgc2FtZSBjaGFp biBlaXRoZXIuIFNvIHdoeSBzdG9wIGF0IGZsb3cgaXRzZWxmLg0KDQo+PiA+PiA+ID4+Pj4+Pg0K DQo+PiA+PiA+ID4+Pj4+PiBBZ2FpbiB0aGUgcG9pbnQgaGVyZSBpcyB0aGF0IGRvIHdlIGFsd2F5 cyBuZWVkIFNGQyBoZWFkZXINCg0KPj4gPj4gPiA+Pj4+Pj4gb3INCg0KPj4gPj5Ob3QuDQoNCj4+ ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhDQoNCj4+ID4+ID4gPj4+Pj4+ DQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQoNCj4+ID4+ID4gPj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBNb25kYXks IE5vdmVtYmVyIDExLCAyMDEzIDc6MDIgUE0NCg0KPj4gPj4gPiA+Pj4+Pj4gVG86IFN1bWFuZHJh IE1hamVlOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz4N Cg0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZD IGNoYXJ0ZXINCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gU3VtYW5kcmEsDQoN Cj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFRoZSBpbnRlbnRpb24gb2Ygc2Vydmlj ZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBhbGxvdw0KDQo+PiA+PiA+ID4+Pj4+PiBmb3Igb3Bl cmF0aW9uDQoNCj4+ID4+ID4gPj4+PiBhdA0KDQo+PiA+PiA+ID4+Pj4+PiB0aGUgZnVsbHkgcXVh bGlmaWVkIGZsb3cgbGV2ZWwsIG9yIGV2ZW4gZmluZXIgZ3JhaW5lZCBhdA0KDQo+PiA+PiA+ID4+ Pj4+PiB0aGUNCg0KPj4gPj4gPiA+Pj4+IHRyYW5zYWN0aW9uDQoNCj4+ID4+ID4gPj4+Pj4+IGxl dmVsICh0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlciBmb3IgdGhlIFBEUCkuDQoNCj4+ QWxsDQoNCj4+ID4+ID4gZmxvd3MNCg0KPj4gPj4gPiA+Pj4+IGZyb20NCg0KPj4gPj4gPiA+Pj4+ Pj4gdGhlIHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSBmb2xsb3cgdGhlIHNhbWUg Y2hhaW4uDQoNCj4+ID4+ID4gPj4gU291cmNlDQoNCj4+ID4+ID4gPj4+Pj4+IElQLA0KDQo+PiA+ PiA+ID4+Pj4+PiB0aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlmeSB0aGUgY2hhaW4gSUQuICAg IEFub3RoZXINCg0KPj4gPj5pbnRlbnRpb24NCg0KPj4gPj4gPiBvZg0KDQo+PiA+PiA+ID4+Pj4+ PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29y aw0KDQo+PiA+PiA+IHRvcG9sb2d5DQoNCj4+ID4+ID4gPj4gYW5kDQoNCj4+ID4+ID4gPj4+Pj4+ IG5vdA0KDQo+PiA+PiA+ID4+Pj4+PiBiZSBsaW1pdGVkIHRvIGEgc2luZ2xlIExBTi4gICBUaHVz LCB3aGlsZSBWTEFOIG1heSBiZSBwYXJ0DQoNCj4+b2YNCg0KPj4gPj4gPiB0aGUNCg0KPj4gPj4g PiA+Pj4+Pj4gdHJhbnNwb3J0LCBpdCBkb2VzIG5vdCBhZGVxdWF0ZWx5IGlkZW50aWZ5IHRoZSBz ZXJ2aWNlDQoNCj4+ID4+ID4gPj4+Pj4+IGNoYWluLA0KDQo+PiA+PiA+ID4+IGVpdGhlci4NCg0K Pj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24NCg0KPj4gPj4gPiA+Pj4+Pj4N Cg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCg0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1h amVlQEY1LmNvbV0NCg0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwg MjAxMyA5OjU2IFBNDQoNCj4+ID4+ID4gPj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFy dGVuOyBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz4NCg0KPj4gPj4gPiA+Pj4+Pj4g U3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KPj4gPj4g PiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gUm9uLA0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+ PiA+ID4+Pj4+PiBUaGUgc2VydmljZSBoZWFkZXIgaXMgbWVhbnQgdG8gY2FycnkgdGhlIGNvbnRl eHQgd2hpY2gNCg0KPj4gPj4gPiA+Pj4+Pj4gY2FuDQoNCj4+ID4+ID4gKmFsc28qDQoNCj4+ID4+ ID4gPj4+Pj4+IGJlIGRlcml2ZWQgKGZvciBleGFtcGxlIHVzZSBzb3VyY2UgaXAgYW5kIHZsYW4g dG8NCg0KPj4gPj4gPiA+Pj4+Pj4gaWRlbnRpZnkgY2hhaW5JRCBhbmQNCg0KPj4gPj4gPiA+Pj4+ Pj4gcG9zaXRpb24pIG9yIGVuY2Fwc3VsYXRlZCBhcyBwYXJ0IG9mIGFub3RoZXIgdHVubmVsIGhl YWRlci4NCg0KPj4gPj4gPiA+Pj4+Pj4gU28gdGhpcyBjb3VsZCBiZSBvcHRpb25hbCBJTUhPLg0K DQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9uX1Bhcmtl ckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCg0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAxMSwgMjAxMyA0OjM2IFBNDQoNCj4+ID4+ID4gPj4+Pj4+IFRvOiBTdW1hbmRyYSBN YWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoN Cj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBj aGFydGVyDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhLA0KDQo+ PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQsIGFuIFNG QyBwYWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0bw0KDQo+PiA+PiA+ID4+Pj4+PiBTRiBvciBm cm9tDQoNCj4+ID4+ID4gPj4+PiBTRg0KDQo+PiA+PiA+ID4+Pj4+PiB0bw0KDQo+PiA+PiA+ID4+ Pj4+PiBTRiB3aWxsIGxvb2sgbGlrZToNCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+ Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCg0KPj4gPj4gPiA+Pj4+Pj4gfCAgICAgICAg InRyYW5zcG9ydCIgICAgICAgICB8DQoNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0rDQoNCj4+ID4+ID4gPj4+Pj4+IHwgICAgICBzZXJ2aWNlIGhlYWRlciAgICB8DQoN Cj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCj4+ID4+ID4gPj4+ Pj4+IHwgICBvcmlnaW5hbCBJUCBoZWFkZXIgIHwNCg0KPj4gPj4gPiA+Pj4+Pj4gKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCg0KPj4gPj4gPiA+Pj4+Pj4gfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgb3JpZ2luYWwgSVANCg0KPj4gPj4gPiA+Pj4+Pj4gfCBw YXlsb2FkDQoNCj4+ID4+ID4gfA0KDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQoNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFdoZXJlIHNl cnZpY2UgaGVhZGVyIGNvbnRhaW5zLCBhdCBhIG1pbmltdW0sIGVub3VnaA0KDQo+PiA+PiA+ID4+ Pj4+PiBpbmZvcm1hdGlvbiB0bw0KDQo+PiA+PiA+ID4+Pj4gYWxsb3cNCg0KPj4gPj4gPiA+Pj4+ Pj4gdGhlIHBhY2tldCB0byBiZSBwcm9wYWdhdGVkIGFsb25nIHRoZSBmdWxsIGxlbmd0aCBvZiB0 aGUNCg0KPj4gPj4gPiA+Pj4+Pj4gY2hhaW4sIGFuZCBvcHRpb25hbGx5LCBvdGhlciBtZXRhZGF0 YSB0aGF0IGVuaGFuY2VzIHRoZQ0KDQo+PiA+PiA+ID4+Pj4+PiBvcGVyYXRpb24gb2YNCg0KPj4g Pj4gPiBvbmUNCg0KPj4gPj4gPiA+Pj4+Pj4gb3INCg0KPj4gPj4gPiA+PiBtb3JlDQoNCj4+ID4+ ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zLg0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ ID4+Pj4+PiBBbmQgd2hlcmUgInRyYW5zcG9ydCIgY291bGQgY29uY2VpdmFibHkgYmUgYW55IG9m LCBidXQNCg0KPj4gPj4gPiA+Pj4+Pj4gbm90IGxpbWl0ZWQNCg0KPj4gPj4gPiA+Pj4+IHRvOg0K DQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0DQoNCj4+ID4+ID4g Pj4+Pj4+ICogRXRoZXJuZXQgKyBMTEMyDQoNCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQgKyBN UExTDQoNCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQgKyBJUCArIEdSRQ0KDQo+PiA+PiA+ID4+ Pj4+PiAqIEV0aGVybmV0ICsgSVAgK1VEUA0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+ Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBBbHNvLCAib3JpZ2luYWwiIGluIHRoZSBkaWFncmFtIGFi b3ZlIGlzIG5vdCBtZWFudCB0bw0KDQo+PiA+PiA+ID4+Pj4+PiBpbXBseSBpbW11dGFiaWxpdHks IGJ1dCByYXRoZXIgdG8gc3BlY2lmeSB0aGUgcGFja2V0IHRoYXQNCg0KPj4gPj4gPiA+Pj4+Pj4g aXMNCg0KPj4gPj4gPiBwcm9wYWdhdGVkDQoNCj4+ID4+ID4gPj4+Pj4+IGZyb20gcHJlY2VkaW5n IGVudGl0eSB0byBzdWNjZWVkaW5nIGVudGl0eSwgcHJpb3IgdG8NCg0KPj4gPj4gPiA+Pj4+Pj4g ZW5jYXBzdWxhdGlvbi4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24N Cg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KPj4gPj4gPiA+Pj4+Pj4gRnJvbTogbnNjLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOm5zYy1ib3Vu Y2VzQGlldGYub3JnXQ0KDQo+PiA+PiA+ID4+Pj4+PiBPbiBCZWhhbGYNCg0KPj4gPj4gPiA+PiBP Zg0KDQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYSBNYWplZQ0KDQo+PiA+PiA+ID4+Pj4+PiBTZW50 OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDY6NDYgUE0NCg0KPj4gPj4gPiA+Pj4+Pj4gVG86 IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzxtYWlsdG86bnNjQGlldGYub3JnPg0KDQo+PiA+ PiA+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBHZW5lcmljIFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQQ0KDQo+PiA+PiA+ID4+Pj4+PiBkb2N1bWVu dA0KDQo+PiA+PndpbGwNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgZGVzY3JpYmUgdGhlIHNpbmdsZSBz ZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUNCg0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0K DQo+PiA+PiA+ID4+IGZvcm1hdA0KDQo+PiA+PiA+ID4+Pj4+PiBmb3INCg0KPj4gPj4gPiA+Pj4+ Pj4gICAgY29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0aGUgc2Vydmlj ZQ0KDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbg0KDQo+PiA+PiA+ID4+Pj4gcGF0aCwNCg0KPj4g Pj4gPiA+Pj4+Pj4gICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNvbnRleHQgaW5mb3JtYXRpb24g YmV0d2Vlbg0KDQo+PiA+PiA+ID4+Pj4+PiBub2Rlcw0KDQo+PiB0aGF0DQoNCj4+ID4+ID4gPj4+ Pj4+ICAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4gSXQgaXMgaW50ZW5kZWQgdGhhdCB0 aGUNCg0KPj4gPj4gPiA+Pj4+IGVuY2Fwc3VsYXRpb24NCg0KPj4gPj4gPiA+Pj4+Pj4gICAgYmUg YWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQgYW5kDQoNCj4+ID4+ ID4gPj4+Pj4+IHRoZSBzZXJ2aWNlDQoNCj4+ID4+ID4gPj4+PiB0aGF0DQoNCj4+ID4+ID4gPj4+ Pj4+IGlzDQoNCj4+ID4+ID4gPj4+Pj4+ICAgIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1heQ0KDQo+PiA+PiA+ID4+Pj4+PiBiZQ0KDQo+PiA+PiA+ IHVzZWQNCg0KPj4gPj4gPiA+PiBvbg0KDQo+PiA+PiA+ID4+Pj4+PiAgICBhIHNlcnZpY2UgZnVu Y3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yayBsYXllcg0KDQo+PiA+PiA+ID4+Pj4+ PiBvciBhdCBhbnkgb3RoZXINCg0KPj4gPj4gPiA+Pj4+Pj4gICAgbGF5ZXIsIGFuZCB0aGUgc2Ft ZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KDQo+PiA+PiA+ID4+IGNvbnN0cnVj dGlvbg0KDQo+PiA+PiA+ID4+Pj4gb2YNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgc2VydmljZSBmdW5j dGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCg0KPj4gPj4gPiA+ Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gW1NNXSBXaGF0IGRvZXMgaXQgbWVhbiBieSBhIHNpbmds ZSBzZXJ2aWNlLWxldmVsDQoNCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24sDQoNCj4+ID4+ ID4gYQ0KDQo+PiA+PiA+ID4+Pj4gbmV3DQoNCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24g Zm9ybWF0DQoNCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgICAgb3IgYW4gYWJpbGl0eSB0byBzZWxl Y3Qgb25lIGVuY2Fwc3VsYXRpb24NCg0KPj4gPj4gPiA+Pj4+Pj4gZm9ybWF0IHRoYXQNCg0KPj4g Pj4gPiA+Pj4+IGZpdHMNCg0KPj4gPj4gPiA+Pj4+Pj4gdGhlDQoNCj4+ID4+ID4gPj4+Pj4+IG5l ZWQgZm9yIGEgZ2l2ZW4gc2VydmljZSBjaGFpbj8NCg0KPj4gPj4gPiA+Pj4+Pj4gICAgICAgICAg IFRoZSBhYmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24NCg0KPj4gPj4g PiA+Pj4+Pj4gd291bGQgYmUNCg0KPj4gPj4gPiA+PiBhDQoNCj4+ID4+ID4gPj4+Pj4+IG1hbmFn ZW1lbnQgcGxhbmUgZGVjaXNpb24uDQoNCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgIFRoZXJlIGFy ZSBxdWl0ZSBhIGZldyBleGlzdGluZyBlbmNhcHN1bGF0aW9uDQoNCj4+ID4+ID4gPj4+Pj4+IG1l dGhvZHMgdGhhdA0KDQo+PiA+PiA+ID4+Pj4gY2FuDQoNCj4+ID4+ID4gPj4+Pj4+IHBvc3NpYmx5 IGJlIHJldXNlZCB0byBwcm92aWRlDQoNCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgIGNvbnRleHQg aW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMuIEkgaGF2ZQ0KDQo+PiA+PiA+IHNl ZW4NCg0KPj4gPj4gPiA+Pj4+Pj4gbWVudGlvbg0KDQo+PiA+PiA+ID4+Pj4+PiBvZiBHUkUsIGZv ciBIVFRQIGJhc2VkDQoNCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgIGFwcGxpY2F0aW9ucyBjb250 ZXh0cyBhcmUgdHJhbnNmZXJyZWQgdmlhIGhlYWRlcnMuDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQoNCj4+ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuc2Mt Ym91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10NCg0KPj4gPj4g PiA+Pj4+Pj4gT24gQmVoYWxmDQoNCj4+ID4+ID4gPj4gT2YNCg0KPj4gPj4gPiA+Pj4+Pj4gVGhv bWFzIE5hcnRlbg0KDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA2 LCAyMDEzIDExOjA3IEFNDQoNCj4+ID4+ID4gPj4+Pj4+IFRvOiBuc2NAaWV0Zi5vcmc8bWFpbHRv Om5zY0BpZXRmLm9yZz4NCg0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBI aS4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gQ3VycmVudCBjaGFydGVyIGNh biBiZSBmb3VuZCBhdA0KDQo+PiA+PiA+ID4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9jaGFydGVyLQ0KDQo+PiA+PiA+ID4+Pj4+PiBpZXRmLXNmYy8uDQoNCj4+ID4+ID4g Pj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IEl0IGNvbnRhaW5zIHRoZSByZXZpc2VkIG1hbmFnZW1l bnQgdGV4dCBhcyB3ZWxsIGFzDQoNCj4+ID4+ID4gPj4+Pj4+IHVwZGF0ZWQNCg0KPj4gPj4gPiA+ Pj4+IG1pbGVzdG9uZXMuDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IEFsbCBr bm93biBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gSWYgdGhlcmUgYXJlIGFueQ0KDQo+PiA+ PiA+ID4+Pj4+PiByZW1haW5pbmcNCg0KPj4gPj4gPiA+Pj4+IGlzc3VlcywNCg0KPj4gPj4gPiA+ Pj4+Pj4gcGxlYXNlIHNwZWFrIHVwIQ0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+ PiBDaGFydGVyIGNoYXJ0ZXItaWV0Zi1zZmMtMDAtMDQNCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4g Pj4gPiA+Pj4+Pj4gTmV0d29ya3MsIHNlcnZlcnMsIHN0b3JhZ2UgdGVjaG5vbG9naWVzLCBhbmQN Cg0KPj4gPj4gPiA+Pj4+Pj4gYXBwbGljYXRpb25zLCBoYXZlIGFsbCB1bmRlcmdvbmUgc2lnbmlm aWNhbnQgY2hhbmdlIGluDQoNCj4+ID4+ID4gPj4+Pj4+IHJlY2VudCB5ZWFycyB3aXRoIHRoZSBp bnRyb2R1Y3Rpb24NCg0KPj4gPj4gPiA+PiBvZg0KDQo+PiA+PiA+ID4+Pj4+PiB2aXJ0dWFsaXph dGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24uDQoNCj4+ID4+ID4gPj4+ Pj4+IFNlcnZpY2UNCg0KPj4gPj4gPiA+PiBkZWxpdmVyeQ0KDQo+PiA+PiA+ID4+Pj4gaXMNCg0K Pj4gPj4gPiA+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlv bmFsIGNoYWxsZW5nZQ0KDQo+PiA+PiA+ID4+Pj4+PiB0aGF0DQoNCj4+ID4+ID4gPj4gaW52b2x2 ZXMNCg0KPj4gPj4gPiA+Pj4+Pj4gc2lnbmlmaWNhbnQgbW9kaWZpY2F0aW9uIHRvIHRoZSBuZXR3 b3JrIGNvbmZpZ3VyYXRpb24uDQoNCj4+ID4+ID4gPj4+Pj4+IFNlcnZpY2VzIGFyZSB0eXBpY2Fs bHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQNCg0KPj4gPj4gPiA+Pj4+Pj4gY29tYmluYXRp b24gb2YgYSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUNCg0KPj4gPj4gPiA+ Pj4+Pj4gZGVwbG95ZWQgYXQgZGlmZmVyZW50IHBvaW50cyB3aXRoaW4NCg0KPj4gPj4gPiA+PiB0 aGUNCg0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEgY29tbW9uIGRlcGxveW1lbnQg bW9kZWwgaGFzIHNlcnZpY2UNCg0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb25zIHBoeXNpY2FsbHkg aW5zZXJ0ZWQgb24gdGhlIGRhdGEgZm9yd2FyZGluZyBwYXRoDQoNCj4+ID4+ID4gPj4+Pj4+IGJl dHdlZW4gY29tbXVuaWNhdGluZyBwZWVycy4NCg0KPj4gPj4gPiA+Pj4+IEdvaW5nDQoNCj4+ID4+ ID4gPj4+Pj4+IGZvcndhcmQsIGhvd2V2ZXIsIHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdG8g YQ0KDQo+PiA+PiA+ID4+Pj4+PiBkaWZmZXJlbnQgbW9kZWwsDQoNCj4+ID4+ID4gPj4+PiB3aGVy ZQ0KDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgbm90IHJlcXVpcmVkIHRv IHJlc2lkZSBvbiB0aGUNCg0KPj4gPj4gPiA+Pj4+Pj4gZGVmYXVsdCBkYXRhDQoNCj4+ID4+ID4g Pj4gcGF0aA0KDQo+PiA+PiA+ID4+Pj4+PiBhbmQNCg0KPj4gPj4gPiA+Pj4+Pj4gdHJhZmZpYyBp cyBpbnN0ZWFkIHN0ZWVyZWQgdGhyb3VnaCBzZXJ2aWNlcywgd2hlcmV2ZXINCg0KPj4gPj4gPiA+ Pj4+Pj4gdGhleSBhcmUNCg0KPj4gPj4gPiA+Pj4+IGRlcGxveWVkLg0KDQo+PiA+PiA+ID4+Pj4+ Pg0KDQo+PiA+PiA+ID4+Pj4+PiBGb3IgYSBnaXZlbiBzZXJ2aWNlLCB0aGUgYWJzdHJhY3RlZCB2 aWV3IG9mIHRoZSByZXF1aXJlZA0KDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBh bmQgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRvIGJlDQoNCj4+ID4+ID4gPj4+Pj4+IGFw cGxpZWQgaXMNCg0KPj4gPj4gPiBjYWxsZWQNCg0KPj4gPj4gPiA+Pj4+Pj4gYSBTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluIChTRkMpLiBTaW5jZSBhIGdpdmVuIHNlcnZpY2UNCg0KPj4gPj4gPiA+Pj4+ Pj4gZnVuY3Rpb24gbWF5IGJlIGF2YWlsYWJsZSBvbiBtb3JlIHRoYW4gb25lIG5vZGUgd2l0aGlu IGENCg0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yaywgYSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIGlz IGluc3RhbnRpYXRlZA0KDQo+PiA+PiA+ID4+Pj4gdmlhDQoNCj4+ID4+ID4gPj4+Pj4+IHRoZSBz ZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgYW5kDQoNCj4+ ID4+ID4gPj4+Pj4+IHRoZSBuZXR3b3JrIG5vZGVzIG9uIHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVk LCB0aGVyZWJ5DQoNCj4+ID4+ID4gPj4+Pj4+IGZvcm1pbmcgYSBzZXJ2aWNlIHRvcG9sb2d5Og0K DQo+PiA+PiA+ID4+Pj4+PiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4g VGhlIHNlcnZpY2UNCg0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb25zDQoNCj4+ID4+ID4gbWF5DQoN Cj4+ID4+ID4gPj4+Pj4+IGJlIGFwcGxpZWQgYXQgYSBzcGVjaWZpYyBsYXllciB3aXRoaW4gdGhl IG5ldHdvcmsNCg0KPj4gPj4gPiA+Pj4+Pj4gcHJvdG9jb2wgc3RhY2sNCg0KPj4gPj4gPiA+Pj4+ IChuZXR3b3JrDQoNCj4+ID4+ID4gPj4+Pj4+IGxheWVyLCBhcHBsaWNhdGlvbiBsYXllciwgZXRj LikuDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IFRoZSBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nIChTRkMpIHdvcmtpbmcgZ3JvdXAgd2lsbA0KDQo+PiA+PiA+ID4+Pj4+PiBk ZXZlbG9wIG5ldyBhcHByb2FjaGVzIHRvIHNlcnZpY2UgZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQu DQoNCj4+ID4+ID4gPj4+Pj4+IEl0IHdpbGwgcHJvZHVjZSBhIGZyYW1ld29yayBmb3Igc2Vydmlj ZSBmdW5jdGlvbiBjaGFpbmluZw0KDQo+PiA+PiA+ID4+Pj4+PiB0aGF0IGluY2x1ZGVzIHRoZSBu ZWNlc3NhcnkgcHJvdG9jb2xzDQoNCj4+ID4+ID4gPj4+PiBvcg0KDQo+PiA+PiA+ID4+Pj4+PiBw cm90b2NvbCBleHRlbnNpb25zIHRvIGNvbnZleSB0aGUgc2VydmljZSBwYXRoIGFuZA0KDQo+PiA+ PiA+ID4+Pj4+PiBzZXJ2aWNlIHBhdGggaW5mb3JtYXRpb24gdG8gbm9kZXMgdGhhdCBpbXBsZW1l bnQgc2VydmljZQ0KDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbnMsIGFzIHdlbGwNCg0KPj4gPj4g PiBhcw0KDQo+PiA+PiA+ID4+Pj4+PiBtZWNoYW5pc21zIGZvciBzdGVlcmluZyB0cmFmZmljIHRo cm91Z2ggc2VydmljZSBmdW5jdGlvbnMuDQoNCj4+ID4+ID4gPj4+Pj4+IFRoZQ0KDQo+PiA+PiA+ ID4+Pj4gd29ya2luZw0KDQo+PiA+PiA+ID4+Pj4+PiBncm91cCB3aWxsIGFsc28gZXhhbWluZSB3 aGF0IGluZm9ybWF0aW9uIG5lZWRzIHRvIGJlDQoNCj4+ID4+ID4gPj4+Pj4+IGdhdGhlcmVkIGZy b20NCg0KPj4gPj4gPiA+Pj4+IHRoZQ0KDQo+PiA+PiA+ID4+Pj4+PiBuZXR3b3JrIGFuZCBzZXJ2 aWNlIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIHNlcnZpY2UNCg0KPj4gPj4gPiA+Pj4+Pj4gZnVu Y3Rpb24NCg0KPj4gPj4gPiA+PiBjaGFpbmluZw0KDQo+PiA+PiA+ID4+Pj4+PiBhbmQNCg0KPj4g Pj4gPiA+Pj4+Pj4gaG93IHRoYXQgaW5mb3JtYXRpb24gbWF5IGJlIG1hZGUgYXZhaWxhYmxlIHRv IG5vZGVzIHRoYXQNCg0KPj4gPj4gPiA+Pj4+Pj4gaW1wbGVtZW50DQoNCj4+ID4+ID4gPj4+PiB0 aGUNCg0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMuDQoNCj4+ID4+ID4gPj4+Pj4+ DQoNCj4+ID4+ID4gPj4+Pj4+IFNwZWNpZmljYWxseSwgdGhlIFNGQyBXRyBpcyBjaGFydGVyZWQg dG8gZGVsaXZlciB0aGUNCg0KPj4gZm9sbG93aW5nOg0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+ PiA+ID4+Pj4+PiAxKSBQcm9ibGVtIFN0YXRlbWVudDogVGhpcyBkb2N1bWVudCB3aWxsIHByb3Zp ZGUgYQ0KDQo+PiA+PiA+ID4+Pj4+PiBzdW1tYXJ5IG9mDQoNCj4+ID4+ID4gdGhlDQoNCj4+ID4+ ID4gPj4+Pj4+ICAgIHByb2JsZW0gc3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBXRyBpbmNs dWRpbmcNCg0KPj4gPj4gPiA+Pj4+Pj4gZXhhbXBsZQ0KDQo+PiA+PiA+IGhpZ2gtDQoNCj4+ID4+ ID4gPj4+Pj4+ICAgIGxldmVsIHVzZSBjYXNlcy4gQWRkaXRpb25hbGx5LCB0aGUgV0cgd2lsbCBu b3JtYWxpemUNCg0KPj4gPj4gPiA+PiBub21lbmNsYXR1cmUNCg0KPj4gPj4gPiA+Pj4+Pj4gICAg YW5kIGRlZmluaXRpb25zIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLg0KDQo+PiA+PiA+ ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiAyKSBBcmNoaXRlY3R1cmU6IFRoaXMgZG9jdW1lbnQg d2lsbCBwcm92aWRlIGEgZGVzY3JpcHRpb24NCg0KPj4gPj4gPiA+Pj4+Pj4gb2YNCg0KPj4gPj50 aGUNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgYXJjaGl0ZWN0dXJhbCBidWlsZGluZyBibG9ja3MgYW5k IHRoZWlyIHJlbGF0aW9uc2hpcHMNCg0KPj4gPj4gPiBpbmNsdWRpbmcNCg0KPj4gPj4gPiA+Pj4+ Pj4gICAgaW50ZXJjb25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVzLCBtYW5hZ2Vt ZW50LA0KDQo+PiA+PiA+ID4+Pj4+PiAgICBkaWFnbm9zdGljcywgZGVzaWduIGFuYWx5c2lzLCBh bmQgc2VjdXJpdHkgbW9kZWxzLCBhcw0KDQo+PiA+PiA+ID4+Pj4+PiB3ZWxsDQoNCj4+ID4+YXMN Cg0KPj4gPj4gPiA+Pj4+Pj4gICAgcmVxdWlyZW1lbnRzIG9uIHRoZSBwcm90b2NvbCBtZWNoYW5p c21zLg0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiAzKSBHZW5lcmljIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQQ0KDQo+PiA+PiA+ID4+Pj4+PiBk b2N1bWVudA0KDQo+PiA+PiA+IHdpbGwNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgZGVzY3JpYmUgdGhl IHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUNCg0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBz dWxhdGlvbg0KDQo+PiA+PiA+ID4+IGZvcm1hdA0KDQo+PiA+PiA+ID4+Pj4+PiBmb3INCg0KPj4g Pj4gPiA+Pj4+Pj4gICAgY29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0 aGUgc2VydmljZQ0KDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbg0KDQo+PiA+PiA+ID4+Pj4gcGF0 aCwNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNvbnRleHQgaW5m b3JtYXRpb24gYmV0d2Vlbg0KDQo+PiA+PiA+ID4+Pj4+PiBub2Rlcw0KDQo+PiB0aGF0DQoNCj4+ ID4+ID4gPj4+Pj4+ICAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4gSXQgaXMgaW50ZW5k ZWQgdGhhdCB0aGUNCg0KPj4gPj4gPiA+Pj4+IGVuY2Fwc3VsYXRpb24NCg0KPj4gPj4gPiA+Pj4+ Pj4gICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQgYW5k DQoNCj4+ID4+ID4gPj4+Pj4+IHRoZSBzZXJ2aWNlDQoNCj4+ID4+ID4gPj4+PiB0aGF0DQoNCj4+ ID4+ID4gPj4+Pj4+IGlzDQoNCj4+ID4+ID4gPj4+Pj4+ICAgIGJlaW5nIGNvbnN0cnVjdGVkLiBU aGF0IGlzLCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1heQ0KDQo+PiA+PiA+ID4+Pj4+PiBiZQ0K DQo+PiA+PiA+IHVzZWQNCg0KPj4gPj4gPiA+PiBvbg0KDQo+PiA+PiA+ID4+Pj4+PiAgICBhIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yayBsYXllcg0KDQo+PiA+ PiA+ID4+Pj4+PiBvciBhdCBhbnkgb3RoZXINCg0KPj4gPj4gPiA+Pj4+Pj4gICAgbGF5ZXIsIGFu ZCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KDQo+PiA+PiA+ID4+ IGNvbnN0cnVjdGlvbg0KDQo+PiA+PiA+ID4+Pj4gb2YNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgc2Vy dmljZSBmdW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1YWwgc2VydmljZS4NCg0K Pj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4gNCkgQ29udHJvbCBQbGFuZSBNZWNoYW5p c21zOiBBIHNldCBvZiBkb2N1bWVudHMgd2lsbCBiZQ0KDQo+PiA+PiA+IGRldmVsb3BlZCB0bw0K DQo+PiA+PiA+ID4+Pj4+PiAgICBkZXNjcmliZSByZXF1aXJlbWVudHMgYW5kIHByb3RvY29scyBu ZWNlc3NhcnkgdG8NCg0KPj4gPj4gPiA+Pj4+Pj4gY29udmV5DQoNCj4+ID4+ID4gPj4+PiBpbmZv cm1hdGlvbg0KDQo+PiA+PiA+ID4+Pj4+PiAgICB0byBzZXJ2aWNlIGZ1bmN0aW9uIGltcGxlbWVu dGF0aW9uIHBvaW50cy4gV2hlcmUNCg0KPj4gPj4gPiA+Pj4+Pj4gcG9zc2libGUsDQoNCj4+ID4+ ID4gPj4+PiBleGlzdGluZw0KDQo+PiA+PiA+ID4+Pj4+PiAgICBJRVRGIHByb3RvY29scyB3aWxs IGJlIHVzZWQgYW5kIGV4dGVuZGVkLiBBbGwgcHJvdG9jb2wNCg0KPj4gPj4gPiA+PiBleHRlbnNp b25zDQoNCj4+ID4+ID4gPj4+Pj4+ICAgIHdvcmsgc2hvdWxkIGJlIGNhcnJpZWQgb3V0IGluIHRo ZSB3b3JraW5nIGdyb3Vwcw0KDQo+PiA+PiA+ID4+Pj4+PiByZXNwb25zaWJsZSBmb3INCg0KPj4g Pj4gPiA+Pj4+IHRoZQ0KDQo+PiA+PiA+ID4+Pj4+PiAgICBwcm90b2NvbHMgYmVpbmcgbW9kaWZp ZWQgaW4gY29vcmRpbmF0aW9uIHdpdGggdGhpcw0KDQo+PiA+PiA+ID4+Pj4+PiB3b3JraW5nDQoN Cj4+ID4+ID4gPj4gZ3JvdXAsDQoNCj4+ID4+ID4gPj4+Pj4+IGJ1dA0KDQo+PiA+PiA+ID4+Pj4+ PiAgICBtYXkgYmUgZG9uZSBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgYWZ0ZXIgYWdyZWVtZW50IHdp dGgNCg0KPj4gPj4gPiA+Pj4+Pj4gYWxsDQoNCj4+ID4+ID4gdGhlDQoNCj4+ID4+ID4gPj4+Pj4+ ICAgIHJlbGV2YW50IFdHIGNoYWlycyBhbmQgcmVzcG9uc2libGUgQURzLg0KDQo+PiA+PiA+ID4+ Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiA1KSBNYW5hZ2VhYmlsaXR5OiBXb3JrIG9uIHRoZSBtYW5h Z2VtZW50IGFuZA0KDQo+PiA+PiA+ID4+Pj4+PiBjb25maWd1cmF0aW9uIG9mDQoNCj4+ID4+ID4g Pj4gc2VydmljZQ0KDQo+PiA+PiA+ID4+Pj4+PiAgICBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBT RkMgY29tcG9uZW50cyB3aWxsIGNlcnRhaW5seQ0KDQo+PiA+PiA+ID4+Pj4+PiBiZQ0KDQo+PiA+ PiA+IG5lZWRlZCwNCg0KPj4gPj4gPiA+Pj4+Pj4gICAgYnV0IGZpcnN0IG5lZWRzIHRvIGJlIGJl dHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4g Pj4+Pj4+IFByb3Bvc2VkIE1pbGVzdG9uZXMNCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+ Pj4+Pj4gQXByIDIwMTQgU3VibWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudChzKQ0K DQo+PiA+PiA+ID4+Pj4+PiBkZWZpbmluZyB0aGUNCg0KPj4gPj4gPiA+Pj4+IHByb2JsZW0NCg0K Pj4gPj4gPiA+Pj4+Pj4gc3RhdGVtZW50IGFuZCBjb3JlIHVzZSBjYXNlcyBmb3IgU2VydmljZSBG dW5jdGlvbg0KDQo+PiA+PiA+ID4+Pj4+PiBDaGFpbmluZw0KDQo+PiA+PiA+ID4+Pj4+Pg0KDQo+ PiA+PiA+ID4+Pj4+PiBNYXkgMjAxNCBDb25zdWx0IHdpdGggT1BTIEFyZWEgb24gcG9zc2libGUg Y2hhcnRlcg0KDQo+PiA+PiA+ID4+Pj4+PiBtb2RpZmljYXRpb25zIGZvciBtYW5hZ2VtZW50IGFu ZCBjb25maWd1cmF0aW9uIG9mIFNGQw0KDQo+PiA+PiA+ID4+Pj4+PiBjb21wb25lbnRzDQoNCj4+ ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIElu Zm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcNCg0KPj4gPj4gPiA+Pj4+Pj4gdGhlDQoNCj4+ ID4+ID4gPj4+PiBhcmNoaXRlY3R1cmUNCg0KPj4gPj4gPiA+Pj4+Pj4gZm9yIFNGQw0KDQo+PiA+ PiA+ID4+Pj4+Pg0KDQo+PiA+PiA+ID4+Pj4+PiBKYW4gMjAxNSBTdWJtaXQgdG8gSUVTRyByZXF1 aXJlbWVudHMgZm9yIGEgZ2VuZXJpYw0KDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4g Pj4gPiA+Pj4+Pj4gQXVnIDIwMTUgU3VibWl0IHRvIElFU0cgU3RhbmRhcmRzIFRyYWNrIGRvY3Vt ZW50DQoNCj4+ID4+ID4gPj4+Pj4+IHNwZWNpZnlpbmcgdGhlDQoNCj4+ID4+ID4gPj4+PiBnZW5l cmljDQoNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaGVhZGVyIGVu Y2Fwc3VsYXRpb24NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4g PiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+Pj4+Pj4NCg0KPj4gPj4gPiA+ Pj4+Pj4gVGhvbWFzDQoNCj4+ID4+ID4gPj4+Pj4+DQoNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+ID4+ID4gPj4+Pj4+ IG5zYyBtYWlsaW5nIGxpc3QNCg0KPj4gPj4gPiA+Pj4+Pj4gbnNjQGlldGYub3JnPG1haWx0bzpu c2NAaWV0Zi5vcmc+DQoNCj4+ID4+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbnNjDQoNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+ID4+ID4gPj4+Pj4+IG5zYyBtYWlsaW5nIGxp c3QNCg0KPj4gPj4gPiA+Pj4+Pj4gbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoN Cj4+ID4+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNj DQoNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCj4+ID4+ID4gPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCg0KPj4gPj4gPiA+ Pj4+Pj4gbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoNCj4+ID4+ID4gPj4+Pj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoNCj4+ID4+ID4gPj4+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4g Pj4gPiA+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQoNCj4+ID4+ID4gPj4+Pj4gbnNjQGlldGYub3Jn PG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoNCj4+ID4+ID4gPj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KPj4gPj4gPiA+DQoNCj4+ID4+ID4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KPj4gPj4gPiBuc2MgbWFp bGluZyBsaXN0DQoNCj4+ID4+ID4gbnNjQGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoN Cj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KPj4g Pj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQo+ PiA+PiA+IG5zYyBtYWlsaW5nIGxpc3QNCg0KPj4gPj4gPiBuc2NAaWV0Zi5vcmc8bWFpbHRvOm5z Y0BpZXRmLm9yZz4NCg0KPj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zYw0KDQo+PiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KDQo+PiA+PiA+IG5zY0BpZXRm Lm9yZzxtYWlsdG86bnNjQGlldGYub3JnPg0KDQo+PiA+PiA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnNjDQoNCj4+DQoNCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQoNCj4+IG5zYyBtYWlsaW5nIGxpc3QNCg0KPj4gbnNj QGlldGYub3JnPG1haWx0bzpuc2NAaWV0Zi5vcmc+DQoNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnNjDQoNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQo+bnNjIG1haWxpbmcgbGlzdA0KDQo+bnNjQGlldGYub3JnPG1h aWx0bzpuc2NAaWV0Zi5vcmc+DQoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zYw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCg0KbnNjIG1haWxpbmcgbGlzdA0KDQpuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRm Lm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbnNjIG1haWxp bmcgbGlzdA0KDQpuc2NAaWV0Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbnNjIG1haWxpbmcgbGlzdA0KDQpuc2NAaWV0 Zi5vcmc8bWFpbHRvOm5zY0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uc2MNCg== --_000_4040FE44D74FA042A7C2595F696FD1227FA10CA3SZXEMA502MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi David,<= /p>

Service function instance se= rving multiple service chains is different from the branching function.

For the former , packet=A1=AF= s path id( service chaining id) field of the se= rvice chaining header is not changed while whole specific service chain=A1=AFs packets passing through th= e service function. That likes parallel railways path through the railway s= tation.  

For the later,  after s= ervice function processing, packets belongs to the same service chain will = be changed about their common path id value to several different path id va= lues according the service function=A1=AFs decision. That likes one railway forks several railways after the railway = station.

 

Best Regards

Lehong Niu    = ;   

 

 

-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] =B4=FA=B1=ED David Allan I
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C213=C8=D5 23:45
=CA=D5=BC=FE=C8=CB: Hongyu Li (Julio); nsc@ietf.org
=D6=F7=CC=E2: Re: [nsc] FW: re classification & branching, was: Curren= t Proposed SFC charter

 

HI Hongyu:=

 

I think we will have scenari= os where a service function appears in more than one chain, as would be the= case, for example, if some flows could dynamically bypass DPI but still ne= eded to transit a common set of stateful service functions...

 

Once you postulate a service= function instance appearing in more than one chain, it seems artificially = restrictive not to permit such a function to also implement branching, all = the control structures would already be there.

 

Rgds

Dave

 

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

From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com]

Sent: Wednesday, November 13= , 2013 2:12 AM

To: David Allan I; nsc@ietf.org

Subject: RE: [nsc] FW: re cl= assification & branching, was: Current Proposed SFC charter<= /span>

 

May I suggest summary of my = views here:

 

1. Branch is a sort of use c= ase or scenario, while reclassification is a way to solve the problem.=

2. Service Functions should = be decoupled with the chain itself.

    &nbs= p;    Meaning, a SF shall not *directly* impact the forwardi= ng of packets in a chain. Branching should be performed by chain forwarding= nodes, possibly under control of a control node. The reason for this is in NFV world, service functions may come from a third party, while chain is p= rovided by the infrastructure of the network. There must be a cushion avoid= ing a service function operating infrastructure directly.=

3. (Re)classification is bas= ed on info in a packet.

    &nbs= p;    This is very general. Such info could be L2~L7 derived= from a user's packet, as well as some info like metadata in a SFC header. = As classification is out of scope of SFC, we don't have to provide too much details of how to do classification.

4. Chain segments stitching = is relatively a easy way for branching. Compared with chains and subchains,= which may require a more complex header and forwarding capabilities.<= /o:p>

My two cents.

Hongyu

 

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

From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On B= ehalf Of David Allan I

Sent: Wednesday, November 13= , 2013 3:04 AM

To: nsc@ietf.org<= /span>

Subject: [nsc] FW: re classi= fication & branching, was: Current Proposed SFC charter

 

Hi:

(resend with recipient list = cleaned up)

 

I agree we are discussing mu= ltiple concepts, classification and flow-subsetting. Perhaps more ;-)<= /o:p>

 

Defining a flow subset can b= e a result of classification, but it is not the exclusive mechanism. Branch= ing is a mechanism by which flow subsets are exposed and mapped to a set of= subchains such that it can be identified in the dataplane...

 

That's the view from here

Dave

 

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

From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On B= ehalf Of David Lake (dlake)

Sent: Tuesday, November 12, = 2013 10:51 AM

To: Jim Guichard (jguichar);= Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li = (Julio)

Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee

Subject: Re: [nsc] Current P= roposed SFC charter

 

Understood - maybe just a li= ttle localised warming of the sea then ?   But I still think we n= eed to consider where and how policy is defined/set even for the single-dom= ain instance.

 

I don't think we can assume = that any L1-3 device will be able to determine much useful information from= the data-plane.

 

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

From: Jim Guichard (jguichar= )

Sent: 12 November 2013 10:44=

To: David Lake (dlake); Kevi= n J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Juli= o)

Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee

Subject: Re: [nsc] Current P= roposed SFC charter

 

As discussed during the BOF = our initial work is single administrative domain for some of the very reaso= ns you point out. We need to keep focused without trying to boil the ocean = right off the bat.

 

On 11/12/13 1:36 PM, "D= avid Lake (dlake)" <dlake@cisco.com> w= rote:

 

>Exactly.  But how c= an network-components "terminate" an application ????<= /span>

> =

>I think we need a good u= nderstanding of a recursive policy mechanism

>(recursive because a use= r-land application will ride with a specific

>policy across potentiall= y different sets of carrier policies).

> =

>I hate to bring this up = now, but we also need to think about this

>multi-domain issue - if = I set a policy as a user, chances are I will be

>crossing several domain = boundaries.  Are we expecting the service

>headers to define the se= rvice chaining for the duration of the entire

>flow across all domains,= or just across a single one ?

> =

>In which case, do I have= to re-set policy as I traverse domains  and

>where does that policy g= et set ?   It would be much better to set policy

>once based on L5-7 needs= , and have that instantiated across the

>multiple domains.

> =

>Again, this appears to b= e outside the scope of SFC, but pretty relevant

>to how it would operate = in the real world.

> =

>David<= /p>

> =

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

>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]

>Sent: 12 November 2013 1= 0:27

>To: David Lake (dlake); = Surendra Kumar (smkumar); Ron Parker; Linda

>Dunbar; Hongyu Li (Julio= )

>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee

>Subject: RE: [nsc] Curre= nt Proposed SFC charter

> =

>> In those circumstan= ces, only the end applications themselves or a

>> reasonably broad-br= ushed classification (really traffic steering

>> based on what we ca= n see at ingress) is going to be useful - is THAT

>> what we're aiming f= or here ?

> =

>I would certainly hope n= ot, but that has been my concern as well.

>Application layer termin= ation and re-classification seems a must?

> =

>--  Kevin J. Ma

> =

>> -----Original Messa= ge-----

>> From: David Lake (d= lake) [mailto:dlake@cisco.com]

>> Sent: Tuesday, Nove= mber 12, 2013 1:00 PM

>> To: Surendra Kumar = (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;

>> Hongyu Li (Julio)

>> Cc: Thomas Narten; = nsc@ietf.org; Sumandra Majee

>> Subject: RE: [nsc] = Current Proposed SFC charter

>> 

>> Policy may be outsi= de of the scope of SFC, but without strong mapping

>> between Policy and = the inserted Service Header(s), we run-the-risk of

>> limiting the effica= cy of the protocol IMO.

>> 

>> For example, in a w= orld where the network has "gone dark," (as per

>> the IETF Technical = Plenary ?:-) ) what is our ability to determine

>> policy based on DPI= of packets-in-flight ?

>> 

>> In those circumstan= ces, only the end applications themselves or a

>> reasonably broad-br= ushed classification (really traffic steering

>> based on what we ca= n see at ingress) is going to be useful - is THAT

>> what we're aiming f= or here ?

>> 

>> David

>> 

>> -----Original Messa= ge-----

>> From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On B= ehalf Of

>> Surendra Kumar (smk= umar)

>> Sent: 12 November 2= 013 09:26

>> To: Ron Parker; Kev= in J Ma; Linda Dunbar; Hongyu Li (Julio)

>> Cc: Thomas Narten; = nsc@ietf.org; Sumandra Majee

>> Subject: Re: [nsc] = Current Proposed SFC charter

>> 

>> Ron,

>> 

>> Classification of t= raffic is well understood and we do not have to

>> redefine it - it's = been around for all the time middle boxes have

>> been or for that ma= tter the L2/L3 devices. All we are talking about

>> is the applicabilit= y of the classification to branching in SFC.

>> 

>> You are right, it i= s all about policy which is outside the scope of SFC.

>> 

>> Surendra.

>> 

>> On 11/12/13 7:53 AM= , "Ron Parker" <Ron_Parker@affir= mednetworks.com>

>>wrote:

>> 

>> >I think the lac= k of definition of "reclassification" may be causing

>>some

>> >misunderstandin= gs here.    A branch would occur for some policy-driven=

>> >reason based on= the behavior and conclusions of the service function,

>> >itself. &n= bsp; The graph would represent the fact that there is a branch

>> >point, but the = service function, itself, being aware that it is a

>> >branching point= would contain the policy and logic to decide on which

>> >branch to take.=    Specifying that policy and logic is out of scope,

>>IMO.

>> >

>> >   Ro= n

>> >

>> >

>> >-----Original M= essage-----

>> >From: Kevin J M= a [mailto:kevin.ma@azukisystems.com]

>> >Sent: Tuesday, = November 12, 2013 10:49 AM

>> >To: Linda Dunba= r; Ron Parker; Hongyu Li (Julio)

>> >Cc: Thomas Nart= en; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra

>> >Majee

>> >Subject: RE: [n= sc] Current Proposed SFC charter

>> >

>> >Hi Linda,<= /o:p>

>> >

>> >  Are you = saying that a branching point is "never" a

>> > reclassificati= on point, or are you saying that a branching point "does not have to b= e"

>> >  a reclas= sification point?

>> >

>> >  I think = this is an important distinction that needs to be clarified.

>> >  If branc= hing is never reclassification, then the meaning of a

>> > chain is diffe= rent than I originally inferred.  If the chain is a

>> > tree with othe= r "branching" points in it, then that limits the

>> > scope of the p= roblem statement goals.

>> >

>> >  While th= is could be a degenerate case, and any implementation

>> > could define b= ad service chains, is it the intent of SFC to only

>> > look at the si= mpler packet-level classification cases, or is it the

>> > intent to cons= ider the case where a branching point is viewed as a

>> > re-classificat= ion point?

>> >

>> >thanx.

>> >

>> >--  Kevin = J. Ma

>> >

>> >> -----Origi= nal Message-----

>> >> From: Lind= a Dunbar [mailto:linda.dunbar@huawei.com]<= o:p>

>> >> Sent: Tues= day, November 12, 2013 10:34 AM

>> >> To: Ron Pa= rker; Hongyu Li (Julio); Kevin J Ma

>> >> Cc: Thomas= Narten; nsc@ietf.org; Surendra Kumar (smkumar);

>> >> Sumandra M= ajee

>> >> Subject: R= E: [nsc] Current Proposed SFC charter

>> >>=

>> >> Ron,<= /o:p>

>> >>=

>> >> First, wan= t to make it clear that "branching" !=3D reclassification,

>> >>agree?=

>> >>=

>> >> Second, th= e representation of branching (or service graph) can be

>> >> in a form = of logic on a service function. Some service functions,

>> >> especially= L7 based, can use value in a Database to determine what

>> >> is the nex= t service function.

>> >>=

>> >> Linda=

>> >>=

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

>> >> > From:= nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On

>> >> > Behal= f Of Ron Parker

>> >> > Sent:= Tuesday, November 12, 2013 8:16 AM

>> >> > To: H= ongyu Li (Julio); Kevin J Ma

>> >> > Cc: T= homas Narten; nsc@ietf.org; Surendra Kumar (smkumar);

>> >> > Suman= dra Majee

>> >> > Subje= ct: Re: [nsc] Current Proposed SFC charter

>> >> ><= /o:p>

>> >> > Hongy= u,

>> >> ><= /o:p>

>> >> > I agr= ee completely that re-classification is not limited to DPI.

>> >> ><= /o:p>

>> >> > And a= lso, that an area for us to explore as a group is how to<= /p>

>> >>represent

>> >> > the s= ervice graph.   Do we want to represent it as a proper graph=

>> with

>> >> > an ad= jacency list or other representational model?   Or, do we want

>> to

>> >> > repre= sent it as a set of linear segments and if so, how are the

>> >> > segme= nts connected into a graph?   Other ideas?

>> >> ><= /o:p>

>> >> > =    Ron

>> >> ><= /o:p>

>> >> ><= /o:p>

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

>> >> > From:= nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On

>> >> > Behal= f Of Hongyu Li (Julio)

>> >> > Sent:= Tuesday, November 12, 2013 6:57 AM

>> >> > To: R= on Parker; Kevin J Ma

>> >> > Cc: T= homas Narten; nsc@ietf.org; Surendra Kumar (smkumar);

>> >> > Suman= dra Majee

>> >> > Subje= ct: Re: [nsc] Current Proposed SFC charter

>> >> ><= /o:p>

>> >> > Branc= hing/forking is a very interesting topic of SFC. About the

>> >> > re- c= lassification point, probably we shall not limit it to DPI.

>> >> > It is= also possible that packets go to different branches after

>> >> > been = processed by a certain service function, decision of which

>> >> > branc= hes to go is made based on the result of service function's

>> >> > proce= ss, i.e. not just re- classification by DPI.

>> >> ><= /o:p>

>> >> > Hongy= u

>> >> ><= /o:p>

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

>> >> > From:= nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org] On

>> >> > Behal= f Of Ron Parker

>> >> > Sent:= Tuesday, November 12, 2013 7:45 PM

>> >> > To: K= evin J Ma

>> >> > Cc: T= homas Narten; nsc@ietf.org; Surendra Kumar (smkumar);

>> >> > Suman= dra Majee

>> >> > Subje= ct: Re: [nsc] Current Proposed SFC charter

>> >> ><= /o:p>

>> >> > Hi, K= evin

>> >> ><= /o:p>

>> >> > You a= sk a great question about branching the graph.  The details

>> >> > aroun= d how to convey the selection of the subtree/subgraph are

>> >> > still=

>> >>to be<= /o:p>

>> >> > defin= ed.   Is it one chain id for the whole graph?   Does ea= ch

>>branch

>> >> > have = its own chain id?   Some combination?

>> >> ><= /o:p>

>> >> > =    Ron

>> >> ><= /o:p>

>> >> > On No= v 12, 2013, at 1:52 AM, "Kevin J Ma"

>> >> > <<= a href=3D"mailto:kevin.ma@azukisystems.com">kevin.ma@azukisystems.com><= /span>

>> >> > wrote= :

>> >> ><= /o:p>

>> >> > >&= gt; Yes, reclassification can change the service path and

>> >> > >&= gt; re-classification may happen at any node along a service path.

>> >> > ><= o:p>

>> >> > > = Just to expand on that, going back to the original question

>> >> > > = about service header encapsulation, is it intended that a

>> >> > > = chain that is re-classified will get a new chain ID which

>> >> > > = fully describes a chain that is a superset of the original

>> >> > > = chain ID, prior to DPI-based re-classification?  (assuming the

>> >> > > = goal is "a single chain ID that is commonly understood along

>> >> > > = the entire service

>> chain"

>> >> > > = http://www.ietf.org/m= ail-archive/web/nsc/current/msg00638.html

>> >> > > = )

>> >> > ><= o:p>

>> >> > > = And the applicable subset of the permutative list of service

>> >> > > = paths would be configured at each appropriate service node?

>> >> > > = e.g., ID 1: NAT + firewall + DPI

>> >> > >&= nbsp;     ID 2: NAT + firewall + DPI + AV

>> >> > >&= nbsp;     ID 3: NAT + firewall + DPI + AV &= #43; NAT

>> >> > >&= nbsp;     ID 4: NAT + firewall + DPI + NAT<= o:p>

>> >> > >&= nbsp;     ID 5: NAT + firewall + DPI + AV &= #43; LB

>> >> > >&= nbsp;     ID 6: NAT + firewall + DPI + LB

>> >> > >&= nbsp;     ID 7: NAT + firewall + DPI + LB &= #43; CACHE

>> >> > >&= nbsp;     ID 8: NAT + firewall + DPI + CACH= E

>> >> > >&= nbsp;     ID 9: NAT + firewall + DPI + opti= mizer + LB

>> >> > >&= nbsp;     ID 10: NAT + firewall + DPI + opt= imizer + LB + CACHE

>> >> > >&= nbsp;     ID 11: NAT + firewall + DPI + opt= imizer + CACHE Would

>> >> > > = every flow then be initially classified as ID 1, but

>> >> > > = eventually get re-

>> >> > class= ified

>> >> > > = to ID 2-11, after the DPI phase?

>> >> > ><= o:p>

>> >> > > = thanx.

>> >> > ><= o:p>

>> >> > > = --  Kevin J. Ma

>> >> > ><= o:p>

>> >> > >&= gt; -----Original Message-----

>> >> > >&= gt; From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.co= m]

>> >> > >&= gt; Sent: Tuesday, November 12, 2013 1:01 AM

>> >> > >&= gt; To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;

>> >> > >&= gt; nsc@ietf.org

>> >> > >&= gt; Subject: Re: [nsc] Current Proposed SFC charter

>> >> > >&= gt;

>> >> > >&= gt;

>> >> > >&= gt;

>> >> > >&= gt;> On 11/11/13 9:46 PM, "Kevin J Ma"

>> >> > >&= gt;> <kevin.ma@azukisystems.com>= ;

>> >>wrote:=

>> >> > >&= gt;>

>> >> > >&= gt;> Hi Surendra,

>> >> > >&= gt;>

>> >> > >&= gt;> Classification may be out of scope, but the level of service

>> >> > >&= gt;> that

>> >> > is

>> >> > >&= gt;> applicable is dependent upon the level of classification

>> >> > >&= gt;> that can

>> >> > be

>> >> > >&= gt;> performed.  An assumption of packet level encapsulation has

>> >> > >&= gt; implications

>> >> > >&= gt;> on the level of classification being performed?  If the

>> >> > >&= gt;> stated

>> >> > goals=

>> >> > >&= gt; are

>> >> > >&= gt;> for firewall and load balancer functionality, then the

>> >> > >&= gt;> application

>> >> > >&= gt; level

>> >> > >&= gt;> nature of those functions needs to be taken into account?

>> >> > >&= gt;> If, on the other hand, the service function scope is limited

>> >> > >&= gt;> due to limitations in classification, that would be and

>> >> > >&= gt;> important piece of

>> >> > infor= mation?

>> >> > >&= gt;>

>> >> > >&= gt;> Wrt section 4.4 of draft-liu-service-chaining-use-cases the

>> >> > >&= gt;> fork points of the service paths seem like re-classification

>> points?<= /span>

>> >> > >&= gt;> Is that the interpretation from the architecture perspective?<= /o:p>

>> >> > >&= gt;> Or is the service function chain classification exclusive of

>> >> > >&= gt;> DPI

>> >> > funct= ionality?

>> >> > >&= gt; <SK> I have not fully read that draft yet. But in general, as

>> >> > >&= gt; described in the arch draft, the collection of services form

>> >> > >&= gt; a graph, segments of which are service paths. Yes,

>> >> > >&= gt; reclassification can

>> >> > chang= e

>> >> > >&= gt; the service path and re-classification may happen at any node

>> >> > >&= gt; along

>> >> > a ser= vice path.

>> >> > >&= gt;

>> >> > >&= gt; Surendra.

>> >> > >&= gt;>

>> >> > >&= gt;> thanx.

>> >> > >&= gt;>

>> >> > >&= gt;> --  Kevin J. Ma

>> >> > >&= gt;>

>> >> > >&= gt;>> -----Original Message-----

>> >> > >&= gt;>> From: Surendra Kumar (smkumar) [mailto:smkumar@= cisco.com]

>> >> > >&= gt;>> Sent: Tuesday, November 12, 2013 12:08 AM

>> >> > >&= gt;>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;

>> >> > >&= gt;>> nsc@ietf.org

>> >> > >&= gt;>> Subject: Re: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>

>> >> > >&= gt;>> Kevin,

>> >> > >&= gt;>>

>> >> > >&= gt;>> Classification mechanism is outside the scope of SFC. It

>> >> > >&= gt;>> can be based

>> >> > >&= gt; on

>> >> > >&= gt;>> the packet or information not in the packet(environmental

>> >> > >&= gt;>> attributes

>> >> > >&= gt; for

>> >> > >&= gt;>> instance) or a combination thereof. What is important is

>> >> > >&= gt;>> that such classification aids in traffic selection and

>> >> > >&= gt;>> service path identification.

>> >> > >&= gt;>> It is no different from a policy in this regard except that

>> >> > >&= gt;>> the policy now specifies the service path.

>> >> > >&= gt;>> Further, classification is not limited to the network

>> >> > >&= gt;>> elements but the service functions as well. Some of this is

>> >> > >&= gt;>> described in the

>> >> > >&= gt; architecture

>> >> > >&= gt;>> drafts as well -

>> >> > >&= gt;>> "https://dat= atracker.ietf.org/doc/draft-quinn-sfc-arch/".

>> >> > >&= gt;>>

>> >> > >&= gt;>> Surendra.

>> >> > >&= gt;>>

>> >> > >&= gt;>>> On 11/11/13 7:33 PM, "Kevin J Ma"

>> >> > >&= gt;>>> <kevin.ma@azukisystems.com>

>> >> > wrote= :

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> Hi Ron,

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> I was unable to make the SFC BoF due to a conflict with

>> >> > >&= gt;>>> CDNI, but I had a similar question wrt bullet 11 in

>> >> > >&= gt;>>> section

>> >> > >&= gt;>>> 2 of the

>> >> > probl= em

>> >> > >&= gt;>>> statement:

>> >> > >&= gt;>>>

>> >> > >&= gt;>>>   11.  Per-Service (re)Classification: Class= ification

>> >> > >&= gt;>>> occurs at

>> >> > each<= o:p>

>> >> > >&= gt;>>>        service, independ= ent from previously applied

>> >> > >&= gt;>>> service

>> >> > >&= gt;>> functions.

>> >> > >&= gt;>>>        These unrelated c= lassification events consume

>> >> > >&= gt;>>> resources

>> >> > per

>> >> > >&= gt;>>>        service.  Mo= re importantly, the classification

>> >> > funct= ionality

>> >> > >&= gt;>>>        often differs per= service function and service

>> >> > >&= gt;>>> function

>> >> > >&= gt; cannot

>> >> > >&= gt;>>>        leverage the resu= lts from other deployed network or

>> >> > servi= ce.

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> as it relates to section 5.2 of the framework document:

>> >> > >&= gt;>>>

>> >> > >&= gt;>>>   The SFC Classifier classifies packets based on = (some of)

>> >> > >&= gt;>>> the

>> >> > >&= gt;>> contents

>> >> > >&= gt;>>>   of the packet header.  Concretely, it clas= sifies packets

>> >> > >&= gt;>>> based on

>> >> > >&= gt;>> the

>> >> > >&= gt;>>>   possible combination of one or more header fiel= ds, such

>> >> > >&= gt;>>> as

>> >> > sourc= e

>> >> > >&= gt;>>>   address, destination address, DS field, protoco= l ID,

>> >> > >&= gt;>>> source

>> >> > port<= o:p>

>> >> > >&= gt;>> and

>> >> > >&= gt;>>>   destination port numbers, and any other informa= tion.

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> A packet-based classifier as described in the framework

>> >> > >&= gt;>>> document

>> >> > >&= gt;>> would

>> >> > >&= gt;>>> seem to be limited in what it can classify?  The servi= ce

>> >> > >&= gt;>>> function identifier lookup does not seem to be a

>> >> > >&= gt;>>> significant optimization

>> >> > >&= gt; over

>> >> > >&= gt;>>> a packet-based 5-tuple lookup?  There seems to be some

>> >> > >&= gt;>>> missing

>> >> > >&= gt; detail

>> >> > >&= gt;>>> wrt how classification information is determined and reused= ?

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> When thinking about higher level services, e.g., HTTP and

>> >> > >&= gt;>>> TLS

>> >> > >&= gt;>> encrypted

>> >> > >&= gt;>>> flows, a packet-based classifier seems inadequate?  I = was

>> >> > >&= gt;>>> also

>> >> > >&= gt;>> wondering

>> >> > >&= gt;>>> how independent HLS segment requests might be classified

>> >> > >&= gt;>>> and

>> >> > >&= gt;>> associated?

>> >> > >&= gt;>>> Were these types of use cases discussed in the BoF?

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> thanx.

>> >> > >&= gt;>>>

>> >> > >&= gt;>>> --  Kevin J. Ma

>> >> > >&= gt;>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org]

>> >> > >&= gt;>>>> On Behalf

>> >> > >&= gt; Of

>> >> > >&= gt;>>>> Ron

>> >> > >&= gt;>>>> Parker

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 10:16 PM

>> >> > >&= gt;>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: Re: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Sumandra,

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> As was discussed in Vancouver, there are already many

>> >> > >&= gt;>>>> existing ways

>> >> > >&= gt;>> to

>> >> > >&= gt;>>>> accomplish service chaining.     Bu= t none of them provide a

>> >> > >&= gt;>> sufficient

>> >> > >&= gt;>>>> combination of interoperability, flexibility, and<= /o:p>

>>resiliency.

>> >> > A

>> >> > >&= gt;>> single

>> >> > >&= gt;>>>> service chain encapsulation will go a long way to

>> >> > >&= gt;>>>> ensuring these

>> >> > >&= gt;>> goals.

>> >> > >&= gt;>>>> It  may not be the absolutely most efficient appro= ach for

>> >> > >&= gt;>>>> every

>> >> > >&= gt;>> single

>> >> > >&= gt;>>>> network topology and every single use case, but its

>> >> > >&= gt;>>>> ubiquitous

>> >> > >&= gt; nature

>> >> > >&= gt;>>>> should improve its adoption.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>   Ron

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: Sumandra Majee [mailto:S.Majee@F5.co= m]

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 10:10 PM

>> >> > >&= gt;>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: RE: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Ron,

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Absolutely, that was an example of one type of derivati= on.

>> >> > >&= gt;>>>> However

>> >> > >&= gt;>> this

>> >> > >&= gt;>>>> could be augmented with classification result, again on= e

>> >> > >&= gt;>>>> more

>> >> > >&= gt;>> example.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>>> All flows from the same source IP do not necess= arily

>> >> > >&= gt;>>>>>> follow

>> >> > the

>> >> > >&= gt;>> same

>> >> > >&= gt;>>>> chain.

>> >> > >&= gt;>>>> Correct. It is also not necessary that all transaction = of

>> >> > >&= gt;>>>> the same

>> >> > >&= gt;>> flow

>> >> > >&= gt;>>>> follow the same chain either. So why stop at flow itsel= f.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Again the point here is that do we always need SFC head= er

>> >> > >&= gt;>>>> or

>> >>Not.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Sumandra

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: Ron Parker [mailto:= Ron_Parker@affirmednetworks.com]

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 7:02 PM

>> >> > >&= gt;>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: RE: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Sumandra,

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> The intention of service function chaining is to allow

>> >> > >&= gt;>>>> for operation

>> >> > >&= gt;>> at

>> >> > >&= gt;>>>> the fully qualified flow level, or even finer grained a= t

>> >> > >&= gt;>>>> the

>> >> > >&= gt;>> transaction

>> >> > >&= gt;>>>> level (this is an implementation matter for the PDP).

>>All

>> >> > flows=

>> >> > >&= gt;>> from

>> >> > >&= gt;>>>> the same source IP do not necessarily follow the same c= hain.

>> >> > >&= gt; Source

>> >> > >&= gt;>>>> IP,

>> >> > >&= gt;>>>> therefore,  does not identify the chain ID. &= nbsp;  Another

>> >>intention

>> >> > of

>> >> > >&= gt;>>>> service function chaining is to operate over any networ= k

>> >> > topol= ogy

>> >> > >&= gt; and

>> >> > >&= gt;>>>> not

>> >> > >&= gt;>>>> be limited to a single LAN.   Thus, while VLA= N may be part

>>of=

>> >> > the

>> >> > >&= gt;>>>> transport, it does not adequately identify the service

>> >> > >&= gt;>>>> chain,

>> >> > >&= gt; either.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>   Ron

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: Sumandra Majee [mailto:S.Majee@F5.co= m]

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 9:56 PM

>> >> > >&= gt;>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: RE: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Ron,

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> The service header is meant to carry the context which

>> >> > >&= gt;>>>> can

>> >> > *also= *

>> >> > >&= gt;>>>> be derived (for example use source ip and vlan to

>> >> > >&= gt;>>>> identify chainID and

>> >> > >&= gt;>>>> position) or encapsulated as part of another tunnel hea= der.

>> >> > >&= gt;>>>> So this could be optional IMHO.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: Ron Parker [mailto:= Ron_Parker@affirmednetworks.com]

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 4:36 PM

>> >> > >&= gt;>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: RE: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Sumandra,

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> As I understand it, an SFC packet traversing from PDP t= o

>> >> > >&= gt;>>>> SF or from

>> >> > >&= gt;>> SF

>> >> > >&= gt;>>>> to

>> >> > >&= gt;>>>> SF will look like:

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> +------------------------+

>> >> > >&= gt;>>>> |        "trans= port"         |

>> >> > >&= gt;>>>> +------------------------+

>> >> > >&= gt;>>>> |      service header &nb= sp;  |

>> >> > >&= gt;>>>> +------------------------+

>> >> > >&= gt;>>>> |   original IP header  |

>> >> > >&= gt;>>>> +------------------------+

>> >> > >&= gt;>>>> |         =             &nb= sp;            =        |  original IP

>> >> > >&= gt;>>>> | payload

>> >> > |

>> >> > >&= gt;>>>> |          = ;            &n= bsp;            = ;      |

>> >> > >&= gt;>>>> +------------------------+

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Where service header contains, at a minimum, enough

>> >> > >&= gt;>>>> information to

>> >> > >&= gt;>> allow

>> >> > >&= gt;>>>> the packet to be propagated along the full length of th= e

>> >> > >&= gt;>>>> chain, and optionally, other metadata that enhances the

>> >> > >&= gt;>>>> operation of

>> >> > one

>> >> > >&= gt;>>>> or

>> >> > >&= gt; more

>> >> > >&= gt;>>>> service functions.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> And where "transport" could conceivably be an= y of, but

>> >> > >&= gt;>>>> not limited

>> >> > >&= gt;>> to:

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> * Ethernet

>> >> > >&= gt;>>>> * Ethernet + LLC2

>> >> > >&= gt;>>>> * Ethernet + MPLS

>> >> > >&= gt;>>>> * Ethernet + IP + GRE

>> >> > >&= gt;>>>> * Ethernet + IP +UDP

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Also, "original" in the diagram above is not = meant to

>> >> > >&= gt;>>>> imply immutability, but rather to specify the packet th= at

>> >> > >&= gt;>>>> is

>> >> > propa= gated

>> >> > >&= gt;>>>> from preceding entity to succeeding entity, prior to

>> >> > >&= gt;>>>> encapsulation.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>   Ron

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org]

>> >> > >&= gt;>>>> On Behalf

>> >> > >&= gt; Of

>> >> > >&= gt;>>>> Sumandra Majee

>> >> > >&= gt;>>>> Sent: Monday, November 11, 2013 6:46 PM

>> >> > >&= gt;>>>> To: Thomas Narten; nsc@ietf.org

>> >> > >&= gt;>>>> Subject: Re: [nsc] Current Proposed SFC charter

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Generic Service Function Chaining Encapsulation: A

>> >> > >&= gt;>>>> document

>> >>will

>> >> > >&= gt;>>>>    describe the single service-level dat= a plane

>> >> > >&= gt;>>>> encapsulation

>> >> > >&= gt; format

>> >> > >&= gt;>>>> for

>> >> > >&= gt;>>>>    conveying the service function chain = and the service

>> >> > >&= gt;>>>> function

>> >> > >&= gt;>> path,

>> >> > >&= gt;>>>>    and for communicating context informa= tion between

>> >> > >&= gt;>>>> nodes

>> that

>> >> > >&= gt;>>>>    implement service functions. It is in= tended that the

>> >> > >&= gt;>> encapsulation

>> >> > >&= gt;>>>>    be agnostic to the layer at which it = is applied and

>> >> > >&= gt;>>>> the service

>> >> > >&= gt;>> that

>> >> > >&= gt;>>>> is

>> >> > >&= gt;>>>>    being constructed. That is, the same = encapsulation may

>> >> > >&= gt;>>>> be

>> >> > used<= o:p>

>> >> > >&= gt; on

>> >> > >&= gt;>>>>    a service function path realized at t= he network layer

>> >> > >&= gt;>>>> or at any other

>> >> > >&= gt;>>>>    layer, and the same encapsulation wil= l apply for the

>> >> > >&= gt; construction

>> >> > >&= gt;>> of

>> >> > >&= gt;>>>>    service function paths regardless of = the actual service.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> [SM] What does it mean by a single service-level

>> >> > >&= gt;>>>> encapsulation,

>> >> > a

>> >> > >&= gt;>> new

>> >> > >&= gt;>>>> encapsulation format

>> >> > >&= gt;>>>>         &n= bsp;  or an ability to select one encapsulation

>> >> > >&= gt;>>>> format that

>> >> > >&= gt;>> fits

>> >> > >&= gt;>>>> the

>> >> > >&= gt;>>>> need for a given service chain?

>> >> > >&= gt;>>>>         &n= bsp; The ability to select a specific encapsulation

>> >> > >&= gt;>>>> would be

>> >> > >&= gt; a

>> >> > >&= gt;>>>> management plane decision.

>> >> > >&= gt;>>>>          T= here are quite a few existing encapsulation

>> >> > >&= gt;>>>> methods that

>> >> > >&= gt;>> can

>> >> > >&= gt;>>>> possibly be reused to provide

>> >> > >&= gt;>>>>          c= ontext information between   service nodes. I have

>> >> > seen<= o:p>

>> >> > >&= gt;>>>> mention

>> >> > >&= gt;>>>> of GRE, for HTTP based

>> >> > >&= gt;>>>>          a= pplications contexts are transferred via headers.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> -----Original Message-----

>> >> > >&= gt;>>>> From: nsc-bounces@ietf.org<= /span> [mailto:nsc-bounces@ietf.org]

>> >> > >&= gt;>>>> On Behalf

>> >> > >&= gt; Of

>> >> > >&= gt;>>>> Thomas Narten

>> >> > >&= gt;>>>> Sent: Wednesday, November 06, 2013 11:07 AM<= /span>

>> >> > >&= gt;>>>> To: nsc@ietf.org

>> >> > >&= gt;>>>> Subject: [nsc] Current Proposed SFC charter<= /span>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Hi.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Current charter can be found at

>> >> > >&= gt;>>>> https://datatracker.i= etf.org/doc/charter-

>> >> > >&= gt;>>>> ietf-sfc/.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> It contains the revised management text as well as

>> >> > >&= gt;>>>> updated

>> >> > >&= gt;>> milestones.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> All known issues have been addressed. If there are any

>> >> > >&= gt;>>>> remaining

>> >> > >&= gt;>> issues,

>> >> > >&= gt;>>>> please speak up!

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Charter charter-ietf-sfc-00-04

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Networks, servers, storage technologies, and

>> >> > >&= gt;>>>> applications, have all undergone significant change in

>> >> > >&= gt;>>>> recent years with the introduction

>> >> > >&= gt; of

>> >> > >&= gt;>>>> virtualization, network overlays, and orchestration.

>> >> > >&= gt;>>>> Service

>> >> > >&= gt; delivery

>> >> > >&= gt;>> is

>> >> > >&= gt;>>>> currently both a technical and organizational challenge

>> >> > >&= gt;>>>> that

>> >> > >&= gt; involves

>> >> > >&= gt;>>>> significant modification to the network configuration.<= o:p>

>> >> > >&= gt;>>>> Services are typically implemented by the ordered

>> >> > >&= gt;>>>> combination of a number of service functions that are

>> >> > >&= gt;>>>> deployed at different points within

>> >> > >&= gt; the

>> >> > >&= gt;>>>> network. Today, a common deployment model has service

>> >> > >&= gt;>>>> functions physically inserted on the data forwarding pa= th

>> >> > >&= gt;>>>> between communicating peers.

>> >> > >&= gt;>> Going

>> >> > >&= gt;>>>> forward, however, there is a desire to move to a

>> >> > >&= gt;>>>> different model,

>> >> > >&= gt;>> where

>> >> > >&= gt;>>>> service functions are not required to reside on the

>> >> > >&= gt;>>>> default data

>> >> > >&= gt; path

>> >> > >&= gt;>>>> and

>> >> > >&= gt;>>>> traffic is instead steered through services, wherever

>> >> > >&= gt;>>>> they are

>> >> > >&= gt;>> deployed.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> For a given service, the abstracted view of the require= d

>> >> > >&= gt;>>>> service functions and the order in which they are to be

>> >> > >&= gt;>>>> applied is

>> >> > calle= d

>> >> > >&= gt;>>>> a Service Function Chain (SFC). Since a given service

>> >> > >&= gt;>>>> function may be available on more than one node within = a

>> >> > >&= gt;>>>> network, a Service Function Chain is instantiated<= /o:p>

>> >> > >&= gt;>> via

>> >> > >&= gt;>>>> the selection of specific service function instances an= d

>> >> > >&= gt;>>>> the network nodes on which they are provided, thereby

>> >> > >&= gt;>>>> forming a service topology:

>> >> > >&= gt;>>>> this is called a Service Function Path. The service

>> >> > >&= gt;>>>> functions

>> >> > may

>> >> > >&= gt;>>>> be applied at a specific layer within the network

>> >> > >&= gt;>>>> protocol stack

>> >> > >&= gt;>> (network

>> >> > >&= gt;>>>> layer, application layer, etc.).

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> The Service Function Chaining (SFC) working group will

>> >> > >&= gt;>>>> develop new approaches to service delivery and deployme= nt.

>> >> > >&= gt;>>>> It will produce a framework for service function chaini= ng

>> >> > >&= gt;>>>> that includes the necessary protocols=

>> >> > >&= gt;>> or

>> >> > >&= gt;>>>> protocol extensions to convey the service path and

>> >> > >&= gt;>>>> service path information to nodes that implement servic= e

>> >> > >&= gt;>>>> functions, as well

>> >> > as

>> >> > >&= gt;>>>> mechanisms for steering traffic through service functio= ns.

>> >> > >&= gt;>>>> The

>> >> > >&= gt;>> working

>> >> > >&= gt;>>>> group will also examine what information needs to be

>> >> > >&= gt;>>>> gathered from

>> >> > >&= gt;>> the

>> >> > >&= gt;>>>> network and service functions in support of service

>> >> > >&= gt;>>>> function

>> >> > >&= gt; chaining

>> >> > >&= gt;>>>> and

>> >> > >&= gt;>>>> how that information may be made available to nodes tha= t

>> >> > >&= gt;>>>> implement

>> >> > >&= gt;>> the

>> >> > >&= gt;>>>> service functions.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Specifically, the SFC WG is chartered to deliver the

>> following:

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> 1) Problem Statement: This document will provide a

>> >> > >&= gt;>>>> summary of

>> >> > the

>> >> > >&= gt;>>>>    problem space to be addressed by the = WG including

>> >> > >&= gt;>>>> example

>> >> > high-=

>> >> > >&= gt;>>>>    level use cases. Additionally, the WG= will normalize

>> >> > >&= gt; nomenclature

>> >> > >&= gt;>>>>    and definitions for service function = chaining.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> 2) Architecture: This document will provide a descripti= on

>> >> > >&= gt;>>>> of

>> >>the

>> >> > >&= gt;>>>>    architectural building blocks and the= ir relationships

>> >> > inclu= ding

>> >> > >&= gt;>>>>    interconnection, placement of capabil= ities, management,

>> >> > >&= gt;>>>>    diagnostics, design analysis, and sec= urity models, as

>> >> > >&= gt;>>>> well

>> >>as

>> >> > >&= gt;>>>>    requirements on the protocol mechanis= ms.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> 3) Generic Service Function Chaining Encapsulation: A

>> >> > >&= gt;>>>> document

>> >> > will<= o:p>

>> >> > >&= gt;>>>>    describe the single service-level dat= a plane

>> >> > >&= gt;>>>> encapsulation

>> >> > >&= gt; format

>> >> > >&= gt;>>>> for

>> >> > >&= gt;>>>>    conveying the service function chain = and the service

>> >> > >&= gt;>>>> function

>> >> > >&= gt;>> path,

>> >> > >&= gt;>>>>    and for communicating context informa= tion between

>> >> > >&= gt;>>>> nodes

>> that

>> >> > >&= gt;>>>>    implement service functions. It is in= tended that the

>> >> > >&= gt;>> encapsulation

>> >> > >&= gt;>>>>    be agnostic to the layer at which it = is applied and

>> >> > >&= gt;>>>> the service

>> >> > >&= gt;>> that

>> >> > >&= gt;>>>> is

>> >> > >&= gt;>>>>    being constructed. That is, the same = encapsulation may

>> >> > >&= gt;>>>> be

>> >> > used<= o:p>

>> >> > >&= gt; on

>> >> > >&= gt;>>>>    a service function path realized at t= he network layer

>> >> > >&= gt;>>>> or at any other

>> >> > >&= gt;>>>>    layer, and the same encapsulation wil= l apply for the

>> >> > >&= gt; construction

>> >> > >&= gt;>> of

>> >> > >&= gt;>>>>    service function paths regardless of = the actual service.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> 4) Control Plane Mechanisms: A set of documents will be=

>> >> > devel= oped to

>> >> > >&= gt;>>>>    describe requirements and protocols n= ecessary to

>> >> > >&= gt;>>>> convey

>> >> > >&= gt;>> information

>> >> > >&= gt;>>>>    to service function implementation po= ints. Where

>> >> > >&= gt;>>>> possible,

>> >> > >&= gt;>> existing

>> >> > >&= gt;>>>>    IETF protocols will be used and exten= ded. All protocol

>> >> > >&= gt; extensions

>> >> > >&= gt;>>>>    work should be carried out in the wor= king groups

>> >> > >&= gt;>>>> responsible for

>> >> > >&= gt;>> the

>> >> > >&= gt;>>>>    protocols being modified in coordinat= ion with this

>> >> > >&= gt;>>>> working

>> >> > >&= gt; group,

>> >> > >&= gt;>>>> but

>> >> > >&= gt;>>>>    may be done in this working group aft= er agreement with

>> >> > >&= gt;>>>> all

>> >> > the

>> >> > >&= gt;>>>>    relevant WG chairs and responsible AD= s.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> 5) Manageability: Work on the management and

>> >> > >&= gt;>>>> configuration of

>> >> > >&= gt; service

>> >> > >&= gt;>>>>    functions in support of SFC component= s will certainly

>> >> > >&= gt;>>>> be

>> >> > neede= d,

>> >> > >&= gt;>>>>    but first needs to be better understo= od and scoped.

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Proposed Milestones

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Apr 2014 Submit to IESG Informational document(s)

>> >> > >&= gt;>>>> defining the

>> >> > >&= gt;>> problem

>> >> > >&= gt;>>>> statement and core use cases for Service Function

>> >> > >&= gt;>>>> Chaining

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> May 2014 Consult with OPS Area on possible charter

>> >> > >&= gt;>>>> modifications for management and configuration of SFC

>> >> > >&= gt;>>>> components

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Jan 2015 Submit to IESG Informational document defining

>> >> > >&= gt;>>>> the

>> >> > >&= gt;>> architecture

>> >> > >&= gt;>>>> for SFC

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Jan 2015 Submit to IESG requirements for a generic

>> >> > >&= gt;>>>> service function chaining encapsulation protocol

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Aug 2015 Submit to IESG Standards Track document

>> >> > >&= gt;>>>> specifying the

>> >> > >&= gt;>> generic

>> >> > >&= gt;>>>> service function chaining header encapsulation

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> Thomas

>> >> > >&= gt;>>>>

>> >> > >&= gt;>>>> _______________________________________________

>> >> > >&= gt;>>>> nsc mailing list

>> >> > >&= gt;>>>> nsc@ietf.org

>> >> > >&= gt;>>>> https://www.ietf.org/= mailman/listinfo/nsc

>> >> > >&= gt;>>>> _______________________________________________

>> >> > >&= gt;>>>> nsc mailing list

>> >> > >&= gt;>>>> nsc@ietf.org

>> >> > >&= gt;>>>> https://www.ietf.org/= mailman/listinfo/nsc

>> >> > >&= gt;>>>> _______________________________________________

>> >> > >&= gt;>>>> nsc mailing list

>> >> > >&= gt;>>>> nsc@ietf.org

>> >> > >&= gt;>>>> https://www.ietf.org/= mailman/listinfo/nsc

>> >> > >&= gt;>>> _______________________________________________<= /span>

>> >> > >&= gt;>>> nsc mailing list

>> >> > >&= gt;>>> nsc@ietf.org

>> >> > >&= gt;>>> https://www.ietf.org/= mailman/listinfo/nsc

>> >> > ><= o:p>

>> >> > _____= __________________________________________

>> >> > nsc m= ailing list

>> >> > nsc@ietf.org

>> >> > https://www.ietf.org/= mailman/listinfo/nsc

>> >> > _____= __________________________________________

>> >> > nsc m= ailing list

>> >> > nsc@ietf.org

>> >> > https://www.ietf.org/= mailman/listinfo/nsc

>> >> > _____= __________________________________________

>> >> > nsc m= ailing list

>> >> > nsc@ietf.org

>> >> > https://www.ietf.org/= mailman/listinfo/nsc

>> 

>> ___________________= ____________________________

>> nsc mailing list

>> nsc@ietf= .org

>> https://www.ietf.org/= mailman/listinfo/nsc

>________________________= _______________________

>nsc mailing list

>nsc@ietf.org<= /span>

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

 

____________________________= ___________________

nsc mailing list<= /span>

nsc@ietf.org

https://www.ietf.org/mailman/listinfo/nsc=

____________________________= ___________________

nsc mailing list<= /span>

nsc@ietf.org

https://www.ietf.org/mailman/listinfo/nsc=

____________________________= ___________________

nsc mailing list<= /span>

nsc@ietf.org

https://www.ietf.org/mailman/listinfo/nsc=

--_000_4040FE44D74FA042A7C2595F696FD1227FA10CA3SZXEMA502MBSchi_-- From hongyu.li@huawei.com Wed Nov 13 18:30:07 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B458D21E812D for ; Wed, 13 Nov 2013 18:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtm7PSRhz5AX for ; Wed, 13 Nov 2013 18:30:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 127A321E80CB for ; Wed, 13 Nov 2013 18:30:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAG36701; Thu, 14 Nov 2013 02:29:59 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 02:28:59 +0000 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 14 Nov 2013 02:29:57 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 10:29:50 +0800 From: "Hongyu Li (Julio)" To: David Allan I , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhNOKetVd+0mYdBTNJtPCzpoi7T2A///bpACAAToXAA== Date: Thu, 14 Nov 2013 02:29:49 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> References: <6EB34CB5D82C4645B826C56144826EA97E996662@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 02:30:08 -0000 SGkgRGF2ZSwNCg0KWW91ciBpbmZlcnJlZCByZXN0cmljdGlvbiBtYXkgYmUgbm90IGFsd2F5cyB0 cnVlLiBJbiBnZW5lcmFsLCBzZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgYmUgYWJsZSB0byBjb21w b3NlIGEgY2hhaW4gYXJiaXRyYXJpbHkuIFBhcnRpY3VsYXJseSBmb3IgYnJhbmNoaW5nLCBhcyBJ IHN1Z2dlc3RlZCBpbiBwcmV2aW91cyBlbWFpbCwgc2VydmljZSBmdW5jdGlvbiBzaGFsbCBub3Qg ZGlyZWN0bHkgaW1wYWN0IHBhY2tldCBmb3J3YXJkaW5nLiBUaGlzIHByZWNsdWRlcyB0aGUgcmVz dHJpY3Rpb24geW91IG1lbnRpb25lZC4gRm9yd2FyZGluZyBwbGFuZSBjYW4gZGVjaWRlIHdoZXRo ZXIgYSBicmFuY2hpbmcgYWN0aW9uIHNob3VsZCBiZSB0YWtlbiBieSByZWNsYXNzaWZpY2F0aW9u IG9yIG5vdCBwZXIgc2VydmljZSBjaGFpbi4NCg0KRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQoNCkhv bmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRGF2aWQgQWxsYW4gSSBb bWFpbHRvOmRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMTMsIDIwMTMgMTE6NDUgUE0NClRvOiBIb25neXUgTGkgKEp1bGlvKTsgbnNjQGlldGYu b3JnDQpTdWJqZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5n LCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KSEkgSG9uZ3l1Og0KDQpJIHRo aW5rIHdlIHdpbGwgaGF2ZSBzY2VuYXJpb3Mgd2hlcmUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVh cnMgaW4gbW9yZSB0aGFuIG9uZSBjaGFpbiwgYXMgd291bGQgYmUgdGhlIGNhc2UsIGZvciBleGFt cGxlLCBpZiBzb21lIGZsb3dzIGNvdWxkIGR5bmFtaWNhbGx5IGJ5cGFzcyBEUEkgYnV0IHN0aWxs IG5lZWRlZCB0byB0cmFuc2l0IGEgY29tbW9uIHNldCBvZiBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1bmN0 aW9ucy4uLg0KDQpPbmNlIHlvdSBwb3N0dWxhdGUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNl IGFwcGVhcmluZyBpbiBtb3JlIHRoYW4gb25lIGNoYWluLCBpdCBzZWVtcyBhcnRpZmljaWFsbHkg cmVzdHJpY3RpdmUgbm90IHRvIHBlcm1pdCBzdWNoIGEgZnVuY3Rpb24gdG8gYWxzbyBpbXBsZW1l bnQgYnJhbmNoaW5nLCBhbGwgdGhlIGNvbnRyb2wgc3RydWN0dXJlcyB3b3VsZCBhbHJlYWR5IGJl IHRoZXJlLg0KDQpSZ2RzDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBIb25neXUgTGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMyAyOjEyIEFNDQpUbzogRGF2aWQgQWxsYW4gSTsg bnNjQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYg YnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KTWF5IEkgc3Vn Z2VzdCBzdW1tYXJ5IG9mIG15IHZpZXdzIGhlcmU6DQoNCjEuIEJyYW5jaCBpcyBhIHNvcnQgb2Yg dXNlIGNhc2Ugb3Igc2NlbmFyaW8sIHdoaWxlIHJlY2xhc3NpZmljYXRpb24gaXMgYSB3YXkgdG8g c29sdmUgdGhlIHByb2JsZW0uDQoyLiBTZXJ2aWNlIEZ1bmN0aW9ucyBzaG91bGQgYmUgZGVjb3Vw bGVkIHdpdGggdGhlIGNoYWluIGl0c2VsZi4NCglNZWFuaW5nLCBhIFNGIHNoYWxsIG5vdCAqZGly ZWN0bHkqIGltcGFjdCB0aGUgZm9yd2FyZGluZyBvZiBwYWNrZXRzIGluIGEgY2hhaW4uIEJyYW5j aGluZyBzaG91bGQgYmUgcGVyZm9ybWVkIGJ5IGNoYWluIGZvcndhcmRpbmcgbm9kZXMsIHBvc3Np Ymx5IHVuZGVyIGNvbnRyb2wgb2YgYSBjb250cm9sIG5vZGUuIFRoZSByZWFzb24gZm9yIHRoaXMg aXMgaW4gTkZWIHdvcmxkLCBzZXJ2aWNlIGZ1bmN0aW9ucyBtYXkgY29tZSBmcm9tIGEgdGhpcmQg cGFydHksIHdoaWxlIGNoYWluIGlzIHByb3ZpZGVkIGJ5IHRoZSBpbmZyYXN0cnVjdHVyZSBvZiB0 aGUgbmV0d29yay4gVGhlcmUgbXVzdCBiZSBhIGN1c2hpb24gYXZvaWRpbmcgYSBzZXJ2aWNlIGZ1 bmN0aW9uIG9wZXJhdGluZyBpbmZyYXN0cnVjdHVyZSBkaXJlY3RseS4NCjMuIChSZSljbGFzc2lm aWNhdGlvbiBpcyBiYXNlZCBvbiBpbmZvIGluIGEgcGFja2V0Lg0KCVRoaXMgaXMgdmVyeSBnZW5l cmFsLiBTdWNoIGluZm8gY291bGQgYmUgTDJ+TDcgZGVyaXZlZCBmcm9tIGEgdXNlcidzIHBhY2tl dCwgYXMgd2VsbCBhcyBzb21lIGluZm8gbGlrZSBtZXRhZGF0YSBpbiBhIFNGQyBoZWFkZXIuIEFz IGNsYXNzaWZpY2F0aW9uIGlzIG91dCBvZiBzY29wZSBvZiBTRkMsIHdlIGRvbid0IGhhdmUgdG8g cHJvdmlkZSB0b28gbXVjaCBkZXRhaWxzIG9mIGhvdyB0byBkbyBjbGFzc2lmaWNhdGlvbi4NCjQu IENoYWluIHNlZ21lbnRzIHN0aXRjaGluZyBpcyByZWxhdGl2ZWx5IGEgZWFzeSB3YXkgZm9yIGJy YW5jaGluZy4gQ29tcGFyZWQgd2l0aCBjaGFpbnMgYW5kIHN1YmNoYWlucywgd2hpY2ggbWF5IHJl cXVpcmUgYSBtb3JlIGNvbXBsZXggaGVhZGVyIGFuZCBmb3J3YXJkaW5nIGNhcGFiaWxpdGllcy4N Ck15IHR3byBjZW50cy4NCkhvbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIERhdmlkIEFsbGFuIEkNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIw MTMgMzowNCBBTQ0KVG86IG5zY0BpZXRmLm9yZw0KU3ViamVjdDogW25zY10gRlc6IHJlIGNsYXNz aWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXIN Cg0KSGk6DQoocmVzZW5kIHdpdGggcmVjaXBpZW50IGxpc3QgY2xlYW5lZCB1cCkNCg0KSSBhZ3Jl ZSB3ZSBhcmUgZGlzY3Vzc2luZyBtdWx0aXBsZSBjb25jZXB0cywgY2xhc3NpZmljYXRpb24gYW5k IGZsb3ctc3Vic2V0dGluZy4gUGVyaGFwcyBtb3JlIDstKQ0KDQpEZWZpbmluZyBhIGZsb3cgc3Vi c2V0IGNhbiBiZSBhIHJlc3VsdCBvZiBjbGFzc2lmaWNhdGlvbiwgYnV0IGl0IGlzIG5vdCB0aGUg ZXhjbHVzaXZlIG1lY2hhbmlzbS4gQnJhbmNoaW5nIGlzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGZs b3cgc3Vic2V0cyBhcmUgZXhwb3NlZCBhbmQgbWFwcGVkIHRvIGEgc2V0IG9mIHN1YmNoYWlucyBz dWNoIHRoYXQgaXQgY2FuIGJlIGlkZW50aWZpZWQgaW4gdGhlIGRhdGFwbGFuZS4uLg0KDQpUaGF0 J3MgdGhlIHZpZXcgZnJvbSBoZXJlDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgRGF2aWQgTGFrZSAoZGxha2UpDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJl ciAxMiwgMjAxMyAxMDo1MSBBTQ0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBLZXZpbiBK IE1hOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IExpbmRhIER1bmJhcjsg SG9uZ3l1IExpIChKdWxpbykNCkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFu ZHJhIE1hamVlDQpTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KDQpVbmRlcnN0b29kIC0gbWF5YmUganVzdCBhIGxpdHRsZSBsb2NhbGlzZWQgd2FybWluZyBv ZiB0aGUgc2VhIHRoZW4gPyAgIEJ1dCBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gY29uc2lkZXIg d2hlcmUgYW5kIGhvdyBwb2xpY3kgaXMgZGVmaW5lZC9zZXQgZXZlbiBmb3IgdGhlIHNpbmdsZS1k b21haW4gaW5zdGFuY2UuDQoNCkkgZG9uJ3QgdGhpbmsgd2UgY2FuIGFzc3VtZSB0aGF0IGFueSBM MS0zIGRldmljZSB3aWxsIGJlIGFibGUgdG8gZGV0ZXJtaW5lIG11Y2ggdXNlZnVsIGluZm9ybWF0 aW9uIGZyb20gdGhlIGRhdGEtcGxhbmUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KU2VudDogMTIgTm92ZW1iZXIgMjAxMyAxMDo0 NA0KVG86IERhdmlkIExha2UgKGRsYWtlKTsgS2V2aW4gSiBNYTsgU3VyZW5kcmEgS3VtYXIgKHNt a3VtYXIpOyBSb24gUGFya2VyOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQpDYzog VGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KU3ViamVjdDogUmU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KQXMgZGlzY3Vzc2VkIGR1cmlu ZyB0aGUgQk9GIG91ciBpbml0aWFsIHdvcmsgaXMgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGRvbWFp biBmb3Igc29tZSBvZiB0aGUgdmVyeSByZWFzb25zIHlvdSBwb2ludCBvdXQuIFdlIG5lZWQgdG8g a2VlcCBmb2N1c2VkIHdpdGhvdXQgdHJ5aW5nIHRvIGJvaWwgdGhlIG9jZWFuIHJpZ2h0IG9mZiB0 aGUgYmF0Lg0KDQpPbiAxMS8xMi8xMyAxOjM2IFBNLCAiRGF2aWQgTGFrZSAoZGxha2UpIiA8ZGxh a2VAY2lzY28uY29tPiB3cm90ZToNCg0KPkV4YWN0bHkuICBCdXQgaG93IGNhbiBuZXR3b3JrLWNv bXBvbmVudHMgInRlcm1pbmF0ZSIgYW4gYXBwbGljYXRpb24gPz8/Pw0KPg0KPkkgdGhpbmsgd2Ug bmVlZCBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiBhIHJlY3Vyc2l2ZSBwb2xpY3kgbWVjaGFuaXNt IA0KPihyZWN1cnNpdmUgYmVjYXVzZSBhIHVzZXItbGFuZCBhcHBsaWNhdGlvbiB3aWxsIHJpZGUg d2l0aCBhIHNwZWNpZmljIA0KPnBvbGljeSBhY3Jvc3MgcG90ZW50aWFsbHkgZGlmZmVyZW50IHNl dHMgb2YgY2FycmllciBwb2xpY2llcykuDQo+DQo+SSBoYXRlIHRvIGJyaW5nIHRoaXMgdXAgbm93 LCBidXQgd2UgYWxzbyBuZWVkIHRvIHRoaW5rIGFib3V0IHRoaXMgDQo+bXVsdGktZG9tYWluIGlz c3VlIC0gaWYgSSBzZXQgYSBwb2xpY3kgYXMgYSB1c2VyLCBjaGFuY2VzIGFyZSBJIHdpbGwgYmUg DQo+Y3Jvc3Npbmcgc2V2ZXJhbCBkb21haW4gYm91bmRhcmllcy4gIEFyZSB3ZSBleHBlY3Rpbmcg dGhlIHNlcnZpY2UgDQo+aGVhZGVycyB0byBkZWZpbmUgdGhlIHNlcnZpY2UgY2hhaW5pbmcgZm9y IHRoZSBkdXJhdGlvbiBvZiB0aGUgZW50aXJlIA0KPmZsb3cgYWNyb3NzIGFsbCBkb21haW5zLCBv ciBqdXN0IGFjcm9zcyBhIHNpbmdsZSBvbmUgPw0KPg0KPkluIHdoaWNoIGNhc2UsIGRvIEkgaGF2 ZSB0byByZS1zZXQgcG9saWN5IGFzIEkgdHJhdmVyc2UgZG9tYWlucyAgYW5kDQo+d2hlcmUgZG9l cyB0aGF0IHBvbGljeSBnZXQgc2V0ID8gICBJdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBzZXQg cG9saWN5DQo+b25jZSBiYXNlZCBvbiBMNS03IG5lZWRzLCBhbmQgaGF2ZSB0aGF0IGluc3RhbnRp YXRlZCBhY3Jvc3MgdGhlIA0KPm11bHRpcGxlIGRvbWFpbnMuDQo+DQo+QWdhaW4sIHRoaXMgYXBw ZWFycyB0byBiZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBTRkMsIGJ1dCBwcmV0dHkgcmVsZXZhbnQg DQo+dG8gaG93IGl0IHdvdWxkIG9wZXJhdGUgaW4gdGhlIHJlYWwgd29ybGQuDQo+DQo+RGF2aWQN Cj4NCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IEtldmluIEogTWEgW21haWx0 bzprZXZpbi5tYUBhenVraXN5c3RlbXMuY29tXQ0KPlNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMTA6 MjcNCj5UbzogRGF2aWQgTGFrZSAoZGxha2UpOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJv biBQYXJrZXI7IExpbmRhIA0KPkR1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCj5DYzogVGhvbWFz IE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPlN1YmplY3Q6IFJFOiBbbnNj XSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+DQo+PiBJbiB0aG9zZSBjaXJjdW1zdGFu Y2VzLCBvbmx5IHRoZSBlbmQgYXBwbGljYXRpb25zIHRoZW1zZWx2ZXMgb3IgYSANCj4+IHJlYXNv bmFibHkgYnJvYWQtYnJ1c2hlZCBjbGFzc2lmaWNhdGlvbiAocmVhbGx5IHRyYWZmaWMgc3RlZXJp bmcgDQo+PiBiYXNlZCBvbiB3aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcgdG8g YmUgdXNlZnVsIC0gaXMgVEhBVCANCj4+IHdoYXQgd2UncmUgYWltaW5nIGZvciBoZXJlID8NCj4N Cj5JIHdvdWxkIGNlcnRhaW5seSBob3BlIG5vdCwgYnV0IHRoYXQgaGFzIGJlZW4gbXkgY29uY2Vy biBhcyB3ZWxsLg0KPkFwcGxpY2F0aW9uIGxheWVyIHRlcm1pbmF0aW9uIGFuZCByZS1jbGFzc2lm aWNhdGlvbiBzZWVtcyBhIG11c3Q/DQo+DQo+LS0gIEtldmluIEouIE1hDQo+DQo+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogRGF2aWQgTGFrZSAoZGxha2UpIFttYWlsdG86 ZGxha2VAY2lzY28uY29tXQ0KPj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTow MCBQTQ0KPj4gVG86IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsgS2V2aW4g SiBNYTsgTGluZGEgRHVuYmFyOyANCj4+IEhvbmd5dSBMaSAoSnVsaW8pDQo+PiBDYzogVGhvbWFz IE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4gU3ViamVjdDogUkU6IFtu c2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+DQo+PiBQb2xpY3kgbWF5IGJlIG91 dHNpZGUgb2YgdGhlIHNjb3BlIG9mIFNGQywgYnV0IHdpdGhvdXQgc3Ryb25nIG1hcHBpbmcgDQo+ PiBiZXR3ZWVuIFBvbGljeSBhbmQgdGhlIGluc2VydGVkIFNlcnZpY2UgSGVhZGVyKHMpLCB3ZSBy dW4tdGhlLXJpc2sgb2YgDQo+PiBsaW1pdGluZyB0aGUgZWZmaWNhY3kgb2YgdGhlIHByb3RvY29s IElNTy4NCj4+DQo+PiBGb3IgZXhhbXBsZSwgaW4gYSB3b3JsZCB3aGVyZSB0aGUgbmV0d29yayBo YXMgImdvbmUgZGFyaywiIChhcyBwZXIgDQo+PiB0aGUgSUVURiBUZWNobmljYWwgUGxlbmFyeSA/ Oi0pICkgd2hhdCBpcyBvdXIgYWJpbGl0eSB0byBkZXRlcm1pbmUgDQo+PiBwb2xpY3kgYmFzZWQg b24gRFBJIG9mIHBhY2tldHMtaW4tZmxpZ2h0ID8NCj4+DQo+PiBJbiB0aG9zZSBjaXJjdW1zdGFu Y2VzLCBvbmx5IHRoZSBlbmQgYXBwbGljYXRpb25zIHRoZW1zZWx2ZXMgb3IgYSANCj4+IHJlYXNv bmFibHkgYnJvYWQtYnJ1c2hlZCBjbGFzc2lmaWNhdGlvbiAocmVhbGx5IHRyYWZmaWMgc3RlZXJp bmcgDQo+PiBiYXNlZCBvbiB3aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcgdG8g YmUgdXNlZnVsIC0gaXMgVEhBVCANCj4+IHdoYXQgd2UncmUgYWltaW5nIGZvciBoZXJlID8NCj4+ DQo+PiBEYXZpZA0KPj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgDQo+PiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikNCj4+IFNlbnQ6IDEyIE5vdmVtYmVy IDIwMTMgMDk6MjYNCj4+IFRvOiBSb24gUGFya2VyOyBLZXZpbiBKIE1hOyBMaW5kYSBEdW5iYXI7 IEhvbmd5dSBMaSAoSnVsaW8pDQo+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBT dW1hbmRyYSBNYWplZQ0KPj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZD IGNoYXJ0ZXINCj4+DQo+PiBSb24sDQo+Pg0KPj4gQ2xhc3NpZmljYXRpb24gb2YgdHJhZmZpYyBp cyB3ZWxsIHVuZGVyc3Rvb2QgYW5kIHdlIGRvIG5vdCBoYXZlIHRvIA0KPj4gcmVkZWZpbmUgaXQg LSBpdCdzIGJlZW4gYXJvdW5kIGZvciBhbGwgdGhlIHRpbWUgbWlkZGxlIGJveGVzIGhhdmUgDQo+ PiBiZWVuIG9yIGZvciB0aGF0IG1hdHRlciB0aGUgTDIvTDMgZGV2aWNlcy4gQWxsIHdlIGFyZSB0 YWxraW5nIGFib3V0IA0KPj4gaXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGNsYXNzaWZpY2F0 aW9uIHRvIGJyYW5jaGluZyBpbiBTRkMuDQo+Pg0KPj4gWW91IGFyZSByaWdodCwgaXQgaXMgYWxs IGFib3V0IHBvbGljeSB3aGljaCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBTRkMuDQo+Pg0KPj4g U3VyZW5kcmEuDQo+Pg0KPj4gT24gMTEvMTIvMTMgNzo1MyBBTSwgIlJvbiBQYXJrZXIiIDxSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tPg0KPj53cm90ZToNCj4+DQo+PiA+SSB0aGluayB0 aGUgbGFjayBvZiBkZWZpbml0aW9uIG9mICJyZWNsYXNzaWZpY2F0aW9uIiBtYXkgYmUgY2F1c2lu Zw0KPj5zb21lDQo+PiA+bWlzdW5kZXJzdGFuZGluZ3MgaGVyZS4gICAgQSBicmFuY2ggd291bGQg b2NjdXIgZm9yIHNvbWUgcG9saWN5LWRyaXZlbg0KPj4gPnJlYXNvbiBiYXNlZCBvbiB0aGUgYmVo YXZpb3IgYW5kIGNvbmNsdXNpb25zIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLA0KPj4gPml0c2Vs Zi4gICBUaGUgZ3JhcGggd291bGQgcmVwcmVzZW50IHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBi cmFuY2gNCj4+ID5wb2ludCwgYnV0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLCBpdHNlbGYsIGJlaW5n IGF3YXJlIHRoYXQgaXQgaXMgYSANCj4+ID5icmFuY2hpbmcgcG9pbnQgd291bGQgY29udGFpbiB0 aGUgcG9saWN5IGFuZCBsb2dpYyB0byBkZWNpZGUgb24gd2hpY2gNCj4+ID5icmFuY2ggdG8gdGFr ZS4gICBTcGVjaWZ5aW5nIHRoYXQgcG9saWN5IGFuZCBsb2dpYyBpcyBvdXQgb2Ygc2NvcGUsDQo+ PklNTy4NCj4+ID4NCj4+ID4gICBSb24NCj4+ID4NCj4+ID4NCj4+ID4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4gPkZyb206IEtldmluIEogTWEgW21haWx0bzprZXZpbi5tYUBhenVraXN5 c3RlbXMuY29tXQ0KPj4gPlNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEwOjQ5IEFN DQo+PiA+VG86IExpbmRhIER1bmJhcjsgUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbykNCj4+ ID5DYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1h cik7IFN1bWFuZHJhIA0KPj4gPk1hamVlDQo+PiA+U3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQg UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4NCj4+ID5IaSBMaW5kYSwNCj4+ID4NCj4+ID4gIEFy ZSB5b3Ugc2F5aW5nIHRoYXQgYSBicmFuY2hpbmcgcG9pbnQgaXMgIm5ldmVyIiBhIA0KPj4gPiBy ZWNsYXNzaWZpY2F0aW9uIHBvaW50LCBvciBhcmUgeW91IHNheWluZyB0aGF0IGEgYnJhbmNoaW5n IHBvaW50ICJkb2VzIG5vdCBoYXZlIHRvIGJlIg0KPj4gPiAgYSByZWNsYXNzaWZpY2F0aW9uIHBv aW50Pw0KPj4gPg0KPj4gPiAgSSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBkaXN0aW5jdGlv biB0aGF0IG5lZWRzIHRvIGJlIGNsYXJpZmllZC4NCj4+ID4gIElmIGJyYW5jaGluZyBpcyBuZXZl ciByZWNsYXNzaWZpY2F0aW9uLCB0aGVuIHRoZSBtZWFuaW5nIG9mIGEgDQo+PiA+IGNoYWluIGlz IGRpZmZlcmVudCB0aGFuIEkgb3JpZ2luYWxseSBpbmZlcnJlZC4gIElmIHRoZSBjaGFpbiBpcyBh IA0KPj4gPiB0cmVlIHdpdGggb3RoZXIgImJyYW5jaGluZyIgcG9pbnRzIGluIGl0LCB0aGVuIHRo YXQgbGltaXRzIHRoZSANCj4+ID4gc2NvcGUgb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50IGdvYWxz Lg0KPj4gPg0KPj4gPiAgV2hpbGUgdGhpcyBjb3VsZCBiZSBhIGRlZ2VuZXJhdGUgY2FzZSwgYW5k IGFueSBpbXBsZW1lbnRhdGlvbiANCj4+ID4gY291bGQgZGVmaW5lIGJhZCBzZXJ2aWNlIGNoYWlu cywgaXMgaXQgdGhlIGludGVudCBvZiBTRkMgdG8gb25seSANCj4+ID4gbG9vayBhdCB0aGUgc2lt cGxlciBwYWNrZXQtbGV2ZWwgY2xhc3NpZmljYXRpb24gY2FzZXMsIG9yIGlzIGl0IHRoZSANCj4+ ID4gaW50ZW50IHRvIGNvbnNpZGVyIHRoZSBjYXNlIHdoZXJlIGEgYnJhbmNoaW5nIHBvaW50IGlz IHZpZXdlZCBhcyBhIA0KPj4gPiByZS1jbGFzc2lmaWNhdGlvbiBwb2ludD8NCj4+ID4NCj4+ID50 aGFueC4NCj4+ID4NCj4+ID4tLSAgS2V2aW4gSi4gTWENCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+PiA+PiBGcm9tOiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbV0NCj4+ID4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEz IDEwOjM0IEFNDQo+PiA+PiBUbzogUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbyk7IEtldmlu IEogTWENCj4+ID4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1 bWFyIChzbWt1bWFyKTsgDQo+PiA+PiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gU3ViamVjdDogUkU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+DQo+PiA+PiBSb24sDQo+ PiA+Pg0KPj4gPj4gRmlyc3QsIHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0ICJicmFuY2hpbmci ICE9IHJlY2xhc3NpZmljYXRpb24sIA0KPj4gPj5hZ3JlZT8NCj4+ID4+DQo+PiA+PiBTZWNvbmQs IHRoZSByZXByZXNlbnRhdGlvbiBvZiBicmFuY2hpbmcgKG9yIHNlcnZpY2UgZ3JhcGgpIGNhbiBi ZSANCj4+ID4+IGluIGEgZm9ybSBvZiBsb2dpYyBvbiBhIHNlcnZpY2UgZnVuY3Rpb24uIFNvbWUg c2VydmljZSBmdW5jdGlvbnMsIA0KPj4gPj4gZXNwZWNpYWxseSBMNyBiYXNlZCwgY2FuIHVzZSB2 YWx1ZSBpbiBhIERhdGFiYXNlIHRvIGRldGVybWluZSB3aGF0IA0KPj4gPj4gaXMgdGhlIG5leHQg c2VydmljZSBmdW5jdGlvbi4NCj4+ID4+DQo+PiA+PiBMaW5kYQ0KPj4gPj4NCj4+ID4+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+PiA+PiA+IEJlaGFsZiBPZiBS b24gUGFya2VyDQo+PiA+PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDg6MTYg QU0NCj4+ID4+ID4gVG86IEhvbmd5dSBMaSAoSnVsaW8pOyBLZXZpbiBKIE1hDQo+PiA+PiA+IENj OiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsg DQo+PiA+PiA+IFN1bWFuZHJhIE1hamVlDQo+PiA+PiA+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJy ZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+DQo+PiA+PiA+IEhvbmd5dSwNCj4+ID4+ ID4NCj4+ID4+ID4gSSBhZ3JlZSBjb21wbGV0ZWx5IHRoYXQgcmUtY2xhc3NpZmljYXRpb24gaXMg bm90IGxpbWl0ZWQgdG8gRFBJLg0KPj4gPj4gPg0KPj4gPj4gPiBBbmQgYWxzbywgdGhhdCBhbiBh cmVhIGZvciB1cyB0byBleHBsb3JlIGFzIGEgZ3JvdXAgaXMgaG93IHRvDQo+PiA+PnJlcHJlc2Vu dA0KPj4gPj4gPiB0aGUgc2VydmljZSBncmFwaC4gICBEbyB3ZSB3YW50IHRvIHJlcHJlc2VudCBp dCBhcyBhIHByb3BlciBncmFwaA0KPj4gd2l0aA0KPj4gPj4gPiBhbiBhZGphY2VuY3kgbGlzdCBv ciBvdGhlciByZXByZXNlbnRhdGlvbmFsIG1vZGVsPyAgIE9yLCBkbyB3ZSB3YW50DQo+PiB0bw0K Pj4gPj4gPiByZXByZXNlbnQgaXQgYXMgYSBzZXQgb2YgbGluZWFyIHNlZ21lbnRzIGFuZCBpZiBz bywgaG93IGFyZSB0aGUNCj4+ID4+ID4gc2VnbWVudHMgY29ubmVjdGVkIGludG8gYSBncmFwaD8g ICBPdGhlciBpZGVhcz8NCj4+ID4+ID4NCj4+ID4+ID4gICAgUm9uDQo+PiA+PiA+DQo+PiA+PiA+ DQo+PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+IEZyb206IG5zYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4gPj4g PiBCZWhhbGYgT2YgSG9uZ3l1IExpIChKdWxpbykNCj4+ID4+ID4gU2VudDogVHVlc2RheSwgTm92 ZW1iZXIgMTIsIDIwMTMgNjo1NyBBTQ0KPj4gPj4gPiBUbzogUm9uIFBhcmtlcjsgS2V2aW4gSiBN YQ0KPj4gPj4gPiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1h ciAoc21rdW1hcik7IA0KPj4gPj4gPiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiBTdWJqZWN0OiBS ZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPg0KPj4gPj4gPiBC cmFuY2hpbmcvZm9ya2luZyBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgdG9waWMgb2YgU0ZDLiBBYm91 dCB0aGUNCj4+ID4+ID4gcmUtIGNsYXNzaWZpY2F0aW9uIHBvaW50LCBwcm9iYWJseSB3ZSBzaGFs bCBub3QgbGltaXQgaXQgdG8gRFBJLg0KPj4gPj4gPiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQg cGFja2V0cyBnbyB0byBkaWZmZXJlbnQgYnJhbmNoZXMgYWZ0ZXIgDQo+PiA+PiA+IGJlZW4gcHJv Y2Vzc2VkIGJ5IGEgY2VydGFpbiBzZXJ2aWNlIGZ1bmN0aW9uLCBkZWNpc2lvbiBvZiB3aGljaCAN Cj4+ID4+ID4gYnJhbmNoZXMgdG8gZ28gaXMgbWFkZSBiYXNlZCBvbiB0aGUgcmVzdWx0IG9mIHNl cnZpY2UgZnVuY3Rpb24ncyANCj4+ID4+ID4gcHJvY2VzcywgaS5lLiBub3QganVzdCByZS0gY2xh c3NpZmljYXRpb24gYnkgRFBJLg0KPj4gPj4gPg0KPj4gPj4gPiBIb25neXUNCj4+ID4+ID4NCj4+ ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gRnJvbTogbnNjLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+PiA+PiA+IEJl aGFsZiBPZiBSb24gUGFya2VyDQo+PiA+PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAy MDEzIDc6NDUgUE0NCj4+ID4+ID4gVG86IEtldmluIEogTWENCj4+ID4+ID4gQ2M6IFRob21hcyBO YXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyANCj4+ID4+ID4g U3VtYW5kcmEgTWFqZWUNCj4+ID4+ID4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4NCj4+ID4+ID4gSGksIEtldmluDQo+PiA+PiA+DQo+PiA+ PiA+IFlvdSBhc2sgYSBncmVhdCBxdWVzdGlvbiBhYm91dCBicmFuY2hpbmcgdGhlIGdyYXBoLiAg VGhlIGRldGFpbHMgDQo+PiA+PiA+IGFyb3VuZCBob3cgdG8gY29udmV5IHRoZSBzZWxlY3Rpb24g b2YgdGhlIHN1YnRyZWUvc3ViZ3JhcGggYXJlIA0KPj4gPj4gPiBzdGlsbA0KPj4gPj50byBiZQ0K Pj4gPj4gPiBkZWZpbmVkLiAgIElzIGl0IG9uZSBjaGFpbiBpZCBmb3IgdGhlIHdob2xlIGdyYXBo PyAgIERvZXMgZWFjaA0KPj5icmFuY2gNCj4+ID4+ID4gaGF2ZSBpdHMgb3duIGNoYWluIGlkPyAg IFNvbWUgY29tYmluYXRpb24/DQo+PiA+PiA+DQo+PiA+PiA+ICAgIFJvbg0KPj4gPj4gPg0KPj4g Pj4gPiBPbiBOb3YgMTIsIDIwMTMsIGF0IDE6NTIgQU0sICJLZXZpbiBKIE1hIg0KPj4gPj4gPiA8 a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+ID4+ID4gd3JvdGU6DQo+PiA+PiA+DQo+PiA+ PiA+ID4+IFllcywgcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRoZSBzZXJ2aWNlIHBhdGgg YW5kIA0KPj4gPj4gPiA+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2Rl IGFsb25nIGEgc2VydmljZSBwYXRoLg0KPj4gPj4gPiA+DQo+PiA+PiA+ID4gSnVzdCB0byBleHBh bmQgb24gdGhhdCwgZ29pbmcgYmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gDQo+PiA+PiA+ ID4gYWJvdXQgc2VydmljZSBoZWFkZXIgZW5jYXBzdWxhdGlvbiwgaXMgaXQgaW50ZW5kZWQgdGhh dCBhIA0KPj4gPj4gPiA+IGNoYWluIHRoYXQgaXMgcmUtY2xhc3NpZmllZCB3aWxsIGdldCBhIG5l dyBjaGFpbiBJRCB3aGljaCANCj4+ID4+ID4gPiBmdWxseSBkZXNjcmliZXMgYSBjaGFpbiB0aGF0 IGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFsIA0KPj4gPj4gPiA+IGNoYWluIElELCBwcmlv ciB0byBEUEktYmFzZWQgcmUtY2xhc3NpZmljYXRpb24/ICAoYXNzdW1pbmcgdGhlIA0KPj4gPj4g PiA+IGdvYWwgaXMgImEgc2luZ2xlIGNoYWluIElEIHRoYXQgaXMgY29tbW9ubHkgdW5kZXJzdG9v ZCBhbG9uZyANCj4+ID4+ID4gPiB0aGUgZW50aXJlIHNlcnZpY2UNCj4+IGNoYWluIg0KPj4gPj4g PiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cw MDYzOC5odG1sDQo+PiA+PiA+ID4gKQ0KPj4gPj4gPiA+DQo+PiA+PiA+ID4gQW5kIHRoZSBhcHBs aWNhYmxlIHN1YnNldCBvZiB0aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlIA0KPj4gPj4g PiA+IHBhdGhzIHdvdWxkIGJlIGNvbmZpZ3VyZWQgYXQgZWFjaCBhcHByb3ByaWF0ZSBzZXJ2aWNl IG5vZGU/DQo+PiA+PiA+ID4gZS5nLiwgSUQgMTogTkFUICsgZmlyZXdhbGwgKyBEUEkNCj4+ID4+ ID4gPiAgICAgIElEIDI6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYNCj4+ID4+ID4gPiAgICAg IElEIDM6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBOQVQNCj4+ID4+ID4gPiAgICAgIElE IDQ6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTkFUDQo+PiA+PiA+ID4gICAgICBJRCA1OiBOQVQg KyBmaXJld2FsbCArIERQSSArIEFWICsgTEINCj4+ID4+ID4gPiAgICAgIElEIDY6IE5BVCArIGZp cmV3YWxsICsgRFBJICsgTEINCj4+ID4+ID4gPiAgICAgIElEIDc6IE5BVCArIGZpcmV3YWxsICsg RFBJICsgTEIgKyBDQUNIRQ0KPj4gPj4gPiA+ICAgICAgSUQgODogTkFUICsgZmlyZXdhbGwgKyBE UEkgKyBDQUNIRQ0KPj4gPj4gPiA+ICAgICAgSUQgOTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBv cHRpbWl6ZXIgKyBMQg0KPj4gPj4gPiA+ICAgICAgSUQgMTA6IE5BVCArIGZpcmV3YWxsICsgRFBJ ICsgb3B0aW1pemVyICsgTEIgKyBDQUNIRQ0KPj4gPj4gPiA+ICAgICAgSUQgMTE6IE5BVCArIGZp cmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgQ0FDSEUgV291bGQgDQo+PiA+PiA+ID4gZXZlcnkg ZmxvdyB0aGVuIGJlIGluaXRpYWxseSBjbGFzc2lmaWVkIGFzIElEIDEsIGJ1dCANCj4+ID4+ID4g PiBldmVudHVhbGx5IGdldCByZS0NCj4+ID4+ID4gY2xhc3NpZmllZA0KPj4gPj4gPiA+IHRvIElE IDItMTEsIGFmdGVyIHRoZSBEUEkgcGhhc2U/DQo+PiA+PiA+ID4NCj4+ID4+ID4gPiB0aGFueC4N Cj4+ID4+ID4gPg0KPj4gPj4gPiA+IC0tICBLZXZpbiBKLiBNYQ0KPj4gPj4gPiA+DQo+PiA+PiA+ ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+IEZyb206IFN1cmVuZHJh IEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPj4gPj4gPiA+PiBT ZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+PiA+PiA+ID4+IFRvOiBL ZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgDQo+ PiA+PiA+ID4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+PiBTdWJqZWN0OiBSZTogW25zY10gQ3Vy cmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pg0KPj4gPj4gPiA+Pg0KPj4gPj4g PiA+Pg0KPj4gPj4gPiA+Pj4gT24gMTEvMTEvMTMgOTo0NiBQTSwgIktldmluIEogTWEiIA0KPj4g Pj4gPiA+Pj4gPGtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+DQo+PiA+Pndyb3RlOg0KPj4gPj4g PiA+Pj4NCj4+ID4+ID4gPj4+IEhpIFN1cmVuZHJhLA0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+ IENsYXNzaWZpY2F0aW9uIG1heSBiZSBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGUgbGV2ZWwgb2Ygc2Vy dmljZSANCj4+ID4+ID4gPj4+IHRoYXQNCj4+ID4+ID4gaXMNCj4+ID4+ID4gPj4+IGFwcGxpY2Fi bGUgaXMgZGVwZW5kZW50IHVwb24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIA0KPj4gPj4g PiA+Pj4gdGhhdCBjYW4NCj4+ID4+ID4gYmUNCj4+ID4+ID4gPj4+IHBlcmZvcm1lZC4gIEFuIGFz c3VtcHRpb24gb2YgcGFja2V0IGxldmVsIGVuY2Fwc3VsYXRpb24gaGFzDQo+PiA+PiA+ID4+IGlt cGxpY2F0aW9ucw0KPj4gPj4gPiA+Pj4gb24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIGJl aW5nIHBlcmZvcm1lZD8gIElmIHRoZSANCj4+ID4+ID4gPj4+IHN0YXRlZA0KPj4gPj4gPiBnb2Fs cw0KPj4gPj4gPiA+PiBhcmUNCj4+ID4+ID4gPj4+IGZvciBmaXJld2FsbCBhbmQgbG9hZCBiYWxh bmNlciBmdW5jdGlvbmFsaXR5LCB0aGVuIHRoZSANCj4+ID4+ID4gPj4+IGFwcGxpY2F0aW9uDQo+ PiA+PiA+ID4+IGxldmVsDQo+PiA+PiA+ID4+PiBuYXR1cmUgb2YgdGhvc2UgZnVuY3Rpb25zIG5l ZWRzIHRvIGJlIHRha2VuIGludG8gYWNjb3VudD8NCj4+ID4+ID4gPj4+IElmLCBvbiB0aGUgb3Ro ZXIgaGFuZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gc2NvcGUgaXMgbGltaXRlZCANCj4+ID4+ID4g Pj4+IGR1ZSB0byBsaW1pdGF0aW9ucyBpbiBjbGFzc2lmaWNhdGlvbiwgdGhhdCB3b3VsZCBiZSBh bmQgDQo+PiA+PiA+ID4+PiBpbXBvcnRhbnQgcGllY2Ugb2YNCj4+ID4+ID4gaW5mb3JtYXRpb24/ DQo+PiA+PiA+ID4+Pg0KPj4gPj4gPiA+Pj4gV3J0IHNlY3Rpb24gNC40IG9mIGRyYWZ0LWxpdS1z ZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcyB0aGUgDQo+PiA+PiA+ID4+PiBmb3JrIHBvaW50cyBv ZiB0aGUgc2VydmljZSBwYXRocyBzZWVtIGxpa2UgcmUtY2xhc3NpZmljYXRpb24NCj4+IHBvaW50 cz8NCj4+ID4+ID4gPj4+IElzIHRoYXQgdGhlIGludGVycHJldGF0aW9uIGZyb20gdGhlIGFyY2hp dGVjdHVyZSBwZXJzcGVjdGl2ZT8NCj4+ID4+ID4gPj4+IE9yIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWluIGNsYXNzaWZpY2F0aW9uIGV4Y2x1c2l2ZSBvZiANCj4+ID4+ID4gPj4+IERQSQ0K Pj4gPj4gPiBmdW5jdGlvbmFsaXR5Pw0KPj4gPj4gPiA+PiA8U0s+IEkgaGF2ZSBub3QgZnVsbHkg cmVhZCB0aGF0IGRyYWZ0IHlldC4gQnV0IGluIGdlbmVyYWwsIGFzIA0KPj4gPj4gPiA+PiBkZXNj cmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9mIHNlcnZpY2VzIGZvcm0g DQo+PiA+PiA+ID4+IGEgZ3JhcGgsIHNlZ21lbnRzIG9mIHdoaWNoIGFyZSBzZXJ2aWNlIHBhdGhz LiBZZXMsIA0KPj4gPj4gPiA+PiByZWNsYXNzaWZpY2F0aW9uIGNhbg0KPj4gPj4gPiBjaGFuZ2UN Cj4+ID4+ID4gPj4gdGhlIHNlcnZpY2UgcGF0aCBhbmQgcmUtY2xhc3NpZmljYXRpb24gbWF5IGhh cHBlbiBhdCBhbnkgbm9kZSANCj4+ID4+ID4gPj4gYWxvbmcNCj4+ID4+ID4gYSBzZXJ2aWNlIHBh dGguDQo+PiA+PiA+ID4+DQo+PiA+PiA+ID4+IFN1cmVuZHJhLg0KPj4gPj4gPiA+Pj4NCj4+ID4+ ID4gPj4+IHRoYW54Lg0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+IC0tICBLZXZpbiBKLiBNYQ0K Pj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g Pj4gPiA+Pj4+IEZyb206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJA Y2lzY28uY29tXQ0KPj4gPj4gPiA+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEz IDEyOjA4IEFNDQo+PiA+PiA+ID4+Pj4gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1bWFu ZHJhIE1hamVlOyBUaG9tYXMgTmFydGVuOyANCj4+ID4+ID4gPj4+PiBuc2NAaWV0Zi5vcmcNCj4+ ID4+ID4gPj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KPj4gPj4gPiA+Pj4+DQo+PiA+PiA+ID4+Pj4gS2V2aW4sDQo+PiA+PiA+ID4+Pj4NCj4+ID4+ ID4gPj4+PiBDbGFzc2lmaWNhdGlvbiBtZWNoYW5pc20gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg U0ZDLiBJdCANCj4+ID4+ID4gPj4+PiBjYW4gYmUgYmFzZWQNCj4+ID4+ID4gPj4gb24NCj4+ID4+ ID4gPj4+PiB0aGUgcGFja2V0IG9yIGluZm9ybWF0aW9uIG5vdCBpbiB0aGUgcGFja2V0KGVudmly b25tZW50YWwgDQo+PiA+PiA+ID4+Pj4gYXR0cmlidXRlcw0KPj4gPj4gPiA+PiBmb3INCj4+ID4+ ID4gPj4+PiBpbnN0YW5jZSkgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlzIGltcG9y dGFudCBpcyANCj4+ID4+ID4gPj4+PiB0aGF0IHN1Y2ggY2xhc3NpZmljYXRpb24gYWlkcyBpbiB0 cmFmZmljIHNlbGVjdGlvbiBhbmQgDQo+PiA+PiA+ID4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZp Y2F0aW9uLg0KPj4gPj4gPiA+Pj4+IEl0IGlzIG5vIGRpZmZlcmVudCBmcm9tIGEgcG9saWN5IGlu IHRoaXMgcmVnYXJkIGV4Y2VwdCB0aGF0IA0KPj4gPj4gPiA+Pj4+IHRoZSBwb2xpY3kgbm93IHNw ZWNpZmllcyB0aGUgc2VydmljZSBwYXRoLg0KPj4gPj4gPiA+Pj4+IEZ1cnRoZXIsIGNsYXNzaWZp Y2F0aW9uIGlzIG5vdCBsaW1pdGVkIHRvIHRoZSBuZXR3b3JrIA0KPj4gPj4gPiA+Pj4+IGVsZW1l bnRzIGJ1dCB0aGUgc2VydmljZSBmdW5jdGlvbnMgYXMgd2VsbC4gU29tZSBvZiB0aGlzIGlzIA0K Pj4gPj4gPiA+Pj4+IGRlc2NyaWJlZCBpbiB0aGUNCj4+ID4+ID4gPj4gYXJjaGl0ZWN0dXJlDQo+ PiA+PiA+ID4+Pj4gZHJhZnRzIGFzIHdlbGwgLQ0KPj4gPj4gPiA+Pj4+ICJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMtYXJjaC8iLg0KPj4gPj4gPiA+Pj4+ DQo+PiA+PiA+ID4+Pj4gU3VyZW5kcmEuDQo+PiA+PiA+ID4+Pj4NCj4+ID4+ID4gPj4+Pj4gT24g MTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiDQo+PiA+PiA+ID4+Pj4+IDxrZXZpbi5tYUBh enVraXN5c3RlbXMuY29tPg0KPj4gPj4gPiB3cm90ZToNCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4g Pj4+Pj4gSGkgUm9uLA0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiBJIHdhcyB1bmFibGUg dG8gbWFrZSB0aGUgU0ZDIEJvRiBkdWUgdG8gYSBjb25mbGljdCB3aXRoIA0KPj4gPj4gPiA+Pj4+ PiBDRE5JLCBidXQgSSBoYWQgYSBzaW1pbGFyIHF1ZXN0aW9uIHdydCBidWxsZXQgMTEgaW4gDQo+ PiA+PiA+ID4+Pj4+IHNlY3Rpb24NCj4+ID4+ID4gPj4+Pj4gMiBvZiB0aGUNCj4+ID4+ID4gcHJv YmxlbQ0KPj4gPj4gPiA+Pj4+PiBzdGF0ZW1lbnQ6DQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+ Pj4+ICAgMTEuICBQZXItU2VydmljZSAocmUpQ2xhc3NpZmljYXRpb246IENsYXNzaWZpY2F0aW9u IA0KPj4gPj4gPiA+Pj4+PiBvY2N1cnMgYXQNCj4+ID4+ID4gZWFjaA0KPj4gPj4gPiA+Pj4+PiAg ICAgICAgc2VydmljZSwgaW5kZXBlbmRlbnQgZnJvbSBwcmV2aW91c2x5IGFwcGxpZWQgDQo+PiA+ PiA+ID4+Pj4+IHNlcnZpY2UNCj4+ID4+ID4gPj4+PiBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+Pj4+ ICAgICAgICBUaGVzZSB1bnJlbGF0ZWQgY2xhc3NpZmljYXRpb24gZXZlbnRzIGNvbnN1bWUgDQo+ PiA+PiA+ID4+Pj4+IHJlc291cmNlcw0KPj4gPj4gPiBwZXINCj4+ID4+ID4gPj4+Pj4gICAgICAg IHNlcnZpY2UuICBNb3JlIGltcG9ydGFudGx5LCB0aGUgY2xhc3NpZmljYXRpb24NCj4+ID4+ID4g ZnVuY3Rpb25hbGl0eQ0KPj4gPj4gPiA+Pj4+PiAgICAgICAgb2Z0ZW4gZGlmZmVycyBwZXIgc2Vy dmljZSBmdW5jdGlvbiBhbmQgc2VydmljZSANCj4+ID4+ID4gPj4+Pj4gZnVuY3Rpb24NCj4+ID4+ ID4gPj4gY2Fubm90DQo+PiA+PiA+ID4+Pj4+ICAgICAgICBsZXZlcmFnZSB0aGUgcmVzdWx0cyBm cm9tIG90aGVyIGRlcGxveWVkIG5ldHdvcmsgb3INCj4+ID4+ID4gc2VydmljZS4NCj4+ID4+ID4g Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4gYXMgaXQgcmVsYXRlcyB0byBzZWN0aW9uIDUuMiBvZiB0aGUg ZnJhbWV3b3JrIGRvY3VtZW50Og0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiAgIFRoZSBT RkMgQ2xhc3NpZmllciBjbGFzc2lmaWVzIHBhY2tldHMgYmFzZWQgb24gKHNvbWUgb2YpIA0KPj4g Pj4gPiA+Pj4+PiB0aGUNCj4+ID4+ID4gPj4+PiBjb250ZW50cw0KPj4gPj4gPiA+Pj4+PiAgIG9m IHRoZSBwYWNrZXQgaGVhZGVyLiAgQ29uY3JldGVseSwgaXQgY2xhc3NpZmllcyBwYWNrZXRzIA0K Pj4gPj4gPiA+Pj4+PiBiYXNlZCBvbg0KPj4gPj4gPiA+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+PiAg IHBvc3NpYmxlIGNvbWJpbmF0aW9uIG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsIHN1Y2gg DQo+PiA+PiA+ID4+Pj4+IGFzDQo+PiA+PiA+IHNvdXJjZQ0KPj4gPj4gPiA+Pj4+PiAgIGFkZHJl c3MsIGRlc3RpbmF0aW9uIGFkZHJlc3MsIERTIGZpZWxkLCBwcm90b2NvbCBJRCwgDQo+PiA+PiA+ ID4+Pj4+IHNvdXJjZQ0KPj4gPj4gPiBwb3J0DQo+PiA+PiA+ID4+Pj4gYW5kDQo+PiA+PiA+ID4+ Pj4+ICAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBhbmQgYW55IG90aGVyIGluZm9ybWF0aW9u Lg0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiBBIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVy IGFzIGRlc2NyaWJlZCBpbiB0aGUgZnJhbWV3b3JrIA0KPj4gPj4gPiA+Pj4+PiBkb2N1bWVudA0K Pj4gPj4gPiA+Pj4+IHdvdWxkDQo+PiA+PiA+ID4+Pj4+IHNlZW0gdG8gYmUgbGltaXRlZCBpbiB3 aGF0IGl0IGNhbiBjbGFzc2lmeT8gIFRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+PiBmdW5jdGlv biBpZGVudGlmaWVyIGxvb2t1cCBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgDQo+PiA+PiA+ID4+Pj4+ IHNpZ25pZmljYW50IG9wdGltaXphdGlvbg0KPj4gPj4gPiA+PiBvdmVyDQo+PiA+PiA+ID4+Pj4+ IGEgcGFja2V0LWJhc2VkIDUtdHVwbGUgbG9va3VwPyAgVGhlcmUgc2VlbXMgdG8gYmUgc29tZSAN Cj4+ID4+ID4gPj4+Pj4gbWlzc2luZw0KPj4gPj4gPiA+PiBkZXRhaWwNCj4+ID4+ID4gPj4+Pj4g d3J0IGhvdyBjbGFzc2lmaWNhdGlvbiBpbmZvcm1hdGlvbiBpcyBkZXRlcm1pbmVkIGFuZCByZXVz ZWQ/DQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IFdoZW4gdGhpbmtpbmcgYWJvdXQgaGln aGVyIGxldmVsIHNlcnZpY2VzLCBlLmcuLCBIVFRQIGFuZCANCj4+ID4+ID4gPj4+Pj4gVExTDQo+ PiA+PiA+ID4+Pj4gZW5jcnlwdGVkDQo+PiA+PiA+ID4+Pj4+IGZsb3dzLCBhIHBhY2tldC1iYXNl ZCBjbGFzc2lmaWVyIHNlZW1zIGluYWRlcXVhdGU/ICBJIHdhcyANCj4+ID4+ID4gPj4+Pj4gYWxz bw0KPj4gPj4gPiA+Pj4+IHdvbmRlcmluZw0KPj4gPj4gPiA+Pj4+PiBob3cgaW5kZXBlbmRlbnQg SExTIHNlZ21lbnQgcmVxdWVzdHMgbWlnaHQgYmUgY2xhc3NpZmllZCANCj4+ID4+ID4gPj4+Pj4g YW5kDQo+PiA+PiA+ID4+Pj4gYXNzb2NpYXRlZD8NCj4+ID4+ID4gPj4+Pj4gV2VyZSB0aGVzZSB0 eXBlcyBvZiB1c2UgY2FzZXMgZGlzY3Vzc2VkIGluIHRoZSBCb0Y/DQo+PiA+PiA+ID4+Pj4+DQo+ PiA+PiA+ID4+Pj4+IHRoYW54Lg0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiAtLSAgS2V2 aW4gSi4gTWENCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFp bHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSANCj4+ID4+ID4gPj4+Pj4+IE9uIEJlaGFsZg0KPj4g Pj4gPiA+PiBPZg0KPj4gPj4gPiA+Pj4+Pj4gUm9uDQo+PiA+PiA+ID4+Pj4+PiBQYXJrZXINCj4+ ID4+ID4gPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTYgUE0NCj4+ ID4+ID4gPj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYu b3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBT RkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhLA0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFzIHdhcyBkaXNjdXNzZWQgaW4gVmFuY291dmVy LCB0aGVyZSBhcmUgYWxyZWFkeSBtYW55IA0KPj4gPj4gPiA+Pj4+Pj4gZXhpc3Rpbmcgd2F5cw0K Pj4gPj4gPiA+Pj4+IHRvDQo+PiA+PiA+ID4+Pj4+PiBhY2NvbXBsaXNoIHNlcnZpY2UgY2hhaW5p bmcuICAgICBCdXQgbm9uZSBvZiB0aGVtIHByb3ZpZGUgYQ0KPj4gPj4gPiA+Pj4+IHN1ZmZpY2ll bnQNCj4+ID4+ID4gPj4+Pj4+IGNvbWJpbmF0aW9uIG9mIGludGVyb3BlcmFiaWxpdHksIGZsZXhp YmlsaXR5LCBhbmQNCj4+cmVzaWxpZW5jeS4NCj4+ID4+ID4gQQ0KPj4gPj4gPiA+Pj4+IHNpbmds ZQ0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdpbGwgZ28gYSBs b25nIHdheSB0byANCj4+ID4+ID4gPj4+Pj4+IGVuc3VyaW5nIHRoZXNlDQo+PiA+PiA+ID4+Pj4g Z29hbHMuDQo+PiA+PiA+ID4+Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBtb3N0 IGVmZmljaWVudCBhcHByb2FjaCBmb3IgDQo+PiA+PiA+ID4+Pj4+PiBldmVyeQ0KPj4gPj4gPiA+ Pj4+IHNpbmdsZQ0KPj4gPj4gPiA+Pj4+Pj4gbmV0d29yayB0b3BvbG9neSBhbmQgZXZlcnkgc2lu Z2xlIHVzZSBjYXNlLCBidXQgaXRzIA0KPj4gPj4gPiA+Pj4+Pj4gdWJpcXVpdG91cw0KPj4gPj4g PiA+PiBuYXR1cmUNCj4+ID4+ID4gPj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4N Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAgIFJvbg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gPj4gPiA+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNv bV0NCj4+ID4+ID4gPj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTAg UE0NCj4+ID4+ID4gPj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0 Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gUm9uLA0KPj4gPj4g PiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFuIGV4YW1wbGUg b2Ygb25lIHR5cGUgb2YgZGVyaXZhdGlvbi4NCj4+ID4+ID4gPj4+Pj4+IEhvd2V2ZXINCj4+ID4+ ID4gPj4+PiB0aGlzDQo+PiA+PiA+ID4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQgd2l0aCBjbGFz c2lmaWNhdGlvbiByZXN1bHQsIGFnYWluIG9uZSANCj4+ID4+ID4gPj4+Pj4+IG1vcmUNCj4+ID4+ ID4gPj4+PiBleGFtcGxlLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+Pj4gQWxsIGZs b3dzIGZyb20gdGhlIHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSANCj4+ID4+ID4g Pj4+Pj4+Pj4gZm9sbG93DQo+PiA+PiA+IHRoZQ0KPj4gPj4gPiA+Pj4+IHNhbWUNCj4+ID4+ID4g Pj4+Pj4+IGNoYWluLg0KPj4gPj4gPiA+Pj4+Pj4gQ29ycmVjdC4gSXQgaXMgYWxzbyBub3QgbmVj ZXNzYXJ5IHRoYXQgYWxsIHRyYW5zYWN0aW9uIG9mIA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIHNhbWUN Cj4+ID4+ID4gPj4+PiBmbG93DQo+PiA+PiA+ID4+Pj4+PiBmb2xsb3cgdGhlIHNhbWUgY2hhaW4g ZWl0aGVyLiBTbyB3aHkgc3RvcCBhdCBmbG93IGl0c2VsZi4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+PiBBZ2FpbiB0aGUgcG9pbnQgaGVyZSBpcyB0aGF0IGRvIHdlIGFsd2F5cyBuZWVk IFNGQyBoZWFkZXIgDQo+PiA+PiA+ID4+Pj4+PiBvcg0KPj4gPj5Ob3QuDQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gU3VtYW5kcmENCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+ Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3Mu Y29tXQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA3OjAy IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47IG5z Y0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRy YSwNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBUaGUgaW50ZW50aW9uIG9mIHNlcnZp Y2UgZnVuY3Rpb24gY2hhaW5pbmcgaXMgdG8gYWxsb3cgDQo+PiA+PiA+ID4+Pj4+PiBmb3Igb3Bl cmF0aW9uDQo+PiA+PiA+ID4+Pj4gYXQNCj4+ID4+ID4gPj4+Pj4+IHRoZSBmdWxseSBxdWFsaWZp ZWQgZmxvdyBsZXZlbCwgb3IgZXZlbiBmaW5lciBncmFpbmVkIGF0IA0KPj4gPj4gPiA+Pj4+Pj4g dGhlDQo+PiA+PiA+ID4+Pj4gdHJhbnNhY3Rpb24NCj4+ID4+ID4gPj4+Pj4+IGxldmVsICh0aGlz IGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlciBmb3IgdGhlIFBEUCkuDQo+PkFsbA0KPj4gPj4g PiBmbG93cw0KPj4gPj4gPiA+Pj4+IGZyb20NCj4+ID4+ID4gPj4+Pj4+IHRoZSBzYW1lIHNvdXJj ZSBJUCBkbyBub3QgbmVjZXNzYXJpbHkgZm9sbG93IHRoZSBzYW1lIGNoYWluLg0KPj4gPj4gPiA+ PiBTb3VyY2UNCj4+ID4+ID4gPj4+Pj4+IElQLA0KPj4gPj4gPiA+Pj4+Pj4gdGhlcmVmb3JlLCAg ZG9lcyBub3QgaWRlbnRpZnkgdGhlIGNoYWluIElELiAgICBBbm90aGVyDQo+PiA+PmludGVudGlv bg0KPj4gPj4gPiBvZg0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBp cyB0byBvcGVyYXRlIG92ZXIgYW55IG5ldHdvcmsNCj4+ID4+ID4gdG9wb2xvZ3kNCj4+ID4+ID4g Pj4gYW5kDQo+PiA+PiA+ID4+Pj4+PiBub3QNCj4+ID4+ID4gPj4+Pj4+IGJlIGxpbWl0ZWQgdG8g YSBzaW5nbGUgTEFOLiAgIFRodXMsIHdoaWxlIFZMQU4gbWF5IGJlIHBhcnQNCj4+b2YNCj4+ID4+ ID4gdGhlDQo+PiA+PiA+ID4+Pj4+PiB0cmFuc3BvcnQsIGl0IGRvZXMgbm90IGFkZXF1YXRlbHkg aWRlbnRpZnkgdGhlIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBjaGFpbiwNCj4+ID4+ID4gPj4g ZWl0aGVyLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ICAgUm9uDQo+PiA+PiA+ID4+ Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+PiA+PiA+ID4+Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFq ZWVARjUuY29tXQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAx MyA5OjU2IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhvbWFzIE5hcnRlbjsg bnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFJvbiwN Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBUaGUgc2VydmljZSBoZWFkZXIgaXMgbWVh bnQgdG8gY2FycnkgdGhlIGNvbnRleHQgd2hpY2ggDQo+PiA+PiA+ID4+Pj4+PiBjYW4NCj4+ID4+ ID4gKmFsc28qDQo+PiA+PiA+ID4+Pj4+PiBiZSBkZXJpdmVkIChmb3IgZXhhbXBsZSB1c2Ugc291 cmNlIGlwIGFuZCB2bGFuIHRvIA0KPj4gPj4gPiA+Pj4+Pj4gaWRlbnRpZnkgY2hhaW5JRCBhbmQN Cj4+ID4+ID4gPj4+Pj4+IHBvc2l0aW9uKSBvciBlbmNhcHN1bGF0ZWQgYXMgcGFydCBvZiBhbm90 aGVyIHR1bm5lbCBoZWFkZXIuDQo+PiA+PiA+ID4+Pj4+PiBTbyB0aGlzIGNvdWxkIGJlIG9wdGlv bmFsIElNSE8uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25f UGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAxMSwgMjAxMyA0OjM2IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogU3VtYW5kcmEg TWFqZWU7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVj dDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+ DQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYSwNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+ PiBBcyBJIHVuZGVyc3RhbmQgaXQsIGFuIFNGQyBwYWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0 byANCj4+ID4+ID4gPj4+Pj4+IFNGIG9yIGZyb20NCj4+ID4+ID4gPj4+PiBTRg0KPj4gPj4gPiA+ Pj4+Pj4gdG8NCj4+ID4+ID4gPj4+Pj4+IFNGIHdpbGwgbG9vayBsaWtlOg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+ Pj4+PiB8ICAgICAgICAidHJhbnNwb3J0IiAgICAgICAgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgc2VydmljZSBoZWFk ZXIgICAgfA0KPj4gPj4gPiA+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ID4+ ID4gPj4+Pj4+IHwgICBvcmlnaW5hbCBJUCBoZWFkZXIgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8ICBvcmlnaW5hbCBJUCANCj4+ID4+ID4gPj4+Pj4+IHwg cGF5bG9hZA0KPj4gPj4gPiB8DQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tKw0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFdoZXJlIHNlcnZpY2UgaGVh ZGVyIGNvbnRhaW5zLCBhdCBhIG1pbmltdW0sIGVub3VnaCANCj4+ID4+ID4gPj4+Pj4+IGluZm9y bWF0aW9uIHRvDQo+PiA+PiA+ID4+Pj4gYWxsb3cNCj4+ID4+ID4gPj4+Pj4+IHRoZSBwYWNrZXQg dG8gYmUgcHJvcGFnYXRlZCBhbG9uZyB0aGUgZnVsbCBsZW5ndGggb2YgdGhlIA0KPj4gPj4gPiA+ Pj4+Pj4gY2hhaW4sIGFuZCBvcHRpb25hbGx5LCBvdGhlciBtZXRhZGF0YSB0aGF0IGVuaGFuY2Vz IHRoZSANCj4+ID4+ID4gPj4+Pj4+IG9wZXJhdGlvbiBvZg0KPj4gPj4gPiBvbmUNCj4+ID4+ID4g Pj4+Pj4+IG9yDQo+PiA+PiA+ID4+IG1vcmUNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rp b25zLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFuZCB3aGVyZSAidHJhbnNwb3J0 IiBjb3VsZCBjb25jZWl2YWJseSBiZSBhbnkgb2YsIGJ1dCANCj4+ID4+ID4gPj4+Pj4+IG5vdCBs aW1pdGVkDQo+PiA+PiA+ID4+Pj4gdG86DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4g KiBFdGhlcm5ldA0KPj4gPj4gPiA+Pj4+Pj4gKiBFdGhlcm5ldCArIExMQzINCj4+ID4+ID4gPj4+ Pj4+ICogRXRoZXJuZXQgKyBNUExTDQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgKyBH UkUNCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQgKyBJUCArVURQDQo+PiA+PiA+ID4+Pj4+Pg0K Pj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRp YWdyYW0gYWJvdmUgaXMgbm90IG1lYW50IHRvIA0KPj4gPj4gPiA+Pj4+Pj4gaW1wbHkgaW1tdXRh YmlsaXR5LCBidXQgcmF0aGVyIHRvIHNwZWNpZnkgdGhlIHBhY2tldCB0aGF0IA0KPj4gPj4gPiA+ Pj4+Pj4gaXMNCj4+ID4+ID4gcHJvcGFnYXRlZA0KPj4gPj4gPiA+Pj4+Pj4gZnJvbSBwcmVjZWRp bmcgZW50aXR5IHRvIHN1Y2NlZWRpbmcgZW50aXR5LCBwcmlvciB0byANCj4+ID4+ID4gPj4+Pj4+ IGVuY2Fwc3VsYXRpb24uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24NCj4+ ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIA0KPj4gPj4gPiA+Pj4+Pj4gT24gQmVoYWxm DQo+PiA+PiA+ID4+IE9mDQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiA+ Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA2OjQ2IFBNDQo+PiA+PiA+ID4+ Pj4+PiBUbzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJq ZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+IEdlbmVyaWMgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBFbmNh cHN1bGF0aW9uOiBBIA0KPj4gPj4gPiA+Pj4+Pj4gZG9jdW1lbnQNCj4+ID4+d2lsbA0KPj4gPj4g PiA+Pj4+Pj4gICAgZGVzY3JpYmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUg DQo+PiA+PiA+ID4+Pj4+PiBlbmNhcHN1bGF0aW9uDQo+PiA+PiA+ID4+IGZvcm1hdA0KPj4gPj4g PiA+Pj4+Pj4gZm9yDQo+PiA+PiA+ID4+Pj4+PiAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb24NCj4+ ID4+ID4gPj4+PiBwYXRoLA0KPj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGZvciBjb21tdW5pY2F0aW5n IGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiANCj4+ID4+ID4gPj4+Pj4+IG5vZGVzDQo+PiB0 aGF0DQo+PiA+PiA+ID4+Pj4+PiAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMuIEl0IGlz IGludGVuZGVkIHRoYXQgdGhlDQo+PiA+PiA+ID4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4gPj4gPiA+ Pj4+Pj4gICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQg YW5kIA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIHNlcnZpY2UNCj4+ID4+ID4gPj4+PiB0aGF0DQo+PiA+ PiA+ID4+Pj4+PiBpcw0KPj4gPj4gPiA+Pj4+Pj4gICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQg aXMsIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gbWF5IA0KPj4gPj4gPiA+Pj4+Pj4gYmUNCj4+ID4+ ID4gdXNlZA0KPj4gPj4gPiA+PiBvbg0KPj4gPj4gPiA+Pj4+Pj4gICAgYSBzZXJ2aWNlIGZ1bmN0 aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgDQo+PiA+PiA+ID4+Pj4+PiBv ciBhdCBhbnkgb3RoZXINCj4+ID4+ID4gPj4+Pj4+ICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5j YXBzdWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUNCj4+ID4+ID4gPj4gY29uc3RydWN0aW9uDQo+ PiA+PiA+ID4+Pj4gb2YNCj4+ID4+ID4gPj4+Pj4+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMg cmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsIHNlcnZpY2UuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4g PiA+Pj4+Pj4gW1NNXSBXaGF0IGRvZXMgaXQgbWVhbiBieSBhIHNpbmdsZSBzZXJ2aWNlLWxldmVs IA0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbiwNCj4+ID4+ID4gYQ0KPj4gPj4gPiA+Pj4+ IG5ldw0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBmb3JtYXQNCj4+ID4+ID4gPj4+Pj4+ ICAgICAgICAgICAgb3IgYW4gYWJpbGl0eSB0byBzZWxlY3Qgb25lIGVuY2Fwc3VsYXRpb24gDQo+ PiA+PiA+ID4+Pj4+PiBmb3JtYXQgdGhhdA0KPj4gPj4gPiA+Pj4+IGZpdHMNCj4+ID4+ID4gPj4+ Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gbmVlZCBmb3IgYSBnaXZlbiBzZXJ2aWNlIGNoYWluPw0K Pj4gPj4gPiA+Pj4+Pj4gICAgICAgICAgIFRoZSBhYmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNpZmlj IGVuY2Fwc3VsYXRpb24gDQo+PiA+PiA+ID4+Pj4+PiB3b3VsZCBiZQ0KPj4gPj4gPiA+PiBhDQo+ PiA+PiA+ID4+Pj4+PiBtYW5hZ2VtZW50IHBsYW5lIGRlY2lzaW9uLg0KPj4gPj4gPiA+Pj4+Pj4g ICAgICAgICAgVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGV4aXN0aW5nIGVuY2Fwc3VsYXRpb24gDQo+ PiA+PiA+ID4+Pj4+PiBtZXRob2RzIHRoYXQNCj4+ID4+ID4gPj4+PiBjYW4NCj4+ID4+ID4gPj4+ Pj4+IHBvc3NpYmx5IGJlIHJldXNlZCB0byBwcm92aWRlDQo+PiA+PiA+ID4+Pj4+PiAgICAgICAg ICBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gICBzZXJ2aWNlIG5vZGVzLiBJIGhhdmUNCj4+ ID4+ID4gc2Vlbg0KPj4gPj4gPiA+Pj4+Pj4gbWVudGlvbg0KPj4gPj4gPiA+Pj4+Pj4gb2YgR1JF LCBmb3IgSFRUUCBiYXNlZA0KPj4gPj4gPiA+Pj4+Pj4gICAgICAgICAgYXBwbGljYXRpb25zIGNv bnRleHRzIGFyZSB0cmFuc2ZlcnJlZCB2aWEgaGVhZGVycy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5j ZXNAaWV0Zi5vcmddIA0KPj4gPj4gPiA+Pj4+Pj4gT24gQmVoYWxmDQo+PiA+PiA+ID4+IE9mDQo+ PiA+PiA+ID4+Pj4+PiBUaG9tYXMgTmFydGVuDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDA2LCAyMDEzIDExOjA3IEFNDQo+PiA+PiA+ID4+Pj4+PiBUbzogbnNjQGll dGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNG QyBjaGFydGVyDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gSGkuDQo+PiA+PiA+ID4+ Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gQ3VycmVudCBjaGFydGVyIGNhbiBiZSBmb3VuZCBhdA0KPj4g Pj4gPiA+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci0NCj4+ ID4+ID4gPj4+Pj4+IGlldGYtc2ZjLy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBJ dCBjb250YWlucyB0aGUgcmV2aXNlZCBtYW5hZ2VtZW50IHRleHQgYXMgd2VsbCBhcyANCj4+ID4+ ID4gPj4+Pj4+IHVwZGF0ZWQNCj4+ID4+ID4gPj4+PiBtaWxlc3RvbmVzLg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+IEFsbCBrbm93biBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4g SWYgdGhlcmUgYXJlIGFueSANCj4+ID4+ID4gPj4+Pj4+IHJlbWFpbmluZw0KPj4gPj4gPiA+Pj4+ IGlzc3VlcywNCj4+ID4+ID4gPj4+Pj4+IHBsZWFzZSBzcGVhayB1cCENCj4+ID4+ID4gPj4+Pj4+ DQo+PiA+PiA+ID4+Pj4+PiBDaGFydGVyIGNoYXJ0ZXItaWV0Zi1zZmMtMDAtMDQNCj4+ID4+ID4g Pj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBOZXR3b3Jrcywgc2VydmVycywgc3RvcmFnZSB0ZWNobm9s b2dpZXMsIGFuZCANCj4+ID4+ID4gPj4+Pj4+IGFwcGxpY2F0aW9ucywgaGF2ZSBhbGwgdW5kZXJn b25lIHNpZ25pZmljYW50IGNoYW5nZSBpbiANCj4+ID4+ID4gPj4+Pj4+IHJlY2VudCB5ZWFycyB3 aXRoIHRoZSBpbnRyb2R1Y3Rpb24NCj4+ID4+ID4gPj4gb2YNCj4+ID4+ID4gPj4+Pj4+IHZpcnR1 YWxpemF0aW9uLCBuZXR3b3JrIG92ZXJsYXlzLCBhbmQgb3JjaGVzdHJhdGlvbi4NCj4+ID4+ID4g Pj4+Pj4+IFNlcnZpY2UNCj4+ID4+ID4gPj4gZGVsaXZlcnkNCj4+ID4+ID4gPj4+PiBpcw0KPj4g Pj4gPiA+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFs IGNoYWxsZW5nZSANCj4+ID4+ID4gPj4+Pj4+IHRoYXQNCj4+ID4+ID4gPj4gaW52b2x2ZXMNCj4+ ID4+ID4gPj4+Pj4+IHNpZ25pZmljYW50IG1vZGlmaWNhdGlvbiB0byB0aGUgbmV0d29yayBjb25m aWd1cmF0aW9uLg0KPj4gPj4gPiA+Pj4+Pj4gU2VydmljZXMgYXJlIHR5cGljYWxseSBpbXBsZW1l bnRlZCBieSB0aGUgb3JkZXJlZCANCj4+ID4+ID4gPj4+Pj4+IGNvbWJpbmF0aW9uIG9mIGEgbnVt YmVyIG9mIHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgYXJlIA0KPj4gPj4gPiA+Pj4+Pj4gZGVwbG95 ZWQgYXQgZGlmZmVyZW50IHBvaW50cyB3aXRoaW4NCj4+ID4+ID4gPj4gdGhlDQo+PiA+PiA+ID4+ Pj4+PiBuZXR3b3JrLiBUb2RheSwgYSBjb21tb24gZGVwbG95bWVudCBtb2RlbCBoYXMgc2Vydmlj ZSANCj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9ucyBwaHlzaWNhbGx5IGluc2VydGVkIG9uIHRoZSBk YXRhIGZvcndhcmRpbmcgcGF0aCANCj4+ID4+ID4gPj4+Pj4+IGJldHdlZW4gY29tbXVuaWNhdGlu ZyBwZWVycy4NCj4+ID4+ID4gPj4+PiBHb2luZw0KPj4gPj4gPiA+Pj4+Pj4gZm9yd2FyZCwgaG93 ZXZlciwgdGhlcmUgaXMgYSBkZXNpcmUgdG8gbW92ZSB0byBhIA0KPj4gPj4gPiA+Pj4+Pj4gZGlm ZmVyZW50IG1vZGVsLA0KPj4gPj4gPiA+Pj4+IHdoZXJlDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNl IGZ1bmN0aW9ucyBhcmUgbm90IHJlcXVpcmVkIHRvIHJlc2lkZSBvbiB0aGUgDQo+PiA+PiA+ID4+ Pj4+PiBkZWZhdWx0IGRhdGENCj4+ID4+ID4gPj4gcGF0aA0KPj4gPj4gPiA+Pj4+Pj4gYW5kDQo+ PiA+PiA+ID4+Pj4+PiB0cmFmZmljIGlzIGluc3RlYWQgc3RlZXJlZCB0aHJvdWdoIHNlcnZpY2Vz LCB3aGVyZXZlciANCj4+ID4+ID4gPj4+Pj4+IHRoZXkgYXJlDQo+PiA+PiA+ID4+Pj4gZGVwbG95 ZWQuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gRm9yIGEgZ2l2ZW4gc2VydmljZSwg dGhlIGFic3RyYWN0ZWQgdmlldyBvZiB0aGUgcmVxdWlyZWQgDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2 aWNlIGZ1bmN0aW9ucyBhbmQgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRvIGJlIA0KPj4g Pj4gPiA+Pj4+Pj4gYXBwbGllZCBpcw0KPj4gPj4gPiBjYWxsZWQNCj4+ID4+ID4gPj4+Pj4+IGEg U2VydmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKS4gU2luY2UgYSBnaXZlbiBzZXJ2aWNlIA0KPj4g Pj4gPiA+Pj4+Pj4gZnVuY3Rpb24gbWF5IGJlIGF2YWlsYWJsZSBvbiBtb3JlIHRoYW4gb25lIG5v ZGUgd2l0aGluIGEgDQo+PiA+PiA+ID4+Pj4+PiBuZXR3b3JrLCBhIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW4gaXMgaW5zdGFudGlhdGVkDQo+PiA+PiA+ID4+Pj4gdmlhDQo+PiA+PiA+ID4+Pj4+PiB0 aGUgc2VsZWN0aW9uIG9mIHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIGFuZCAN Cj4+ID4+ID4gPj4+Pj4+IHRoZSBuZXR3b3JrIG5vZGVzIG9uIHdoaWNoIHRoZXkgYXJlIHByb3Zp ZGVkLCB0aGVyZWJ5IA0KPj4gPj4gPiA+Pj4+Pj4gZm9ybWluZyBhIHNlcnZpY2UgdG9wb2xvZ3k6 DQo+PiA+PiA+ID4+Pj4+PiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4g VGhlIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbnMNCj4+ID4+ID4gbWF5DQo+PiA+ PiA+ID4+Pj4+PiBiZSBhcHBsaWVkIGF0IGEgc3BlY2lmaWMgbGF5ZXIgd2l0aGluIHRoZSBuZXR3 b3JrIA0KPj4gPj4gPiA+Pj4+Pj4gcHJvdG9jb2wgc3RhY2sNCj4+ID4+ID4gPj4+PiAobmV0d29y aw0KPj4gPj4gPiA+Pj4+Pj4gbGF5ZXIsIGFwcGxpY2F0aW9uIGxheWVyLCBldGMuKS4NCj4+ID4+ ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAo U0ZDKSB3b3JraW5nIGdyb3VwIHdpbGwgDQo+PiA+PiA+ID4+Pj4+PiBkZXZlbG9wIG5ldyBhcHBy b2FjaGVzIHRvIHNlcnZpY2UgZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuDQo+PiA+PiA+ID4+Pj4+ PiBJdCB3aWxsIHByb2R1Y2UgYSBmcmFtZXdvcmsgZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgDQo+PiA+PiA+ID4+Pj4+PiB0aGF0IGluY2x1ZGVzIHRoZSBuZWNlc3NhcnkgcHJvdG9jb2xz DQo+PiA+PiA+ID4+Pj4gb3INCj4+ID4+ID4gPj4+Pj4+IHByb3RvY29sIGV4dGVuc2lvbnMgdG8g Y29udmV5IHRoZSBzZXJ2aWNlIHBhdGggYW5kIA0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBwYXRo IGluZm9ybWF0aW9uIHRvIG5vZGVzIHRoYXQgaW1wbGVtZW50IHNlcnZpY2UgDQo+PiA+PiA+ID4+ Pj4+PiBmdW5jdGlvbnMsIGFzIHdlbGwNCj4+ID4+ID4gYXMNCj4+ID4+ID4gPj4+Pj4+IG1lY2hh bmlzbXMgZm9yIHN0ZWVyaW5nIHRyYWZmaWMgdGhyb3VnaCBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ ID4+ID4gPj4+Pj4+IFRoZQ0KPj4gPj4gPiA+Pj4+IHdvcmtpbmcNCj4+ID4+ID4gPj4+Pj4+IGdy b3VwIHdpbGwgYWxzbyBleGFtaW5lIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgDQo+PiA+ PiA+ID4+Pj4+PiBnYXRoZXJlZCBmcm9tDQo+PiA+PiA+ID4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4+ PiBuZXR3b3JrIGFuZCBzZXJ2aWNlIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIHNlcnZpY2UgDQo+ PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbg0KPj4gPj4gPiA+PiBjaGFpbmluZw0KPj4gPj4gPiA+Pj4+ Pj4gYW5kDQo+PiA+PiA+ID4+Pj4+PiBob3cgdGhhdCBpbmZvcm1hdGlvbiBtYXkgYmUgbWFkZSBh dmFpbGFibGUgdG8gbm9kZXMgdGhhdCANCj4+ID4+ID4gPj4+Pj4+IGltcGxlbWVudA0KPj4gPj4g PiA+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+ Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gU3BlY2lmaWNhbGx5LCB0aGUgU0ZDIFdHIGlzIGNoYXJ0ZXJl ZCB0byBkZWxpdmVyIHRoZQ0KPj4gZm9sbG93aW5nOg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4g Pj4+Pj4+IDEpIFByb2JsZW0gU3RhdGVtZW50OiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZSBh IA0KPj4gPj4gPiA+Pj4+Pj4gc3VtbWFyeSBvZg0KPj4gPj4gPiB0aGUNCj4+ID4+ID4gPj4+Pj4+ ICAgIHByb2JsZW0gc3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBXRyBpbmNsdWRpbmcgDQo+ PiA+PiA+ID4+Pj4+PiBleGFtcGxlDQo+PiA+PiA+IGhpZ2gtDQo+PiA+PiA+ID4+Pj4+PiAgICBs ZXZlbCB1c2UgY2FzZXMuIEFkZGl0aW9uYWxseSwgdGhlIFdHIHdpbGwgbm9ybWFsaXplDQo+PiA+ PiA+ID4+IG5vbWVuY2xhdHVyZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGRlZmluaXRpb25zIGZv ciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+ Pj4+IDIpIEFyY2hpdGVjdHVyZTogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSBkZXNjcmlw dGlvbiANCj4+ID4+ID4gPj4+Pj4+IG9mDQo+PiA+PnRoZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgYXJj aGl0ZWN0dXJhbCBidWlsZGluZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMNCj4+ID4+ ID4gaW5jbHVkaW5nDQo+PiA+PiA+ID4+Pj4+PiAgICBpbnRlcmNvbm5lY3Rpb24sIHBsYWNlbWVu dCBvZiBjYXBhYmlsaXRpZXMsIG1hbmFnZW1lbnQsDQo+PiA+PiA+ID4+Pj4+PiAgICBkaWFnbm9z dGljcywgZGVzaWduIGFuYWx5c2lzLCBhbmQgc2VjdXJpdHkgbW9kZWxzLCBhcyANCj4+ID4+ID4g Pj4+Pj4+IHdlbGwNCj4+ID4+YXMNCj4+ID4+ID4gPj4+Pj4+ICAgIHJlcXVpcmVtZW50cyBvbiB0 aGUgcHJvdG9jb2wgbWVjaGFuaXNtcy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAz KSBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSANCj4+ ID4+ID4gPj4+Pj4+IGRvY3VtZW50DQo+PiA+PiA+IHdpbGwNCj4+ID4+ID4gPj4+Pj4+ICAgIGRl c2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIA0KPj4gPj4gPiA+Pj4+ Pj4gZW5jYXBzdWxhdGlvbg0KPj4gPj4gPiA+PiBmb3JtYXQNCj4+ID4+ID4gPj4+Pj4+IGZvcg0K Pj4gPj4gPiA+Pj4+Pj4gICAgY29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFu ZCB0aGUgc2VydmljZSANCj4+ID4+ID4gPj4+Pj4+IGZ1bmN0aW9uDQo+PiA+PiA+ID4+Pj4gcGF0 aCwNCj4+ID4+ID4gPj4+Pj4+ICAgIGFuZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9y bWF0aW9uIGJldHdlZW4gDQo+PiA+PiA+ID4+Pj4+PiBub2Rlcw0KPj4gdGhhdA0KPj4gPj4gPiA+ Pj4+Pj4gICAgaW1wbGVtZW50IHNlcnZpY2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0 IHRoZQ0KPj4gPj4gPiA+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+ID4+ID4gPj4+Pj4+ICAgIGJlIGFn bm9zdGljIHRvIHRoZSBsYXllciBhdCB3aGljaCBpdCBpcyBhcHBsaWVkIGFuZCANCj4+ID4+ID4g Pj4+Pj4+IHRoZSBzZXJ2aWNlDQo+PiA+PiA+ID4+Pj4gdGhhdA0KPj4gPj4gPiA+Pj4+Pj4gaXMN Cj4+ID4+ID4gPj4+Pj4+ICAgIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2FtZSBl bmNhcHN1bGF0aW9uIG1heSANCj4+ID4+ID4gPj4+Pj4+IGJlDQo+PiA+PiA+IHVzZWQNCj4+ID4+ ID4gPj4gb24NCj4+ID4+ID4gPj4+Pj4+ICAgIGEgc2VydmljZSBmdW5jdGlvbiBwYXRoIHJlYWxp emVkIGF0IHRoZSBuZXR3b3JrIGxheWVyIA0KPj4gPj4gPiA+Pj4+Pj4gb3IgYXQgYW55IG90aGVy DQo+PiA+PiA+ID4+Pj4+PiAgICBsYXllciwgYW5kIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2ls bCBhcHBseSBmb3IgdGhlDQo+PiA+PiA+ID4+IGNvbnN0cnVjdGlvbg0KPj4gPj4gPiA+Pj4+IG9m DQo+PiA+PiA+ID4+Pj4+PiAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2Yg dGhlIGFjdHVhbCBzZXJ2aWNlLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IDQpIENv bnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBzZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUNCj4+ID4+ ID4gZGV2ZWxvcGVkIHRvDQo+PiA+PiA+ID4+Pj4+PiAgICBkZXNjcmliZSByZXF1aXJlbWVudHMg YW5kIHByb3RvY29scyBuZWNlc3NhcnkgdG8gDQo+PiA+PiA+ID4+Pj4+PiBjb252ZXkNCj4+ID4+ ID4gPj4+PiBpbmZvcm1hdGlvbg0KPj4gPj4gPiA+Pj4+Pj4gICAgdG8gc2VydmljZSBmdW5jdGlv biBpbXBsZW1lbnRhdGlvbiBwb2ludHMuIFdoZXJlIA0KPj4gPj4gPiA+Pj4+Pj4gcG9zc2libGUs DQo+PiA+PiA+ID4+Pj4gZXhpc3RpbmcNCj4+ID4+ID4gPj4+Pj4+ICAgIElFVEYgcHJvdG9jb2xz IHdpbGwgYmUgdXNlZCBhbmQgZXh0ZW5kZWQuIEFsbCBwcm90b2NvbA0KPj4gPj4gPiA+PiBleHRl bnNpb25zDQo+PiA+PiA+ID4+Pj4+PiAgICB3b3JrIHNob3VsZCBiZSBjYXJyaWVkIG91dCBpbiB0 aGUgd29ya2luZyBncm91cHMgDQo+PiA+PiA+ID4+Pj4+PiByZXNwb25zaWJsZSBmb3INCj4+ID4+ ID4gPj4+PiB0aGUNCj4+ID4+ID4gPj4+Pj4+ICAgIHByb3RvY29scyBiZWluZyBtb2RpZmllZCBp biBjb29yZGluYXRpb24gd2l0aCB0aGlzIA0KPj4gPj4gPiA+Pj4+Pj4gd29ya2luZw0KPj4gPj4g PiA+PiBncm91cCwNCj4+ID4+ID4gPj4+Pj4+IGJ1dA0KPj4gPj4gPiA+Pj4+Pj4gICAgbWF5IGJl IGRvbmUgaW4gdGhpcyB3b3JraW5nIGdyb3VwIGFmdGVyIGFncmVlbWVudCB3aXRoIA0KPj4gPj4g PiA+Pj4+Pj4gYWxsDQo+PiA+PiA+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgcmVsZXZhbnQgV0cg Y2hhaXJzIGFuZCByZXNwb25zaWJsZSBBRHMuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4gNSkgTWFuYWdlYWJpbGl0eTogV29yayBvbiB0aGUgbWFuYWdlbWVudCBhbmQgDQo+PiA+PiA+ ID4+Pj4+PiBjb25maWd1cmF0aW9uIG9mDQo+PiA+PiA+ID4+IHNlcnZpY2UNCj4+ID4+ID4gPj4+ Pj4+ICAgIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIFNGQyBjb21wb25lbnRzIHdpbGwgY2VydGFp bmx5IA0KPj4gPj4gPiA+Pj4+Pj4gYmUNCj4+ID4+ID4gbmVlZGVkLA0KPj4gPj4gPiA+Pj4+Pj4g ICAgYnV0IGZpcnN0IG5lZWRzIHRvIGJlIGJldHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gUHJvcG9zZWQgTWlsZXN0b25lcw0KPj4gPj4g PiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0 aW9uYWwgZG9jdW1lbnQocykgDQo+PiA+PiA+ID4+Pj4+PiBkZWZpbmluZyB0aGUNCj4+ID4+ID4g Pj4+PiBwcm9ibGVtDQo+PiA+PiA+ID4+Pj4+PiBzdGF0ZW1lbnQgYW5kIGNvcmUgdXNlIGNhc2Vz IGZvciBTZXJ2aWNlIEZ1bmN0aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gQ2hhaW5pbmcNCj4+ID4+ID4g Pj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBNYXkgMjAxNCBDb25zdWx0IHdpdGggT1BTIEFyZWEgb24g cG9zc2libGUgY2hhcnRlciANCj4+ID4+ID4gPj4+Pj4+IG1vZGlmaWNhdGlvbnMgZm9yIG1hbmFn ZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YgU0ZDIA0KPj4gPj4gPiA+Pj4+Pj4gY29tcG9uZW50 cw0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNH IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcgDQo+PiA+PiA+ID4+Pj4+PiB0aGUNCj4+ ID4+ID4gPj4+PiBhcmNoaXRlY3R1cmUNCj4+ID4+ID4gPj4+Pj4+IGZvciBTRkMNCj4+ID4+ID4g Pj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBKYW4gMjAxNSBTdWJtaXQgdG8gSUVTRyByZXF1aXJlbWVu dHMgZm9yIGEgZ2VuZXJpYyANCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgZW5jYXBzdWxhdGlvbiBwcm90b2NvbA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ IEF1ZyAyMDE1IFN1Ym1pdCB0byBJRVNHIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCANCj4+ID4+ ID4gPj4+Pj4+IHNwZWNpZnlpbmcgdGhlDQo+PiA+PiA+ID4+Pj4gZ2VuZXJpYw0KPj4gPj4gPiA+ Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBoZWFkZXIgZW5jYXBzdWxhdGlvbg0KPj4g Pj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBUaG9tYXMNCj4+ID4+ID4gPj4+Pj4+ DQo+PiA+PiA+ID4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPj4gPiA+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiA+Pj4+Pj4g bnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KPj4gPj4gPiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ ID4+ID4gPj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+Pj4+PiBuc2MgbWFp bGluZyBsaXN0DQo+PiA+PiA+ID4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ID4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+ Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gPj4+Pj4gbnNjQGlldGYub3JnDQo+PiA+PiA+ ID4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ ID4NCj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gbnNj IG1haWxpbmcgbGlzdA0KPj4gPj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0K Pj4gPj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uc2MNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5z Y0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuc2MgbWFp bGluZyBsaXN0DQpuc2NAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnNjDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25zYw0K From jmh@joelhalpern.com Thu Nov 14 04:46:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09A411E811A for ; Thu, 14 Nov 2013 04:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4X9COuywZi3g for ; Thu, 14 Nov 2013 04:46:35 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB7221E8085 for ; Thu, 14 Nov 2013 04:46:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 3E1601BC4E05; Thu, 14 Nov 2013 04:46:35 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BE9681BC4DFD; Thu, 14 Nov 2013 04:46:33 -0800 (PST) Message-ID: <5284C627.2070906@joelhalpern.com> Date: Thu, 14 Nov 2013 07:46:31 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Hongyu Li (Julio)" , David Allan I , "nsc@ietf.org" References: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 12:46:40 -0000 You assert in the below text that "service functions should be able to compose a chain arbitrarily." That does not seem to follow. The operator defines the service chains they want. They provision those service chains. Thus, I would expect that the job of a service function is to deliver its specific service. In general, it should not need to know or care about the chains in which it is participating. Yours, Joel M. Halpern On 11/13/13 9:29 PM, Hongyu Li (Julio) wrote: > Hi Dave, > > Your inferred restriction may be not always true. In general, service > functions should be able to compose a chain arbitrarily. Particularly > for branching, as I suggested in previous email, service function > shall not directly impact packet forwarding. This precludes the > restriction you mentioned. Forwarding plane can decide whether a > branching action should be taken by reclassification or not per > service chain. > > Does this make sense? > > Hongyu > > -----Original Message----- From: David Allan I > [mailto:david.i.allan@ericsson.com] Sent: Wednesday, November 13, > 2013 11:45 PM To: Hongyu Li (Julio); nsc@ietf.org Subject: RE: [nsc] > FW: re classification & branching, was: Current Proposed SFC charter > > HI Hongyu: > > I think we will have scenarios where a service function appears in > more than one chain, as would be the case, for example, if some flows > could dynamically bypass DPI but still needed to transit a common set > of stateful service functions... > > Once you postulate a service function instance appearing in more than > one chain, it seems artificially restrictive not to permit such a > function to also implement branching, all the control structures > would already be there. > > Rgds Dave > > -----Original Message----- From: Hongyu Li (Julio) > [mailto:hongyu.li@huawei.com] Sent: Wednesday, November 13, 2013 2:12 > AM To: David Allan I; nsc@ietf.org Subject: RE: [nsc] FW: re > classification & branching, was: Current Proposed SFC charter > > May I suggest summary of my views here: > > 1. Branch is a sort of use case or scenario, while reclassification > is a way to solve the problem. 2. Service Functions should be > decoupled with the chain itself. Meaning, a SF shall not *directly* > impact the forwarding of packets in a chain. Branching should be > performed by chain forwarding nodes, possibly under control of a > control node. The reason for this is in NFV world, service functions > may come from a third party, while chain is provided by the > infrastructure of the network. There must be a cushion avoiding a > service function operating infrastructure directly. 3. > (Re)classification is based on info in a packet. This is very > general. Such info could be L2~L7 derived from a user's packet, as > well as some info like metadata in a SFC header. As classification is > out of scope of SFC, we don't have to provide too much details of how > to do classification. 4. Chain segments stitching is relatively a > easy way for branching. Compared with chains and subchains, which may > require a more complex header and forwarding capabilities. My two > cents. Hongyu > > -----Original Message----- From: nsc-bounces@ietf.org > [mailto:nsc-bounces@ietf.org] On Behalf Of David Allan I Sent: > Wednesday, November 13, 2013 3:04 AM To: nsc@ietf.org Subject: [nsc] > FW: re classification & branching, was: Current Proposed SFC charter > > Hi: (resend with recipient list cleaned up) > > I agree we are discussing multiple concepts, classification and > flow-subsetting. Perhaps more ;-) > > Defining a flow subset can be a result of classification, but it is > not the exclusive mechanism. Branching is a mechanism by which flow > subsets are exposed and mapped to a set of subchains such that it can > be identified in the dataplane... > > That's the view from here Dave > > -----Original Message----- From: nsc-bounces@ietf.org > [mailto:nsc-bounces@ietf.org] On Behalf Of David Lake (dlake) Sent: > Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); > Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; > Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee > Subject: Re: [nsc] Current Proposed SFC charter > > Understood - maybe just a little localised warming of the sea then ? > But I still think we need to consider where and how policy is > defined/set even for the single-domain instance. > > I don't think we can assume that any L1-3 device will be able to > determine much useful information from the data-plane. > > -----Original Message----- From: Jim Guichard (jguichar) Sent: 12 > November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra > Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: > Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] > Current Proposed SFC charter > > As discussed during the BOF our initial work is single administrative > domain for some of the very reasons you point out. We need to keep > focused without trying to boil the ocean right off the bat. > > On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >> Exactly. But how can network-components "terminate" an application >> ???? >> >> I think we need a good understanding of a recursive policy >> mechanism (recursive because a user-land application will ride with >> a specific policy across potentially different sets of carrier >> policies). >> >> I hate to bring this up now, but we also need to think about this >> multi-domain issue - if I set a policy as a user, chances are I >> will be crossing several domain boundaries. Are we expecting the >> service headers to define the service chaining for the duration of >> the entire flow across all domains, or just across a single one ? >> >> In which case, do I have to re-set policy as I traverse domains >> and where does that policy get set ? It would be much better to >> set policy once based on L5-7 needs, and have that instantiated >> across the multiple domains. >> >> Again, this appears to be outside the scope of SFC, but pretty >> relevant to how it would operate in the real world. >> >> David >> >> -----Original Message----- From: Kevin J Ma >> [mailto:kevin.ma@azukisystems.com] Sent: 12 November 2013 10:27 To: >> David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra >> Majee Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or >>> a reasonably broad-brushed classification (really traffic >>> steering based on what we can see at ingress) is going to be >>> useful - is THAT what we're aiming for here ? >> >> I would certainly hope not, but that has been my concern as well. >> Application layer termination and re-classification seems a must? >> >> -- Kevin J. Ma >> >>> -----Original Message----- From: David Lake (dlake) >>> [mailto:dlake@cisco.com] Sent: Tuesday, November 12, 2013 1:00 >>> PM To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda >>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; >>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong >>> mapping between Policy and the inserted Service Header(s), we >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as >>> per the IETF Technical Plenary ?:-) ) what is our ability to >>> determine policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or >>> a reasonably broad-brushed classification (really traffic >>> steering based on what we can see at ingress) is going to be >>> useful - is THAT what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- From: nsc-bounces@ietf.org >>> [mailto:nsc-bounces@ietf.org] On Behalf Of Surendra Kumar >>> (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J >>> Ma; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; >>> nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed >>> SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have >>> to redefine it - it's been around for all the time middle boxes >>> have been or for that matter the L2/L3 devices. All we are >>> talking about is the applicability of the classification to >>> branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope >>> of SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>> wrote: >>> >>>> I think the lack of definition of "reclassification" may be >>>> causing >>> some >>>> misunderstandings here. A branch would occur for some >>>> policy-driven reason based on the behavior and conclusions of >>>> the service function, itself. The graph would represent the >>>> fact that there is a branch point, but the service function, >>>> itself, being aware that it is a branching point would contain >>>> the policy and logic to decide on which branch to take. >>>> Specifying that policy and logic is out of scope, >>> IMO. >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- From: Kevin J Ma >>>> [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, November 12, >>>> 2013 10:49 AM To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>>> >>>> Hi Linda, >>>> >>>> Are you saying that a branching point is "never" a >>>> reclassification point, or are you saying that a branching >>>> point "does not have to be" a reclassification point? >>>> >>>> I think this is an important distinction that needs to be >>>> clarified. If branching is never reclassification, then the >>>> meaning of a chain is different than I originally inferred. If >>>> the chain is a tree with other "branching" points in it, then >>>> that limits the scope of the problem statement goals. >>>> >>>> While this could be a degenerate case, and any implementation >>>> could define bad service chains, is it the intent of SFC to >>>> only look at the simpler packet-level classification cases, or >>>> is it the intent to consider the case where a branching point >>>> is viewed as a re-classification point? >>>> >>>> thanx. >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- From: Linda Dunbar >>>>> [mailto:linda.dunbar@huawei.com] Sent: Tuesday, November 12, >>>>> 2013 10:34 AM To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC >>>>> charter >>>>> >>>>> Ron, >>>>> >>>>> First, want to make it clear that "branching" != >>>>> reclassification, agree? >>>>> >>>>> Second, the representation of branching (or service graph) >>>>> can be in a form of logic on a service function. Some service >>>>> functions, especially L7 based, can use value in a Database >>>>> to determine what is the next service function. >>>>> >>>>> Linda >>>>> >>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>> Tuesday, November 12, 2013 8:16 AM To: Hongyu Li (Julio); >>>>>> Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar >>>>>> (smkumar); Sumandra Majee Subject: Re: [nsc] Current >>>>>> Proposed SFC charter >>>>>> >>>>>> Hongyu, >>>>>> >>>>>> I agree completely that re-classification is not limited to >>>>>> DPI. >>>>>> >>>>>> And also, that an area for us to explore as a group is how >>>>>> to >>>>> represent >>>>>> the service graph. Do we want to represent it as a proper >>>>>> graph >>> with >>>>>> an adjacency list or other representational model? Or, do >>>>>> we want >>> to >>>>>> represent it as a set of linear segments and if so, how are >>>>>> the segments connected into a graph? Other ideas? >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Hongyu Li >>>>>> (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron >>>>>> Parker; Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; >>>>>> Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] >>>>>> Current Proposed SFC charter >>>>>> >>>>>> Branching/forking is a very interesting topic of SFC. About >>>>>> the re- classification point, probably we shall not limit >>>>>> it to DPI. It is also possible that packets go to different >>>>>> branches after been processed by a certain service >>>>>> function, decision of which branches to go is made based on >>>>>> the result of service function's process, i.e. not just re- >>>>>> classification by DPI. >>>>>> >>>>>> Hongyu >>>>>> >>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>> Tuesday, November 12, 2013 7:45 PM To: Kevin J Ma Cc: >>>>>> Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC >>>>>> charter >>>>>> >>>>>> Hi, Kevin >>>>>> >>>>>> You ask a great question about branching the graph. The >>>>>> details around how to convey the selection of the >>>>>> subtree/subgraph are still >>>>> to be >>>>>> defined. Is it one chain id for the whole graph? Does >>>>>> each >>> branch >>>>>> have its own chain id? Some combination? >>>>>> >>>>>> Ron >>>>>> >>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>> wrote: >>>>>> >>>>>>>> Yes, reclassification can change the service path and >>>>>>>> re-classification may happen at any node along a >>>>>>>> service path. >>>>>>> >>>>>>> Just to expand on that, going back to the original >>>>>>> question about service header encapsulation, is it >>>>>>> intended that a chain that is re-classified will get a >>>>>>> new chain ID which fully describes a chain that is a >>>>>>> superset of the original chain ID, prior to DPI-based >>>>>>> re-classification? (assuming the goal is "a single chain >>>>>>> ID that is commonly understood along the entire service >>> chain" >>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>>>>>> >>>>>>> ) >>>>>>> >>>>>>> And the applicable subset of the permutative list of >>>>>>> service paths would be configured at each appropriate >>>>>>> service node? e.g., ID 1: NAT + firewall + DPI ID 2: NAT >>>>>>> + firewall + DPI + AV ID 3: NAT + firewall + DPI + AV + >>>>>>> NAT ID 4: NAT + firewall + DPI + NAT ID 5: NAT + firewall >>>>>>> + DPI + AV + LB ID 6: NAT + firewall + DPI + LB ID 7: NAT >>>>>>> + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI >>>>>>> + CACHE ID 9: NAT + firewall + DPI + optimizer + LB ID >>>>>>> 10: NAT + firewall + DPI + optimizer + LB + CACHE ID 11: >>>>>>> NAT + firewall + DPI + optimizer + CACHE Would every flow >>>>>>> then be initially classified as ID 1, but eventually get >>>>>>> re- >>>>>> classified >>>>>>> to ID 2-11, after the DPI phase? >>>>>>> >>>>>>> thanx. >>>>>>> >>>>>>> -- Kevin J. Ma >>>>>>> >>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>> November 12, 2013 1:01 AM To: Kevin J Ma; Ron Parker; >>>>>>>> Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: >>>>>>>> Re: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>> >>>>> wrote: >>>>>>>>> >>>>>>>>> Hi Surendra, >>>>>>>>> >>>>>>>>> Classification may be out of scope, but the level of >>>>>>>>> service that >>>>>> is >>>>>>>>> applicable is dependent upon the level of >>>>>>>>> classification that can >>>>>> be >>>>>>>>> performed. An assumption of packet level >>>>>>>>> encapsulation has >>>>>>>> implications >>>>>>>>> on the level of classification being performed? If >>>>>>>>> the stated >>>>>> goals >>>>>>>> are >>>>>>>>> for firewall and load balancer functionality, then >>>>>>>>> the application >>>>>>>> level >>>>>>>>> nature of those functions needs to be taken into >>>>>>>>> account? If, on the other hand, the service function >>>>>>>>> scope is limited due to limitations in >>>>>>>>> classification, that would be and important piece of >>>>>> information? >>>>>>>>> >>>>>>>>> Wrt section 4.4 of >>>>>>>>> draft-liu-service-chaining-use-cases the fork points >>>>>>>>> of the service paths seem like re-classification >>> points? >>>>>>>>> Is that the interpretation from the architecture >>>>>>>>> perspective? Or is the service function chain >>>>>>>>> classification exclusive of DPI >>>>>> functionality? >>>>>>>> I have not fully read that draft yet. But in >>>>>>>> general, as described in the arch draft, the collection >>>>>>>> of services form a graph, segments of which are service >>>>>>>> paths. Yes, reclassification can >>>>>> change >>>>>>>> the service path and re-classification may happen at >>>>>>>> any node along >>>>>> a service path. >>>>>>>> >>>>>>>> Surendra. >>>>>>>>> >>>>>>>>> thanx. >>>>>>>>> >>>>>>>>> -- Kevin J. Ma >>>>>>>>> >>>>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>>>> November 12, 2013 12:08 AM To: Kevin J Ma; Ron >>>>>>>>>> Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current Proposed >>>>>>>>>> SFC charter >>>>>>>>>> >>>>>>>>>> Kevin, >>>>>>>>>> >>>>>>>>>> Classification mechanism is outside the scope of >>>>>>>>>> SFC. It can be based >>>>>>>> on >>>>>>>>>> the packet or information not in the >>>>>>>>>> packet(environmental attributes >>>>>>>> for >>>>>>>>>> instance) or a combination thereof. What is >>>>>>>>>> important is that such classification aids in >>>>>>>>>> traffic selection and service path identification. >>>>>>>>>> It is no different from a policy in this regard >>>>>>>>>> except that the policy now specifies the service >>>>>>>>>> path. Further, classification is not limited to the >>>>>>>>>> network elements but the service functions as well. >>>>>>>>>> Some of this is described in the >>>>>>>> architecture >>>>>>>>>> drafts as well - >>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Surendra. >>>>>>>>>> >>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>> >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Ron, >>>>>>>>>>> >>>>>>>>>>> I was unable to make the SFC BoF due to a >>>>>>>>>>> conflict with CDNI, but I had a similar question >>>>>>>>>>> wrt bullet 11 in section 2 of the >>>>>> problem >>>>>>>>>>> statement: >>>>>>>>>>> >>>>>>>>>>> 11. Per-Service (re)Classification: >>>>>>>>>>> Classification occurs at >>>>>> each >>>>>>>>>>> service, independent from previously applied >>>>>>>>>>> service >>>>>>>>>> functions. >>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>> resources >>>>>> per >>>>>>>>>>> service. More importantly, the classification >>>>>> functionality >>>>>>>>>>> often differs per service function and service >>>>>>>>>>> function >>>>>>>> cannot >>>>>>>>>>> leverage the results from other deployed network >>>>>>>>>>> or >>>>>> service. >>>>>>>>>>> >>>>>>>>>>> as it relates to section 5.2 of the framework >>>>>>>>>>> document: >>>>>>>>>>> >>>>>>>>>>> The SFC Classifier classifies packets based on >>>>>>>>>>> (some of) the >>>>>>>>>> contents >>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>> packets based on >>>>>>>>>> the >>>>>>>>>>> possible combination of one or more header >>>>>>>>>>> fields, such as >>>>>> source >>>>>>>>>>> address, destination address, DS field, protocol >>>>>>>>>>> ID, source >>>>>> port >>>>>>>>>> and >>>>>>>>>>> destination port numbers, and any other >>>>>>>>>>> information. >>>>>>>>>>> >>>>>>>>>>> A packet-based classifier as described in the >>>>>>>>>>> framework document >>>>>>>>>> would >>>>>>>>>>> seem to be limited in what it can classify? The >>>>>>>>>>> service function identifier lookup does not seem >>>>>>>>>>> to be a significant optimization >>>>>>>> over >>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be >>>>>>>>>>> some missing >>>>>>>> detail >>>>>>>>>>> wrt how classification information is determined >>>>>>>>>>> and reused? >>>>>>>>>>> >>>>>>>>>>> When thinking about higher level services, e.g., >>>>>>>>>>> HTTP and TLS >>>>>>>>>> encrypted >>>>>>>>>>> flows, a packet-based classifier seems >>>>>>>>>>> inadequate? I was also >>>>>>>>>> wondering >>>>>>>>>>> how independent HLS segment requests might be >>>>>>>>>>> classified and >>>>>>>>>> associated? >>>>>>>>>>> Were these types of use cases discussed in the >>>>>>>>>>> BoF? >>>>>>>>>>> >>>>>>>>>>> thanx. >>>>>>>>>>> >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>> Of >>>>>>>>>>>> Ron Parker Sent: Monday, November 11, 2013 >>>>>>>>>>>> 10:16 PM To: Sumandra Majee; Thomas Narten; >>>>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current >>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Sumandra, >>>>>>>>>>>> >>>>>>>>>>>> As was discussed in Vancouver, there are >>>>>>>>>>>> already many existing ways >>>>>>>>>> to >>>>>>>>>>>> accomplish service chaining. But none of >>>>>>>>>>>> them provide a >>>>>>>>>> sufficient >>>>>>>>>>>> combination of interoperability, flexibility, >>>>>>>>>>>> and >>> resiliency. >>>>>> A >>>>>>>>>> single >>>>>>>>>>>> service chain encapsulation will go a long way >>>>>>>>>>>> to ensuring these >>>>>>>>>> goals. >>>>>>>>>>>> It may not be the absolutely most efficient >>>>>>>>>>>> approach for every >>>>>>>>>> single >>>>>>>>>>>> network topology and every single use case, but >>>>>>>>>>>> its ubiquitous >>>>>>>> nature >>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>> >>>>>>>>>>>> Ron >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>> 11, 2013 10:10 PM To: Ron Parker; Thomas >>>>>>>>>>>> Narten; nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Ron, >>>>>>>>>>>> >>>>>>>>>>>> Absolutely, that was an example of one type of >>>>>>>>>>>> derivation. However >>>>>>>>>> this >>>>>>>>>>>> could be augmented with classification result, >>>>>>>>>>>> again one more >>>>>>>>>> example. >>>>>>>>>>>> >>>>>>>>>>>>>> All flows from the same source IP do not >>>>>>>>>>>>>> necessarily follow >>>>>> the >>>>>>>>>> same >>>>>>>>>>>> chain. Correct. It is also not necessary that >>>>>>>>>>>> all transaction of the same >>>>>>>>>> flow >>>>>>>>>>>> follow the same chain either. So why stop at >>>>>>>>>>>> flow itself. >>>>>>>>>>>> >>>>>>>>>>>> Again the point here is that do we always need >>>>>>>>>>>> SFC header or >>>>> Not. >>>>>>>>>>>> >>>>>>>>>>>> Sumandra >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>> Monday, November 11, 2013 7:02 PM To: Sumandra >>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Sumandra, >>>>>>>>>>>> >>>>>>>>>>>> The intention of service function chaining is >>>>>>>>>>>> to allow for operation >>>>>>>>>> at >>>>>>>>>>>> the fully qualified flow level, or even finer >>>>>>>>>>>> grained at the >>>>>>>>>> transaction >>>>>>>>>>>> level (this is an implementation matter for the >>>>>>>>>>>> PDP). >>> All >>>>>> flows >>>>>>>>>> from >>>>>>>>>>>> the same source IP do not necessarily follow >>>>>>>>>>>> the same chain. >>>>>>>> Source >>>>>>>>>>>> IP, therefore, does not identify the chain ID. >>>>>>>>>>>> Another >>>>> intention >>>>>> of >>>>>>>>>>>> service function chaining is to operate over >>>>>>>>>>>> any network >>>>>> topology >>>>>>>> and >>>>>>>>>>>> not be limited to a single LAN. Thus, while >>>>>>>>>>>> VLAN may be part >>> of >>>>>> the >>>>>>>>>>>> transport, it does not adequately identify the >>>>>>>>>>>> service chain, >>>>>>>> either. >>>>>>>>>>>> >>>>>>>>>>>> Ron >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>> 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; >>>>>>>>>>>> nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Ron, >>>>>>>>>>>> >>>>>>>>>>>> The service header is meant to carry the >>>>>>>>>>>> context which can >>>>>> *also* >>>>>>>>>>>> be derived (for example use source ip and vlan >>>>>>>>>>>> to identify chainID and position) or >>>>>>>>>>>> encapsulated as part of another tunnel header. >>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>> Monday, November 11, 2013 4:36 PM To: Sumandra >>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Sumandra, >>>>>>>>>>>> >>>>>>>>>>>> As I understand it, an SFC packet traversing >>>>>>>>>>>> from PDP to SF or from >>>>>>>>>> SF >>>>>>>>>>>> to SF will look like: >>>>>>>>>>>> >>>>>>>>>>>> +------------------------+ | "transport" >>>>>>>>>>>> | +------------------------+ | service >>>>>>>>>>>> header | +------------------------+ | >>>>>>>>>>>> original IP header | >>>>>>>>>>>> +------------------------+ | >>>>>>>>>>>> | original IP | payload >>>>>> | >>>>>>>>>>>> | | >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>> >>>>>>>>>>>> Where service header contains, at a minimum, >>>>>>>>>>>> enough information to >>>>>>>>>> allow >>>>>>>>>>>> the packet to be propagated along the full >>>>>>>>>>>> length of the chain, and optionally, other >>>>>>>>>>>> metadata that enhances the operation of >>>>>> one >>>>>>>>>>>> or >>>>>>>> more >>>>>>>>>>>> service functions. >>>>>>>>>>>> >>>>>>>>>>>> And where "transport" could conceivably be any >>>>>>>>>>>> of, but not limited >>>>>>>>>> to: >>>>>>>>>>>> >>>>>>>>>>>> * Ethernet * Ethernet + LLC2 * Ethernet + MPLS >>>>>>>>>>>> * Ethernet + IP + GRE * Ethernet + IP +UDP >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Also, "original" in the diagram above is not >>>>>>>>>>>> meant to imply immutability, but rather to >>>>>>>>>>>> specify the packet that is >>>>>> propagated >>>>>>>>>>>> from preceding entity to succeeding entity, >>>>>>>>>>>> prior to encapsulation. >>>>>>>>>>>> >>>>>>>>>>>> Ron >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>> Of >>>>>>>>>>>> Sumandra Majee Sent: Monday, November 11, 2013 >>>>>>>>>>>> 6:46 PM To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC >>>>>>>>>>>> charter >>>>>>>>>>>> >>>>>>>>>>>> Generic Service Function Chaining >>>>>>>>>>>> Encapsulation: A document >>>>> will >>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>> encapsulation >>>>>>>> format >>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>> the service function >>>>>>>>>> path, >>>>>>>>>>>> and for communicating context information >>>>>>>>>>>> between nodes >>> that >>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>> that the >>>>>>>>>> encapsulation >>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>> and the service >>>>>>>>>> that >>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>> encapsulation may be >>>>>> used >>>>>>>> on >>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>> encapsulation will apply for the >>>>>>>> construction >>>>>>>>>> of >>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>> service. >>>>>>>>>>>> >>>>>>>>>>>> [SM] What does it mean by a single >>>>>>>>>>>> service-level encapsulation, >>>>>> a >>>>>>>>>> new >>>>>>>>>>>> encapsulation format or an ability to select >>>>>>>>>>>> one encapsulation format that >>>>>>>>>> fits >>>>>>>>>>>> the need for a given service chain? The ability >>>>>>>>>>>> to select a specific encapsulation would be >>>>>>>> a >>>>>>>>>>>> management plane decision. There are quite a >>>>>>>>>>>> few existing encapsulation methods that >>>>>>>>>> can >>>>>>>>>>>> possibly be reused to provide context >>>>>>>>>>>> information between service nodes. I have >>>>>> seen >>>>>>>>>>>> mention of GRE, for HTTP based applications >>>>>>>>>>>> contexts are transferred via headers. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>> Of >>>>>>>>>>>> Thomas Narten Sent: Wednesday, November 06, >>>>>>>>>>>> 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] >>>>>>>>>>>> Current Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Hi. >>>>>>>>>>>> >>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>> >>>>>>>>>>>> It contains the revised management text as well >>>>>>>>>>>> as updated >>>>>>>>>> milestones. >>>>>>>>>>>> >>>>>>>>>>>> All known issues have been addressed. If there >>>>>>>>>>>> are any remaining >>>>>>>>>> issues, >>>>>>>>>>>> please speak up! >>>>>>>>>>>> >>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>> >>>>>>>>>>>> Networks, servers, storage technologies, and >>>>>>>>>>>> applications, have all undergone significant >>>>>>>>>>>> change in recent years with the introduction >>>>>>>> of >>>>>>>>>>>> virtualization, network overlays, and >>>>>>>>>>>> orchestration. Service >>>>>>>> delivery >>>>>>>>>> is >>>>>>>>>>>> currently both a technical and organizational >>>>>>>>>>>> challenge that >>>>>>>> involves >>>>>>>>>>>> significant modification to the network >>>>>>>>>>>> configuration. Services are typically >>>>>>>>>>>> implemented by the ordered combination of a >>>>>>>>>>>> number of service functions that are deployed >>>>>>>>>>>> at different points within >>>>>>>> the >>>>>>>>>>>> network. Today, a common deployment model has >>>>>>>>>>>> service functions physically inserted on the >>>>>>>>>>>> data forwarding path between communicating >>>>>>>>>>>> peers. >>>>>>>>>> Going >>>>>>>>>>>> forward, however, there is a desire to move to >>>>>>>>>>>> a different model, >>>>>>>>>> where >>>>>>>>>>>> service functions are not required to reside on >>>>>>>>>>>> the default data >>>>>>>> path >>>>>>>>>>>> and traffic is instead steered through >>>>>>>>>>>> services, wherever they are >>>>>>>>>> deployed. >>>>>>>>>>>> >>>>>>>>>>>> For a given service, the abstracted view of the >>>>>>>>>>>> required service functions and the order in >>>>>>>>>>>> which they are to be applied is >>>>>> called >>>>>>>>>>>> a Service Function Chain (SFC). Since a given >>>>>>>>>>>> service function may be available on more than >>>>>>>>>>>> one node within a network, a Service Function >>>>>>>>>>>> Chain is instantiated >>>>>>>>>> via >>>>>>>>>>>> the selection of specific service function >>>>>>>>>>>> instances and the network nodes on which they >>>>>>>>>>>> are provided, thereby forming a service >>>>>>>>>>>> topology: this is called a Service Function >>>>>>>>>>>> Path. The service functions >>>>>> may >>>>>>>>>>>> be applied at a specific layer within the >>>>>>>>>>>> network protocol stack >>>>>>>>>> (network >>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>> >>>>>>>>>>>> The Service Function Chaining (SFC) working >>>>>>>>>>>> group will develop new approaches to service >>>>>>>>>>>> delivery and deployment. It will produce a >>>>>>>>>>>> framework for service function chaining that >>>>>>>>>>>> includes the necessary protocols >>>>>>>>>> or >>>>>>>>>>>> protocol extensions to convey the service path >>>>>>>>>>>> and service path information to nodes that >>>>>>>>>>>> implement service functions, as well >>>>>> as >>>>>>>>>>>> mechanisms for steering traffic through service >>>>>>>>>>>> functions. The >>>>>>>>>> working >>>>>>>>>>>> group will also examine what information needs >>>>>>>>>>>> to be gathered from >>>>>>>>>> the >>>>>>>>>>>> network and service functions in support of >>>>>>>>>>>> service function >>>>>>>> chaining >>>>>>>>>>>> and how that information may be made available >>>>>>>>>>>> to nodes that implement >>>>>>>>>> the >>>>>>>>>>>> service functions. >>>>>>>>>>>> >>>>>>>>>>>> Specifically, the SFC WG is chartered to >>>>>>>>>>>> deliver the >>> following: >>>>>>>>>>>> >>>>>>>>>>>> 1) Problem Statement: This document will >>>>>>>>>>>> provide a summary of >>>>>> the >>>>>>>>>>>> problem space to be addressed by the WG >>>>>>>>>>>> including example >>>>>> high- >>>>>>>>>>>> level use cases. Additionally, the WG will >>>>>>>>>>>> normalize >>>>>>>> nomenclature >>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>> >>>>>>>>>>>> 2) Architecture: This document will provide a >>>>>>>>>>>> description of >>>>> the >>>>>>>>>>>> architectural building blocks and their >>>>>>>>>>>> relationships >>>>>> including >>>>>>>>>>>> interconnection, placement of capabilities, >>>>>>>>>>>> management, diagnostics, design analysis, and >>>>>>>>>>>> security models, as well >>>>> as >>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>> >>>>>>>>>>>> 3) Generic Service Function Chaining >>>>>>>>>>>> Encapsulation: A document >>>>>> will >>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>> encapsulation >>>>>>>> format >>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>> the service function >>>>>>>>>> path, >>>>>>>>>>>> and for communicating context information >>>>>>>>>>>> between nodes >>> that >>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>> that the >>>>>>>>>> encapsulation >>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>> and the service >>>>>>>>>> that >>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>> encapsulation may be >>>>>> used >>>>>>>> on >>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>> encapsulation will apply for the >>>>>>>> construction >>>>>>>>>> of >>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>> service. >>>>>>>>>>>> >>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents >>>>>>>>>>>> will be >>>>>> developed to >>>>>>>>>>>> describe requirements and protocols necessary >>>>>>>>>>>> to convey >>>>>>>>>> information >>>>>>>>>>>> to service function implementation points. >>>>>>>>>>>> Where possible, >>>>>>>>>> existing >>>>>>>>>>>> IETF protocols will be used and extended. All >>>>>>>>>>>> protocol >>>>>>>> extensions >>>>>>>>>>>> work should be carried out in the working >>>>>>>>>>>> groups responsible for >>>>>>>>>> the >>>>>>>>>>>> protocols being modified in coordination with >>>>>>>>>>>> this working >>>>>>>> group, >>>>>>>>>>>> but may be done in this working group after >>>>>>>>>>>> agreement with all >>>>>> the >>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>> >>>>>>>>>>>> 5) Manageability: Work on the management and >>>>>>>>>>>> configuration of >>>>>>>> service >>>>>>>>>>>> functions in support of SFC components will >>>>>>>>>>>> certainly be >>>>>> needed, >>>>>>>>>>>> but first needs to be better understood and >>>>>>>>>>>> scoped. >>>>>>>>>>>> >>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>> >>>>>>>>>>>> Apr 2014 Submit to IESG Informational >>>>>>>>>>>> document(s) defining the >>>>>>>>>> problem >>>>>>>>>>>> statement and core use cases for Service >>>>>>>>>>>> Function Chaining >>>>>>>>>>>> >>>>>>>>>>>> May 2014 Consult with OPS Area on possible >>>>>>>>>>>> charter modifications for management and >>>>>>>>>>>> configuration of SFC components >>>>>>>>>>>> >>>>>>>>>>>> Jan 2015 Submit to IESG Informational document >>>>>>>>>>>> defining the >>>>>>>>>> architecture >>>>>>>>>>>> for SFC >>>>>>>>>>>> >>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a >>>>>>>>>>>> generic service function chaining encapsulation >>>>>>>>>>>> protocol >>>>>>>>>>>> >>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track >>>>>>>>>>>> document specifying the >>>>>>>>>> generic >>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thomas >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> >>>>>> _______________________________________________ nsc mailing >>>>>> list nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ nsc mailing >>>>>> list nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ nsc mailing >>>>>> list nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ nsc mailing list > nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list > nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list > nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Thu Nov 14 04:49:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0A321E8085 for ; Thu, 14 Nov 2013 04:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oUlOfx0ZcZg for ; Thu, 14 Nov 2013 04:49:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0138A21E81A3 for ; Thu, 14 Nov 2013 04:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=41405; q=dns/txt; s=iport; t=1384433370; x=1385642970; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NYynKGd5g3P336xq87LunZWAoD/rQYkXE9KKv5IZkts=; b=Fv29FF1JyfEMD0c/s6dz8XLH5jnul1g4HR/QwkAdSRA4HBjTq1HxqAu2 JuaaF032jSSZ9NMr8b178ohbksk/p4cMRb6DguFpcaOaTNif/A9QUF8/5 7Mg44xTDA9A9tGdsw0RfbrD4yHpDedieAfT0NebR8Sfne8t9+/nisDprZ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAITGhFKtJV2Z/2dsb2JhbABQCoMHOFO/IIEhFnSCJQEBAQQBAQEXAR8rAgcEEwYBCBEBAwEBARUJCS4LFAMFAQgCBAEJCQmHeA3AI44cBAEFBoEILQUCBASEJwOULoNikgyDKIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,699,1378857600"; d="scan'208";a="284805946" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 14 Nov 2013 12:49:27 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAECnReD018690 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 12:49:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 06:49:27 -0600 From: "Jim Guichard (jguichar)" To: David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAAQ1gAA== Date: Thu, 14 Nov 2013 12:49:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <196FBD82399C994985CA0B05D105C6BB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 12:49:38 -0000 Hi Dave, I am not sure I am catching your point. There is no doubt that a service function may appear in more than one chain; it must as otherwise you would be spinning up service function instances that could only ever be used by traffic flowing through a single service chain. Simple example is a chain a-b-c; I see no reason why you could not also build a chain d-b-e where b is the same service function instance in both chains. Branching seems to me to be independent of how many service function instances you have for a given service function. On 11/13/13 10:45 AM, "David Allan I" wrote: >HI Hongyu: > >I think we will have scenarios where a service function appears in more >than one chain, as would be the case, for example, if some flows could >dynamically bypass DPI but still needed to transit a common set of >stateful service functions... > >Once you postulate a service function instance appearing in more than one >chain, it seems artificially restrictive not to permit such a function to >also implement branching, all the control structures would already be >there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is a >way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets in a >chain. Branching should be performed by chain forwarding nodes, possibly >under control of a control node. The reason for this is in NFV world, >service functions may come from a third party, while chain is provided by >the infrastructure of the network. There must be a cushion avoiding a >service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user's >packet, as well as some info like metadata in a SFC header. As >classification is out of scope of SFC, we don't have to provide too much >details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not >the exclusive mechanism. Branching is a mechanism by which flow subsets >are exposed and mapped to a set of subchains such that it can be >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is defined/set >even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; >Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative >domain for some of the very reasons you point out. We need to keep >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism >>(recursive because a user-land application will ride with a specific >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this >>multi-domain issue - if I set a policy as a user, chances are I will be >>crossing several domain boundaries. Are we expecting the service >>headers to define the service chaining for the duration of the entire >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty relevant >>to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong mapping >>> between Policy and the inserted Service Header(s), we run-the-risk of >>> limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per >>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to >>> redefine it - it's been around for all the time middle boxes have >>> been or for that matter the L2/L3 devices. All we are talking about >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a >>> > chain is different than I originally inferred. If the chain is a >>> > tree with other "branching" points in it, then that limits the >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation >>> > could define bad service chains, is it the intent of SFC to only >>> > look at the simpler packet-level classification cases, or is it the >>> > intent to consider the case where a branching point is viewed as a >>> > re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D reclassification, >>> >>agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be >>> >> in a form of logic on a service function. Some service functions, >>> >> especially L7 based, can use value in a Database to determine what >>> >> is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after >>> >> > been processed by a certain service function, decision of which >>> >> > branches to go is made based on the result of service function's >>> >> > process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The details >>> >> > around how to convey the selection of the subtree/subgraph are >>> >> > still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question >>> >> > > about service header encapsulation, is it intended that a >>> >> > > chain that is re-classified will get a new chain ID which >>> >> > > fully describes a chain that is a superset of the original >>> >> > > chain ID, prior to DPI-based re-classification? (assuming the >>> >> > > goal is "a single chain ID that is commonly understood along >>> >> > > the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>> >> > > every flow then be initially classified as ID 1, but >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of service >>> >> > >>> that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is limited >>> >> > >>> due to limitations in classification, that would be and >>> >> > >>> important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>> >> > >>> fork points of the service paths seem like re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive of >>> >> > >>> DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general, as >>> >> > >> described in the arch draft, the collection of services form >>> >> > >> a graph, segments of which are service paths. Yes, >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any node >>> >> > >> along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is >>> >> > >>>> that such classification aids in traffic selection and >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except that >>> >> > >>>> the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network >>> >> > >>>> elements but the service functions as well. Some of this is >>> >> > >>>> described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some of) >>> >> > >>>>> the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies packets >>> >> > >>>>> based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID, >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service >>> >> > >>>>> function identifier lookup does not seem to be a >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach for >>> >> > >>>>>> every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction of >>> >> > >>>>>> the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC header >>> >> > >>>>>> or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the >>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>> >> > >>>>>> imply immutability, but rather to specify the packet that >>> >> > >>>>>> is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and >>> >> > >>>>>> applications, have all undergone significant change in >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered >>> >> > >>>>>> combination of a number of service functions that are >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service >>> >> > >>>>>> functions physically inserted on the data forwarding path >>> >> > >>>>>> between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required >>> >> > >>>>>> service functions and the order in which they are to be >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service >>> >> > >>>>>> function may be available on more than one node within a >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and >>> >> > >>>>>> the network nodes on which they are provided, thereby >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function chaining=20 >>> >> > >>>>>> that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a description=20 >>> >> > >>>>>> of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement with=20 >>> >> > >>>>>> all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Nov 14 05:00:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D68021E8087 for ; Thu, 14 Nov 2013 05:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NulPSqtH2VDh for ; Thu, 14 Nov 2013 05:00:27 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 594CE21E8085 for ; Thu, 14 Nov 2013 05:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40945; q=dns/txt; s=iport; t=1384434027; x=1385643627; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=oDWg80yCzFOwOE6sSB7MIeg2UKUk0FtK0IFFoCcCDrA=; b=PCCxMjzaCKD67RINbVjPKwrPUjJaeJhyMU96skdXwufT6gIIX14x4iOh 54JAzTURX6JWAzBiuMC/xAddst/T69K8Jfiscg7fFqoj9q1mGHWAvJrPp dDZrmvIiZMz05XkLYAKxm/zQL6q+OxkwSFZRcJU0Z287DgEYueLjEB6Ve 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FANnIhFKtJV2d/2dsb2JhbABQCoMHOFO/IIEhFnSCJQEBAQQBAQEXAR8rAgcEEwYBCBEBAwEBARUJCS4LFAMFAQgCBAEJCQmHeA3ALI4WBgQBBQaBCC0FAgQEhCcDlC6DYpIMgyiBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,699,1378857600"; d="scan'208";a="284750220" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 14 Nov 2013 13:00:25 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAED0PYl019016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 13:00:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 07:00:25 -0600 From: "Jim Guichard (jguichar)" To: "Joel M. Halpern" , "Hongyu Li (Julio)" , David Allan I , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAALQWgIAArE2A//+wCwA= Date: Thu, 14 Nov 2013 13:00:24 +0000 Message-ID: In-Reply-To: <5284C627.2070906@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <35F2E54B9B0B3343820A6875B5A4778F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 13:00:32 -0000 Completely agree Joel although the service function *may* directly update metadata context and service path identification (which effectively forces a branching operation). On 11/14/13 7:46 AM, "Joel M. Halpern" wrote: >You assert in the below text that "service functions should be able to >compose a chain arbitrarily." >That does not seem to follow. >The operator defines the service chains they want. They provision those >service chains. >Thus, I would expect that the job of a service function is to deliver >its specific service. In general, it should not need to know or care >about the chains in which it is participating. > >Yours, >Joel M. Halpern > >On 11/13/13 9:29 PM, Hongyu Li (Julio) wrote: >> Hi Dave, >> >> Your inferred restriction may be not always true. In general, service >> functions should be able to compose a chain arbitrarily. Particularly >> for branching, as I suggested in previous email, service function >> shall not directly impact packet forwarding. This precludes the >> restriction you mentioned. Forwarding plane can decide whether a >> branching action should be taken by reclassification or not per >> service chain. >> >> Does this make sense? >> >> Hongyu >> >> -----Original Message----- From: David Allan I >> [mailto:david.i.allan@ericsson.com] Sent: Wednesday, November 13, >> 2013 11:45 PM To: Hongyu Li (Julio); nsc@ietf.org Subject: RE: [nsc] >> FW: re classification & branching, was: Current Proposed SFC charter >> >> HI Hongyu: >> >> I think we will have scenarios where a service function appears in >> more than one chain, as would be the case, for example, if some flows >> could dynamically bypass DPI but still needed to transit a common set >> of stateful service functions... >> >> Once you postulate a service function instance appearing in more than >> one chain, it seems artificially restrictive not to permit such a >> function to also implement branching, all the control structures >> would already be there. >> >> Rgds Dave >> >> -----Original Message----- From: Hongyu Li (Julio) >> [mailto:hongyu.li@huawei.com] Sent: Wednesday, November 13, 2013 2:12 >> AM To: David Allan I; nsc@ietf.org Subject: RE: [nsc] FW: re >> classification & branching, was: Current Proposed SFC charter >> >> May I suggest summary of my views here: >> >> 1. Branch is a sort of use case or scenario, while reclassification >> is a way to solve the problem. 2. Service Functions should be >> decoupled with the chain itself. Meaning, a SF shall not *directly* >> impact the forwarding of packets in a chain. Branching should be >> performed by chain forwarding nodes, possibly under control of a >> control node. The reason for this is in NFV world, service functions >> may come from a third party, while chain is provided by the >> infrastructure of the network. There must be a cushion avoiding a >> service function operating infrastructure directly. 3. >> (Re)classification is based on info in a packet. This is very >> general. Such info could be L2~L7 derived from a user's packet, as >> well as some info like metadata in a SFC header. As classification is >> out of scope of SFC, we don't have to provide too much details of how >> to do classification. 4. Chain segments stitching is relatively a >> easy way for branching. Compared with chains and subchains, which may >> require a more complex header and forwarding capabilities. My two >> cents. Hongyu >> >> -----Original Message----- From: nsc-bounces@ietf.org >> [mailto:nsc-bounces@ietf.org] On Behalf Of David Allan I Sent: >> Wednesday, November 13, 2013 3:04 AM To: nsc@ietf.org Subject: [nsc] >> FW: re classification & branching, was: Current Proposed SFC charter >> >> Hi: (resend with recipient list cleaned up) >> >> I agree we are discussing multiple concepts, classification and >> flow-subsetting. Perhaps more ;-) >> >> Defining a flow subset can be a result of classification, but it is >> not the exclusive mechanism. Branching is a mechanism by which flow >> subsets are exposed and mapped to a set of subchains such that it can >> be identified in the dataplane... >> >> That's the view from here Dave >> >> -----Original Message----- From: nsc-bounces@ietf.org >> [mailto:nsc-bounces@ietf.org] On Behalf Of David Lake (dlake) Sent: >> Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); >> Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; >> Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Understood - maybe just a little localised warming of the sea then ? >> But I still think we need to consider where and how policy is >> defined/set even for the single-domain instance. >> >> I don't think we can assume that any L1-3 device will be able to >> determine much useful information from the data-plane. >> >> -----Original Message----- From: Jim Guichard (jguichar) Sent: 12 >> November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra >> Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: >> Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] >> Current Proposed SFC charter >> >> As discussed during the BOF our initial work is single administrative >> domain for some of the very reasons you point out. We need to keep >> focused without trying to boil the ocean right off the bat. >> >> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >> >>> Exactly. But how can network-components "terminate" an application >>> ???? >>> >>> I think we need a good understanding of a recursive policy >>> mechanism (recursive because a user-land application will ride with >>> a specific policy across potentially different sets of carrier >>> policies). >>> >>> I hate to bring this up now, but we also need to think about this >>> multi-domain issue - if I set a policy as a user, chances are I >>> will be crossing several domain boundaries. Are we expecting the >>> service headers to define the service chaining for the duration of >>> the entire flow across all domains, or just across a single one ? >>> >>> In which case, do I have to re-set policy as I traverse domains >>> and where does that policy get set ? It would be much better to >>> set policy once based on L5-7 needs, and have that instantiated >>> across the multiple domains. >>> >>> Again, this appears to be outside the scope of SFC, but pretty >>> relevant to how it would operate in the real world. >>> >>> David >>> >>> -----Original Message----- From: Kevin J Ma >>> [mailto:kevin.ma@azukisystems.com] Sent: 12 November 2013 10:27 To: >>> David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra >>> Majee Subject: RE: [nsc] Current Proposed SFC charter >>> >>>> In those circumstances, only the end applications themselves or >>>> a reasonably broad-brushed classification (really traffic >>>> steering based on what we can see at ingress) is going to be >>>> useful - is THAT what we're aiming for here ? >>> >>> I would certainly hope not, but that has been my concern as well. >>> Application layer termination and re-classification seems a must? >>> >>> -- Kevin J. Ma >>> >>>> -----Original Message----- From: David Lake (dlake) >>>> [mailto:dlake@cisco.com] Sent: Tuesday, November 12, 2013 1:00 >>>> PM To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda >>>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; >>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>>> >>>> Policy may be outside of the scope of SFC, but without strong >>>> mapping between Policy and the inserted Service Header(s), we >>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>> >>>> For example, in a world where the network has "gone dark," (as >>>> per the IETF Technical Plenary ?:-) ) what is our ability to >>>> determine policy based on DPI of packets-in-flight ? >>>> >>>> In those circumstances, only the end applications themselves or >>>> a reasonably broad-brushed classification (really traffic >>>> steering based on what we can see at ingress) is going to be >>>> useful - is THAT what we're aiming for here ? >>>> >>>> David >>>> >>>> -----Original Message----- From: nsc-bounces@ietf.org >>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Surendra Kumar >>>> (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J >>>> Ma; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; >>>> nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed >>>> SFC charter >>>> >>>> Ron, >>>> >>>> Classification of traffic is well understood and we do not have >>>> to redefine it - it's been around for all the time middle boxes >>>> have been or for that matter the L2/L3 devices. All we are >>>> talking about is the applicability of the classification to >>>> branching in SFC. >>>> >>>> You are right, it is all about policy which is outside the scope >>>> of SFC. >>>> >>>> Surendra. >>>> >>>> On 11/12/13 7:53 AM, "Ron Parker" >>>> wrote: >>>> >>>>> I think the lack of definition of "reclassification" may be >>>>> causing >>>> some >>>>> misunderstandings here. A branch would occur for some >>>>> policy-driven reason based on the behavior and conclusions of >>>>> the service function, itself. The graph would represent the >>>>> fact that there is a branch point, but the service function, >>>>> itself, being aware that it is a branching point would contain >>>>> the policy and logic to decide on which branch to take. >>>>> Specifying that policy and logic is out of scope, >>>> IMO. >>>>> >>>>> Ron >>>>> >>>>> >>>>> -----Original Message----- From: Kevin J Ma >>>>> [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, November 12, >>>>> 2013 10:49 AM To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>>>> >>>>> Hi Linda, >>>>> >>>>> Are you saying that a branching point is "never" a >>>>> reclassification point, or are you saying that a branching >>>>> point "does not have to be" a reclassification point? >>>>> >>>>> I think this is an important distinction that needs to be >>>>> clarified. If branching is never reclassification, then the >>>>> meaning of a chain is different than I originally inferred. If >>>>> the chain is a tree with other "branching" points in it, then >>>>> that limits the scope of the problem statement goals. >>>>> >>>>> While this could be a degenerate case, and any implementation >>>>> could define bad service chains, is it the intent of SFC to >>>>> only look at the simpler packet-level classification cases, or >>>>> is it the intent to consider the case where a branching point >>>>> is viewed as a re-classification point? >>>>> >>>>> thanx. >>>>> >>>>> -- Kevin J. Ma >>>>> >>>>>> -----Original Message----- From: Linda Dunbar >>>>>> [mailto:linda.dunbar@huawei.com] Sent: Tuesday, November 12, >>>>>> 2013 10:34 AM To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC >>>>>> charter >>>>>> >>>>>> Ron, >>>>>> >>>>>> First, want to make it clear that "branching" !=3D >>>>>> reclassification, agree? >>>>>> >>>>>> Second, the representation of branching (or service graph) >>>>>> can be in a form of logic on a service function. Some service >>>>>> functions, especially L7 based, can use value in a Database >>>>>> to determine what is the next service function. >>>>>> >>>>>> Linda >>>>>> >>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>>> Tuesday, November 12, 2013 8:16 AM To: Hongyu Li (Julio); >>>>>>> Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar >>>>>>> (smkumar); Sumandra Majee Subject: Re: [nsc] Current >>>>>>> Proposed SFC charter >>>>>>> >>>>>>> Hongyu, >>>>>>> >>>>>>> I agree completely that re-classification is not limited to >>>>>>> DPI. >>>>>>> >>>>>>> And also, that an area for us to explore as a group is how >>>>>>> to >>>>>> represent >>>>>>> the service graph. Do we want to represent it as a proper >>>>>>> graph >>>> with >>>>>>> an adjacency list or other representational model? Or, do >>>>>>> we want >>>> to >>>>>>> represent it as a set of linear segments and if so, how are >>>>>>> the segments connected into a graph? Other ideas? >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> >>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Hongyu Li >>>>>>> (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron >>>>>>> Parker; Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; >>>>>>> Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] >>>>>>> Current Proposed SFC charter >>>>>>> >>>>>>> Branching/forking is a very interesting topic of SFC. About >>>>>>> the re- classification point, probably we shall not limit >>>>>>> it to DPI. It is also possible that packets go to different >>>>>>> branches after been processed by a certain service >>>>>>> function, decision of which branches to go is made based on >>>>>>> the result of service function's process, i.e. not just re- >>>>>>> classification by DPI. >>>>>>> >>>>>>> Hongyu >>>>>>> >>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>>> Tuesday, November 12, 2013 7:45 PM To: Kevin J Ma Cc: >>>>>>> Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC >>>>>>> charter >>>>>>> >>>>>>> Hi, Kevin >>>>>>> >>>>>>> You ask a great question about branching the graph. The >>>>>>> details around how to convey the selection of the >>>>>>> subtree/subgraph are still >>>>>> to be >>>>>>> defined. Is it one chain id for the whole graph? Does >>>>>>> each >>>> branch >>>>>>> have its own chain id? Some combination? >>>>>>> >>>>>>> Ron >>>>>>> >>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>> wrote: >>>>>>> >>>>>>>>> Yes, reclassification can change the service path and >>>>>>>>> re-classification may happen at any node along a >>>>>>>>> service path. >>>>>>>> >>>>>>>> Just to expand on that, going back to the original >>>>>>>> question about service header encapsulation, is it >>>>>>>> intended that a chain that is re-classified will get a >>>>>>>> new chain ID which fully describes a chain that is a >>>>>>>> superset of the original chain ID, prior to DPI-based >>>>>>>> re-classification? (assuming the goal is "a single chain >>>>>>>> ID that is commonly understood along the entire service >>>> chain" >>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>>>>>>> >>>>>>>> >) >>>>>>>> >>>>>>>> And the applicable subset of the permutative list of >>>>>>>> service paths would be configured at each appropriate >>>>>>>> service node? e.g., ID 1: NAT + firewall + DPI ID 2: NAT >>>>>>>> + firewall + DPI + AV ID 3: NAT + firewall + DPI + AV + >>>>>>>> NAT ID 4: NAT + firewall + DPI + NAT ID 5: NAT + firewall >>>>>>>> + DPI + AV + LB ID 6: NAT + firewall + DPI + LB ID 7: NAT >>>>>>>> + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI >>>>>>>> + CACHE ID 9: NAT + firewall + DPI + optimizer + LB ID >>>>>>>> 10: NAT + firewall + DPI + optimizer + LB + CACHE ID 11: >>>>>>>> NAT + firewall + DPI + optimizer + CACHE Would every flow >>>>>>>> then be initially classified as ID 1, but eventually get >>>>>>>> re- >>>>>>> classified >>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>> >>>>>>>> thanx. >>>>>>>> >>>>>>>> -- Kevin J. Ma >>>>>>>> >>>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>>> November 12, 2013 1:01 AM To: Kevin J Ma; Ron Parker; >>>>>>>>> Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: >>>>>>>>> Re: [nsc] Current Proposed SFC charter >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Surendra, >>>>>>>>>> >>>>>>>>>> Classification may be out of scope, but the level of >>>>>>>>>> service that >>>>>>> is >>>>>>>>>> applicable is dependent upon the level of >>>>>>>>>> classification that can >>>>>>> be >>>>>>>>>> performed. An assumption of packet level >>>>>>>>>> encapsulation has >>>>>>>>> implications >>>>>>>>>> on the level of classification being performed? If >>>>>>>>>> the stated >>>>>>> goals >>>>>>>>> are >>>>>>>>>> for firewall and load balancer functionality, then >>>>>>>>>> the application >>>>>>>>> level >>>>>>>>>> nature of those functions needs to be taken into >>>>>>>>>> account? If, on the other hand, the service function >>>>>>>>>> scope is limited due to limitations in >>>>>>>>>> classification, that would be and important piece of >>>>>>> information? >>>>>>>>>> >>>>>>>>>> Wrt section 4.4 of >>>>>>>>>> draft-liu-service-chaining-use-cases the fork points >>>>>>>>>> of the service paths seem like re-classification >>>> points? >>>>>>>>>> Is that the interpretation from the architecture >>>>>>>>>> perspective? Or is the service function chain >>>>>>>>>> classification exclusive of DPI >>>>>>> functionality? >>>>>>>>> I have not fully read that draft yet. But in >>>>>>>>> general, as described in the arch draft, the collection >>>>>>>>> of services form a graph, segments of which are service >>>>>>>>> paths. Yes, reclassification can >>>>>>> change >>>>>>>>> the service path and re-classification may happen at >>>>>>>>> any node along >>>>>>> a service path. >>>>>>>>> >>>>>>>>> Surendra. >>>>>>>>>> >>>>>>>>>> thanx. >>>>>>>>>> >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>> >>>>>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>>>>> November 12, 2013 12:08 AM To: Kevin J Ma; Ron >>>>>>>>>>> Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current Proposed >>>>>>>>>>> SFC charter >>>>>>>>>>> >>>>>>>>>>> Kevin, >>>>>>>>>>> >>>>>>>>>>> Classification mechanism is outside the scope of >>>>>>>>>>> SFC. It can be based >>>>>>>>> on >>>>>>>>>>> the packet or information not in the >>>>>>>>>>> packet(environmental attributes >>>>>>>>> for >>>>>>>>>>> instance) or a combination thereof. What is >>>>>>>>>>> important is that such classification aids in >>>>>>>>>>> traffic selection and service path identification. >>>>>>>>>>> It is no different from a policy in this regard >>>>>>>>>>> except that the policy now specifies the service >>>>>>>>>>> path. Further, classification is not limited to the >>>>>>>>>>> network elements but the service functions as well. >>>>>>>>>>> Some of this is described in the >>>>>>>>> architecture >>>>>>>>>>> drafts as well - >>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >Surendra. >>>>>>>>>>> >>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>> >>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Ron, >>>>>>>>>>>> >>>>>>>>>>>> I was unable to make the SFC BoF due to a >>>>>>>>>>>> conflict with CDNI, but I had a similar question >>>>>>>>>>>> wrt bullet 11 in section 2 of the >>>>>>> problem >>>>>>>>>>>> statement: >>>>>>>>>>>> >>>>>>>>>>>> 11. Per-Service (re)Classification: >>>>>>>>>>>> Classification occurs at >>>>>>> each >>>>>>>>>>>> service, independent from previously applied >>>>>>>>>>>> service >>>>>>>>>>> functions. >>>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>>> resources >>>>>>> per >>>>>>>>>>>> service. More importantly, the classification >>>>>>> functionality >>>>>>>>>>>> often differs per service function and service >>>>>>>>>>>> function >>>>>>>>> cannot >>>>>>>>>>>> leverage the results from other deployed network >>>>>>>>>>>> or >>>>>>> service. >>>>>>>>>>>> >>>>>>>>>>>> as it relates to section 5.2 of the framework >>>>>>>>>>>> document: >>>>>>>>>>>> >>>>>>>>>>>> The SFC Classifier classifies packets based on >>>>>>>>>>>> (some of) the >>>>>>>>>>> contents >>>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>>> packets based on >>>>>>>>>>> the >>>>>>>>>>>> possible combination of one or more header >>>>>>>>>>>> fields, such as >>>>>>> source >>>>>>>>>>>> address, destination address, DS field, protocol >>>>>>>>>>>> ID, source >>>>>>> port >>>>>>>>>>> and >>>>>>>>>>>> destination port numbers, and any other >>>>>>>>>>>> information. >>>>>>>>>>>> >>>>>>>>>>>> A packet-based classifier as described in the >>>>>>>>>>>> framework document >>>>>>>>>>> would >>>>>>>>>>>> seem to be limited in what it can classify? The >>>>>>>>>>>> service function identifier lookup does not seem >>>>>>>>>>>> to be a significant optimization >>>>>>>>> over >>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be >>>>>>>>>>>> some missing >>>>>>>>> detail >>>>>>>>>>>> wrt how classification information is determined >>>>>>>>>>>> and reused? >>>>>>>>>>>> >>>>>>>>>>>> When thinking about higher level services, e.g., >>>>>>>>>>>> HTTP and TLS >>>>>>>>>>> encrypted >>>>>>>>>>>> flows, a packet-based classifier seems >>>>>>>>>>>> inadequate? I was also >>>>>>>>>>> wondering >>>>>>>>>>>> how independent HLS segment requests might be >>>>>>>>>>>> classified and >>>>>>>>>>> associated? >>>>>>>>>>>> Were these types of use cases discussed in the >>>>>>>>>>>> BoF? >>>>>>>>>>>> >>>>>>>>>>>> thanx. >>>>>>>>>>>> >>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>> Of >>>>>>>>>>>>> Ron Parker Sent: Monday, November 11, 2013 >>>>>>>>>>>>> 10:16 PM To: Sumandra Majee; Thomas Narten; >>>>>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current >>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>> >>>>>>>>>>>>> As was discussed in Vancouver, there are >>>>>>>>>>>>> already many existing ways >>>>>>>>>>> to >>>>>>>>>>>>> accomplish service chaining. But none of >>>>>>>>>>>>> them provide a >>>>>>>>>>> sufficient >>>>>>>>>>>>> combination of interoperability, flexibility, >>>>>>>>>>>>> and >>>> resiliency. >>>>>>> A >>>>>>>>>>> single >>>>>>>>>>>>> service chain encapsulation will go a long way >>>>>>>>>>>>> to ensuring these >>>>>>>>>>> goals. >>>>>>>>>>>>> It may not be the absolutely most efficient >>>>>>>>>>>>> approach for every >>>>>>>>>>> single >>>>>>>>>>>>> network topology and every single use case, but >>>>>>>>>>>>> its ubiquitous >>>>>>>>> nature >>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>> >>>>>>>>>>>>> Ron >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>>> 11, 2013 10:10 PM To: Ron Parker; Thomas >>>>>>>>>>>>> Narten; nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Ron, >>>>>>>>>>>>> >>>>>>>>>>>>> Absolutely, that was an example of one type of >>>>>>>>>>>>> derivation. However >>>>>>>>>>> this >>>>>>>>>>>>> could be augmented with classification result, >>>>>>>>>>>>> again one more >>>>>>>>>>> example. >>>>>>>>>>>>> >>>>>>>>>>>>>>> All flows from the same source IP do not >>>>>>>>>>>>>>> necessarily follow >>>>>>> the >>>>>>>>>>> same >>>>>>>>>>>>> chain. Correct. It is also not necessary that >>>>>>>>>>>>> all transaction of the same >>>>>>>>>>> flow >>>>>>>>>>>>> follow the same chain either. So why stop at >>>>>>>>>>>>> flow itself. >>>>>>>>>>>>> >>>>>>>>>>>>> Again the point here is that do we always need >>>>>>>>>>>>> SFC header or >>>>>> Not. >>>>>>>>>>>>> >>>>>>>>>>>>> Sumandra >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>>> Monday, November 11, 2013 7:02 PM To: Sumandra >>>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>> >>>>>>>>>>>>> The intention of service function chaining is >>>>>>>>>>>>> to allow for operation >>>>>>>>>>> at >>>>>>>>>>>>> the fully qualified flow level, or even finer >>>>>>>>>>>>> grained at the >>>>>>>>>>> transaction >>>>>>>>>>>>> level (this is an implementation matter for the >>>>>>>>>>>>> PDP). >>>> All >>>>>>> flows >>>>>>>>>>> from >>>>>>>>>>>>> the same source IP do not necessarily follow >>>>>>>>>>>>> the same chain. >>>>>>>>> Source >>>>>>>>>>>>> IP, therefore, does not identify the chain ID. >>>>>>>>>>>>> Another >>>>>> intention >>>>>>> of >>>>>>>>>>>>> service function chaining is to operate over >>>>>>>>>>>>> any network >>>>>>> topology >>>>>>>>> and >>>>>>>>>>>>> not be limited to a single LAN. Thus, while >>>>>>>>>>>>> VLAN may be part >>>> of >>>>>>> the >>>>>>>>>>>>> transport, it does not adequately identify the >>>>>>>>>>>>> service chain, >>>>>>>>> either. >>>>>>>>>>>>> >>>>>>>>>>>>> Ron >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>>> 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; >>>>>>>>>>>>> nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Ron, >>>>>>>>>>>>> >>>>>>>>>>>>> The service header is meant to carry the >>>>>>>>>>>>> context which can >>>>>>> *also* >>>>>>>>>>>>> be derived (for example use source ip and vlan >>>>>>>>>>>>> to identify chainID and position) or >>>>>>>>>>>>> encapsulated as part of another tunnel header. >>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>>> Monday, November 11, 2013 4:36 PM To: Sumandra >>>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>> >>>>>>>>>>>>> As I understand it, an SFC packet traversing >>>>>>>>>>>>> from PDP to SF or from >>>>>>>>>>> SF >>>>>>>>>>>>> to SF will look like: >>>>>>>>>>>>> >>>>>>>>>>>>> +------------------------+ | "transport" >>>>>>>>>>>>> | +------------------------+ | service >>>>>>>>>>>>> header | +------------------------+ | >>>>>>>>>>>>> original IP header | >>>>>>>>>>>>> +------------------------+ | >>>>>>>>>>>>> | original IP | payload >>>>>>> | >>>>>>>>>>>>> | | >>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>> >>>>>>>>>>>>> Where service header contains, at a minimum, >>>>>>>>>>>>> enough information to >>>>>>>>>>> allow >>>>>>>>>>>>> the packet to be propagated along the full >>>>>>>>>>>>> length of the chain, and optionally, other >>>>>>>>>>>>> metadata that enhances the operation of >>>>>>> one >>>>>>>>>>>>> or >>>>>>>>> more >>>>>>>>>>>>> service functions. >>>>>>>>>>>>> >>>>>>>>>>>>> And where "transport" could conceivably be any >>>>>>>>>>>>> of, but not limited >>>>>>>>>>> to: >>>>>>>>>>>>> >>>>>>>>>>>>> * Ethernet * Ethernet + LLC2 * Ethernet + MPLS >>>>>>>>>>>>> * Ethernet + IP + GRE * Ethernet + IP +UDP >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Also, "original" in the diagram above is not >>>>>>>>>>>>> meant to imply immutability, but rather to >>>>>>>>>>>>> specify the packet that is >>>>>>> propagated >>>>>>>>>>>>> from preceding entity to succeeding entity, >>>>>>>>>>>>> prior to encapsulation. >>>>>>>>>>>>> >>>>>>>>>>>>> Ron >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>> Of >>>>>>>>>>>>> Sumandra Majee Sent: Monday, November 11, 2013 >>>>>>>>>>>>> 6:46 PM To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC >>>>>>>>>>>>> charter >>>>>>>>>>>>> >>>>>>>>>>>>> Generic Service Function Chaining >>>>>>>>>>>>> Encapsulation: A document >>>>>> will >>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>> encapsulation >>>>>>>>> format >>>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>>> the service function >>>>>>>>>>> path, >>>>>>>>>>>>> and for communicating context information >>>>>>>>>>>>> between nodes >>>> that >>>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>>> that the >>>>>>>>>>> encapsulation >>>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>>> and the service >>>>>>>>>>> that >>>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>>> encapsulation may be >>>>>>> used >>>>>>>>> on >>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>>> encapsulation will apply for the >>>>>>>>> construction >>>>>>>>>>> of >>>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>>> service. >>>>>>>>>>>>> >>>>>>>>>>>>> [SM] What does it mean by a single >>>>>>>>>>>>> service-level encapsulation, >>>>>>> a >>>>>>>>>>> new >>>>>>>>>>>>> encapsulation format or an ability to select >>>>>>>>>>>>> one encapsulation format that >>>>>>>>>>> fits >>>>>>>>>>>>> the need for a given service chain? The ability >>>>>>>>>>>>> to select a specific encapsulation would be >>>>>>>>> a >>>>>>>>>>>>> management plane decision. There are quite a >>>>>>>>>>>>> few existing encapsulation methods that >>>>>>>>>>> can >>>>>>>>>>>>> possibly be reused to provide context >>>>>>>>>>>>> information between service nodes. I have >>>>>>> seen >>>>>>>>>>>>> mention of GRE, for HTTP based applications >>>>>>>>>>>>> contexts are transferred via headers. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>> Of >>>>>>>>>>>>> Thomas Narten Sent: Wednesday, November 06, >>>>>>>>>>>>> 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] >>>>>>>>>>>>> Current Proposed SFC charter >>>>>>>>>>>>> >>>>>>>>>>>>> Hi. >>>>>>>>>>>>> >>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>> >>>>>>>>>>>>> It contains the revised management text as well >>>>>>>>>>>>> as updated >>>>>>>>>>> milestones. >>>>>>>>>>>>> >>>>>>>>>>>>> All known issues have been addressed. If there >>>>>>>>>>>>> are any remaining >>>>>>>>>>> issues, >>>>>>>>>>>>> please speak up! >>>>>>>>>>>>> >>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>> >>>>>>>>>>>>> Networks, servers, storage technologies, and >>>>>>>>>>>>> applications, have all undergone significant >>>>>>>>>>>>> change in recent years with the introduction >>>>>>>>> of >>>>>>>>>>>>> virtualization, network overlays, and >>>>>>>>>>>>> orchestration. Service >>>>>>>>> delivery >>>>>>>>>>> is >>>>>>>>>>>>> currently both a technical and organizational >>>>>>>>>>>>> challenge that >>>>>>>>> involves >>>>>>>>>>>>> significant modification to the network >>>>>>>>>>>>> configuration. Services are typically >>>>>>>>>>>>> implemented by the ordered combination of a >>>>>>>>>>>>> number of service functions that are deployed >>>>>>>>>>>>> at different points within >>>>>>>>> the >>>>>>>>>>>>> network. Today, a common deployment model has >>>>>>>>>>>>> service functions physically inserted on the >>>>>>>>>>>>> data forwarding path between communicating >>>>>>>>>>>>> peers. >>>>>>>>>>> Going >>>>>>>>>>>>> forward, however, there is a desire to move to >>>>>>>>>>>>> a different model, >>>>>>>>>>> where >>>>>>>>>>>>> service functions are not required to reside on >>>>>>>>>>>>> the default data >>>>>>>>> path >>>>>>>>>>>>> and traffic is instead steered through >>>>>>>>>>>>> services, wherever they are >>>>>>>>>>> deployed. >>>>>>>>>>>>> >>>>>>>>>>>>> For a given service, the abstracted view of the >>>>>>>>>>>>> required service functions and the order in >>>>>>>>>>>>> which they are to be applied is >>>>>>> called >>>>>>>>>>>>> a Service Function Chain (SFC). Since a given >>>>>>>>>>>>> service function may be available on more than >>>>>>>>>>>>> one node within a network, a Service Function >>>>>>>>>>>>> Chain is instantiated >>>>>>>>>>> via >>>>>>>>>>>>> the selection of specific service function >>>>>>>>>>>>> instances and the network nodes on which they >>>>>>>>>>>>> are provided, thereby forming a service >>>>>>>>>>>>> topology: this is called a Service Function >>>>>>>>>>>>> Path. The service functions >>>>>>> may >>>>>>>>>>>>> be applied at a specific layer within the >>>>>>>>>>>>> network protocol stack >>>>>>>>>>> (network >>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>> >>>>>>>>>>>>> The Service Function Chaining (SFC) working >>>>>>>>>>>>> group will develop new approaches to service >>>>>>>>>>>>> delivery and deployment. It will produce a >>>>>>>>>>>>> framework for service function chaining that >>>>>>>>>>>>> includes the necessary protocols >>>>>>>>>>> or >>>>>>>>>>>>> protocol extensions to convey the service path >>>>>>>>>>>>> and service path information to nodes that >>>>>>>>>>>>> implement service functions, as well >>>>>>> as >>>>>>>>>>>>> mechanisms for steering traffic through service >>>>>>>>>>>>> functions. The >>>>>>>>>>> working >>>>>>>>>>>>> group will also examine what information needs >>>>>>>>>>>>> to be gathered from >>>>>>>>>>> the >>>>>>>>>>>>> network and service functions in support of >>>>>>>>>>>>> service function >>>>>>>>> chaining >>>>>>>>>>>>> and how that information may be made available >>>>>>>>>>>>> to nodes that implement >>>>>>>>>>> the >>>>>>>>>>>>> service functions. >>>>>>>>>>>>> >>>>>>>>>>>>> Specifically, the SFC WG is chartered to >>>>>>>>>>>>> deliver the >>>> following: >>>>>>>>>>>>> >>>>>>>>>>>>> 1) Problem Statement: This document will >>>>>>>>>>>>> provide a summary of >>>>>>> the >>>>>>>>>>>>> problem space to be addressed by the WG >>>>>>>>>>>>> including example >>>>>>> high- >>>>>>>>>>>>> level use cases. Additionally, the WG will >>>>>>>>>>>>> normalize >>>>>>>>> nomenclature >>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>> >>>>>>>>>>>>> 2) Architecture: This document will provide a >>>>>>>>>>>>> description of >>>>>> the >>>>>>>>>>>>> architectural building blocks and their >>>>>>>>>>>>> relationships >>>>>>> including >>>>>>>>>>>>> interconnection, placement of capabilities, >>>>>>>>>>>>> management, diagnostics, design analysis, and >>>>>>>>>>>>> security models, as well >>>>>> as >>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>> >>>>>>>>>>>>> 3) Generic Service Function Chaining >>>>>>>>>>>>> Encapsulation: A document >>>>>>> will >>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>> encapsulation >>>>>>>>> format >>>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>>> the service function >>>>>>>>>>> path, >>>>>>>>>>>>> and for communicating context information >>>>>>>>>>>>> between nodes >>>> that >>>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>>> that the >>>>>>>>>>> encapsulation >>>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>>> and the service >>>>>>>>>>> that >>>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>>> encapsulation may be >>>>>>> used >>>>>>>>> on >>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>>> encapsulation will apply for the >>>>>>>>> construction >>>>>>>>>>> of >>>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>>> service. >>>>>>>>>>>>> >>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents >>>>>>>>>>>>> will be >>>>>>> developed to >>>>>>>>>>>>> describe requirements and protocols necessary >>>>>>>>>>>>> to convey >>>>>>>>>>> information >>>>>>>>>>>>> to service function implementation points. >>>>>>>>>>>>> Where possible, >>>>>>>>>>> existing >>>>>>>>>>>>> IETF protocols will be used and extended. All >>>>>>>>>>>>> protocol >>>>>>>>> extensions >>>>>>>>>>>>> work should be carried out in the working >>>>>>>>>>>>> groups responsible for >>>>>>>>>>> the >>>>>>>>>>>>> protocols being modified in coordination with >>>>>>>>>>>>> this working >>>>>>>>> group, >>>>>>>>>>>>> but may be done in this working group after >>>>>>>>>>>>> agreement with all >>>>>>> the >>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>> >>>>>>>>>>>>> 5) Manageability: Work on the management and >>>>>>>>>>>>> configuration of >>>>>>>>> service >>>>>>>>>>>>> functions in support of SFC components will >>>>>>>>>>>>> certainly be >>>>>>> needed, >>>>>>>>>>>>> but first needs to be better understood and >>>>>>>>>>>>> scoped. >>>>>>>>>>>>> >>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>> >>>>>>>>>>>>> Apr 2014 Submit to IESG Informational >>>>>>>>>>>>> document(s) defining the >>>>>>>>>>> problem >>>>>>>>>>>>> statement and core use cases for Service >>>>>>>>>>>>> Function Chaining >>>>>>>>>>>>> >>>>>>>>>>>>> May 2014 Consult with OPS Area on possible >>>>>>>>>>>>> charter modifications for management and >>>>>>>>>>>>> configuration of SFC components >>>>>>>>>>>>> >>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document >>>>>>>>>>>>> defining the >>>>>>>>>>> architecture >>>>>>>>>>>>> for SFC >>>>>>>>>>>>> >>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a >>>>>>>>>>>>> generic service function chaining encapsulation >>>>>>>>>>>>> protocol >>>>>>>>>>>>> >>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track >>>>>>>>>>>>> document specifying the >>>>>>>>>>> generic >>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thomas >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >nsc mailing list >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >nsc mailing list >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>> >nsc mailing list >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> nsc mailing list nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> >>>>>>> _______________________________________________ nsc mailing >>>>>>> list nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ nsc mailing >>>>>>> list nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> _______________________________________________ nsc mailing >>>>>>> list nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >>>> _______________________________________________ nsc mailing list >>>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ nsc mailing list >> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Thu Nov 14 05:10:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA4E21E805F for ; Thu, 14 Nov 2013 05:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i80OCxOWiFz8 for ; Thu, 14 Nov 2013 05:10:25 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 6D90B21E8098 for ; Thu, 14 Nov 2013 05:10:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 16A701BC52AE; Thu, 14 Nov 2013 05:10:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 4F59F1BC52A5; Thu, 14 Nov 2013 05:10:23 -0800 (PST) Message-ID: <5284CBBD.7030606@joelhalpern.com> Date: Thu, 14 Nov 2013 08:10:21 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" , "Hongyu Li (Julio)" , David Allan I , "nsc@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 13:10:30 -0000 I agree that there are cases where the service function will need to make such updates. I believe they are rare, and will therefore need to be supported in the architecture in an appropriate fashion. But the debate about frequency and mechanism can wait until we get a WG chartered. Yours, Joel On 11/14/13 8:00 AM, Jim Guichard (jguichar) wrote: > Completely agree Joel although the service function *may* directly update > metadata context and service path identification (which effectively forces > a branching operation). > > On 11/14/13 7:46 AM, "Joel M. Halpern" wrote: > >> You assert in the below text that "service functions should be able to >> compose a chain arbitrarily." >> That does not seem to follow. >> The operator defines the service chains they want. They provision those >> service chains. >> Thus, I would expect that the job of a service function is to deliver >> its specific service. In general, it should not need to know or care >> about the chains in which it is participating. >> >> Yours, >> Joel M. Halpern >> >> On 11/13/13 9:29 PM, Hongyu Li (Julio) wrote: >>> Hi Dave, >>> >>> Your inferred restriction may be not always true. In general, service >>> functions should be able to compose a chain arbitrarily. Particularly >>> for branching, as I suggested in previous email, service function >>> shall not directly impact packet forwarding. This precludes the >>> restriction you mentioned. Forwarding plane can decide whether a >>> branching action should be taken by reclassification or not per >>> service chain. >>> >>> Does this make sense? >>> >>> Hongyu >>> >>> -----Original Message----- From: David Allan I >>> [mailto:david.i.allan@ericsson.com] Sent: Wednesday, November 13, >>> 2013 11:45 PM To: Hongyu Li (Julio); nsc@ietf.org Subject: RE: [nsc] >>> FW: re classification & branching, was: Current Proposed SFC charter >>> >>> HI Hongyu: >>> >>> I think we will have scenarios where a service function appears in >>> more than one chain, as would be the case, for example, if some flows >>> could dynamically bypass DPI but still needed to transit a common set >>> of stateful service functions... >>> >>> Once you postulate a service function instance appearing in more than >>> one chain, it seems artificially restrictive not to permit such a >>> function to also implement branching, all the control structures >>> would already be there. >>> >>> Rgds Dave >>> >>> -----Original Message----- From: Hongyu Li (Julio) >>> [mailto:hongyu.li@huawei.com] Sent: Wednesday, November 13, 2013 2:12 >>> AM To: David Allan I; nsc@ietf.org Subject: RE: [nsc] FW: re >>> classification & branching, was: Current Proposed SFC charter >>> >>> May I suggest summary of my views here: >>> >>> 1. Branch is a sort of use case or scenario, while reclassification >>> is a way to solve the problem. 2. Service Functions should be >>> decoupled with the chain itself. Meaning, a SF shall not *directly* >>> impact the forwarding of packets in a chain. Branching should be >>> performed by chain forwarding nodes, possibly under control of a >>> control node. The reason for this is in NFV world, service functions >>> may come from a third party, while chain is provided by the >>> infrastructure of the network. There must be a cushion avoiding a >>> service function operating infrastructure directly. 3. >>> (Re)classification is based on info in a packet. This is very >>> general. Such info could be L2~L7 derived from a user's packet, as >>> well as some info like metadata in a SFC header. As classification is >>> out of scope of SFC, we don't have to provide too much details of how >>> to do classification. 4. Chain segments stitching is relatively a >>> easy way for branching. Compared with chains and subchains, which may >>> require a more complex header and forwarding capabilities. My two >>> cents. Hongyu >>> >>> -----Original Message----- From: nsc-bounces@ietf.org >>> [mailto:nsc-bounces@ietf.org] On Behalf Of David Allan I Sent: >>> Wednesday, November 13, 2013 3:04 AM To: nsc@ietf.org Subject: [nsc] >>> FW: re classification & branching, was: Current Proposed SFC charter >>> >>> Hi: (resend with recipient list cleaned up) >>> >>> I agree we are discussing multiple concepts, classification and >>> flow-subsetting. Perhaps more ;-) >>> >>> Defining a flow subset can be a result of classification, but it is >>> not the exclusive mechanism. Branching is a mechanism by which flow >>> subsets are exposed and mapped to a set of subchains such that it can >>> be identified in the dataplane... >>> >>> That's the view from here Dave >>> >>> -----Original Message----- From: nsc-bounces@ietf.org >>> [mailto:nsc-bounces@ietf.org] On Behalf Of David Lake (dlake) Sent: >>> Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); >>> Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Linda Dunbar; >>> Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Understood - maybe just a little localised warming of the sea then ? >>> But I still think we need to consider where and how policy is >>> defined/set even for the single-domain instance. >>> >>> I don't think we can assume that any L1-3 device will be able to >>> determine much useful information from the data-plane. >>> >>> -----Original Message----- From: Jim Guichard (jguichar) Sent: 12 >>> November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra >>> Kumar (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio) Cc: >>> Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] >>> Current Proposed SFC charter >>> >>> As discussed during the BOF our initial work is single administrative >>> domain for some of the very reasons you point out. We need to keep >>> focused without trying to boil the ocean right off the bat. >>> >>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>> >>>> Exactly. But how can network-components "terminate" an application >>>> ???? >>>> >>>> I think we need a good understanding of a recursive policy >>>> mechanism (recursive because a user-land application will ride with >>>> a specific policy across potentially different sets of carrier >>>> policies). >>>> >>>> I hate to bring this up now, but we also need to think about this >>>> multi-domain issue - if I set a policy as a user, chances are I >>>> will be crossing several domain boundaries. Are we expecting the >>>> service headers to define the service chaining for the duration of >>>> the entire flow across all domains, or just across a single one ? >>>> >>>> In which case, do I have to re-set policy as I traverse domains >>>> and where does that policy get set ? It would be much better to >>>> set policy once based on L5-7 needs, and have that instantiated >>>> across the multiple domains. >>>> >>>> Again, this appears to be outside the scope of SFC, but pretty >>>> relevant to how it would operate in the real world. >>>> >>>> David >>>> >>>> -----Original Message----- From: Kevin J Ma >>>> [mailto:kevin.ma@azukisystems.com] Sent: 12 November 2013 10:27 To: >>>> David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra >>>> Majee Subject: RE: [nsc] Current Proposed SFC charter >>>> >>>>> In those circumstances, only the end applications themselves or >>>>> a reasonably broad-brushed classification (really traffic >>>>> steering based on what we can see at ingress) is going to be >>>>> useful - is THAT what we're aiming for here ? >>>> >>>> I would certainly hope not, but that has been my concern as well. >>>> Application layer termination and re-classification seems a must? >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- From: David Lake (dlake) >>>>> [mailto:dlake@cisco.com] Sent: Tuesday, November 12, 2013 1:00 >>>>> PM To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda >>>>> Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; >>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>>>> >>>>> Policy may be outside of the scope of SFC, but without strong >>>>> mapping between Policy and the inserted Service Header(s), we >>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>> >>>>> For example, in a world where the network has "gone dark," (as >>>>> per the IETF Technical Plenary ?:-) ) what is our ability to >>>>> determine policy based on DPI of packets-in-flight ? >>>>> >>>>> In those circumstances, only the end applications themselves or >>>>> a reasonably broad-brushed classification (really traffic >>>>> steering based on what we can see at ingress) is going to be >>>>> useful - is THAT what we're aiming for here ? >>>>> >>>>> David >>>>> >>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Surendra Kumar >>>>> (smkumar) Sent: 12 November 2013 09:26 To: Ron Parker; Kevin J >>>>> Ma; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; >>>>> nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed >>>>> SFC charter >>>>> >>>>> Ron, >>>>> >>>>> Classification of traffic is well understood and we do not have >>>>> to redefine it - it's been around for all the time middle boxes >>>>> have been or for that matter the L2/L3 devices. All we are >>>>> talking about is the applicability of the classification to >>>>> branching in SFC. >>>>> >>>>> You are right, it is all about policy which is outside the scope >>>>> of SFC. >>>>> >>>>> Surendra. >>>>> >>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>> wrote: >>>>> >>>>>> I think the lack of definition of "reclassification" may be >>>>>> causing >>>>> some >>>>>> misunderstandings here. A branch would occur for some >>>>>> policy-driven reason based on the behavior and conclusions of >>>>>> the service function, itself. The graph would represent the >>>>>> fact that there is a branch point, but the service function, >>>>>> itself, being aware that it is a branching point would contain >>>>>> the policy and logic to decide on which branch to take. >>>>>> Specifying that policy and logic is out of scope, >>>>> IMO. >>>>>> >>>>>> Ron >>>>>> >>>>>> >>>>>> -----Original Message----- From: Kevin J Ma >>>>>> [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, November 12, >>>>>> 2013 10:49 AM To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC charter >>>>>> >>>>>> Hi Linda, >>>>>> >>>>>> Are you saying that a branching point is "never" a >>>>>> reclassification point, or are you saying that a branching >>>>>> point "does not have to be" a reclassification point? >>>>>> >>>>>> I think this is an important distinction that needs to be >>>>>> clarified. If branching is never reclassification, then the >>>>>> meaning of a chain is different than I originally inferred. If >>>>>> the chain is a tree with other "branching" points in it, then >>>>>> that limits the scope of the problem statement goals. >>>>>> >>>>>> While this could be a degenerate case, and any implementation >>>>>> could define bad service chains, is it the intent of SFC to >>>>>> only look at the simpler packet-level classification cases, or >>>>>> is it the intent to consider the case where a branching point >>>>>> is viewed as a re-classification point? >>>>>> >>>>>> thanx. >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- From: Linda Dunbar >>>>>>> [mailto:linda.dunbar@huawei.com] Sent: Tuesday, November 12, >>>>>>> 2013 10:34 AM To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>> Sumandra Majee Subject: RE: [nsc] Current Proposed SFC >>>>>>> charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> First, want to make it clear that "branching" != >>>>>>> reclassification, agree? >>>>>>> >>>>>>> Second, the representation of branching (or service graph) >>>>>>> can be in a form of logic on a service function. Some service >>>>>>> functions, especially L7 based, can use value in a Database >>>>>>> to determine what is the next service function. >>>>>>> >>>>>>> Linda >>>>>>> >>>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>>>> Tuesday, November 12, 2013 8:16 AM To: Hongyu Li (Julio); >>>>>>>> Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar >>>>>>>> (smkumar); Sumandra Majee Subject: Re: [nsc] Current >>>>>>>> Proposed SFC charter >>>>>>>> >>>>>>>> Hongyu, >>>>>>>> >>>>>>>> I agree completely that re-classification is not limited to >>>>>>>> DPI. >>>>>>>> >>>>>>>> And also, that an area for us to explore as a group is how >>>>>>>> to >>>>>>> represent >>>>>>>> the service graph. Do we want to represent it as a proper >>>>>>>> graph >>>>> with >>>>>>>> an adjacency list or other representational model? Or, do >>>>>>>> we want >>>>> to >>>>>>>> represent it as a set of linear segments and if so, how are >>>>>>>> the segments connected into a graph? Other ideas? >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Hongyu Li >>>>>>>> (Julio) Sent: Tuesday, November 12, 2013 6:57 AM To: Ron >>>>>>>> Parker; Kevin J Ma Cc: Thomas Narten; nsc@ietf.org; >>>>>>>> Surendra Kumar (smkumar); Sumandra Majee Subject: Re: [nsc] >>>>>>>> Current Proposed SFC charter >>>>>>>> >>>>>>>> Branching/forking is a very interesting topic of SFC. About >>>>>>>> the re- classification point, probably we shall not limit >>>>>>>> it to DPI. It is also possible that packets go to different >>>>>>>> branches after been processed by a certain service >>>>>>>> function, decision of which branches to go is made based on >>>>>>>> the result of service function's process, i.e. not just re- >>>>>>>> classification by DPI. >>>>>>>> >>>>>>>> Hongyu >>>>>>>> >>>>>>>> -----Original Message----- From: nsc-bounces@ietf.org >>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf Of Ron Parker Sent: >>>>>>>> Tuesday, November 12, 2013 7:45 PM To: Kevin J Ma Cc: >>>>>>>> Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>> Sumandra Majee Subject: Re: [nsc] Current Proposed SFC >>>>>>>> charter >>>>>>>> >>>>>>>> Hi, Kevin >>>>>>>> >>>>>>>> You ask a great question about branching the graph. The >>>>>>>> details around how to convey the selection of the >>>>>>>> subtree/subgraph are still >>>>>>> to be >>>>>>>> defined. Is it one chain id for the whole graph? Does >>>>>>>> each >>>>> branch >>>>>>>> have its own chain id? Some combination? >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>> wrote: >>>>>>>> >>>>>>>>>> Yes, reclassification can change the service path and >>>>>>>>>> re-classification may happen at any node along a >>>>>>>>>> service path. >>>>>>>>> >>>>>>>>> Just to expand on that, going back to the original >>>>>>>>> question about service header encapsulation, is it >>>>>>>>> intended that a chain that is re-classified will get a >>>>>>>>> new chain ID which fully describes a chain that is a >>>>>>>>> superset of the original chain ID, prior to DPI-based >>>>>>>>> re-classification? (assuming the goal is "a single chain >>>>>>>>> ID that is commonly understood along the entire service >>>>> chain" >>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>>>>>>>> >>>>>>>>> >> ) >>>>>>>>> >>>>>>>>> And the applicable subset of the permutative list of >>>>>>>>> service paths would be configured at each appropriate >>>>>>>>> service node? e.g., ID 1: NAT + firewall + DPI ID 2: NAT >>>>>>>>> + firewall + DPI + AV ID 3: NAT + firewall + DPI + AV + >>>>>>>>> NAT ID 4: NAT + firewall + DPI + NAT ID 5: NAT + firewall >>>>>>>>> + DPI + AV + LB ID 6: NAT + firewall + DPI + LB ID 7: NAT >>>>>>>>> + firewall + DPI + LB + CACHE ID 8: NAT + firewall + DPI >>>>>>>>> + CACHE ID 9: NAT + firewall + DPI + optimizer + LB ID >>>>>>>>> 10: NAT + firewall + DPI + optimizer + LB + CACHE ID 11: >>>>>>>>> NAT + firewall + DPI + optimizer + CACHE Would every flow >>>>>>>>> then be initially classified as ID 1, but eventually get >>>>>>>>> re- >>>>>>>> classified >>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>> >>>>>>>>> thanx. >>>>>>>>> >>>>>>>>> -- Kevin J. Ma >>>>>>>>> >>>>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>>>> November 12, 2013 1:01 AM To: Kevin J Ma; Ron Parker; >>>>>>>>>> Sumandra Majee; Thomas Narten; nsc@ietf.org Subject: >>>>>>>>>> Re: [nsc] Current Proposed SFC charter >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>> >>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Surendra, >>>>>>>>>>> >>>>>>>>>>> Classification may be out of scope, but the level of >>>>>>>>>>> service that >>>>>>>> is >>>>>>>>>>> applicable is dependent upon the level of >>>>>>>>>>> classification that can >>>>>>>> be >>>>>>>>>>> performed. An assumption of packet level >>>>>>>>>>> encapsulation has >>>>>>>>>> implications >>>>>>>>>>> on the level of classification being performed? If >>>>>>>>>>> the stated >>>>>>>> goals >>>>>>>>>> are >>>>>>>>>>> for firewall and load balancer functionality, then >>>>>>>>>>> the application >>>>>>>>>> level >>>>>>>>>>> nature of those functions needs to be taken into >>>>>>>>>>> account? If, on the other hand, the service function >>>>>>>>>>> scope is limited due to limitations in >>>>>>>>>>> classification, that would be and important piece of >>>>>>>> information? >>>>>>>>>>> >>>>>>>>>>> Wrt section 4.4 of >>>>>>>>>>> draft-liu-service-chaining-use-cases the fork points >>>>>>>>>>> of the service paths seem like re-classification >>>>> points? >>>>>>>>>>> Is that the interpretation from the architecture >>>>>>>>>>> perspective? Or is the service function chain >>>>>>>>>>> classification exclusive of DPI >>>>>>>> functionality? >>>>>>>>>> I have not fully read that draft yet. But in >>>>>>>>>> general, as described in the arch draft, the collection >>>>>>>>>> of services form a graph, segments of which are service >>>>>>>>>> paths. Yes, reclassification can >>>>>>>> change >>>>>>>>>> the service path and re-classification may happen at >>>>>>>>>> any node along >>>>>>>> a service path. >>>>>>>>>> >>>>>>>>>> Surendra. >>>>>>>>>>> >>>>>>>>>>> thanx. >>>>>>>>>>> >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- From: Surendra Kumar >>>>>>>>>>>> (smkumar) [mailto:smkumar@cisco.com] Sent: Tuesday, >>>>>>>>>>>> November 12, 2013 12:08 AM To: Kevin J Ma; Ron >>>>>>>>>>>> Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current Proposed >>>>>>>>>>>> SFC charter >>>>>>>>>>>> >>>>>>>>>>>> Kevin, >>>>>>>>>>>> >>>>>>>>>>>> Classification mechanism is outside the scope of >>>>>>>>>>>> SFC. It can be based >>>>>>>>>> on >>>>>>>>>>>> the packet or information not in the >>>>>>>>>>>> packet(environmental attributes >>>>>>>>>> for >>>>>>>>>>>> instance) or a combination thereof. What is >>>>>>>>>>>> important is that such classification aids in >>>>>>>>>>>> traffic selection and service path identification. >>>>>>>>>>>> It is no different from a policy in this regard >>>>>>>>>>>> except that the policy now specifies the service >>>>>>>>>>>> path. Further, classification is not limited to the >>>>>>>>>>>> network elements but the service functions as well. >>>>>>>>>>>> Some of this is described in the >>>>>>>>>> architecture >>>>>>>>>>>> drafts as well - >>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >> Surendra. >>>>>>>>>>>> >>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>> >>>>>>>>>>>>> I was unable to make the SFC BoF due to a >>>>>>>>>>>>> conflict with CDNI, but I had a similar question >>>>>>>>>>>>> wrt bullet 11 in section 2 of the >>>>>>>> problem >>>>>>>>>>>>> statement: >>>>>>>>>>>>> >>>>>>>>>>>>> 11. Per-Service (re)Classification: >>>>>>>>>>>>> Classification occurs at >>>>>>>> each >>>>>>>>>>>>> service, independent from previously applied >>>>>>>>>>>>> service >>>>>>>>>>>> functions. >>>>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>>>> resources >>>>>>>> per >>>>>>>>>>>>> service. More importantly, the classification >>>>>>>> functionality >>>>>>>>>>>>> often differs per service function and service >>>>>>>>>>>>> function >>>>>>>>>> cannot >>>>>>>>>>>>> leverage the results from other deployed network >>>>>>>>>>>>> or >>>>>>>> service. >>>>>>>>>>>>> >>>>>>>>>>>>> as it relates to section 5.2 of the framework >>>>>>>>>>>>> document: >>>>>>>>>>>>> >>>>>>>>>>>>> The SFC Classifier classifies packets based on >>>>>>>>>>>>> (some of) the >>>>>>>>>>>> contents >>>>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>>>> packets based on >>>>>>>>>>>> the >>>>>>>>>>>>> possible combination of one or more header >>>>>>>>>>>>> fields, such as >>>>>>>> source >>>>>>>>>>>>> address, destination address, DS field, protocol >>>>>>>>>>>>> ID, source >>>>>>>> port >>>>>>>>>>>> and >>>>>>>>>>>>> destination port numbers, and any other >>>>>>>>>>>>> information. >>>>>>>>>>>>> >>>>>>>>>>>>> A packet-based classifier as described in the >>>>>>>>>>>>> framework document >>>>>>>>>>>> would >>>>>>>>>>>>> seem to be limited in what it can classify? The >>>>>>>>>>>>> service function identifier lookup does not seem >>>>>>>>>>>>> to be a significant optimization >>>>>>>>>> over >>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be >>>>>>>>>>>>> some missing >>>>>>>>>> detail >>>>>>>>>>>>> wrt how classification information is determined >>>>>>>>>>>>> and reused? >>>>>>>>>>>>> >>>>>>>>>>>>> When thinking about higher level services, e.g., >>>>>>>>>>>>> HTTP and TLS >>>>>>>>>>>> encrypted >>>>>>>>>>>>> flows, a packet-based classifier seems >>>>>>>>>>>>> inadequate? I was also >>>>>>>>>>>> wondering >>>>>>>>>>>>> how independent HLS segment requests might be >>>>>>>>>>>>> classified and >>>>>>>>>>>> associated? >>>>>>>>>>>>> Were these types of use cases discussed in the >>>>>>>>>>>>> BoF? >>>>>>>>>>>>> >>>>>>>>>>>>> thanx. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Ron Parker Sent: Monday, November 11, 2013 >>>>>>>>>>>>>> 10:16 PM To: Sumandra Majee; Thomas Narten; >>>>>>>>>>>>>> nsc@ietf.org Subject: Re: [nsc] Current >>>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As was discussed in Vancouver, there are >>>>>>>>>>>>>> already many existing ways >>>>>>>>>>>> to >>>>>>>>>>>>>> accomplish service chaining. But none of >>>>>>>>>>>>>> them provide a >>>>>>>>>>>> sufficient >>>>>>>>>>>>>> combination of interoperability, flexibility, >>>>>>>>>>>>>> and >>>>> resiliency. >>>>>>>> A >>>>>>>>>>>> single >>>>>>>>>>>>>> service chain encapsulation will go a long way >>>>>>>>>>>>>> to ensuring these >>>>>>>>>>>> goals. >>>>>>>>>>>>>> It may not be the absolutely most efficient >>>>>>>>>>>>>> approach for every >>>>>>>>>>>> single >>>>>>>>>>>>>> network topology and every single use case, but >>>>>>>>>>>>>> its ubiquitous >>>>>>>>>> nature >>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>>>> 11, 2013 10:10 PM To: Ron Parker; Thomas >>>>>>>>>>>>>> Narten; nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Absolutely, that was an example of one type of >>>>>>>>>>>>>> derivation. However >>>>>>>>>>>> this >>>>>>>>>>>>>> could be augmented with classification result, >>>>>>>>>>>>>> again one more >>>>>>>>>>>> example. >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All flows from the same source IP do not >>>>>>>>>>>>>>>> necessarily follow >>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>>>> chain. Correct. It is also not necessary that >>>>>>>>>>>>>> all transaction of the same >>>>>>>>>>>> flow >>>>>>>>>>>>>> follow the same chain either. So why stop at >>>>>>>>>>>>>> flow itself. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Again the point here is that do we always need >>>>>>>>>>>>>> SFC header or >>>>>>> Not. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>>>> Monday, November 11, 2013 7:02 PM To: Sumandra >>>>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The intention of service function chaining is >>>>>>>>>>>>>> to allow for operation >>>>>>>>>>>> at >>>>>>>>>>>>>> the fully qualified flow level, or even finer >>>>>>>>>>>>>> grained at the >>>>>>>>>>>> transaction >>>>>>>>>>>>>> level (this is an implementation matter for the >>>>>>>>>>>>>> PDP). >>>>> All >>>>>>>> flows >>>>>>>>>>>> from >>>>>>>>>>>>>> the same source IP do not necessarily follow >>>>>>>>>>>>>> the same chain. >>>>>>>>>> Source >>>>>>>>>>>>>> IP, therefore, does not identify the chain ID. >>>>>>>>>>>>>> Another >>>>>>> intention >>>>>>>> of >>>>>>>>>>>>>> service function chaining is to operate over >>>>>>>>>>>>>> any network >>>>>>>> topology >>>>>>>>>> and >>>>>>>>>>>>>> not be limited to a single LAN. Thus, while >>>>>>>>>>>>>> VLAN may be part >>>>> of >>>>>>>> the >>>>>>>>>>>>>> transport, it does not adequately identify the >>>>>>>>>>>>>> service chain, >>>>>>>>>> either. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: Sumandra Majee >>>>>>>>>>>>>> [mailto:S.Majee@F5.com] Sent: Monday, November >>>>>>>>>>>>>> 11, 2013 9:56 PM To: Ron Parker; Thomas Narten; >>>>>>>>>>>>>> nsc@ietf.org Subject: RE: [nsc] Current >>>>>>>>>>>>>> Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>> >>>>>>>>>>>>>> The service header is meant to carry the >>>>>>>>>>>>>> context which can >>>>>>>> *also* >>>>>>>>>>>>>> be derived (for example use source ip and vlan >>>>>>>>>>>>>> to identify chainID and position) or >>>>>>>>>>>>>> encapsulated as part of another tunnel header. >>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] Sent: >>>>>>>>>>>>>> Monday, November 11, 2013 4:36 PM To: Sumandra >>>>>>>>>>>>>> Majee; Thomas Narten; nsc@ietf.org Subject: RE: >>>>>>>>>>>>>> [nsc] Current Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>> >>>>>>>>>>>>>> As I understand it, an SFC packet traversing >>>>>>>>>>>>>> from PDP to SF or from >>>>>>>>>>>> SF >>>>>>>>>>>>>> to SF will look like: >>>>>>>>>>>>>> >>>>>>>>>>>>>> +------------------------+ | "transport" >>>>>>>>>>>>>> | +------------------------+ | service >>>>>>>>>>>>>> header | +------------------------+ | >>>>>>>>>>>>>> original IP header | >>>>>>>>>>>>>> +------------------------+ | >>>>>>>>>>>>>> | original IP | payload >>>>>>>> | >>>>>>>>>>>>>> | | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Where service header contains, at a minimum, >>>>>>>>>>>>>> enough information to >>>>>>>>>>>> allow >>>>>>>>>>>>>> the packet to be propagated along the full >>>>>>>>>>>>>> length of the chain, and optionally, other >>>>>>>>>>>>>> metadata that enhances the operation of >>>>>>>> one >>>>>>>>>>>>>> or >>>>>>>>>> more >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> And where "transport" could conceivably be any >>>>>>>>>>>>>> of, but not limited >>>>>>>>>>>> to: >>>>>>>>>>>>>> >>>>>>>>>>>>>> * Ethernet * Ethernet + LLC2 * Ethernet + MPLS >>>>>>>>>>>>>> * Ethernet + IP + GRE * Ethernet + IP +UDP >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Also, "original" in the diagram above is not >>>>>>>>>>>>>> meant to imply immutability, but rather to >>>>>>>>>>>>>> specify the packet that is >>>>>>>> propagated >>>>>>>>>>>>>> from preceding entity to succeeding entity, >>>>>>>>>>>>>> prior to encapsulation. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Sumandra Majee Sent: Monday, November 11, 2013 >>>>>>>>>>>>>> 6:46 PM To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC >>>>>>>>>>>>>> charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Generic Service Function Chaining >>>>>>>>>>>>>> Encapsulation: A document >>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>>>> the service function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information >>>>>>>>>>>>>> between nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>>>> that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>>>> and the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>>>> encapsulation may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>>>> encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>>>> service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [SM] What does it mean by a single >>>>>>>>>>>>>> service-level encapsulation, >>>>>>>> a >>>>>>>>>>>> new >>>>>>>>>>>>>> encapsulation format or an ability to select >>>>>>>>>>>>>> one encapsulation format that >>>>>>>>>>>> fits >>>>>>>>>>>>>> the need for a given service chain? The ability >>>>>>>>>>>>>> to select a specific encapsulation would be >>>>>>>>>> a >>>>>>>>>>>>>> management plane decision. There are quite a >>>>>>>>>>>>>> few existing encapsulation methods that >>>>>>>>>>>> can >>>>>>>>>>>>>> possibly be reused to provide context >>>>>>>>>>>>>> information between service nodes. I have >>>>>>>> seen >>>>>>>>>>>>>> mention of GRE, for HTTP based applications >>>>>>>>>>>>>> contexts are transferred via headers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- From: >>>>>>>>>>>>>> nsc-bounces@ietf.org >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Thomas Narten Sent: Wednesday, November 06, >>>>>>>>>>>>>> 2013 11:07 AM To: nsc@ietf.org Subject: [nsc] >>>>>>>>>>>>>> Current Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It contains the revised management text as well >>>>>>>>>>>>>> as updated >>>>>>>>>>>> milestones. >>>>>>>>>>>>>> >>>>>>>>>>>>>> All known issues have been addressed. If there >>>>>>>>>>>>>> are any remaining >>>>>>>>>>>> issues, >>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Networks, servers, storage technologies, and >>>>>>>>>>>>>> applications, have all undergone significant >>>>>>>>>>>>>> change in recent years with the introduction >>>>>>>>>> of >>>>>>>>>>>>>> virtualization, network overlays, and >>>>>>>>>>>>>> orchestration. Service >>>>>>>>>> delivery >>>>>>>>>>>> is >>>>>>>>>>>>>> currently both a technical and organizational >>>>>>>>>>>>>> challenge that >>>>>>>>>> involves >>>>>>>>>>>>>> significant modification to the network >>>>>>>>>>>>>> configuration. Services are typically >>>>>>>>>>>>>> implemented by the ordered combination of a >>>>>>>>>>>>>> number of service functions that are deployed >>>>>>>>>>>>>> at different points within >>>>>>>>>> the >>>>>>>>>>>>>> network. Today, a common deployment model has >>>>>>>>>>>>>> service functions physically inserted on the >>>>>>>>>>>>>> data forwarding path between communicating >>>>>>>>>>>>>> peers. >>>>>>>>>>>> Going >>>>>>>>>>>>>> forward, however, there is a desire to move to >>>>>>>>>>>>>> a different model, >>>>>>>>>>>> where >>>>>>>>>>>>>> service functions are not required to reside on >>>>>>>>>>>>>> the default data >>>>>>>>>> path >>>>>>>>>>>>>> and traffic is instead steered through >>>>>>>>>>>>>> services, wherever they are >>>>>>>>>>>> deployed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> For a given service, the abstracted view of the >>>>>>>>>>>>>> required service functions and the order in >>>>>>>>>>>>>> which they are to be applied is >>>>>>>> called >>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given >>>>>>>>>>>>>> service function may be available on more than >>>>>>>>>>>>>> one node within a network, a Service Function >>>>>>>>>>>>>> Chain is instantiated >>>>>>>>>>>> via >>>>>>>>>>>>>> the selection of specific service function >>>>>>>>>>>>>> instances and the network nodes on which they >>>>>>>>>>>>>> are provided, thereby forming a service >>>>>>>>>>>>>> topology: this is called a Service Function >>>>>>>>>>>>>> Path. The service functions >>>>>>>> may >>>>>>>>>>>>>> be applied at a specific layer within the >>>>>>>>>>>>>> network protocol stack >>>>>>>>>>>> (network >>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The Service Function Chaining (SFC) working >>>>>>>>>>>>>> group will develop new approaches to service >>>>>>>>>>>>>> delivery and deployment. It will produce a >>>>>>>>>>>>>> framework for service function chaining that >>>>>>>>>>>>>> includes the necessary protocols >>>>>>>>>>>> or >>>>>>>>>>>>>> protocol extensions to convey the service path >>>>>>>>>>>>>> and service path information to nodes that >>>>>>>>>>>>>> implement service functions, as well >>>>>>>> as >>>>>>>>>>>>>> mechanisms for steering traffic through service >>>>>>>>>>>>>> functions. The >>>>>>>>>>>> working >>>>>>>>>>>>>> group will also examine what information needs >>>>>>>>>>>>>> to be gathered from >>>>>>>>>>>> the >>>>>>>>>>>>>> network and service functions in support of >>>>>>>>>>>>>> service function >>>>>>>>>> chaining >>>>>>>>>>>>>> and how that information may be made available >>>>>>>>>>>>>> to nodes that implement >>>>>>>>>>>> the >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Specifically, the SFC WG is chartered to >>>>>>>>>>>>>> deliver the >>>>> following: >>>>>>>>>>>>>> >>>>>>>>>>>>>> 1) Problem Statement: This document will >>>>>>>>>>>>>> provide a summary of >>>>>>>> the >>>>>>>>>>>>>> problem space to be addressed by the WG >>>>>>>>>>>>>> including example >>>>>>>> high- >>>>>>>>>>>>>> level use cases. Additionally, the WG will >>>>>>>>>>>>>> normalize >>>>>>>>>> nomenclature >>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2) Architecture: This document will provide a >>>>>>>>>>>>>> description of >>>>>>> the >>>>>>>>>>>>>> architectural building blocks and their >>>>>>>>>>>>>> relationships >>>>>>>> including >>>>>>>>>>>>>> interconnection, placement of capabilities, >>>>>>>>>>>>>> management, diagnostics, design analysis, and >>>>>>>>>>>>>> security models, as well >>>>>>> as >>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 3) Generic Service Function Chaining >>>>>>>>>>>>>> Encapsulation: A document >>>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for conveying the service function chain and >>>>>>>>>>>>>> the service function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information >>>>>>>>>>>>>> between nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended >>>>>>>>>>>>>> that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied >>>>>>>>>>>>>> and the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is being constructed. That is, the same >>>>>>>>>>>>>> encapsulation may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>>> layer or at any other layer, and the same >>>>>>>>>>>>>> encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>>>>>>>>>>> service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents >>>>>>>>>>>>>> will be >>>>>>>> developed to >>>>>>>>>>>>>> describe requirements and protocols necessary >>>>>>>>>>>>>> to convey >>>>>>>>>>>> information >>>>>>>>>>>>>> to service function implementation points. >>>>>>>>>>>>>> Where possible, >>>>>>>>>>>> existing >>>>>>>>>>>>>> IETF protocols will be used and extended. All >>>>>>>>>>>>>> protocol >>>>>>>>>> extensions >>>>>>>>>>>>>> work should be carried out in the working >>>>>>>>>>>>>> groups responsible for >>>>>>>>>>>> the >>>>>>>>>>>>>> protocols being modified in coordination with >>>>>>>>>>>>>> this working >>>>>>>>>> group, >>>>>>>>>>>>>> but may be done in this working group after >>>>>>>>>>>>>> agreement with all >>>>>>>> the >>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> 5) Manageability: Work on the management and >>>>>>>>>>>>>> configuration of >>>>>>>>>> service >>>>>>>>>>>>>> functions in support of SFC components will >>>>>>>>>>>>>> certainly be >>>>>>>> needed, >>>>>>>>>>>>>> but first needs to be better understood and >>>>>>>>>>>>>> scoped. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>> >>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational >>>>>>>>>>>>>> document(s) defining the >>>>>>>>>>>> problem >>>>>>>>>>>>>> statement and core use cases for Service >>>>>>>>>>>>>> Function Chaining >>>>>>>>>>>>>> >>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible >>>>>>>>>>>>>> charter modifications for management and >>>>>>>>>>>>>> configuration of SFC components >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document >>>>>>>>>>>>>> defining the >>>>>>>>>>>> architecture >>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a >>>>>>>>>>>>>> generic service function chaining encapsulation >>>>>>>>>>>>>> protocol >>>>>>>>>>>>>> >>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track >>>>>>>>>>>>>> document specifying the >>>>>>>>>>>> generic >>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> nsc mailing list nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> >>>>>>>> _______________________________________________ nsc mailing >>>>>>>> list nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ nsc mailing >>>>>>>> list nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ nsc mailing >>>>>>>> list nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>>>> _______________________________________________ nsc mailing list >>>>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ nsc mailing list >>>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > > From david.i.allan@ericsson.com Thu Nov 14 06:56:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCD2B21E80EB for ; Thu, 14 Nov 2013 06:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=0.623, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhXOYe0STgJ7 for ; Thu, 14 Nov 2013 06:56:46 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 692C911E80F2 for ; Thu, 14 Nov 2013 06:56:46 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-95-5284e4ab061e Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 1E.5B.04556.BA4E4825; Thu, 14 Nov 2013 15:56:43 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 09:56:42 -0500 From: David Allan I To: "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO4Fj+iBkfX7fLf02lvFYuCvTIzZojTSqwgAEIvYCAAHxFQA== Date: Thu, 14 Nov 2013 14:56:42 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUyuXSPn+7qJy1BBt/bLCw2TFnCZnF83342 ByaPliNvWT2WLPnJFMAUxWWTkpqTWZZapG+XwJVx7HlYwYxtzBX9LecZGxh/rGLuYuTkkBAw kXiydjEbhC0mceHeeiCbi0NI4AijxK/Jh5ghnOWMEk++fWcHqWITMJDY8/8LI4gtIuArce9C P1i3sECUxOGWJ2wQ8WiJ5/MvsEDYThK/Pr9lBbFZBFQlLm9cBdbLC9S74e57qAUrmSQubn4G toBTIEzi9Jk/YDYj0EnfT61hArGZBcQlbj2ZzwRxqoDEkj3noV4QlXj5+B8rhK0sseTJfqDF HED1mhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToLoWMWko5ZSDoWMLKsYuQoLU4ty003 MtzECIyHYxJsjjsYF3yyPMQozcGiJM775a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbG qhCNuOVuXmuWXap/XVh2Z8n09AnZ07be6NC4wlh33XUCy/n+QysV73qJrT3puuhYaPyxiBix UK8r2YzLXJxL17bv8DM9veSIttvSaX7zKuqX2XClKQZm+r05f+fsuT0FAp4S5mc6azJndb66 fDbKQi9UVD4xxeGLtJSIDw/LxGuvXosH7OhXYinOSDTUYi4qTgQAXZggnVUCAAA= Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 14:56:52 -0000 SSB0aGluayBpdCBpcyBnb2luZyB0byBiZSBhIHJhcmUgZXZlbnQsIGFzIHdoYXQgaXMgbW9yZSBs aWtlbHkgaXMgdGhlIGZyb250IGVuZCBvZiB0aGUgY2hhaW4gaXMgZHluYW1pY2FsbHkgbW9kaWZp ZWQgc28gc3Vic2VxdWVudCBwYWNrZXRzIGluIGEgZmxvdyBza2lwIGNlcnRhaW4gZnVuY3Rpb25z LiBIZW5jZSBhIGdyYXBoIG1vcmUgb2Z0ZW4gdGhhbiBub3QgaXMgbG9naWNhbGx5IFAyUC4gRmFj aWxpdGF0ZXMgdGVzdGluZyBhbW9uZ3N0IG90aGVyIGJlbmVmaXRzLg0KDQpBcyBzdWNoIEknZCBu b3Qgd2FudCB0byBiZSBwcmVzY3JpcHRpdmUgYXMgdG8gaG93IGFuZCB3aGVyZSBpdCBpcyBkb25l Li4uLg0KDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb25neXUg TGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXSANClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMTMsIDIwMTMgNjozMCBQTQ0KVG86IERhdmlkIEFsbGFuIEk7IG5zY0BpZXRm Lm9yZw0KU3ViamVjdDogUkU6IFtuc2NdIEZXOiByZSBjbGFzc2lmaWNhdGlvbiAmIGJyYW5jaGlu Zywgd2FzOiBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQoNCkhpIERhdmUsDQoNCllvdXIg aW5mZXJyZWQgcmVzdHJpY3Rpb24gbWF5IGJlIG5vdCBhbHdheXMgdHJ1ZS4gSW4gZ2VuZXJhbCwg c2VydmljZSBmdW5jdGlvbnMgc2hvdWxkIGJlIGFibGUgdG8gY29tcG9zZSBhIGNoYWluIGFyYml0 cmFyaWx5LiBQYXJ0aWN1bGFybHkgZm9yIGJyYW5jaGluZywgYXMgSSBzdWdnZXN0ZWQgaW4gcHJl dmlvdXMgZW1haWwsIHNlcnZpY2UgZnVuY3Rpb24gc2hhbGwgbm90IGRpcmVjdGx5IGltcGFjdCBw YWNrZXQgZm9yd2FyZGluZy4gVGhpcyBwcmVjbHVkZXMgdGhlIHJlc3RyaWN0aW9uIHlvdSBtZW50 aW9uZWQuIEZvcndhcmRpbmcgcGxhbmUgY2FuIGRlY2lkZSB3aGV0aGVyIGEgYnJhbmNoaW5nIGFj dGlvbiBzaG91bGQgYmUgdGFrZW4gYnkgcmVjbGFzc2lmaWNhdGlvbiBvciBub3QgcGVyIHNlcnZp Y2UgY2hhaW4uDQoNCkRvZXMgdGhpcyBtYWtlIHNlbnNlPw0KDQpIb25neXUNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IERhdmlkIEFsbGFuIEkgW21haWx0bzpkYXZpZC5pLmFs bGFuQGVyaWNzc29uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIwMTMgMTE6 NDUgUE0NClRvOiBIb25neXUgTGkgKEp1bGlvKTsgbnNjQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCg0KSEkgSG9uZ3l1Og0KDQpJIHRoaW5rIHdlIHdpbGwgaGF2ZSBz Y2VuYXJpb3Mgd2hlcmUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFwcGVhcnMgaW4gbW9yZSB0aGFuIG9u ZSBjaGFpbiwgYXMgd291bGQgYmUgdGhlIGNhc2UsIGZvciBleGFtcGxlLCBpZiBzb21lIGZsb3dz IGNvdWxkIGR5bmFtaWNhbGx5IGJ5cGFzcyBEUEkgYnV0IHN0aWxsIG5lZWRlZCB0byB0cmFuc2l0 IGEgY29tbW9uIHNldCBvZiBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1bmN0aW9ucy4uLg0KDQpPbmNlIHlv dSBwb3N0dWxhdGUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIGFwcGVhcmluZyBpbiBtb3Jl IHRoYW4gb25lIGNoYWluLCBpdCBzZWVtcyBhcnRpZmljaWFsbHkgcmVzdHJpY3RpdmUgbm90IHRv IHBlcm1pdCBzdWNoIGEgZnVuY3Rpb24gdG8gYWxzbyBpbXBsZW1lbnQgYnJhbmNoaW5nLCBhbGwg dGhlIGNvbnRyb2wgc3RydWN0dXJlcyB3b3VsZCBhbHJlYWR5IGJlIHRoZXJlLg0KDQpSZ2RzDQpE YXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb25neXUgTGkgKEp1bGlv KSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJl ciAxMywgMjAxMyAyOjEyIEFNDQpUbzogRGF2aWQgQWxsYW4gSTsgbnNjQGlldGYub3JnDQpTdWJq ZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1 cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KTWF5IEkgc3VnZ2VzdCBzdW1tYXJ5IG9mIG15 IHZpZXdzIGhlcmU6DQoNCjEuIEJyYW5jaCBpcyBhIHNvcnQgb2YgdXNlIGNhc2Ugb3Igc2NlbmFy aW8sIHdoaWxlIHJlY2xhc3NpZmljYXRpb24gaXMgYSB3YXkgdG8gc29sdmUgdGhlIHByb2JsZW0u DQoyLiBTZXJ2aWNlIEZ1bmN0aW9ucyBzaG91bGQgYmUgZGVjb3VwbGVkIHdpdGggdGhlIGNoYWlu IGl0c2VsZi4NCglNZWFuaW5nLCBhIFNGIHNoYWxsIG5vdCAqZGlyZWN0bHkqIGltcGFjdCB0aGUg Zm9yd2FyZGluZyBvZiBwYWNrZXRzIGluIGEgY2hhaW4uIEJyYW5jaGluZyBzaG91bGQgYmUgcGVy Zm9ybWVkIGJ5IGNoYWluIGZvcndhcmRpbmcgbm9kZXMsIHBvc3NpYmx5IHVuZGVyIGNvbnRyb2wg b2YgYSBjb250cm9sIG5vZGUuIFRoZSByZWFzb24gZm9yIHRoaXMgaXMgaW4gTkZWIHdvcmxkLCBz ZXJ2aWNlIGZ1bmN0aW9ucyBtYXkgY29tZSBmcm9tIGEgdGhpcmQgcGFydHksIHdoaWxlIGNoYWlu IGlzIHByb3ZpZGVkIGJ5IHRoZSBpbmZyYXN0cnVjdHVyZSBvZiB0aGUgbmV0d29yay4gVGhlcmUg bXVzdCBiZSBhIGN1c2hpb24gYXZvaWRpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uIG9wZXJhdGluZyBp bmZyYXN0cnVjdHVyZSBkaXJlY3RseS4NCjMuIChSZSljbGFzc2lmaWNhdGlvbiBpcyBiYXNlZCBv biBpbmZvIGluIGEgcGFja2V0Lg0KCVRoaXMgaXMgdmVyeSBnZW5lcmFsLiBTdWNoIGluZm8gY291 bGQgYmUgTDJ+TDcgZGVyaXZlZCBmcm9tIGEgdXNlcidzIHBhY2tldCwgYXMgd2VsbCBhcyBzb21l IGluZm8gbGlrZSBtZXRhZGF0YSBpbiBhIFNGQyBoZWFkZXIuIEFzIGNsYXNzaWZpY2F0aW9uIGlz IG91dCBvZiBzY29wZSBvZiBTRkMsIHdlIGRvbid0IGhhdmUgdG8gcHJvdmlkZSB0b28gbXVjaCBk ZXRhaWxzIG9mIGhvdyB0byBkbyBjbGFzc2lmaWNhdGlvbi4NCjQuIENoYWluIHNlZ21lbnRzIHN0 aXRjaGluZyBpcyByZWxhdGl2ZWx5IGEgZWFzeSB3YXkgZm9yIGJyYW5jaGluZy4gQ29tcGFyZWQg d2l0aCBjaGFpbnMgYW5kIHN1YmNoYWlucywgd2hpY2ggbWF5IHJlcXVpcmUgYSBtb3JlIGNvbXBs ZXggaGVhZGVyIGFuZCBmb3J3YXJkaW5nIGNhcGFiaWxpdGllcy4NCk15IHR3byBjZW50cy4NCkhv bmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIEFs bGFuIEkNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIwMTMgMzowNCBBTQ0KVG86IG5z Y0BpZXRmLm9yZw0KU3ViamVjdDogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNo aW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KSGk6DQoocmVzZW5kIHdp dGggcmVjaXBpZW50IGxpc3QgY2xlYW5lZCB1cCkNCg0KSSBhZ3JlZSB3ZSBhcmUgZGlzY3Vzc2lu ZyBtdWx0aXBsZSBjb25jZXB0cywgY2xhc3NpZmljYXRpb24gYW5kIGZsb3ctc3Vic2V0dGluZy4g UGVyaGFwcyBtb3JlIDstKQ0KDQpEZWZpbmluZyBhIGZsb3cgc3Vic2V0IGNhbiBiZSBhIHJlc3Vs dCBvZiBjbGFzc2lmaWNhdGlvbiwgYnV0IGl0IGlzIG5vdCB0aGUgZXhjbHVzaXZlIG1lY2hhbmlz bS4gQnJhbmNoaW5nIGlzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGZsb3cgc3Vic2V0cyBhcmUgZXhw b3NlZCBhbmQgbWFwcGVkIHRvIGEgc2V0IG9mIHN1YmNoYWlucyBzdWNoIHRoYXQgaXQgY2FuIGJl IGlkZW50aWZpZWQgaW4gdGhlIGRhdGFwbGFuZS4uLg0KDQpUaGF0J3MgdGhlIHZpZXcgZnJvbSBo ZXJlDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBuc2MtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2 aWQgTGFrZSAoZGxha2UpDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxMDo1MSBB TQ0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBLZXZpbiBKIE1hOyBTdXJlbmRyYSBLdW1h ciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IExpbmRhIER1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykN CkNjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQpTdWJqZWN0 OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQpVbmRlcnN0b29kIC0g bWF5YmUganVzdCBhIGxpdHRsZSBsb2NhbGlzZWQgd2FybWluZyBvZiB0aGUgc2VhIHRoZW4gPyAg IEJ1dCBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gY29uc2lkZXIgd2hlcmUgYW5kIGhvdyBwb2xp Y3kgaXMgZGVmaW5lZC9zZXQgZXZlbiBmb3IgdGhlIHNpbmdsZS1kb21haW4gaW5zdGFuY2UuDQoN CkkgZG9uJ3QgdGhpbmsgd2UgY2FuIGFzc3VtZSB0aGF0IGFueSBMMS0zIGRldmljZSB3aWxsIGJl IGFibGUgdG8gZGV0ZXJtaW5lIG11Y2ggdXNlZnVsIGluZm9ybWF0aW9uIGZyb20gdGhlIGRhdGEt cGxhbmUuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKaW0gR3VpY2hhcmQg KGpndWljaGFyKQ0KU2VudDogMTIgTm92ZW1iZXIgMjAxMyAxMDo0NA0KVG86IERhdmlkIExha2Ug KGRsYWtlKTsgS2V2aW4gSiBNYTsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBSb24gUGFya2Vy OyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQpDYzogVGhvbWFzIE5hcnRlbjsgbnNj QGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCg0KQXMgZGlzY3Vzc2VkIGR1cmluZyB0aGUgQk9GIG91ciBpbml0 aWFsIHdvcmsgaXMgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBmb3Igc29tZSBvZiB0aGUg dmVyeSByZWFzb25zIHlvdSBwb2ludCBvdXQuIFdlIG5lZWQgdG8ga2VlcCBmb2N1c2VkIHdpdGhv dXQgdHJ5aW5nIHRvIGJvaWwgdGhlIG9jZWFuIHJpZ2h0IG9mZiB0aGUgYmF0Lg0KDQpPbiAxMS8x Mi8xMyAxOjM2IFBNLCAiRGF2aWQgTGFrZSAoZGxha2UpIiA8ZGxha2VAY2lzY28uY29tPiB3cm90 ZToNCg0KPkV4YWN0bHkuICBCdXQgaG93IGNhbiBuZXR3b3JrLWNvbXBvbmVudHMgInRlcm1pbmF0 ZSIgYW4gYXBwbGljYXRpb24gPz8/Pw0KPg0KPkkgdGhpbmsgd2UgbmVlZCBhIGdvb2QgdW5kZXJz dGFuZGluZyBvZiBhIHJlY3Vyc2l2ZSBwb2xpY3kgbWVjaGFuaXNtIA0KPihyZWN1cnNpdmUgYmVj YXVzZSBhIHVzZXItbGFuZCBhcHBsaWNhdGlvbiB3aWxsIHJpZGUgd2l0aCBhIHNwZWNpZmljIA0K PnBvbGljeSBhY3Jvc3MgcG90ZW50aWFsbHkgZGlmZmVyZW50IHNldHMgb2YgY2FycmllciBwb2xp Y2llcykuDQo+DQo+SSBoYXRlIHRvIGJyaW5nIHRoaXMgdXAgbm93LCBidXQgd2UgYWxzbyBuZWVk IHRvIHRoaW5rIGFib3V0IHRoaXMgDQo+bXVsdGktZG9tYWluIGlzc3VlIC0gaWYgSSBzZXQgYSBw b2xpY3kgYXMgYSB1c2VyLCBjaGFuY2VzIGFyZSBJIHdpbGwgYmUgDQo+Y3Jvc3Npbmcgc2V2ZXJh bCBkb21haW4gYm91bmRhcmllcy4gIEFyZSB3ZSBleHBlY3RpbmcgdGhlIHNlcnZpY2UgDQo+aGVh ZGVycyB0byBkZWZpbmUgdGhlIHNlcnZpY2UgY2hhaW5pbmcgZm9yIHRoZSBkdXJhdGlvbiBvZiB0 aGUgZW50aXJlIA0KPmZsb3cgYWNyb3NzIGFsbCBkb21haW5zLCBvciBqdXN0IGFjcm9zcyBhIHNp bmdsZSBvbmUgPw0KPg0KPkluIHdoaWNoIGNhc2UsIGRvIEkgaGF2ZSB0byByZS1zZXQgcG9saWN5 IGFzIEkgdHJhdmVyc2UgZG9tYWlucyAgYW5kDQo+d2hlcmUgZG9lcyB0aGF0IHBvbGljeSBnZXQg c2V0ID8gICBJdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBzZXQgcG9saWN5DQo+b25jZSBiYXNl ZCBvbiBMNS03IG5lZWRzLCBhbmQgaGF2ZSB0aGF0IGluc3RhbnRpYXRlZCBhY3Jvc3MgdGhlIA0K Pm11bHRpcGxlIGRvbWFpbnMuDQo+DQo+QWdhaW4sIHRoaXMgYXBwZWFycyB0byBiZSBvdXRzaWRl IHRoZSBzY29wZSBvZiBTRkMsIGJ1dCBwcmV0dHkgcmVsZXZhbnQgDQo+dG8gaG93IGl0IHdvdWxk IG9wZXJhdGUgaW4gdGhlIHJlYWwgd29ybGQuDQo+DQo+RGF2aWQNCj4NCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IEtldmluIEogTWEgW21haWx0bzprZXZpbi5tYUBhenVraXN5 c3RlbXMuY29tXQ0KPlNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMTA6MjcNCj5UbzogRGF2aWQgTGFr ZSAoZGxha2UpOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7IExpbmRhIA0K PkR1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCj5DYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYu b3JnOyBTdW1hbmRyYSBNYWplZQ0KPlN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+DQo+PiBJbiB0aG9zZSBjaXJjdW1zdGFuY2VzLCBvbmx5IHRoZSBlbmQg YXBwbGljYXRpb25zIHRoZW1zZWx2ZXMgb3IgYSANCj4+IHJlYXNvbmFibHkgYnJvYWQtYnJ1c2hl ZCBjbGFzc2lmaWNhdGlvbiAocmVhbGx5IHRyYWZmaWMgc3RlZXJpbmcgDQo+PiBiYXNlZCBvbiB3 aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcgdG8gYmUgdXNlZnVsIC0gaXMgVEhB VCANCj4+IHdoYXQgd2UncmUgYWltaW5nIGZvciBoZXJlID8NCj4NCj5JIHdvdWxkIGNlcnRhaW5s eSBob3BlIG5vdCwgYnV0IHRoYXQgaGFzIGJlZW4gbXkgY29uY2VybiBhcyB3ZWxsLg0KPkFwcGxp Y2F0aW9uIGxheWVyIHRlcm1pbmF0aW9uIGFuZCByZS1jbGFzc2lmaWNhdGlvbiBzZWVtcyBhIG11 c3Q/DQo+DQo+LS0gIEtldmluIEouIE1hDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4gRnJvbTogRGF2aWQgTGFrZSAoZGxha2UpIFttYWlsdG86ZGxha2VAY2lzY28uY29tXQ0K Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTowMCBQTQ0KPj4gVG86IFN1cmVu ZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsgS2V2aW4gSiBNYTsgTGluZGEgRHVuYmFy OyANCj4+IEhvbmd5dSBMaSAoSnVsaW8pDQo+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYu b3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4+DQo+PiBQb2xpY3kgbWF5IGJlIG91dHNpZGUgb2YgdGhlIHNjb3Bl IG9mIFNGQywgYnV0IHdpdGhvdXQgc3Ryb25nIG1hcHBpbmcgDQo+PiBiZXR3ZWVuIFBvbGljeSBh bmQgdGhlIGluc2VydGVkIFNlcnZpY2UgSGVhZGVyKHMpLCB3ZSBydW4tdGhlLXJpc2sgb2YgDQo+ PiBsaW1pdGluZyB0aGUgZWZmaWNhY3kgb2YgdGhlIHByb3RvY29sIElNTy4NCj4+DQo+PiBGb3Ig ZXhhbXBsZSwgaW4gYSB3b3JsZCB3aGVyZSB0aGUgbmV0d29yayBoYXMgImdvbmUgZGFyaywiIChh cyBwZXIgDQo+PiB0aGUgSUVURiBUZWNobmljYWwgUGxlbmFyeSA/Oi0pICkgd2hhdCBpcyBvdXIg YWJpbGl0eSB0byBkZXRlcm1pbmUgDQo+PiBwb2xpY3kgYmFzZWQgb24gRFBJIG9mIHBhY2tldHMt aW4tZmxpZ2h0ID8NCj4+DQo+PiBJbiB0aG9zZSBjaXJjdW1zdGFuY2VzLCBvbmx5IHRoZSBlbmQg YXBwbGljYXRpb25zIHRoZW1zZWx2ZXMgb3IgYSANCj4+IHJlYXNvbmFibHkgYnJvYWQtYnJ1c2hl ZCBjbGFzc2lmaWNhdGlvbiAocmVhbGx5IHRyYWZmaWMgc3RlZXJpbmcgDQo+PiBiYXNlZCBvbiB3 aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcgdG8gYmUgdXNlZnVsIC0gaXMgVEhB VCANCj4+IHdoYXQgd2UncmUgYWltaW5nIGZvciBoZXJlID8NCj4+DQo+PiBEYXZpZA0KPj4NCj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+PiBTdXJlbmRy YSBLdW1hciAoc21rdW1hcikNCj4+IFNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMDk6MjYNCj4+IFRv OiBSb24gUGFya2VyOyBLZXZpbiBKIE1hOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8p DQo+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4g U3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+DQo+PiBS b24sDQo+Pg0KPj4gQ2xhc3NpZmljYXRpb24gb2YgdHJhZmZpYyBpcyB3ZWxsIHVuZGVyc3Rvb2Qg YW5kIHdlIGRvIG5vdCBoYXZlIHRvIA0KPj4gcmVkZWZpbmUgaXQgLSBpdCdzIGJlZW4gYXJvdW5k IGZvciBhbGwgdGhlIHRpbWUgbWlkZGxlIGJveGVzIGhhdmUgDQo+PiBiZWVuIG9yIGZvciB0aGF0 IG1hdHRlciB0aGUgTDIvTDMgZGV2aWNlcy4gQWxsIHdlIGFyZSB0YWxraW5nIGFib3V0IA0KPj4g aXMgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIGNsYXNzaWZpY2F0aW9uIHRvIGJyYW5jaGluZyBp biBTRkMuDQo+Pg0KPj4gWW91IGFyZSByaWdodCwgaXQgaXMgYWxsIGFib3V0IHBvbGljeSB3aGlj aCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBTRkMuDQo+Pg0KPj4gU3VyZW5kcmEuDQo+Pg0KPj4g T24gMTEvMTIvMTMgNzo1MyBBTSwgIlJvbiBQYXJrZXIiIDxSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tPg0KPj53cm90ZToNCj4+DQo+PiA+SSB0aGluayB0aGUgbGFjayBvZiBkZWZpbml0 aW9uIG9mICJyZWNsYXNzaWZpY2F0aW9uIiBtYXkgYmUgY2F1c2luZw0KPj5zb21lDQo+PiA+bWlz dW5kZXJzdGFuZGluZ3MgaGVyZS4gICAgQSBicmFuY2ggd291bGQgb2NjdXIgZm9yIHNvbWUgcG9s aWN5LWRyaXZlbg0KPj4gPnJlYXNvbiBiYXNlZCBvbiB0aGUgYmVoYXZpb3IgYW5kIGNvbmNsdXNp b25zIG9mIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLA0KPj4gPml0c2VsZi4gICBUaGUgZ3JhcGggd291 bGQgcmVwcmVzZW50IHRoZSBmYWN0IHRoYXQgdGhlcmUgaXMgYSBicmFuY2gNCj4+ID5wb2ludCwg YnV0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLCBpdHNlbGYsIGJlaW5nIGF3YXJlIHRoYXQgaXQgaXMg YSANCj4+ID5icmFuY2hpbmcgcG9pbnQgd291bGQgY29udGFpbiB0aGUgcG9saWN5IGFuZCBsb2dp YyB0byBkZWNpZGUgb24gd2hpY2gNCj4+ID5icmFuY2ggdG8gdGFrZS4gICBTcGVjaWZ5aW5nIHRo YXQgcG9saWN5IGFuZCBsb2dpYyBpcyBvdXQgb2Ygc2NvcGUsDQo+PklNTy4NCj4+ID4NCj4+ID4g ICBSb24NCj4+ID4NCj4+ID4NCj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPkZy b206IEtldmluIEogTWEgW21haWx0bzprZXZpbi5tYUBhenVraXN5c3RlbXMuY29tXQ0KPj4gPlNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEwOjQ5IEFNDQo+PiA+VG86IExpbmRhIER1 bmJhcjsgUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbykNCj4+ID5DYzogVGhvbWFzIE5hcnRl bjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFN1bWFuZHJhIA0KPj4g Pk1hamVlDQo+PiA+U3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0 ZXINCj4+ID4NCj4+ID5IaSBMaW5kYSwNCj4+ID4NCj4+ID4gIEFyZSB5b3Ugc2F5aW5nIHRoYXQg YSBicmFuY2hpbmcgcG9pbnQgaXMgIm5ldmVyIiBhIA0KPj4gPiByZWNsYXNzaWZpY2F0aW9uIHBv aW50LCBvciBhcmUgeW91IHNheWluZyB0aGF0IGEgYnJhbmNoaW5nIHBvaW50ICJkb2VzIG5vdCBo YXZlIHRvIGJlIg0KPj4gPiAgYSByZWNsYXNzaWZpY2F0aW9uIHBvaW50Pw0KPj4gPg0KPj4gPiAg SSB0aGluayB0aGlzIGlzIGFuIGltcG9ydGFudCBkaXN0aW5jdGlvbiB0aGF0IG5lZWRzIHRvIGJl IGNsYXJpZmllZC4NCj4+ID4gIElmIGJyYW5jaGluZyBpcyBuZXZlciByZWNsYXNzaWZpY2F0aW9u LCB0aGVuIHRoZSBtZWFuaW5nIG9mIGEgDQo+PiA+IGNoYWluIGlzIGRpZmZlcmVudCB0aGFuIEkg b3JpZ2luYWxseSBpbmZlcnJlZC4gIElmIHRoZSBjaGFpbiBpcyBhIA0KPj4gPiB0cmVlIHdpdGgg b3RoZXIgImJyYW5jaGluZyIgcG9pbnRzIGluIGl0LCB0aGVuIHRoYXQgbGltaXRzIHRoZSANCj4+ ID4gc2NvcGUgb2YgdGhlIHByb2JsZW0gc3RhdGVtZW50IGdvYWxzLg0KPj4gPg0KPj4gPiAgV2hp bGUgdGhpcyBjb3VsZCBiZSBhIGRlZ2VuZXJhdGUgY2FzZSwgYW5kIGFueSBpbXBsZW1lbnRhdGlv biANCj4+ID4gY291bGQgZGVmaW5lIGJhZCBzZXJ2aWNlIGNoYWlucywgaXMgaXQgdGhlIGludGVu dCBvZiBTRkMgdG8gb25seSANCj4+ID4gbG9vayBhdCB0aGUgc2ltcGxlciBwYWNrZXQtbGV2ZWwg Y2xhc3NpZmljYXRpb24gY2FzZXMsIG9yIGlzIGl0IHRoZSANCj4+ID4gaW50ZW50IHRvIGNvbnNp ZGVyIHRoZSBjYXNlIHdoZXJlIGEgYnJhbmNoaW5nIHBvaW50IGlzIHZpZXdlZCBhcyBhIA0KPj4g PiByZS1jbGFzc2lmaWNhdGlvbiBwb2ludD8NCj4+ID4NCj4+ID50aGFueC4NCj4+ID4NCj4+ID4t LSAgS2V2aW4gSi4gTWENCj4+ID4NCj4+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ PiA+PiBGcm9tOiBMaW5kYSBEdW5iYXIgW21haWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbV0N Cj4+ID4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEwOjM0IEFNDQo+PiA+PiBU bzogUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbyk7IEtldmluIEogTWENCj4+ID4+IENjOiBU aG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+ PiA+PiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJv cG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+DQo+PiA+PiBSb24sDQo+PiA+Pg0KPj4gPj4gRmlyc3Qs IHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0ICJicmFuY2hpbmciICE9IHJlY2xhc3NpZmljYXRp b24sIA0KPj4gPj5hZ3JlZT8NCj4+ID4+DQo+PiA+PiBTZWNvbmQsIHRoZSByZXByZXNlbnRhdGlv biBvZiBicmFuY2hpbmcgKG9yIHNlcnZpY2UgZ3JhcGgpIGNhbiBiZSANCj4+ID4+IGluIGEgZm9y bSBvZiBsb2dpYyBvbiBhIHNlcnZpY2UgZnVuY3Rpb24uIFNvbWUgc2VydmljZSBmdW5jdGlvbnMs IA0KPj4gPj4gZXNwZWNpYWxseSBMNyBiYXNlZCwgY2FuIHVzZSB2YWx1ZSBpbiBhIERhdGFiYXNl IHRvIGRldGVybWluZSB3aGF0IA0KPj4gPj4gaXMgdGhlIG5leHQgc2VydmljZSBmdW5jdGlvbi4N Cj4+ID4+DQo+PiA+PiBMaW5kYQ0KPj4gPj4NCj4+ID4+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+ID4+ID4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91 bmNlc0BpZXRmLm9yZ10gT24gDQo+PiA+PiA+IEJlaGFsZiBPZiBSb24gUGFya2VyDQo+PiA+PiA+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDg6MTYgQU0NCj4+ID4+ID4gVG86IEhv bmd5dSBMaSAoSnVsaW8pOyBLZXZpbiBKIE1hDQo+PiA+PiA+IENjOiBUaG9tYXMgTmFydGVuOyBu c2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+PiA+PiA+IFN1bWFuZHJh IE1hamVlDQo+PiA+PiA+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBj aGFydGVyDQo+PiA+PiA+DQo+PiA+PiA+IEhvbmd5dSwNCj4+ID4+ID4NCj4+ID4+ID4gSSBhZ3Jl ZSBjb21wbGV0ZWx5IHRoYXQgcmUtY2xhc3NpZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8gRFBJ Lg0KPj4gPj4gPg0KPj4gPj4gPiBBbmQgYWxzbywgdGhhdCBhbiBhcmVhIGZvciB1cyB0byBleHBs b3JlIGFzIGEgZ3JvdXAgaXMgaG93IHRvDQo+PiA+PnJlcHJlc2VudA0KPj4gPj4gPiB0aGUgc2Vy dmljZSBncmFwaC4gICBEbyB3ZSB3YW50IHRvIHJlcHJlc2VudCBpdCBhcyBhIHByb3BlciBncmFw aA0KPj4gd2l0aA0KPj4gPj4gPiBhbiBhZGphY2VuY3kgbGlzdCBvciBvdGhlciByZXByZXNlbnRh dGlvbmFsIG1vZGVsPyAgIE9yLCBkbyB3ZSB3YW50DQo+PiB0bw0KPj4gPj4gPiByZXByZXNlbnQg aXQgYXMgYSBzZXQgb2YgbGluZWFyIHNlZ21lbnRzIGFuZCBpZiBzbywgaG93IGFyZSB0aGUNCj4+ ID4+ID4gc2VnbWVudHMgY29ubmVjdGVkIGludG8gYSBncmFwaD8gICBPdGhlciBpZGVhcz8NCj4+ ID4+ID4NCj4+ID4+ID4gICAgUm9uDQo+PiA+PiA+DQo+PiA+PiA+DQo+PiA+PiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4gPj4gPiBCZWhhbGYgT2YgSG9uZ3l1 IExpIChKdWxpbykNCj4+ID4+ID4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgNjo1 NyBBTQ0KPj4gPj4gPiBUbzogUm9uIFBhcmtlcjsgS2V2aW4gSiBNYQ0KPj4gPj4gPiBDYzogVGhv bWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IA0KPj4g Pj4gPiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPg0KPj4gPj4gPiBCcmFuY2hpbmcvZm9ya2luZyBp cyBhIHZlcnkgaW50ZXJlc3RpbmcgdG9waWMgb2YgU0ZDLiBBYm91dCB0aGUNCj4+ID4+ID4gcmUt IGNsYXNzaWZpY2F0aW9uIHBvaW50LCBwcm9iYWJseSB3ZSBzaGFsbCBub3QgbGltaXQgaXQgdG8g RFBJLg0KPj4gPj4gPiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgcGFja2V0cyBnbyB0byBkaWZm ZXJlbnQgYnJhbmNoZXMgYWZ0ZXIgDQo+PiA+PiA+IGJlZW4gcHJvY2Vzc2VkIGJ5IGEgY2VydGFp biBzZXJ2aWNlIGZ1bmN0aW9uLCBkZWNpc2lvbiBvZiB3aGljaCANCj4+ID4+ID4gYnJhbmNoZXMg dG8gZ28gaXMgbWFkZSBiYXNlZCBvbiB0aGUgcmVzdWx0IG9mIHNlcnZpY2UgZnVuY3Rpb24ncyAN Cj4+ID4+ID4gcHJvY2VzcywgaS5lLiBub3QganVzdCByZS0gY2xhc3NpZmljYXRpb24gYnkgRFBJ Lg0KPj4gPj4gPg0KPj4gPj4gPiBIb25neXUNCj4+ID4+ID4NCj4+ID4+ID4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gDQo+PiA+PiA+IEJlaGFsZiBPZiBSb24gUGFya2Vy DQo+PiA+PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDc6NDUgUE0NCj4+ID4+ ID4gVG86IEtldmluIEogTWENCj4+ID4+ID4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9y ZzsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyANCj4+ID4+ID4gU3VtYW5kcmEgTWFqZWUNCj4+ ID4+ID4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ ID4+ID4NCj4+ID4+ID4gSGksIEtldmluDQo+PiA+PiA+DQo+PiA+PiA+IFlvdSBhc2sgYSBncmVh dCBxdWVzdGlvbiBhYm91dCBicmFuY2hpbmcgdGhlIGdyYXBoLiAgVGhlIGRldGFpbHMgDQo+PiA+ PiA+IGFyb3VuZCBob3cgdG8gY29udmV5IHRoZSBzZWxlY3Rpb24gb2YgdGhlIHN1YnRyZWUvc3Vi Z3JhcGggYXJlIA0KPj4gPj4gPiBzdGlsbA0KPj4gPj50byBiZQ0KPj4gPj4gPiBkZWZpbmVkLiAg IElzIGl0IG9uZSBjaGFpbiBpZCBmb3IgdGhlIHdob2xlIGdyYXBoPyAgIERvZXMgZWFjaA0KPj5i cmFuY2gNCj4+ID4+ID4gaGF2ZSBpdHMgb3duIGNoYWluIGlkPyAgIFNvbWUgY29tYmluYXRpb24/ DQo+PiA+PiA+DQo+PiA+PiA+ICAgIFJvbg0KPj4gPj4gPg0KPj4gPj4gPiBPbiBOb3YgMTIsIDIw MTMsIGF0IDE6NTIgQU0sICJLZXZpbiBKIE1hIg0KPj4gPj4gPiA8a2V2aW4ubWFAYXp1a2lzeXN0 ZW1zLmNvbT4NCj4+ID4+ID4gd3JvdGU6DQo+PiA+PiA+DQo+PiA+PiA+ID4+IFllcywgcmVjbGFz c2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRoZSBzZXJ2aWNlIHBhdGggYW5kIA0KPj4gPj4gPiA+PiBy ZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2RlIGFsb25nIGEgc2VydmljZSBw YXRoLg0KPj4gPj4gPiA+DQo+PiA+PiA+ID4gSnVzdCB0byBleHBhbmQgb24gdGhhdCwgZ29pbmcg YmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gDQo+PiA+PiA+ID4gYWJvdXQgc2VydmljZSBo ZWFkZXIgZW5jYXBzdWxhdGlvbiwgaXMgaXQgaW50ZW5kZWQgdGhhdCBhIA0KPj4gPj4gPiA+IGNo YWluIHRoYXQgaXMgcmUtY2xhc3NpZmllZCB3aWxsIGdldCBhIG5ldyBjaGFpbiBJRCB3aGljaCAN Cj4+ID4+ID4gPiBmdWxseSBkZXNjcmliZXMgYSBjaGFpbiB0aGF0IGlzIGEgc3VwZXJzZXQgb2Yg dGhlIG9yaWdpbmFsIA0KPj4gPj4gPiA+IGNoYWluIElELCBwcmlvciB0byBEUEktYmFzZWQgcmUt Y2xhc3NpZmljYXRpb24/ICAoYXNzdW1pbmcgdGhlIA0KPj4gPj4gPiA+IGdvYWwgaXMgImEgc2lu Z2xlIGNoYWluIElEIHRoYXQgaXMgY29tbW9ubHkgdW5kZXJzdG9vZCBhbG9uZyANCj4+ID4+ID4g PiB0aGUgZW50aXJlIHNlcnZpY2UNCj4+IGNoYWluIg0KPj4gPj4gPiA+IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cwMDYzOC5odG1sDQo+PiA+PiA+ ID4gKQ0KPj4gPj4gPiA+DQo+PiA+PiA+ID4gQW5kIHRoZSBhcHBsaWNhYmxlIHN1YnNldCBvZiB0 aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlIA0KPj4gPj4gPiA+IHBhdGhzIHdvdWxkIGJl IGNvbmZpZ3VyZWQgYXQgZWFjaCBhcHByb3ByaWF0ZSBzZXJ2aWNlIG5vZGU/DQo+PiA+PiA+ID4g ZS5nLiwgSUQgMTogTkFUICsgZmlyZXdhbGwgKyBEUEkNCj4+ID4+ID4gPiAgICAgIElEIDI6IE5B VCArIGZpcmV3YWxsICsgRFBJICsgQVYNCj4+ID4+ID4gPiAgICAgIElEIDM6IE5BVCArIGZpcmV3 YWxsICsgRFBJICsgQVYgKyBOQVQNCj4+ID4+ID4gPiAgICAgIElEIDQ6IE5BVCArIGZpcmV3YWxs ICsgRFBJICsgTkFUDQo+PiA+PiA+ID4gICAgICBJRCA1OiBOQVQgKyBmaXJld2FsbCArIERQSSAr IEFWICsgTEINCj4+ID4+ID4gPiAgICAgIElEIDY6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTEIN Cj4+ID4+ID4gPiAgICAgIElEIDc6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTEIgKyBDQUNIRQ0K Pj4gPj4gPiA+ICAgICAgSUQgODogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBDQUNIRQ0KPj4gPj4g PiA+ICAgICAgSUQgOTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQg0KPj4g Pj4gPiA+ICAgICAgSUQgMTA6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgTEIg KyBDQUNIRQ0KPj4gPj4gPiA+ICAgICAgSUQgMTE6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0 aW1pemVyICsgQ0FDSEUgV291bGQgDQo+PiA+PiA+ID4gZXZlcnkgZmxvdyB0aGVuIGJlIGluaXRp YWxseSBjbGFzc2lmaWVkIGFzIElEIDEsIGJ1dCANCj4+ID4+ID4gPiBldmVudHVhbGx5IGdldCBy ZS0NCj4+ID4+ID4gY2xhc3NpZmllZA0KPj4gPj4gPiA+IHRvIElEIDItMTEsIGFmdGVyIHRoZSBE UEkgcGhhc2U/DQo+PiA+PiA+ID4NCj4+ID4+ID4gPiB0aGFueC4NCj4+ID4+ID4gPg0KPj4gPj4g PiA+IC0tICBLZXZpbiBKLiBNYQ0KPj4gPj4gPiA+DQo+PiA+PiA+ID4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+IEZyb206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBb bWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPj4gPj4gPiA+PiBTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+PiA+PiA+ID4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFy a2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgDQo+PiA+PiA+ID4+IG5zY0BpZXRm Lm9yZw0KPj4gPj4gPiA+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMg Y2hhcnRlcg0KPj4gPj4gPiA+Pg0KPj4gPj4gPiA+Pg0KPj4gPj4gPiA+Pg0KPj4gPj4gPiA+Pj4g T24gMTEvMTEvMTMgOTo0NiBQTSwgIktldmluIEogTWEiIA0KPj4gPj4gPiA+Pj4gPGtldmluLm1h QGF6dWtpc3lzdGVtcy5jb20+DQo+PiA+Pndyb3RlOg0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+ IEhpIFN1cmVuZHJhLA0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+IENsYXNzaWZpY2F0aW9uIG1h eSBiZSBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGUgbGV2ZWwgb2Ygc2VydmljZSANCj4+ID4+ID4gPj4+ IHRoYXQNCj4+ID4+ID4gaXMNCj4+ID4+ID4gPj4+IGFwcGxpY2FibGUgaXMgZGVwZW5kZW50IHVw b24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIA0KPj4gPj4gPiA+Pj4gdGhhdCBjYW4NCj4+ ID4+ID4gYmUNCj4+ID4+ID4gPj4+IHBlcmZvcm1lZC4gIEFuIGFzc3VtcHRpb24gb2YgcGFja2V0 IGxldmVsIGVuY2Fwc3VsYXRpb24gaGFzDQo+PiA+PiA+ID4+IGltcGxpY2F0aW9ucw0KPj4gPj4g PiA+Pj4gb24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIGJlaW5nIHBlcmZvcm1lZD8gIElm IHRoZSANCj4+ID4+ID4gPj4+IHN0YXRlZA0KPj4gPj4gPiBnb2Fscw0KPj4gPj4gPiA+PiBhcmUN Cj4+ID4+ID4gPj4+IGZvciBmaXJld2FsbCBhbmQgbG9hZCBiYWxhbmNlciBmdW5jdGlvbmFsaXR5 LCB0aGVuIHRoZSANCj4+ID4+ID4gPj4+IGFwcGxpY2F0aW9uDQo+PiA+PiA+ID4+IGxldmVsDQo+ PiA+PiA+ID4+PiBuYXR1cmUgb2YgdGhvc2UgZnVuY3Rpb25zIG5lZWRzIHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudD8NCj4+ID4+ID4gPj4+IElmLCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHNlcnZp Y2UgZnVuY3Rpb24gc2NvcGUgaXMgbGltaXRlZCANCj4+ID4+ID4gPj4+IGR1ZSB0byBsaW1pdGF0 aW9ucyBpbiBjbGFzc2lmaWNhdGlvbiwgdGhhdCB3b3VsZCBiZSBhbmQgDQo+PiA+PiA+ID4+PiBp bXBvcnRhbnQgcGllY2Ugb2YNCj4+ID4+ID4gaW5mb3JtYXRpb24/DQo+PiA+PiA+ID4+Pg0KPj4g Pj4gPiA+Pj4gV3J0IHNlY3Rpb24gNC40IG9mIGRyYWZ0LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVz ZS1jYXNlcyB0aGUgDQo+PiA+PiA+ID4+PiBmb3JrIHBvaW50cyBvZiB0aGUgc2VydmljZSBwYXRo cyBzZWVtIGxpa2UgcmUtY2xhc3NpZmljYXRpb24NCj4+IHBvaW50cz8NCj4+ID4+ID4gPj4+IElz IHRoYXQgdGhlIGludGVycHJldGF0aW9uIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2 ZT8NCj4+ID4+ID4gPj4+IE9yIGlzIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGNsYXNzaWZp Y2F0aW9uIGV4Y2x1c2l2ZSBvZiANCj4+ID4+ID4gPj4+IERQSQ0KPj4gPj4gPiBmdW5jdGlvbmFs aXR5Pw0KPj4gPj4gPiA+PiA8U0s+IEkgaGF2ZSBub3QgZnVsbHkgcmVhZCB0aGF0IGRyYWZ0IHll dC4gQnV0IGluIGdlbmVyYWwsIGFzIA0KPj4gPj4gPiA+PiBkZXNjcmliZWQgaW4gdGhlIGFyY2gg ZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9mIHNlcnZpY2VzIGZvcm0gDQo+PiA+PiA+ID4+IGEgZ3Jh cGgsIHNlZ21lbnRzIG9mIHdoaWNoIGFyZSBzZXJ2aWNlIHBhdGhzLiBZZXMsIA0KPj4gPj4gPiA+ PiByZWNsYXNzaWZpY2F0aW9uIGNhbg0KPj4gPj4gPiBjaGFuZ2UNCj4+ID4+ID4gPj4gdGhlIHNl cnZpY2UgcGF0aCBhbmQgcmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZSAN Cj4+ID4+ID4gPj4gYWxvbmcNCj4+ID4+ID4gYSBzZXJ2aWNlIHBhdGguDQo+PiA+PiA+ID4+DQo+ PiA+PiA+ID4+IFN1cmVuZHJhLg0KPj4gPj4gPiA+Pj4NCj4+ID4+ID4gPj4+IHRoYW54Lg0KPj4g Pj4gPiA+Pj4NCj4+ID4+ID4gPj4+IC0tICBLZXZpbiBKLiBNYQ0KPj4gPj4gPiA+Pj4NCj4+ID4+ ID4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+IEZyb206IFN1 cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPj4gPj4g PiA+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEyOjA4IEFNDQo+PiA+PiA+ ID4+Pj4gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMg TmFydGVuOyANCj4+ID4+ID4gPj4+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+PiBTdWJqZWN0 OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+DQo+ PiA+PiA+ID4+Pj4gS2V2aW4sDQo+PiA+PiA+ID4+Pj4NCj4+ID4+ID4gPj4+PiBDbGFzc2lmaWNh dGlvbiBtZWNoYW5pc20gaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLiBJdCANCj4+ID4+ID4g Pj4+PiBjYW4gYmUgYmFzZWQNCj4+ID4+ID4gPj4gb24NCj4+ID4+ID4gPj4+PiB0aGUgcGFja2V0 IG9yIGluZm9ybWF0aW9uIG5vdCBpbiB0aGUgcGFja2V0KGVudmlyb25tZW50YWwgDQo+PiA+PiA+ ID4+Pj4gYXR0cmlidXRlcw0KPj4gPj4gPiA+PiBmb3INCj4+ID4+ID4gPj4+PiBpbnN0YW5jZSkg b3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlzIGltcG9ydGFudCBpcyANCj4+ID4+ID4g Pj4+PiB0aGF0IHN1Y2ggY2xhc3NpZmljYXRpb24gYWlkcyBpbiB0cmFmZmljIHNlbGVjdGlvbiBh bmQgDQo+PiA+PiA+ID4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpY2F0aW9uLg0KPj4gPj4gPiA+ Pj4+IEl0IGlzIG5vIGRpZmZlcmVudCBmcm9tIGEgcG9saWN5IGluIHRoaXMgcmVnYXJkIGV4Y2Vw dCB0aGF0IA0KPj4gPj4gPiA+Pj4+IHRoZSBwb2xpY3kgbm93IHNwZWNpZmllcyB0aGUgc2Vydmlj ZSBwYXRoLg0KPj4gPj4gPiA+Pj4+IEZ1cnRoZXIsIGNsYXNzaWZpY2F0aW9uIGlzIG5vdCBsaW1p dGVkIHRvIHRoZSBuZXR3b3JrIA0KPj4gPj4gPiA+Pj4+IGVsZW1lbnRzIGJ1dCB0aGUgc2Vydmlj ZSBmdW5jdGlvbnMgYXMgd2VsbC4gU29tZSBvZiB0aGlzIGlzIA0KPj4gPj4gPiA+Pj4+IGRlc2Ny aWJlZCBpbiB0aGUNCj4+ID4+ID4gPj4gYXJjaGl0ZWN0dXJlDQo+PiA+PiA+ID4+Pj4gZHJhZnRz IGFzIHdlbGwgLQ0KPj4gPj4gPiA+Pj4+ICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1xdWlubi1zZmMtYXJjaC8iLg0KPj4gPj4gPiA+Pj4+DQo+PiA+PiA+ID4+Pj4gU3Vy ZW5kcmEuDQo+PiA+PiA+ID4+Pj4NCj4+ID4+ID4gPj4+Pj4gT24gMTEvMTEvMTMgNzozMyBQTSwg IktldmluIEogTWEiDQo+PiA+PiA+ID4+Pj4+IDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0K Pj4gPj4gPiB3cm90ZToNCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4gPj4+Pj4gSGkgUm9uLA0KPj4g Pj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiBJIHdhcyB1bmFibGUgdG8gbWFrZSB0aGUgU0ZDIEJv RiBkdWUgdG8gYSBjb25mbGljdCB3aXRoIA0KPj4gPj4gPiA+Pj4+PiBDRE5JLCBidXQgSSBoYWQg YSBzaW1pbGFyIHF1ZXN0aW9uIHdydCBidWxsZXQgMTEgaW4gDQo+PiA+PiA+ID4+Pj4+IHNlY3Rp b24NCj4+ID4+ID4gPj4+Pj4gMiBvZiB0aGUNCj4+ID4+ID4gcHJvYmxlbQ0KPj4gPj4gPiA+Pj4+ PiBzdGF0ZW1lbnQ6DQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+ICAgMTEuICBQZXItU2Vy dmljZSAocmUpQ2xhc3NpZmljYXRpb246IENsYXNzaWZpY2F0aW9uIA0KPj4gPj4gPiA+Pj4+PiBv Y2N1cnMgYXQNCj4+ID4+ID4gZWFjaA0KPj4gPj4gPiA+Pj4+PiAgICAgICAgc2VydmljZSwgaW5k ZXBlbmRlbnQgZnJvbSBwcmV2aW91c2x5IGFwcGxpZWQgDQo+PiA+PiA+ID4+Pj4+IHNlcnZpY2UN Cj4+ID4+ID4gPj4+PiBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+Pj4+ICAgICAgICBUaGVzZSB1bnJl bGF0ZWQgY2xhc3NpZmljYXRpb24gZXZlbnRzIGNvbnN1bWUgDQo+PiA+PiA+ID4+Pj4+IHJlc291 cmNlcw0KPj4gPj4gPiBwZXINCj4+ID4+ID4gPj4+Pj4gICAgICAgIHNlcnZpY2UuICBNb3JlIGlt cG9ydGFudGx5LCB0aGUgY2xhc3NpZmljYXRpb24NCj4+ID4+ID4gZnVuY3Rpb25hbGl0eQ0KPj4g Pj4gPiA+Pj4+PiAgICAgICAgb2Z0ZW4gZGlmZmVycyBwZXIgc2VydmljZSBmdW5jdGlvbiBhbmQg c2VydmljZSANCj4+ID4+ID4gPj4+Pj4gZnVuY3Rpb24NCj4+ID4+ID4gPj4gY2Fubm90DQo+PiA+ PiA+ID4+Pj4+ICAgICAgICBsZXZlcmFnZSB0aGUgcmVzdWx0cyBmcm9tIG90aGVyIGRlcGxveWVk IG5ldHdvcmsgb3INCj4+ID4+ID4gc2VydmljZS4NCj4+ID4+ID4gPj4+Pj4NCj4+ID4+ID4gPj4+ Pj4gYXMgaXQgcmVsYXRlcyB0byBzZWN0aW9uIDUuMiBvZiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50 Og0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiAgIFRoZSBTRkMgQ2xhc3NpZmllciBjbGFz c2lmaWVzIHBhY2tldHMgYmFzZWQgb24gKHNvbWUgb2YpIA0KPj4gPj4gPiA+Pj4+PiB0aGUNCj4+ ID4+ID4gPj4+PiBjb250ZW50cw0KPj4gPj4gPiA+Pj4+PiAgIG9mIHRoZSBwYWNrZXQgaGVhZGVy LiAgQ29uY3JldGVseSwgaXQgY2xhc3NpZmllcyBwYWNrZXRzIA0KPj4gPj4gPiA+Pj4+PiBiYXNl ZCBvbg0KPj4gPj4gPiA+Pj4+IHRoZQ0KPj4gPj4gPiA+Pj4+PiAgIHBvc3NpYmxlIGNvbWJpbmF0 aW9uIG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsIHN1Y2ggDQo+PiA+PiA+ID4+Pj4+IGFz DQo+PiA+PiA+IHNvdXJjZQ0KPj4gPj4gPiA+Pj4+PiAgIGFkZHJlc3MsIGRlc3RpbmF0aW9uIGFk ZHJlc3MsIERTIGZpZWxkLCBwcm90b2NvbCBJRCwgDQo+PiA+PiA+ID4+Pj4+IHNvdXJjZQ0KPj4g Pj4gPiBwb3J0DQo+PiA+PiA+ID4+Pj4gYW5kDQo+PiA+PiA+ID4+Pj4+ICAgZGVzdGluYXRpb24g cG9ydCBudW1iZXJzLCBhbmQgYW55IG90aGVyIGluZm9ybWF0aW9uLg0KPj4gPj4gPiA+Pj4+Pg0K Pj4gPj4gPiA+Pj4+PiBBIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVyIGFzIGRlc2NyaWJlZCBpbiB0 aGUgZnJhbWV3b3JrIA0KPj4gPj4gPiA+Pj4+PiBkb2N1bWVudA0KPj4gPj4gPiA+Pj4+IHdvdWxk DQo+PiA+PiA+ID4+Pj4+IHNlZW0gdG8gYmUgbGltaXRlZCBpbiB3aGF0IGl0IGNhbiBjbGFzc2lm eT8gIFRoZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+PiBmdW5jdGlvbiBpZGVudGlmaWVyIGxvb2t1 cCBkb2VzIG5vdCBzZWVtIHRvIGJlIGEgDQo+PiA+PiA+ID4+Pj4+IHNpZ25pZmljYW50IG9wdGlt aXphdGlvbg0KPj4gPj4gPiA+PiBvdmVyDQo+PiA+PiA+ID4+Pj4+IGEgcGFja2V0LWJhc2VkIDUt dHVwbGUgbG9va3VwPyAgVGhlcmUgc2VlbXMgdG8gYmUgc29tZSANCj4+ID4+ID4gPj4+Pj4gbWlz c2luZw0KPj4gPj4gPiA+PiBkZXRhaWwNCj4+ID4+ID4gPj4+Pj4gd3J0IGhvdyBjbGFzc2lmaWNh dGlvbiBpbmZvcm1hdGlvbiBpcyBkZXRlcm1pbmVkIGFuZCByZXVzZWQ/DQo+PiA+PiA+ID4+Pj4+ DQo+PiA+PiA+ID4+Pj4+IFdoZW4gdGhpbmtpbmcgYWJvdXQgaGlnaGVyIGxldmVsIHNlcnZpY2Vz LCBlLmcuLCBIVFRQIGFuZCANCj4+ID4+ID4gPj4+Pj4gVExTDQo+PiA+PiA+ID4+Pj4gZW5jcnlw dGVkDQo+PiA+PiA+ID4+Pj4+IGZsb3dzLCBhIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVyIHNlZW1z IGluYWRlcXVhdGU/ICBJIHdhcyANCj4+ID4+ID4gPj4+Pj4gYWxzbw0KPj4gPj4gPiA+Pj4+IHdv bmRlcmluZw0KPj4gPj4gPiA+Pj4+PiBob3cgaW5kZXBlbmRlbnQgSExTIHNlZ21lbnQgcmVxdWVz dHMgbWlnaHQgYmUgY2xhc3NpZmllZCANCj4+ID4+ID4gPj4+Pj4gYW5kDQo+PiA+PiA+ID4+Pj4g YXNzb2NpYXRlZD8NCj4+ID4+ID4gPj4+Pj4gV2VyZSB0aGVzZSB0eXBlcyBvZiB1c2UgY2FzZXMg ZGlzY3Vzc2VkIGluIHRoZSBCb0Y/DQo+PiA+PiA+ID4+Pj4+DQo+PiA+PiA+ID4+Pj4+IHRoYW54 Lg0KPj4gPj4gPiA+Pj4+Pg0KPj4gPj4gPiA+Pj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+ID4+ID4g Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ ID4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGll dGYub3JnXSANCj4+ID4+ID4gPj4+Pj4+IE9uIEJlaGFsZg0KPj4gPj4gPiA+PiBPZg0KPj4gPj4g PiA+Pj4+Pj4gUm9uDQo+PiA+PiA+ID4+Pj4+PiBQYXJrZXINCj4+ID4+ID4gPj4+Pj4+IFNlbnQ6 IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTYgUE0NCj4+ID4+ID4gPj4+Pj4+IFRvOiBT dW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+ PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4g PiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFN1bWFuZHJhLA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ ID4gPj4+Pj4+IEFzIHdhcyBkaXNjdXNzZWQgaW4gVmFuY291dmVyLCB0aGVyZSBhcmUgYWxyZWFk eSBtYW55IA0KPj4gPj4gPiA+Pj4+Pj4gZXhpc3Rpbmcgd2F5cw0KPj4gPj4gPiA+Pj4+IHRvDQo+ PiA+PiA+ID4+Pj4+PiBhY2NvbXBsaXNoIHNlcnZpY2UgY2hhaW5pbmcuICAgICBCdXQgbm9uZSBv ZiB0aGVtIHByb3ZpZGUgYQ0KPj4gPj4gPiA+Pj4+IHN1ZmZpY2llbnQNCj4+ID4+ID4gPj4+Pj4+ IGNvbWJpbmF0aW9uIG9mIGludGVyb3BlcmFiaWxpdHksIGZsZXhpYmlsaXR5LCBhbmQNCj4+cmVz aWxpZW5jeS4NCj4+ID4+ID4gQQ0KPj4gPj4gPiA+Pj4+IHNpbmdsZQ0KPj4gPj4gPiA+Pj4+Pj4g c2VydmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdpbGwgZ28gYSBsb25nIHdheSB0byANCj4+ID4+ ID4gPj4+Pj4+IGVuc3VyaW5nIHRoZXNlDQo+PiA+PiA+ID4+Pj4gZ29hbHMuDQo+PiA+PiA+ID4+ Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBtb3N0IGVmZmljaWVudCBhcHByb2Fj aCBmb3IgDQo+PiA+PiA+ID4+Pj4+PiBldmVyeQ0KPj4gPj4gPiA+Pj4+IHNpbmdsZQ0KPj4gPj4g PiA+Pj4+Pj4gbmV0d29yayB0b3BvbG9neSBhbmQgZXZlcnkgc2luZ2xlIHVzZSBjYXNlLCBidXQg aXRzIA0KPj4gPj4gPiA+Pj4+Pj4gdWJpcXVpdG91cw0KPj4gPj4gPiA+PiBuYXR1cmUNCj4+ID4+ ID4gPj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4NCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+PiAgIFJvbg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPj4gPiA+Pj4+Pj4gRnJv bTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0NCj4+ID4+ID4gPj4+Pj4+ IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTAgUE0NCj4+ID4+ID4gPj4+Pj4+ IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+ Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+ PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gUm9uLA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4g Pj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFuIGV4YW1wbGUgb2Ygb25lIHR5cGUgb2YgZGVy aXZhdGlvbi4NCj4+ID4+ID4gPj4+Pj4+IEhvd2V2ZXINCj4+ID4+ID4gPj4+PiB0aGlzDQo+PiA+ PiA+ID4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQgd2l0aCBjbGFzc2lmaWNhdGlvbiByZXN1bHQs IGFnYWluIG9uZSANCj4+ID4+ID4gPj4+Pj4+IG1vcmUNCj4+ID4+ID4gPj4+PiBleGFtcGxlLg0K Pj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+Pj4gQWxsIGZsb3dzIGZyb20gdGhlIHNhbWUg c291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSANCj4+ID4+ID4gPj4+Pj4+Pj4gZm9sbG93DQo+ PiA+PiA+IHRoZQ0KPj4gPj4gPiA+Pj4+IHNhbWUNCj4+ID4+ID4gPj4+Pj4+IGNoYWluLg0KPj4g Pj4gPiA+Pj4+Pj4gQ29ycmVjdC4gSXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQgYWxsIHRy YW5zYWN0aW9uIG9mIA0KPj4gPj4gPiA+Pj4+Pj4gdGhlIHNhbWUNCj4+ID4+ID4gPj4+PiBmbG93 DQo+PiA+PiA+ID4+Pj4+PiBmb2xsb3cgdGhlIHNhbWUgY2hhaW4gZWl0aGVyLiBTbyB3aHkgc3Rv cCBhdCBmbG93IGl0c2VsZi4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBZ2FpbiB0 aGUgcG9pbnQgaGVyZSBpcyB0aGF0IGRvIHdlIGFsd2F5cyBuZWVkIFNGQyBoZWFkZXIgDQo+PiA+ PiA+ID4+Pj4+PiBvcg0KPj4gPj5Ob3QuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4g U3VtYW5kcmENCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206IFJvbiBQYXJr ZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0d29ya3MuY29tXQ0KPj4gPj4gPiA+Pj4+ Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA3OjAyIFBNDQo+PiA+PiA+ID4+Pj4+ PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4g PiA+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXIN Cj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYSwNCj4+ID4+ID4gPj4+Pj4+ DQo+PiA+PiA+ID4+Pj4+PiBUaGUgaW50ZW50aW9uIG9mIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5p bmcgaXMgdG8gYWxsb3cgDQo+PiA+PiA+ID4+Pj4+PiBmb3Igb3BlcmF0aW9uDQo+PiA+PiA+ID4+ Pj4gYXQNCj4+ID4+ID4gPj4+Pj4+IHRoZSBmdWxseSBxdWFsaWZpZWQgZmxvdyBsZXZlbCwgb3Ig ZXZlbiBmaW5lciBncmFpbmVkIGF0IA0KPj4gPj4gPiA+Pj4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4g dHJhbnNhY3Rpb24NCj4+ID4+ID4gPj4+Pj4+IGxldmVsICh0aGlzIGlzIGFuIGltcGxlbWVudGF0 aW9uIG1hdHRlciBmb3IgdGhlIFBEUCkuDQo+PkFsbA0KPj4gPj4gPiBmbG93cw0KPj4gPj4gPiA+ Pj4+IGZyb20NCj4+ID4+ID4gPj4+Pj4+IHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVjZXNz YXJpbHkgZm9sbG93IHRoZSBzYW1lIGNoYWluLg0KPj4gPj4gPiA+PiBTb3VyY2UNCj4+ID4+ID4g Pj4+Pj4+IElQLA0KPj4gPj4gPiA+Pj4+Pj4gdGhlcmVmb3JlLCAgZG9lcyBub3QgaWRlbnRpZnkg dGhlIGNoYWluIElELiAgICBBbm90aGVyDQo+PiA+PmludGVudGlvbg0KPj4gPj4gPiBvZg0KPj4g Pj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBvcGVyYXRlIG92ZXIg YW55IG5ldHdvcmsNCj4+ID4+ID4gdG9wb2xvZ3kNCj4+ID4+ID4gPj4gYW5kDQo+PiA+PiA+ID4+ Pj4+PiBub3QNCj4+ID4+ID4gPj4+Pj4+IGJlIGxpbWl0ZWQgdG8gYSBzaW5nbGUgTEFOLiAgIFRo dXMsIHdoaWxlIFZMQU4gbWF5IGJlIHBhcnQNCj4+b2YNCj4+ID4+ID4gdGhlDQo+PiA+PiA+ID4+ Pj4+PiB0cmFuc3BvcnQsIGl0IGRvZXMgbm90IGFkZXF1YXRlbHkgaWRlbnRpZnkgdGhlIHNlcnZp Y2UgDQo+PiA+PiA+ID4+Pj4+PiBjaGFpbiwNCj4+ID4+ID4gPj4gZWl0aGVyLg0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ICAgUm9uDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiA+PiA+ID4+ Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29tXQ0KPj4gPj4g PiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA5OjU2IFBNDQo+PiA+PiA+ ID4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+PiA+ PiA+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFJvbiwNCj4+ID4+ID4gPj4+Pj4+DQo+ PiA+PiA+ID4+Pj4+PiBUaGUgc2VydmljZSBoZWFkZXIgaXMgbWVhbnQgdG8gY2FycnkgdGhlIGNv bnRleHQgd2hpY2ggDQo+PiA+PiA+ID4+Pj4+PiBjYW4NCj4+ID4+ID4gKmFsc28qDQo+PiA+PiA+ ID4+Pj4+PiBiZSBkZXJpdmVkIChmb3IgZXhhbXBsZSB1c2Ugc291cmNlIGlwIGFuZCB2bGFuIHRv IA0KPj4gPj4gPiA+Pj4+Pj4gaWRlbnRpZnkgY2hhaW5JRCBhbmQNCj4+ID4+ID4gPj4+Pj4+IHBv c2l0aW9uKSBvciBlbmNhcHN1bGF0ZWQgYXMgcGFydCBvZiBhbm90aGVyIHR1bm5lbCBoZWFkZXIu DQo+PiA+PiA+ID4+Pj4+PiBTbyB0aGlzIGNvdWxkIGJlIG9wdGlvbmFsIElNSE8uDQo+PiA+PiA+ ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ ID4gPj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFmZmlybWVkbmV0 d29ya3MuY29tXQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAx MyA0OjM2IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0 ZW47IG5zY0BpZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJl bnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBT dW1hbmRyYSwNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQg aXQsIGFuIFNGQyBwYWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0byANCj4+ID4+ID4gPj4+Pj4+ IFNGIG9yIGZyb20NCj4+ID4+ID4gPj4+PiBTRg0KPj4gPj4gPiA+Pj4+Pj4gdG8NCj4+ID4+ID4g Pj4+Pj4+IFNGIHdpbGwgbG9vayBsaWtlOg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAidHJh bnNwb3J0IiAgICAgICAgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgc2VydmljZSBoZWFkZXIgICAgfA0KPj4gPj4gPiA+ Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+ID4+ID4gPj4+Pj4+IHwgICBvcmln aW5hbCBJUCBoZWFkZXIgIHwNCj4+ID4+ID4gPj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rDQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8ICBvcmlnaW5hbCBJUCANCj4+ID4+ID4gPj4+Pj4+IHwgcGF5bG9hZA0KPj4gPj4gPiB8 DQo+PiA+PiA+ID4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQo+PiA+PiA+ID4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4gPj4gPiA+ Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IFdoZXJlIHNlcnZpY2UgaGVhZGVyIGNvbnRhaW5zLCBhdCBh IG1pbmltdW0sIGVub3VnaCANCj4+ID4+ID4gPj4+Pj4+IGluZm9ybWF0aW9uIHRvDQo+PiA+PiA+ ID4+Pj4gYWxsb3cNCj4+ID4+ID4gPj4+Pj4+IHRoZSBwYWNrZXQgdG8gYmUgcHJvcGFnYXRlZCBh bG9uZyB0aGUgZnVsbCBsZW5ndGggb2YgdGhlIA0KPj4gPj4gPiA+Pj4+Pj4gY2hhaW4sIGFuZCBv cHRpb25hbGx5LCBvdGhlciBtZXRhZGF0YSB0aGF0IGVuaGFuY2VzIHRoZSANCj4+ID4+ID4gPj4+ Pj4+IG9wZXJhdGlvbiBvZg0KPj4gPj4gPiBvbmUNCj4+ID4+ID4gPj4+Pj4+IG9yDQo+PiA+PiA+ ID4+IG1vcmUNCj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4gPj4gPiA+Pj4+ Pj4NCj4+ID4+ID4gPj4+Pj4+IEFuZCB3aGVyZSAidHJhbnNwb3J0IiBjb3VsZCBjb25jZWl2YWJs eSBiZSBhbnkgb2YsIGJ1dCANCj4+ID4+ID4gPj4+Pj4+IG5vdCBsaW1pdGVkDQo+PiA+PiA+ID4+ Pj4gdG86DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gKiBFdGhlcm5ldA0KPj4gPj4g PiA+Pj4+Pj4gKiBFdGhlcm5ldCArIExMQzINCj4+ID4+ID4gPj4+Pj4+ICogRXRoZXJuZXQgKyBN UExTDQo+PiA+PiA+ID4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgKyBHUkUNCj4+ID4+ID4gPj4+Pj4+ ICogRXRoZXJuZXQgKyBJUCArVURQDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ ID4+ID4gPj4+Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRpYWdyYW0gYWJvdmUgaXMgbm90 IG1lYW50IHRvIA0KPj4gPj4gPiA+Pj4+Pj4gaW1wbHkgaW1tdXRhYmlsaXR5LCBidXQgcmF0aGVy IHRvIHNwZWNpZnkgdGhlIHBhY2tldCB0aGF0IA0KPj4gPj4gPiA+Pj4+Pj4gaXMNCj4+ID4+ID4g cHJvcGFnYXRlZA0KPj4gPj4gPiA+Pj4+Pj4gZnJvbSBwcmVjZWRpbmcgZW50aXR5IHRvIHN1Y2Nl ZWRpbmcgZW50aXR5LCBwcmlvciB0byANCj4+ID4+ID4gPj4+Pj4+IGVuY2Fwc3VsYXRpb24uDQo+ PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gICBSb24NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+ PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ ID4+ID4gPj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5j ZXNAaWV0Zi5vcmddIA0KPj4gPj4gPiA+Pj4+Pj4gT24gQmVoYWxmDQo+PiA+PiA+ID4+IE9mDQo+ PiA+PiA+ID4+Pj4+PiBTdW1hbmRyYSBNYWplZQ0KPj4gPj4gPiA+Pj4+Pj4gU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAxMSwgMjAxMyA2OjQ2IFBNDQo+PiA+PiA+ID4+Pj4+PiBUbzogVGhvbWFzIE5h cnRlbjsgbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3Vy cmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ IEdlbmVyaWMgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBFbmNhcHN1bGF0aW9uOiBBIA0KPj4g Pj4gPiA+Pj4+Pj4gZG9jdW1lbnQNCj4+ID4+d2lsbA0KPj4gPj4gPiA+Pj4+Pj4gICAgZGVzY3Jp YmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgDQo+PiA+PiA+ID4+Pj4+PiBl bmNhcHN1bGF0aW9uDQo+PiA+PiA+ID4+IGZvcm1hdA0KPj4gPj4gPiA+Pj4+Pj4gZm9yDQo+PiA+ PiA+ID4+Pj4+PiAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRo ZSBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rpb24NCj4+ID4+ID4gPj4+PiBwYXRoLA0K Pj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNvbnRleHQgaW5mb3JtYXRp b24gYmV0d2VlbiANCj4+ID4+ID4gPj4+Pj4+IG5vZGVzDQo+PiB0aGF0DQo+PiA+PiA+ID4+Pj4+ PiAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMuIEl0IGlzIGludGVuZGVkIHRoYXQgdGhl DQo+PiA+PiA+ID4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4gPj4gPiA+Pj4+Pj4gICAgYmUgYWdub3N0 aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxpZWQgYW5kIA0KPj4gPj4gPiA+Pj4+ Pj4gdGhlIHNlcnZpY2UNCj4+ID4+ID4gPj4+PiB0aGF0DQo+PiA+PiA+ID4+Pj4+PiBpcw0KPj4g Pj4gPiA+Pj4+Pj4gICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1lIGVuY2Fw c3VsYXRpb24gbWF5IA0KPj4gPj4gPiA+Pj4+Pj4gYmUNCj4+ID4+ID4gdXNlZA0KPj4gPj4gPiA+ PiBvbg0KPj4gPj4gPiA+Pj4+Pj4gICAgYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQg YXQgdGhlIG5ldHdvcmsgbGF5ZXIgDQo+PiA+PiA+ID4+Pj4+PiBvciBhdCBhbnkgb3RoZXINCj4+ ID4+ID4gPj4+Pj4+ICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3aWxsIGFw cGx5IGZvciB0aGUNCj4+ID4+ID4gPj4gY29uc3RydWN0aW9uDQo+PiA+PiA+ID4+Pj4gb2YNCj4+ ID4+ID4gPj4+Pj4+ICAgIHNlcnZpY2UgZnVuY3Rpb24gcGF0aHMgcmVnYXJkbGVzcyBvZiB0aGUg YWN0dWFsIHNlcnZpY2UuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gW1NNXSBXaGF0 IGRvZXMgaXQgbWVhbiBieSBhIHNpbmdsZSBzZXJ2aWNlLWxldmVsIA0KPj4gPj4gPiA+Pj4+Pj4g ZW5jYXBzdWxhdGlvbiwNCj4+ID4+ID4gYQ0KPj4gPj4gPiA+Pj4+IG5ldw0KPj4gPj4gPiA+Pj4+ Pj4gZW5jYXBzdWxhdGlvbiBmb3JtYXQNCj4+ID4+ID4gPj4+Pj4+ICAgICAgICAgICAgb3IgYW4g YWJpbGl0eSB0byBzZWxlY3Qgb25lIGVuY2Fwc3VsYXRpb24gDQo+PiA+PiA+ID4+Pj4+PiBmb3Jt YXQgdGhhdA0KPj4gPj4gPiA+Pj4+IGZpdHMNCj4+ID4+ID4gPj4+Pj4+IHRoZQ0KPj4gPj4gPiA+ Pj4+Pj4gbmVlZCBmb3IgYSBnaXZlbiBzZXJ2aWNlIGNoYWluPw0KPj4gPj4gPiA+Pj4+Pj4gICAg ICAgICAgIFRoZSBhYmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gDQo+ PiA+PiA+ID4+Pj4+PiB3b3VsZCBiZQ0KPj4gPj4gPiA+PiBhDQo+PiA+PiA+ID4+Pj4+PiBtYW5h Z2VtZW50IHBsYW5lIGRlY2lzaW9uLg0KPj4gPj4gPiA+Pj4+Pj4gICAgICAgICAgVGhlcmUgYXJl IHF1aXRlIGEgZmV3IGV4aXN0aW5nIGVuY2Fwc3VsYXRpb24gDQo+PiA+PiA+ID4+Pj4+PiBtZXRo b2RzIHRoYXQNCj4+ID4+ID4gPj4+PiBjYW4NCj4+ID4+ID4gPj4+Pj4+IHBvc3NpYmx5IGJlIHJl dXNlZCB0byBwcm92aWRlDQo+PiA+PiA+ID4+Pj4+PiAgICAgICAgICBjb250ZXh0IGluZm9ybWF0 aW9uIGJldHdlZW4gICBzZXJ2aWNlIG5vZGVzLiBJIGhhdmUNCj4+ID4+ID4gc2Vlbg0KPj4gPj4g PiA+Pj4+Pj4gbWVudGlvbg0KPj4gPj4gPiA+Pj4+Pj4gb2YgR1JFLCBmb3IgSFRUUCBiYXNlZA0K Pj4gPj4gPiA+Pj4+Pj4gICAgICAgICAgYXBwbGljYXRpb25zIGNvbnRleHRzIGFyZSB0cmFuc2Zl cnJlZCB2aWEgaGVhZGVycy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4g PiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ID4gPj4+Pj4+IEZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIA0KPj4g Pj4gPiA+Pj4+Pj4gT24gQmVoYWxmDQo+PiA+PiA+ID4+IE9mDQo+PiA+PiA+ID4+Pj4+PiBUaG9t YXMgTmFydGVuDQo+PiA+PiA+ID4+Pj4+PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDA2LCAy MDEzIDExOjA3IEFNDQo+PiA+PiA+ID4+Pj4+PiBUbzogbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+ Pj4+PiBTdWJqZWN0OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+PiA+PiA+ ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gSGkuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4gQ3VycmVudCBjaGFydGVyIGNhbiBiZSBmb3VuZCBhdA0KPj4gPj4gPiA+Pj4+Pj4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci0NCj4+ID4+ID4gPj4+Pj4+IGlldGYt c2ZjLy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBJdCBjb250YWlucyB0aGUgcmV2 aXNlZCBtYW5hZ2VtZW50IHRleHQgYXMgd2VsbCBhcyANCj4+ID4+ID4gPj4+Pj4+IHVwZGF0ZWQN Cj4+ID4+ID4gPj4+PiBtaWxlc3RvbmVzLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ IEFsbCBrbm93biBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gSWYgdGhlcmUgYXJlIGFueSAN Cj4+ID4+ID4gPj4+Pj4+IHJlbWFpbmluZw0KPj4gPj4gPiA+Pj4+IGlzc3VlcywNCj4+ID4+ID4g Pj4+Pj4+IHBsZWFzZSBzcGVhayB1cCENCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBD aGFydGVyIGNoYXJ0ZXItaWV0Zi1zZmMtMDAtMDQNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+ Pj4+PiBOZXR3b3Jrcywgc2VydmVycywgc3RvcmFnZSB0ZWNobm9sb2dpZXMsIGFuZCANCj4+ID4+ ID4gPj4+Pj4+IGFwcGxpY2F0aW9ucywgaGF2ZSBhbGwgdW5kZXJnb25lIHNpZ25pZmljYW50IGNo YW5nZSBpbiANCj4+ID4+ID4gPj4+Pj4+IHJlY2VudCB5ZWFycyB3aXRoIHRoZSBpbnRyb2R1Y3Rp b24NCj4+ID4+ID4gPj4gb2YNCj4+ID4+ID4gPj4+Pj4+IHZpcnR1YWxpemF0aW9uLCBuZXR3b3Jr IG92ZXJsYXlzLCBhbmQgb3JjaGVzdHJhdGlvbi4NCj4+ID4+ID4gPj4+Pj4+IFNlcnZpY2UNCj4+ ID4+ID4gPj4gZGVsaXZlcnkNCj4+ID4+ID4gPj4+PiBpcw0KPj4gPj4gPiA+Pj4+Pj4gY3VycmVu dGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFsIGNoYWxsZW5nZSANCj4+ID4+ ID4gPj4+Pj4+IHRoYXQNCj4+ID4+ID4gPj4gaW52b2x2ZXMNCj4+ID4+ID4gPj4+Pj4+IHNpZ25p ZmljYW50IG1vZGlmaWNhdGlvbiB0byB0aGUgbmV0d29yayBjb25maWd1cmF0aW9uLg0KPj4gPj4g PiA+Pj4+Pj4gU2VydmljZXMgYXJlIHR5cGljYWxseSBpbXBsZW1lbnRlZCBieSB0aGUgb3JkZXJl ZCANCj4+ID4+ID4gPj4+Pj4+IGNvbWJpbmF0aW9uIG9mIGEgbnVtYmVyIG9mIHNlcnZpY2UgZnVu Y3Rpb25zIHRoYXQgYXJlIA0KPj4gPj4gPiA+Pj4+Pj4gZGVwbG95ZWQgYXQgZGlmZmVyZW50IHBv aW50cyB3aXRoaW4NCj4+ID4+ID4gPj4gdGhlDQo+PiA+PiA+ID4+Pj4+PiBuZXR3b3JrLiBUb2Rh eSwgYSBjb21tb24gZGVwbG95bWVudCBtb2RlbCBoYXMgc2VydmljZSANCj4+ID4+ID4gPj4+Pj4+ IGZ1bmN0aW9ucyBwaHlzaWNhbGx5IGluc2VydGVkIG9uIHRoZSBkYXRhIGZvcndhcmRpbmcgcGF0 aCANCj4+ID4+ID4gPj4+Pj4+IGJldHdlZW4gY29tbXVuaWNhdGluZyBwZWVycy4NCj4+ID4+ID4g Pj4+PiBHb2luZw0KPj4gPj4gPiA+Pj4+Pj4gZm9yd2FyZCwgaG93ZXZlciwgdGhlcmUgaXMgYSBk ZXNpcmUgdG8gbW92ZSB0byBhIA0KPj4gPj4gPiA+Pj4+Pj4gZGlmZmVyZW50IG1vZGVsLA0KPj4g Pj4gPiA+Pj4+IHdoZXJlDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgbm90 IHJlcXVpcmVkIHRvIHJlc2lkZSBvbiB0aGUgDQo+PiA+PiA+ID4+Pj4+PiBkZWZhdWx0IGRhdGEN Cj4+ID4+ID4gPj4gcGF0aA0KPj4gPj4gPiA+Pj4+Pj4gYW5kDQo+PiA+PiA+ID4+Pj4+PiB0cmFm ZmljIGlzIGluc3RlYWQgc3RlZXJlZCB0aHJvdWdoIHNlcnZpY2VzLCB3aGVyZXZlciANCj4+ID4+ ID4gPj4+Pj4+IHRoZXkgYXJlDQo+PiA+PiA+ID4+Pj4gZGVwbG95ZWQuDQo+PiA+PiA+ID4+Pj4+ Pg0KPj4gPj4gPiA+Pj4+Pj4gRm9yIGEgZ2l2ZW4gc2VydmljZSwgdGhlIGFic3RyYWN0ZWQgdmll dyBvZiB0aGUgcmVxdWlyZWQgDQo+PiA+PiA+ID4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhbmQg dGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRvIGJlIA0KPj4gPj4gPiA+Pj4+Pj4gYXBwbGll ZCBpcw0KPj4gPj4gPiBjYWxsZWQNCj4+ID4+ID4gPj4+Pj4+IGEgU2VydmljZSBGdW5jdGlvbiBD aGFpbiAoU0ZDKS4gU2luY2UgYSBnaXZlbiBzZXJ2aWNlIA0KPj4gPj4gPiA+Pj4+Pj4gZnVuY3Rp b24gbWF5IGJlIGF2YWlsYWJsZSBvbiBtb3JlIHRoYW4gb25lIG5vZGUgd2l0aGluIGEgDQo+PiA+ PiA+ID4+Pj4+PiBuZXR3b3JrLCBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gaXMgaW5zdGFudGlh dGVkDQo+PiA+PiA+ID4+Pj4gdmlhDQo+PiA+PiA+ID4+Pj4+PiB0aGUgc2VsZWN0aW9uIG9mIHNw ZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIGFuZCANCj4+ID4+ID4gPj4+Pj4+IHRo ZSBuZXR3b3JrIG5vZGVzIG9uIHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVkLCB0aGVyZWJ5IA0KPj4g Pj4gPiA+Pj4+Pj4gZm9ybWluZyBhIHNlcnZpY2UgdG9wb2xvZ3k6DQo+PiA+PiA+ID4+Pj4+PiB0 aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aC4gVGhlIHNlcnZpY2UgDQo+PiA+ PiA+ID4+Pj4+PiBmdW5jdGlvbnMNCj4+ID4+ID4gbWF5DQo+PiA+PiA+ID4+Pj4+PiBiZSBhcHBs aWVkIGF0IGEgc3BlY2lmaWMgbGF5ZXIgd2l0aGluIHRoZSBuZXR3b3JrIA0KPj4gPj4gPiA+Pj4+ Pj4gcHJvdG9jb2wgc3RhY2sNCj4+ID4+ID4gPj4+PiAobmV0d29yaw0KPj4gPj4gPiA+Pj4+Pj4g bGF5ZXIsIGFwcGxpY2F0aW9uIGxheWVyLCBldGMuKS4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ ID4+Pj4+PiBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSB3b3JraW5nIGdyb3Vw IHdpbGwgDQo+PiA+PiA+ID4+Pj4+PiBkZXZlbG9wIG5ldyBhcHByb2FjaGVzIHRvIHNlcnZpY2Ug ZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuDQo+PiA+PiA+ID4+Pj4+PiBJdCB3aWxsIHByb2R1Y2Ug YSBmcmFtZXdvcmsgZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgDQo+PiA+PiA+ID4+Pj4+ PiB0aGF0IGluY2x1ZGVzIHRoZSBuZWNlc3NhcnkgcHJvdG9jb2xzDQo+PiA+PiA+ID4+Pj4gb3IN Cj4+ID4+ID4gPj4+Pj4+IHByb3RvY29sIGV4dGVuc2lvbnMgdG8gY29udmV5IHRoZSBzZXJ2aWNl IHBhdGggYW5kIA0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBwYXRoIGluZm9ybWF0aW9uIHRvIG5v ZGVzIHRoYXQgaW1wbGVtZW50IHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5jdGlvbnMsIGFz IHdlbGwNCj4+ID4+ID4gYXMNCj4+ID4+ID4gPj4+Pj4+IG1lY2hhbmlzbXMgZm9yIHN0ZWVyaW5n IHRyYWZmaWMgdGhyb3VnaCBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+ID4+ID4gPj4+Pj4+IFRoZQ0K Pj4gPj4gPiA+Pj4+IHdvcmtpbmcNCj4+ID4+ID4gPj4+Pj4+IGdyb3VwIHdpbGwgYWxzbyBleGFt aW5lIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgDQo+PiA+PiA+ID4+Pj4+PiBnYXRoZXJl ZCBmcm9tDQo+PiA+PiA+ID4+Pj4gdGhlDQo+PiA+PiA+ID4+Pj4+PiBuZXR3b3JrIGFuZCBzZXJ2 aWNlIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIHNlcnZpY2UgDQo+PiA+PiA+ID4+Pj4+PiBmdW5j dGlvbg0KPj4gPj4gPiA+PiBjaGFpbmluZw0KPj4gPj4gPiA+Pj4+Pj4gYW5kDQo+PiA+PiA+ID4+ Pj4+PiBob3cgdGhhdCBpbmZvcm1hdGlvbiBtYXkgYmUgbWFkZSBhdmFpbGFibGUgdG8gbm9kZXMg dGhhdCANCj4+ID4+ID4gPj4+Pj4+IGltcGxlbWVudA0KPj4gPj4gPiA+Pj4+IHRoZQ0KPj4gPj4g PiA+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+ Pj4gU3BlY2lmaWNhbGx5LCB0aGUgU0ZDIFdHIGlzIGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZQ0K Pj4gZm9sbG93aW5nOg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IDEpIFByb2JsZW0g U3RhdGVtZW50OiBUaGlzIGRvY3VtZW50IHdpbGwgcHJvdmlkZSBhIA0KPj4gPj4gPiA+Pj4+Pj4g c3VtbWFyeSBvZg0KPj4gPj4gPiB0aGUNCj4+ID4+ID4gPj4+Pj4+ICAgIHByb2JsZW0gc3BhY2Ug dG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBXRyBpbmNsdWRpbmcgDQo+PiA+PiA+ID4+Pj4+PiBleGFt cGxlDQo+PiA+PiA+IGhpZ2gtDQo+PiA+PiA+ID4+Pj4+PiAgICBsZXZlbCB1c2UgY2FzZXMuIEFk ZGl0aW9uYWxseSwgdGhlIFdHIHdpbGwgbm9ybWFsaXplDQo+PiA+PiA+ID4+IG5vbWVuY2xhdHVy ZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgYW5kIGRlZmluaXRpb25zIGZvciBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nLg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IDIpIEFyY2hpdGVjdHVy ZTogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSBkZXNjcmlwdGlvbiANCj4+ID4+ID4gPj4+ Pj4+IG9mDQo+PiA+PnRoZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgYXJjaGl0ZWN0dXJhbCBidWlsZGlu ZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMNCj4+ID4+ID4gaW5jbHVkaW5nDQo+PiA+ PiA+ID4+Pj4+PiAgICBpbnRlcmNvbm5lY3Rpb24sIHBsYWNlbWVudCBvZiBjYXBhYmlsaXRpZXMs IG1hbmFnZW1lbnQsDQo+PiA+PiA+ID4+Pj4+PiAgICBkaWFnbm9zdGljcywgZGVzaWduIGFuYWx5 c2lzLCBhbmQgc2VjdXJpdHkgbW9kZWxzLCBhcyANCj4+ID4+ID4gPj4+Pj4+IHdlbGwNCj4+ID4+ YXMNCj4+ID4+ID4gPj4+Pj4+ICAgIHJlcXVpcmVtZW50cyBvbiB0aGUgcHJvdG9jb2wgbWVjaGFu aXNtcy4NCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiAzKSBHZW5lcmljIFNlcnZpY2Ug RnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSANCj4+ID4+ID4gPj4+Pj4+IGRvY3Vt ZW50DQo+PiA+PiA+IHdpbGwNCj4+ID4+ID4gPj4+Pj4+ICAgIGRlc2NyaWJlIHRoZSBzaW5nbGUg c2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIA0KPj4gPj4gPiA+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0K Pj4gPj4gPiA+PiBmb3JtYXQNCj4+ID4+ID4gPj4+Pj4+IGZvcg0KPj4gPj4gPiA+Pj4+Pj4gICAg Y29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZCB0aGUgc2VydmljZSANCj4+ ID4+ID4gPj4+Pj4+IGZ1bmN0aW9uDQo+PiA+PiA+ID4+Pj4gcGF0aCwNCj4+ID4+ID4gPj4+Pj4+ ICAgIGFuZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gDQo+ PiA+PiA+ID4+Pj4+PiBub2Rlcw0KPj4gdGhhdA0KPj4gPj4gPiA+Pj4+Pj4gICAgaW1wbGVtZW50 IHNlcnZpY2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0KPj4gPj4gPiA+Pj4+ IGVuY2Fwc3VsYXRpb24NCj4+ID4+ID4gPj4+Pj4+ICAgIGJlIGFnbm9zdGljIHRvIHRoZSBsYXll ciBhdCB3aGljaCBpdCBpcyBhcHBsaWVkIGFuZCANCj4+ID4+ID4gPj4+Pj4+IHRoZSBzZXJ2aWNl DQo+PiA+PiA+ID4+Pj4gdGhhdA0KPj4gPj4gPiA+Pj4+Pj4gaXMNCj4+ID4+ID4gPj4+Pj4+ICAg IGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIG1heSAN Cj4+ID4+ID4gPj4+Pj4+IGJlDQo+PiA+PiA+IHVzZWQNCj4+ID4+ID4gPj4gb24NCj4+ID4+ID4g Pj4+Pj4+ICAgIGEgc2VydmljZSBmdW5jdGlvbiBwYXRoIHJlYWxpemVkIGF0IHRoZSBuZXR3b3Jr IGxheWVyIA0KPj4gPj4gPiA+Pj4+Pj4gb3IgYXQgYW55IG90aGVyDQo+PiA+PiA+ID4+Pj4+PiAg ICBsYXllciwgYW5kIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBmb3IgdGhlDQo+ PiA+PiA+ID4+IGNvbnN0cnVjdGlvbg0KPj4gPj4gPiA+Pj4+IG9mDQo+PiA+PiA+ID4+Pj4+PiAg ICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbCBzZXJ2aWNl Lg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IDQpIENvbnRyb2wgUGxhbmUgTWVjaGFu aXNtczogQSBzZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUNCj4+ID4+ID4gZGV2ZWxvcGVkIHRvDQo+ PiA+PiA+ID4+Pj4+PiAgICBkZXNjcmliZSByZXF1aXJlbWVudHMgYW5kIHByb3RvY29scyBuZWNl c3NhcnkgdG8gDQo+PiA+PiA+ID4+Pj4+PiBjb252ZXkNCj4+ID4+ID4gPj4+PiBpbmZvcm1hdGlv bg0KPj4gPj4gPiA+Pj4+Pj4gICAgdG8gc2VydmljZSBmdW5jdGlvbiBpbXBsZW1lbnRhdGlvbiBw b2ludHMuIFdoZXJlIA0KPj4gPj4gPiA+Pj4+Pj4gcG9zc2libGUsDQo+PiA+PiA+ID4+Pj4gZXhp c3RpbmcNCj4+ID4+ID4gPj4+Pj4+ICAgIElFVEYgcHJvdG9jb2xzIHdpbGwgYmUgdXNlZCBhbmQg ZXh0ZW5kZWQuIEFsbCBwcm90b2NvbA0KPj4gPj4gPiA+PiBleHRlbnNpb25zDQo+PiA+PiA+ID4+ Pj4+PiAgICB3b3JrIHNob3VsZCBiZSBjYXJyaWVkIG91dCBpbiB0aGUgd29ya2luZyBncm91cHMg DQo+PiA+PiA+ID4+Pj4+PiByZXNwb25zaWJsZSBmb3INCj4+ID4+ID4gPj4+PiB0aGUNCj4+ID4+ ID4gPj4+Pj4+ICAgIHByb3RvY29scyBiZWluZyBtb2RpZmllZCBpbiBjb29yZGluYXRpb24gd2l0 aCB0aGlzIA0KPj4gPj4gPiA+Pj4+Pj4gd29ya2luZw0KPj4gPj4gPiA+PiBncm91cCwNCj4+ID4+ ID4gPj4+Pj4+IGJ1dA0KPj4gPj4gPiA+Pj4+Pj4gICAgbWF5IGJlIGRvbmUgaW4gdGhpcyB3b3Jr aW5nIGdyb3VwIGFmdGVyIGFncmVlbWVudCB3aXRoIA0KPj4gPj4gPiA+Pj4+Pj4gYWxsDQo+PiA+ PiA+IHRoZQ0KPj4gPj4gPiA+Pj4+Pj4gICAgcmVsZXZhbnQgV0cgY2hhaXJzIGFuZCByZXNwb25z aWJsZSBBRHMuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4gNSkgTWFuYWdlYWJpbGl0 eTogV29yayBvbiB0aGUgbWFuYWdlbWVudCBhbmQgDQo+PiA+PiA+ID4+Pj4+PiBjb25maWd1cmF0 aW9uIG9mDQo+PiA+PiA+ID4+IHNlcnZpY2UNCj4+ID4+ID4gPj4+Pj4+ICAgIGZ1bmN0aW9ucyBp biBzdXBwb3J0IG9mIFNGQyBjb21wb25lbnRzIHdpbGwgY2VydGFpbmx5IA0KPj4gPj4gPiA+Pj4+ Pj4gYmUNCj4+ID4+ID4gbmVlZGVkLA0KPj4gPj4gPiA+Pj4+Pj4gICAgYnV0IGZpcnN0IG5lZWRz IHRvIGJlIGJldHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQuDQo+PiA+PiA+ID4+Pj4+Pg0KPj4g Pj4gPiA+Pj4+Pj4gUHJvcG9zZWQgTWlsZXN0b25lcw0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4g Pj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQocykg DQo+PiA+PiA+ID4+Pj4+PiBkZWZpbmluZyB0aGUNCj4+ID4+ID4gPj4+PiBwcm9ibGVtDQo+PiA+ PiA+ID4+Pj4+PiBzdGF0ZW1lbnQgYW5kIGNvcmUgdXNlIGNhc2VzIGZvciBTZXJ2aWNlIEZ1bmN0 aW9uIA0KPj4gPj4gPiA+Pj4+Pj4gQ2hhaW5pbmcNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+ Pj4+PiBNYXkgMjAxNCBDb25zdWx0IHdpdGggT1BTIEFyZWEgb24gcG9zc2libGUgY2hhcnRlciAN Cj4+ID4+ID4gPj4+Pj4+IG1vZGlmaWNhdGlvbnMgZm9yIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3Vy YXRpb24gb2YgU0ZDIA0KPj4gPj4gPiA+Pj4+Pj4gY29tcG9uZW50cw0KPj4gPj4gPiA+Pj4+Pj4N Cj4+ID4+ID4gPj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9j dW1lbnQgZGVmaW5pbmcgDQo+PiA+PiA+ID4+Pj4+PiB0aGUNCj4+ID4+ID4gPj4+PiBhcmNoaXRl Y3R1cmUNCj4+ID4+ID4gPj4+Pj4+IGZvciBTRkMNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+ Pj4+PiBKYW4gMjAxNSBTdWJtaXQgdG8gSUVTRyByZXF1aXJlbWVudHMgZm9yIGEgZ2VuZXJpYyAN Cj4+ID4+ID4gPj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgZW5jYXBzdWxhdGlvbiBw cm90b2NvbA0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+IEF1ZyAyMDE1IFN1Ym1pdCB0 byBJRVNHIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCANCj4+ID4+ID4gPj4+Pj4+IHNwZWNpZnlp bmcgdGhlDQo+PiA+PiA+ID4+Pj4gZ2VuZXJpYw0KPj4gPj4gPiA+Pj4+Pj4gc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZyBoZWFkZXIgZW5jYXBzdWxhdGlvbg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+Pg0KPj4gPj4gPiA+Pj4+Pj4NCj4+ID4+ID4gPj4+Pj4+ DQo+PiA+PiA+ID4+Pj4+PiBUaG9tYXMNCj4+ID4+ID4gPj4+Pj4+DQo+PiA+PiA+ID4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4gPiA+ Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiA+Pj4+Pj4gbnNjQGlldGYub3JnDQo+PiA+ PiA+ID4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4g Pj4gPiA+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+ID4+ID4gPj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ID4+ID4gPj4+Pj4+IG5zY0Bp ZXRmLm9yZw0KPj4gPj4gPiA+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+ID4+ID4gPj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiA+PiA+ ID4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gPj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ID4+Pj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiA+PiA+ID4+Pj4+IG5zYyBtYWlsaW5nIGxp c3QNCj4+ID4+ID4gPj4+Pj4gbnNjQGlldGYub3JnDQo+PiA+PiA+ID4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+PiA+PiA+ID4NCj4+ID4+ID4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gbnNjIG1h aWxpbmcgbGlzdA0KPj4gPj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KPj4g Pj4gPiBuc2NAaWV0Zi5vcmcNCj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uc2MNCj4+ID4+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+ID4+ID4gbnNjIG1haWxpbmcgbGlzdA0KPj4gPj4gPiBuc2NAaWV0Zi5v cmcNCj4+ID4+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+ DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4g bnNjIG1haWxpbmcgbGlzdA0KPj4gbnNjQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuc2MgbWFpbGluZyBsaXN0DQpuc2NAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlz dA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0K From jguichar@cisco.com Thu Nov 14 07:14:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C991821E80F5 for ; Thu, 14 Nov 2013 07:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.567 X-Spam-Level: X-Spam-Status: No, score=-10.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3q3DWWMQeXY for ; Thu, 14 Nov 2013 07:14:34 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A221E80EB for ; Thu, 14 Nov 2013 07:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43001; q=dns/txt; s=iport; t=1384442072; x=1385651672; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Z+Jj+v0N4YNsW4GjwoGmJ37sZTUyVN2Ow1L7GyUPd14=; b=l9diKgbski8F42+FxtDod2+Yg2F1Rox0I9RgL8c62ZoPko13putGGfH+ 7NCet8OjE2Wff1dfCJkgPn2WnRZ41UNPbBdVd6Mfk2zE6quddoLTNDyGA s9FB8zj0gVSGWa620SXQODxCQqaW2mN0vpSd59fb4ywc0+H4j0vfw7Upk 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAIfohFKtJV2c/2dsb2JhbABQCoMHOFO/IYEfFnSCJQEBAQMBAQEBFwEfKwIHBBMGAQgRAQMBAQEVCQkuCxQDBQEIAgQBCQkJh3IGDcAjjhYGBAEFBoEILQUCBASEJwOULoNikgyDKIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284866014" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 14 Nov 2013 15:14:28 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAEFERxh001956 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 15:14:28 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 09:14:27 -0600 From: "Jim Guichard (jguichar)" To: David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAALQWgIAA0K0A//+xHgA= Date: Thu, 14 Nov 2013 15:14:26 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:14:38 -0000 I think it is misleading to say that a service function does not impact packet forwarding. If branching occurs then the service function does impact packet forwarding, whether directly or indirectly, as otherwise packets would not take the new path as a result of the branch. For example, if the chain is a-b-c and b decides that for certain flows the traffic should go to d rather than c then it *must* force the forwarding component to direct traffic to the new next-hop. While the service function may not modify forwarding in terms of updating forwarding tables and so forth, it has to inform the forwarding component of its intent somehow. Also, I think what you describe Dave is a bypass operation rather than a branch?=20 On 11/14/13 9:56 AM, "David Allan I" wrote: >I think it is going to be a rare event, as what is more likely is the >front end of the chain is dynamically modified so subsequent packets in a >flow skip certain functions. Hence a graph more often than not is >logically P2P. Facilitates testing amongst other benefits. > >As such I'd not want to be prescriptive as to how and where it is done.... > >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 6:30 PM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >Hi Dave, > >Your inferred restriction may be not always true. In general, service >functions should be able to compose a chain arbitrarily. Particularly for >branching, as I suggested in previous email, service function shall not >directly impact packet forwarding. This precludes the restriction you >mentioned. Forwarding plane can decide whether a branching action should >be taken by reclassification or not per service chain. > >Does this make sense? > >Hongyu > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: Wednesday, November 13, 2013 11:45 PM >To: Hongyu Li (Julio); nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >HI Hongyu: > >I think we will have scenarios where a service function appears in more >than one chain, as would be the case, for example, if some flows could >dynamically bypass DPI but still needed to transit a common set of >stateful service functions... > >Once you postulate a service function instance appearing in more than one >chain, it seems artificially restrictive not to permit such a function to >also implement branching, all the control structures would already be >there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is a >way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets in a >chain. Branching should be performed by chain forwarding nodes, possibly >under control of a control node. The reason for this is in NFV world, >service functions may come from a third party, while chain is provided by >the infrastructure of the network. There must be a cushion avoiding a >service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user's >packet, as well as some info like metadata in a SFC header. As >classification is out of scope of SFC, we don't have to provide too much >details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not >the exclusive mechanism. Branching is a mechanism by which flow subsets >are exposed and mapped to a set of subchains such that it can be >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is defined/set >even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; >Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative >domain for some of the very reasons you point out. We need to keep >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism >>(recursive because a user-land application will ride with a specific >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this >>multi-domain issue - if I set a policy as a user, chances are I will be >>crossing several domain boundaries. Are we expecting the service >>headers to define the service chaining for the duration of the entire >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty relevant >>to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong mapping >>> between Policy and the inserted Service Header(s), we run-the-risk of >>> limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per >>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to >>> redefine it - it's been around for all the time middle boxes have >>> been or for that matter the L2/L3 devices. All we are talking about >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a >>> > chain is different than I originally inferred. If the chain is a >>> > tree with other "branching" points in it, then that limits the >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation >>> > could define bad service chains, is it the intent of SFC to only >>> > look at the simpler packet-level classification cases, or is it the >>> > intent to consider the case where a branching point is viewed as a >>> > re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D reclassification, >>> >>agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be >>> >> in a form of logic on a service function. Some service functions, >>> >> especially L7 based, can use value in a Database to determine what >>> >> is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after >>> >> > been processed by a certain service function, decision of which >>> >> > branches to go is made based on the result of service function's >>> >> > process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The details >>> >> > around how to convey the selection of the subtree/subgraph are >>> >> > still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question >>> >> > > about service header encapsulation, is it intended that a >>> >> > > chain that is re-classified will get a new chain ID which >>> >> > > fully describes a chain that is a superset of the original >>> >> > > chain ID, prior to DPI-based re-classification? (assuming the >>> >> > > goal is "a single chain ID that is commonly understood along >>> >> > > the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>> >> > > every flow then be initially classified as ID 1, but >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of service >>> >> > >>> that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is limited >>> >> > >>> due to limitations in classification, that would be and >>> >> > >>> important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>> >> > >>> fork points of the service paths seem like re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive of >>> >> > >>> DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general, as >>> >> > >> described in the arch draft, the collection of services form >>> >> > >> a graph, segments of which are service paths. Yes, >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any node >>> >> > >> along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is >>> >> > >>>> that such classification aids in traffic selection and >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except that >>> >> > >>>> the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network >>> >> > >>>> elements but the service functions as well. Some of this is >>> >> > >>>> described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some of) >>> >> > >>>>> the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies packets >>> >> > >>>>> based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID, >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service >>> >> > >>>>> function identifier lookup does not seem to be a >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach for >>> >> > >>>>>> every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction of >>> >> > >>>>>> the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC header >>> >> > >>>>>> or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the >>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>> >> > >>>>>> imply immutability, but rather to specify the packet that >>> >> > >>>>>> is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and >>> >> > >>>>>> applications, have all undergone significant change in >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge=20 >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered=20 >>> >> > >>>>>> combination of a number of service functions that are=20 >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service=20 >>> >> > >>>>>> functions physically inserted on the data forwarding path=20 >>> >> > >>>>>> between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the=20 >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>> >> > >>>>>> service functions and the order in which they are to be=20 >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>> >> > >>>>>> function may be available on more than one node within a=20 >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and=20 >>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function chaining=20 >>> >> > >>>>>> that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a description=20 >>> >> > >>>>>> of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement with=20 >>> >> > >>>>>> all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From david.i.allan@ericsson.com Thu Nov 14 07:22:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3276421E8056 for ; Thu, 14 Nov 2013 07:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.054 X-Spam-Level: X-Spam-Status: No, score=-2.054 tagged_above=-999 required=5 tests=[AWL=0.545, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94IgC4oTQtGA for ; Thu, 14 Nov 2013 07:22:13 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id CF48311E8133 for ; Thu, 14 Nov 2013 07:22:12 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-95-5284eaa3a933 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id BF.AA.23183.3AAE4825; Thu, 14 Nov 2013 16:22:11 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 10:22:04 -0500 From: David Allan I To: "Jim Guichard (jguichar)" , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO4Fj+iBkfX7fLf02lvFYuCvTIzZojTSqwgAG13AD//9W/EA== Date: Thu, 14 Nov 2013 15:22:02 +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: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPiO7iVy1BBj+vSFlsmLKEzWLpPHWL 4/v2szkwe0z5vZHVo+XIW1aPJUt+MgUwR3HZpKTmZJalFunbJXBl9P2Zw16w/TxTxdz1G9ka GNs6mboYOTkkBEwkph2bwQhhi0lcuLeerYuRi0NI4AijxMvD85kgnOWMEif/9YJVsQkYSOz5 /wXMFhGol9g6u4MNxBYWiJI43PKEDSIeLfF8/gUWCNtJ4nT3ebA4i4CqxO8tv8DivAK+Enev 7WQGsYUEiiXenvsBVsMJNL/h0Huw6xiBLvp+ag2YzSwgLnHryXyoqwUkluw5zwxhi0q8fPyP FcJWlljyZD8LRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlW MXKUFqeW5aYbGWxiBEbJMQk23R2Me15aHmKU5mBREuf98tY5SEggPbEkNTs1tSC1KL6oNCe1 +BAjEwenVAOj9rm82F03dsdcP7Qu6Jn2l1qx6nvf9xQHrJU44GFbwvXhdXPlGe3yCxptTDuO 2C5my9mSuuWVpD3DndW9mpXHbXfXceSnK3ybVvXzaOSMRnu5r7UfS9fvf3fR593E+nsJP74u mCqTGrTlhWBpd1bJ/wcpVbu5b+r8axS6ccN7Wdqr/50pyxIklViKMxINtZiLihMBprgNZGAC AAA= Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:22:18 -0000 My point was once a function in participating in more than one chain, the p= arallel tracks Niulehong refers to, then conceptually there is no reason wh= y a switch in the function woundn't allow a train to change tracks. As I've indicated I think it is a rare case, causes traceability issues etc= . and therefore is actually undesirable but I'd rather not be prescriptive= on whether this is possible or not, or HOW it MUST be done....Conceptually= I think what you refer to as bypass is the far more likely dynamic chain b= ehavior we would expect... Dave -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, November 14, 2013 4:49 AM To: David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter Hi Dave, I am not sure I am catching your point. There is no doubt that a service fu= nction may appear in more than one chain; it must as otherwise you would be= spinning up service function instances that could only ever be used by tra= ffic flowing through a single service chain. Simple example is a chain a-b-= c; I see no reason why you could not also build a chain d-b-e where b is th= e same service function instance in both chains. Branching seems to me to b= e independent of how many service function instances you have for a given s= ervice function. On 11/13/13 10:45 AM, "David Allan I" wrote: >HI Hongyu: > >I think we will have scenarios where a service function appears in more=20 >than one chain, as would be the case, for example, if some flows could=20 >dynamically bypass DPI but still needed to transit a common set of=20 >stateful service functions... > >Once you postulate a service function instance appearing in more than=20 >one chain, it seems artificially restrictive not to permit such a=20 >function to also implement branching, all the control structures would=20 >already be there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is=20 >a way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets in=20 >a chain. Branching should be performed by chain forwarding nodes,=20 >possibly under control of a control node. The reason for this is in NFV=20 >world, service functions may come from a third party, while chain is=20 >provided by the infrastructure of the network. There must be a cushion=20 >avoiding a service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user's=20 >packet, as well as some info like metadata in a SFC header. As=20 >classification is out of scope of SFC, we don't have to provide too=20 >much details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex=20 >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed=20 >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and=20 >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not=20 >the exclusive mechanism. Branching is a mechanism by which flow subsets=20 >are exposed and mapped to a set of subchains such that it can be=20 >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is=20 >defined/set even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to=20 >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative=20 >domain for some of the very reasons you point out. We need to keep=20 >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism=20 >>(recursive because a user-land application will ride with a specific=20 >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this=20 >>multi-domain issue - if I set a policy as a user, chances are I will=20 >>be crossing several domain boundaries. Are we expecting the service=20 >>headers to define the service chaining for the duration of the entire=20 >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the=20 >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty=20 >>relevant to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong=20 >>> mapping between Policy and the inserted Service Header(s), we=20 >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per=20 >>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to=20 >>> redefine it - it's been around for all the time middle boxes have=20 >>> been or for that matter the L2/L3 devices. All we are talking about=20 >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of=20 >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a=20 >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a=20 >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a=20 >>> > chain is different than I originally inferred. If the chain is a=20 >>> > tree with other "branching" points in it, then that limits the=20 >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation=20 >>> > could define bad service chains, is it the intent of SFC to only=20 >>> > look at the simpler packet-level classification cases, or is it=20 >>> > the intent to consider the case where a branching point is viewed=20 >>> > as a re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D=20 >>> >>reclassification, agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be=20 >>> >> in a form of logic on a service function. Some service functions,=20 >>> >> especially L7 based, can use value in a Database to determine=20 >>> >> what is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after=20 >>> >> > been processed by a certain service function, decision of which=20 >>> >> > branches to go is made based on the result of service=20 >>> >> > function's process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The=20 >>> >> > details around how to convey the selection of the=20 >>> >> > subtree/subgraph are still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and=20 >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question=20 >>> >> > > about service header encapsulation, is it intended that a=20 >>> >> > > chain that is re-classified will get a new chain ID which=20 >>> >> > > fully describes a chain that is a superset of the original=20 >>> >> > > chain ID, prior to DPI-based re-classification? (assuming=20 >>> >> > > the goal is "a single chain ID that is commonly understood=20 >>> >> > > along the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>> >> > > l >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service=20 >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>> >> > > every flow then be initially classified as ID 1, but=20 >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of=20 >>> >> > >>> service that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification=20 >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the=20 >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the=20 >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is=20 >>> >> > >>> limited due to limitations in classification, that would be=20 >>> >> > >>> and important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >>> >> > >>> fork points of the service paths seem like=20 >>> >> > >>> re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive=20 >>> >> > >>> of DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general,=20 >>> >> > >> as described in the arch draft, the collection of services=20 >>> >> > >> form a graph, segments of which are service paths. Yes,=20 >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any=20 >>> >> > >> node along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental=20 >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is=20 >>> >> > >>>> that such classification aids in traffic selection and=20 >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except=20 >>> >> > >>>> that the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network=20 >>> >> > >>>> elements but the service functions as well. Some of this=20 >>> >> > >>>> is described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied=20 >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume=20 >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service=20 >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network=20 >>> >> > >>>>> or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some=20 >>> >> > >>>>> of) the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies=20 >>> >> > >>>>> packets based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such=20 >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID,=20 >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework=20 >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service=20 >>> >> > >>>>> function identifier lookup does not seem to be a=20 >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified=20 >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to=20 >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach=20 >>> >> > >>>>>> for every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its=20 >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one=20 >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction=20 >>> >> > >>>>>> of the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC=20 >>> >> > >>>>>> header or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow=20 >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service=20 >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which=20 >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to=20 >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP=20 >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the=20 >>> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >>> >> > >>>>>> imply immutability, but rather to specify the packet=20 >>> >> > >>>>>> that is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation=20 >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation=20 >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation=20 >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as=20 >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>> >> > >>>>>> applications, have all undergone significant change in=20 >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge=20 >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered=20 >>> >> > >>>>>> combination of a number of service functions that are=20 >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service=20 >>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>> >> > >>>>>> path between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the=20 >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>> >> > >>>>>> service functions and the order in which they are to be=20 >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>> >> > >>>>>> function may be available on more than one node within a=20 >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and=20 >>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function=20 >>> >> > >>>>>> chaining that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>> >> > >>>>>> description of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>> >> > >>>>>> protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement=20 >>> >> > >>>>>> with all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Nov 14 07:24:07 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7091F21F9C70 for ; Thu, 14 Nov 2013 07:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN4b50Z2Fo9Z for ; Thu, 14 Nov 2013 07:24:03 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id EDED221E8056 for ; Thu, 14 Nov 2013 07:24:02 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 07:24:02 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oBTPtlYMFwdkW7YwvFgDvnV5ojd/8AgABdGwCAALQWgIAA0K0AgAAE9AD//3rfEA== Date: Thu, 14 Nov 2013 15:24:02 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:24:07 -0000 Hi, Jim. I agree that forwarding is affected indirectly. Whether function b forwar= ds to function c or function d is accomplished by b correctly adding (modif= ying) the transport header so that d is addressed or c is addressed. In t= he most general case of utilizing an IP-based transport encapsulation (e.g.= , IP/UDP, IP/GRE, etc.), the selection of next hop is not made at this leve= l. The transport location (IP address) for c and d may or may not share t= he same next-hop based on the newtwork topology (i.e., c and/or d may or ma= y not be on the same subnet as b, may or may not be reached via the same ne= xt hop router). Ron -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Thursday, November 14, 2013 10:14 AM To: David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter I think it is misleading to say that a service function does not impact pac= ket forwarding. If branching occurs then the service function does impact p= acket forwarding, whether directly or indirectly, as otherwise packets woul= d not take the new path as a result of the branch. For example, if the chai= n is a-b-c and b decides that for certain flows the traffic should go to d = rather than c then it *must* force the forwarding component to direct traff= ic to the new next-hop. While the service function may not modify forwardin= g in terms of updating forwarding tables and so forth, it has to inform the= forwarding component of its intent somehow. Also, I think what you describ= e Dave is a bypass operation rather than a branch?=20 On 11/14/13 9:56 AM, "David Allan I" wrote: >I think it is going to be a rare event, as what is more likely is the=20 >front end of the chain is dynamically modified so subsequent packets in=20 >a flow skip certain functions. Hence a graph more often than not is=20 >logically P2P. Facilitates testing amongst other benefits. > >As such I'd not want to be prescriptive as to how and where it is done.... > >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 6:30 PM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >Hi Dave, > >Your inferred restriction may be not always true. In general, service=20 >functions should be able to compose a chain arbitrarily. Particularly=20 >for branching, as I suggested in previous email, service function shall=20 >not directly impact packet forwarding. This precludes the restriction=20 >you mentioned. Forwarding plane can decide whether a branching action=20 >should be taken by reclassification or not per service chain. > >Does this make sense? > >Hongyu > >-----Original Message----- >From: David Allan I [mailto:david.i.allan@ericsson.com] >Sent: Wednesday, November 13, 2013 11:45 PM >To: Hongyu Li (Julio); nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >HI Hongyu: > >I think we will have scenarios where a service function appears in more=20 >than one chain, as would be the case, for example, if some flows could=20 >dynamically bypass DPI but still needed to transit a common set of=20 >stateful service functions... > >Once you postulate a service function instance appearing in more than=20 >one chain, it seems artificially restrictive not to permit such a=20 >function to also implement branching, all the control structures would=20 >already be there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is=20 >a way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets in=20 >a chain. Branching should be performed by chain forwarding nodes,=20 >possibly under control of a control node. The reason for this is in NFV=20 >world, service functions may come from a third party, while chain is=20 >provided by the infrastructure of the network. There must be a cushion=20 >avoiding a service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user's=20 >packet, as well as some info like metadata in a SFC header. As=20 >classification is out of scope of SFC, we don't have to provide too=20 >much details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex=20 >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed=20 >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and=20 >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not=20 >the exclusive mechanism. Branching is a mechanism by which flow subsets=20 >are exposed and mapped to a set of subchains such that it can be=20 >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is=20 >defined/set even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to=20 >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative=20 >domain for some of the very reasons you point out. We need to keep=20 >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism=20 >>(recursive because a user-land application will ride with a specific=20 >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this=20 >>multi-domain issue - if I set a policy as a user, chances are I will=20 >>be crossing several domain boundaries. Are we expecting the service=20 >>headers to define the service chaining for the duration of the entire=20 >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the=20 >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty=20 >>relevant to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong=20 >>> mapping between Policy and the inserted Service Header(s), we=20 >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per=20 >>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to=20 >>> redefine it - it's been around for all the time middle boxes have=20 >>> been or for that matter the L2/L3 devices. All we are talking about=20 >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of=20 >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a=20 >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a=20 >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a=20 >>> > chain is different than I originally inferred. If the chain is a=20 >>> > tree with other "branching" points in it, then that limits the=20 >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation=20 >>> > could define bad service chains, is it the intent of SFC to only=20 >>> > look at the simpler packet-level classification cases, or is it=20 >>> > the intent to consider the case where a branching point is viewed=20 >>> > as a re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D=20 >>> >>reclassification, agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be=20 >>> >> in a form of logic on a service function. Some service functions,=20 >>> >> especially L7 based, can use value in a Database to determine=20 >>> >> what is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after=20 >>> >> > been processed by a certain service function, decision of which=20 >>> >> > branches to go is made based on the result of service=20 >>> >> > function's process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The=20 >>> >> > details around how to convey the selection of the=20 >>> >> > subtree/subgraph are still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and=20 >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question=20 >>> >> > > about service header encapsulation, is it intended that a=20 >>> >> > > chain that is re-classified will get a new chain ID which=20 >>> >> > > fully describes a chain that is a superset of the original=20 >>> >> > > chain ID, prior to DPI-based re-classification? (assuming=20 >>> >> > > the goal is "a single chain ID that is commonly understood=20 >>> >> > > along the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>> >> > > l >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service=20 >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>> >> > > every flow then be initially classified as ID 1, but=20 >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of=20 >>> >> > >>> service that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification=20 >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the=20 >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the=20 >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is=20 >>> >> > >>> limited due to limitations in classification, that would be=20 >>> >> > >>> and important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >>> >> > >>> fork points of the service paths seem like=20 >>> >> > >>> re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive=20 >>> >> > >>> of DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general,=20 >>> >> > >> as described in the arch draft, the collection of services=20 >>> >> > >> form a graph, segments of which are service paths. Yes,=20 >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any=20 >>> >> > >> node along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental=20 >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is=20 >>> >> > >>>> that such classification aids in traffic selection and=20 >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except=20 >>> >> > >>>> that the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network=20 >>> >> > >>>> elements but the service functions as well. Some of this=20 >>> >> > >>>> is described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied=20 >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume=20 >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service=20 >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network=20 >>> >> > >>>>> or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some=20 >>> >> > >>>>> of) the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies=20 >>> >> > >>>>> packets based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such=20 >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID,=20 >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework=20 >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service=20 >>> >> > >>>>> function identifier lookup does not seem to be a=20 >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified=20 >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to=20 >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach=20 >>> >> > >>>>>> for every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its=20 >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one=20 >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction=20 >>> >> > >>>>>> of the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC=20 >>> >> > >>>>>> header or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow=20 >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service=20 >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which=20 >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to=20 >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker=20 >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP=20 >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the=20 >>> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >>> >> > >>>>>> imply immutability, but rather to specify the packet=20 >>> >> > >>>>>> that is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation=20 >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation=20 >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation=20 >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as=20 >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>> >> > >>>>>> applications, have all undergone significant change in=20 >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge=20 >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered=20 >>> >> > >>>>>> combination of a number of service functions that are=20 >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service=20 >>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>> >> > >>>>>> path between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the=20 >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>> >> > >>>>>> service functions and the order in which they are to be=20 >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>> >> > >>>>>> function may be available on more than one node within a=20 >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and=20 >>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function=20 >>> >> > >>>>>> chaining that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>> >> > >>>>>> description of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>> >> > >>>>>> protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement=20 >>> >> > >>>>>> with all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Nov 14 07:29:49 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFBBF21E80E8 for ; Thu, 14 Nov 2013 07:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou6e4HyOZGRe for ; Thu, 14 Nov 2013 07:29:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A7AAF11E8133 for ; Thu, 14 Nov 2013 07:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45654; q=dns/txt; s=iport; t=1384442983; x=1385652583; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cbrCQG2hEiUL1E1P+HrKpyDXDUfhagDgXFJA0M/pR+w=; b=Zb3F5lG7oy20A18qQ4UfdarKWvXXjEWPIVSRhS1wdhWQk1oZwx76VOSv SEqvk4y9FC9fK/+/HVHR9wZecMDi8WgJYSFdkovNHXvkJj89dU6aBYxYu ZctH5MFqkrByVU5wPHNetaUoxx2dIR53nlPc8ZQDy7JO5ro+t120zzuNT I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAB7rhFKtJV2d/2dsb2JhbABQCoMHOFO/IYEfFnSCJQEBAQQBAQEXAR8rAgcEEwYBCBEBAwEBARUJCS4LFAMFAQgCBAEJCQmHeA3AJY4WBgQBBQaBCDICBASEJwOULoNikgyDKIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284791241" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2013 15:29:42 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAEFTfOw013958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 15:29:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 09:29:41 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAALQWgIAA0K0A//+xHgCAAFaFAP//rb6A Date: Thu, 14 Nov 2013 15:29:40 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="us-ascii" Content-ID: <26AEB9755E8ED645A3C95189FDAD4FB5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:29:49 -0000 Hi Ron, I would not say that b modifies the transport header but rather b informs the forwarding component of it's intent so that it may insert the appropriate transport header to meet b's requirement. On 11/14/13 10:24 AM, "Ron Parker" wrote: >Hi, Jim. > >I agree that forwarding is affected indirectly. Whether function b >forwards to function c or function d is accomplished by b correctly >adding (modifying) the transport header so that d is addressed or c is >addressed. In the most general case of utilizing an IP-based transport >encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is >not made at this level. The transport location (IP address) for c and d >may or may not share the same next-hop based on the newtwork topology >(i.e., c and/or d may or may not be on the same subnet as b, may or may >not be reached via the same next hop router). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim >Guichard (jguichar) >Sent: Thursday, November 14, 2013 10:14 AM >To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >Subject: Re: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >I think it is misleading to say that a service function does not impact >packet forwarding. If branching occurs then the service function does >impact packet forwarding, whether directly or indirectly, as otherwise >packets would not take the new path as a result of the branch. For >example, if the chain is a-b-c and b decides that for certain flows the >traffic should go to d rather than c then it *must* force the forwarding >component to direct traffic to the new next-hop. While the service >function may not modify forwarding in terms of updating forwarding tables >and so forth, it has to inform the forwarding component of its intent >somehow. Also, I think what you describe Dave is a bypass operation >rather than a branch? > >On 11/14/13 9:56 AM, "David Allan I" wrote: > >>I think it is going to be a rare event, as what is more likely is the >>front end of the chain is dynamically modified so subsequent packets in >>a flow skip certain functions. Hence a graph more often than not is >>logically P2P. Facilitates testing amongst other benefits. >> >>As such I'd not want to be prescriptive as to how and where it is >>done.... >> >>Dave >> >>-----Original Message----- >>From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>Sent: Wednesday, November 13, 2013 6:30 PM >>To: David Allan I; nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current >>Proposed SFC charter >> >>Hi Dave, >> >>Your inferred restriction may be not always true. In general, service >>functions should be able to compose a chain arbitrarily. Particularly >>for branching, as I suggested in previous email, service function shall >>not directly impact packet forwarding. This precludes the restriction >>you mentioned. Forwarding plane can decide whether a branching action >>should be taken by reclassification or not per service chain. >> >>Does this make sense? >> >>Hongyu >> >>-----Original Message----- >>From: David Allan I [mailto:david.i.allan@ericsson.com] >>Sent: Wednesday, November 13, 2013 11:45 PM >>To: Hongyu Li (Julio); nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current >>Proposed SFC charter >> >>HI Hongyu: >> >>I think we will have scenarios where a service function appears in more >>than one chain, as would be the case, for example, if some flows could >>dynamically bypass DPI but still needed to transit a common set of >>stateful service functions... >> >>Once you postulate a service function instance appearing in more than >>one chain, it seems artificially restrictive not to permit such a >>function to also implement branching, all the control structures would >>already be there. >> >>Rgds >>Dave >> >>-----Original Message----- >>From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>Sent: Wednesday, November 13, 2013 2:12 AM >>To: David Allan I; nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current >>Proposed SFC charter >> >>May I suggest summary of my views here: >> >>1. Branch is a sort of use case or scenario, while reclassification is >>a way to solve the problem. >>2. Service Functions should be decoupled with the chain itself. >> Meaning, a SF shall not *directly* impact the forwarding of packets in >>a chain. Branching should be performed by chain forwarding nodes, >>possibly under control of a control node. The reason for this is in NFV >>world, service functions may come from a third party, while chain is >>provided by the infrastructure of the network. There must be a cushion >>avoiding a service function operating infrastructure directly. >>3. (Re)classification is based on info in a packet. >> This is very general. Such info could be L2~L7 derived from a user's >>packet, as well as some info like metadata in a SFC header. As >>classification is out of scope of SFC, we don't have to provide too >>much details of how to do classification. >>4. Chain segments stitching is relatively a easy way for branching. >>Compared with chains and subchains, which may require a more complex >>header and forwarding capabilities. >>My two cents. >>Hongyu >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>David Allan I >>Sent: Wednesday, November 13, 2013 3:04 AM >>To: nsc@ietf.org >>Subject: [nsc] FW: re classification & branching, was: Current Proposed >>SFC charter >> >>Hi: >>(resend with recipient list cleaned up) >> >>I agree we are discussing multiple concepts, classification and >>flow-subsetting. Perhaps more ;-) >> >>Defining a flow subset can be a result of classification, but it is not >>the exclusive mechanism. Branching is a mechanism by which flow subsets >>are exposed and mapped to a set of subchains such that it can be >>identified in the dataplane... >> >>That's the view from here >>Dave >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>David Lake (dlake) >>Sent: Tuesday, November 12, 2013 10:51 AM >>To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >>Parker; Linda Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: Re: [nsc] Current Proposed SFC charter >> >>Understood - maybe just a little localised warming of the sea then ? >>But I still think we need to consider where and how policy is >>defined/set even for the single-domain instance. >> >>I don't think we can assume that any L1-3 device will be able to >>determine much useful information from the data-plane. >> >>-----Original Message----- >>From: Jim Guichard (jguichar) >>Sent: 12 November 2013 10:44 >>To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron >>Parker; Linda Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: Re: [nsc] Current Proposed SFC charter >> >>As discussed during the BOF our initial work is single administrative >>domain for some of the very reasons you point out. We need to keep >>focused without trying to boil the ocean right off the bat. >> >>On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >> >>>Exactly. But how can network-components "terminate" an application ???? >>> >>>I think we need a good understanding of a recursive policy mechanism >>>(recursive because a user-land application will ride with a specific >>>policy across potentially different sets of carrier policies). >>> >>>I hate to bring this up now, but we also need to think about this >>>multi-domain issue - if I set a policy as a user, chances are I will >>>be crossing several domain boundaries. Are we expecting the service >>>headers to define the service chaining for the duration of the entire >>>flow across all domains, or just across a single one ? >>> >>>In which case, do I have to re-set policy as I traverse domains and >>>where does that policy get set ? It would be much better to set policy >>>once based on L5-7 needs, and have that instantiated across the >>>multiple domains. >>> >>>Again, this appears to be outside the scope of SFC, but pretty >>>relevant to how it would operate in the real world. >>> >>>David >>> >>>-----Original Message----- >>>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>Sent: 12 November 2013 10:27 >>>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>>Dunbar; Hongyu Li (Julio) >>>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>Subject: RE: [nsc] Current Proposed SFC charter >>> >>>> In those circumstances, only the end applications themselves or a >>>> reasonably broad-brushed classification (really traffic steering >>>> based on what we can see at ingress) is going to be useful - is THAT >>>> what we're aiming for here ? >>> >>>I would certainly hope not, but that has been my concern as well. >>>Application layer termination and re-classification seems a must? >>> >>>-- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>>> Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >>>> Policy may be outside of the scope of SFC, but without strong >>>> mapping between Policy and the inserted Service Header(s), we >>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>> >>>> For example, in a world where the network has "gone dark," (as per >>>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>>> policy based on DPI of packets-in-flight ? >>>> >>>> In those circumstances, only the end applications themselves or a >>>> reasonably broad-brushed classification (really traffic steering >>>> based on what we can see at ingress) is going to be useful - is THAT >>>> what we're aiming for here ? >>>> >>>> David >>>> >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of Surendra Kumar (smkumar) >>>> Sent: 12 November 2013 09:26 >>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >>>> Ron, >>>> >>>> Classification of traffic is well understood and we do not have to >>>> redefine it - it's been around for all the time middle boxes have >>>> been or for that matter the L2/L3 devices. All we are talking about >>>> is the applicability of the classification to branching in SFC. >>>> >>>> You are right, it is all about policy which is outside the scope of >>>>SFC. >>>> >>>> Surendra. >>>> >>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>wrote: >>>> >>>> >I think the lack of definition of "reclassification" may be causing >>>>some >>>> >misunderstandings here. A branch would occur for some >>>>policy-driven >>>> >reason based on the behavior and conclusions of the service function, >>>> >itself. The graph would represent the fact that there is a branch >>>> >point, but the service function, itself, being aware that it is a >>>> >branching point would contain the policy and logic to decide on which >>>> >branch to take. Specifying that policy and logic is out of scope, >>>>IMO. >>>> > >>>> > Ron >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>> >Sent: Tuesday, November 12, 2013 10:49 AM >>>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>>> >Majee >>>> >Subject: RE: [nsc] Current Proposed SFC charter >>>> > >>>> >Hi Linda, >>>> > >>>> > Are you saying that a branching point is "never" a >>>> > reclassification point, or are you saying that a branching point >>>>"does not have to be" >>>> > a reclassification point? >>>> > >>>> > I think this is an important distinction that needs to be >>>>clarified. >>>> > If branching is never reclassification, then the meaning of a >>>> > chain is different than I originally inferred. If the chain is a >>>> > tree with other "branching" points in it, then that limits the >>>> > scope of the problem statement goals. >>>> > >>>> > While this could be a degenerate case, and any implementation >>>> > could define bad service chains, is it the intent of SFC to only >>>> > look at the simpler packet-level classification cases, or is it >>>> > the intent to consider the case where a branching point is viewed >>>> > as a re-classification point? >>>> > >>>> >thanx. >>>> > >>>> >-- Kevin J. Ma >>>> > >>>> >> -----Original Message----- >>>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>> >> Sumandra Majee >>>> >> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> >>>> >> Ron, >>>> >> >>>> >> First, want to make it clear that "branching" !=3D >>>> >>reclassification, agree? >>>> >> >>>> >> Second, the representation of branching (or service graph) can be >>>> >> in a form of logic on a service function. Some service functions, >>>> >> especially L7 based, can use value in a Database to determine >>>> >> what is the next service function. >>>> >> >>>> >> Linda >>>> >> >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>> >> > Behalf Of Ron Parker >>>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>>> >> > To: Hongyu Li (Julio); Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Hongyu, >>>> >> > >>>> >> > I agree completely that re-classification is not limited to DPI. >>>> >> > >>>> >> > And also, that an area for us to explore as a group is how to >>>> >>represent >>>> >> > the service graph. Do we want to represent it as a proper graph >>>> with >>>> >> > an adjacency list or other representational model? Or, do we >>>>want >>>> to >>>> >> > represent it as a set of linear segments and if so, how are the >>>> >> > segments connected into a graph? Other ideas? >>>> >> > >>>> >> > Ron >>>> >> > >>>> >> > >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>> >> > Behalf Of Hongyu Li (Julio) >>>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>>> >> > To: Ron Parker; Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Branching/forking is a very interesting topic of SFC. About the >>>> >> > re- classification point, probably we shall not limit it to DPI. >>>> >> > It is also possible that packets go to different branches after >>>> >> > been processed by a certain service function, decision of which >>>> >> > branches to go is made based on the result of service >>>> >> > function's process, i.e. not just re- classification by DPI. >>>> >> > >>>> >> > Hongyu >>>> >> > >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>> >> > Behalf Of Ron Parker >>>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>>> >> > To: Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Hi, Kevin >>>> >> > >>>> >> > You ask a great question about branching the graph. The >>>> >> > details around how to convey the selection of the >>>> >> > subtree/subgraph are still >>>> >>to be >>>> >> > defined. Is it one chain id for the whole graph? Does each >>>>branch >>>> >> > have its own chain id? Some combination? >>>> >> > >>>> >> > Ron >>>> >> > >>>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>> >> > >>>> >> > wrote: >>>> >> > >>>> >> > >> Yes, reclassification can change the service path and >>>> >> > >> re-classification may happen at any node along a service path. >>>> >> > > >>>> >> > > Just to expand on that, going back to the original question >>>> >> > > about service header encapsulation, is it intended that a >>>> >> > > chain that is re-classified will get a new chain ID which >>>> >> > > fully describes a chain that is a superset of the original >>>> >> > > chain ID, prior to DPI-based re-classification? (assuming >>>> >> > > the goal is "a single chain ID that is commonly understood >>>> >> > > along the entire service >>>> chain" >>>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>>> >> > > l >>>> >> > > ) >>>> >> > > >>>> >> > > And the applicable subset of the permutative list of service >>>> >> > > paths would be configured at each appropriate service node? >>>> >> > > e.g., ID 1: NAT + firewall + DPI >>>> >> > > ID 2: NAT + firewall + DPI + AV >>>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>>> >> > > ID 4: NAT + firewall + DPI + NAT >>>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>>> >> > > ID 6: NAT + firewall + DPI + LB >>>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>>> >> > > ID 8: NAT + firewall + DPI + CACHE >>>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>>> >> > > every flow then be initially classified as ID 1, but >>>> >> > > eventually get re- >>>> >> > classified >>>> >> > > to ID 2-11, after the DPI phase? >>>> >> > > >>>> >> > > thanx. >>>> >> > > >>>> >> > > -- Kevin J. Ma >>>> >> > > >>>> >> > >> -----Original Message----- >>>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> >> > >> nsc@ietf.org >>>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>> >> > >>> >>>> >>wrote: >>>> >> > >>> >>>> >> > >>> Hi Surendra, >>>> >> > >>> >>>> >> > >>> Classification may be out of scope, but the level of >>>> >> > >>> service that >>>> >> > is >>>> >> > >>> applicable is dependent upon the level of classification >>>> >> > >>> that can >>>> >> > be >>>> >> > >>> performed. An assumption of packet level encapsulation has >>>> >> > >> implications >>>> >> > >>> on the level of classification being performed? If the >>>> >> > >>> stated >>>> >> > goals >>>> >> > >> are >>>> >> > >>> for firewall and load balancer functionality, then the >>>> >> > >>> application >>>> >> > >> level >>>> >> > >>> nature of those functions needs to be taken into account? >>>> >> > >>> If, on the other hand, the service function scope is >>>> >> > >>> limited due to limitations in classification, that would be >>>> >> > >>> and important piece of >>>> >> > information? >>>> >> > >>> >>>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>>> >> > >>> fork points of the service paths seem like >>>> >> > >>> re-classification >>>> points? >>>> >> > >>> Is that the interpretation from the architecture perspective? >>>> >> > >>> Or is the service function chain classification exclusive >>>> >> > >>> of DPI >>>> >> > functionality? >>>> >> > >> I have not fully read that draft yet. But in general, >>>> >> > >> as described in the arch draft, the collection of services >>>> >> > >> form a graph, segments of which are service paths. Yes, >>>> >> > >> reclassification can >>>> >> > change >>>> >> > >> the service path and re-classification may happen at any >>>> >> > >> node along >>>> >> > a service path. >>>> >> > >> >>>> >> > >> Surendra. >>>> >> > >>> >>>> >> > >>> thanx. >>>> >> > >>> >>>> >> > >>> -- Kevin J. Ma >>>> >> > >>> >>>> >> > >>>> -----Original Message----- >>>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>> >> > >>>> nsc@ietf.org >>>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >>>> >> > >>>> Kevin, >>>> >> > >>>> >>>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>>> >> > >>>> can be based >>>> >> > >> on >>>> >> > >>>> the packet or information not in the packet(environmental >>>> >> > >>>> attributes >>>> >> > >> for >>>> >> > >>>> instance) or a combination thereof. What is important is >>>> >> > >>>> that such classification aids in traffic selection and >>>> >> > >>>> service path identification. >>>> >> > >>>> It is no different from a policy in this regard except >>>> >> > >>>> that the policy now specifies the service path. >>>> >> > >>>> Further, classification is not limited to the network >>>> >> > >>>> elements but the service functions as well. Some of this >>>> >> > >>>> is described in the >>>> >> > >> architecture >>>> >> > >>>> drafts as well - >>>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>> >> > >>>> >>>> >> > >>>> Surendra. >>>> >> > >>>> >>>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>> >> > >>>>> >>>> >> > wrote: >>>> >> > >>>>> >>>> >> > >>>>> Hi Ron, >>>> >> > >>>>> >>>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>>> >> > >>>>> section >>>> >> > >>>>> 2 of the >>>> >> > problem >>>> >> > >>>>> statement: >>>> >> > >>>>> >>>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>>> >> > >>>>> occurs at >>>> >> > each >>>> >> > >>>>> service, independent from previously applied >>>> >> > >>>>> service >>>> >> > >>>> functions. >>>> >> > >>>>> These unrelated classification events consume >>>> >> > >>>>> resources >>>> >> > per >>>> >> > >>>>> service. More importantly, the classification >>>> >> > functionality >>>> >> > >>>>> often differs per service function and service >>>> >> > >>>>> function >>>> >> > >> cannot >>>> >> > >>>>> leverage the results from other deployed network >>>> >> > >>>>> or >>>> >> > service. >>>> >> > >>>>> >>>> >> > >>>>> as it relates to section 5.2 of the framework document: >>>> >> > >>>>> >>>> >> > >>>>> The SFC Classifier classifies packets based on (some >>>> >> > >>>>> of) the >>>> >> > >>>> contents >>>> >> > >>>>> of the packet header. Concretely, it classifies >>>> >> > >>>>> packets based on >>>> >> > >>>> the >>>> >> > >>>>> possible combination of one or more header fields, such >>>> >> > >>>>> as >>>> >> > source >>>> >> > >>>>> address, destination address, DS field, protocol ID, >>>> >> > >>>>> source >>>> >> > port >>>> >> > >>>> and >>>> >> > >>>>> destination port numbers, and any other information. >>>> >> > >>>>> >>>> >> > >>>>> A packet-based classifier as described in the framework >>>> >> > >>>>> document >>>> >> > >>>> would >>>> >> > >>>>> seem to be limited in what it can classify? The service >>>> >> > >>>>> function identifier lookup does not seem to be a >>>> >> > >>>>> significant optimization >>>> >> > >> over >>>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>>> >> > >>>>> missing >>>> >> > >> detail >>>> >> > >>>>> wrt how classification information is determined and >>>>reused? >>>> >> > >>>>> >>>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>>> >> > >>>>> TLS >>>> >> > >>>> encrypted >>>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>>> >> > >>>>> also >>>> >> > >>>> wondering >>>> >> > >>>>> how independent HLS segment requests might be classified >>>> >> > >>>>> and >>>> >> > >>>> associated? >>>> >> > >>>>> Were these types of use cases discussed in the BoF? >>>> >> > >>>>> >>>> >> > >>>>> thanx. >>>> >> > >>>>> >>>> >> > >>>>> -- Kevin J. Ma >>>> >> > >>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>>> >> > >>>>>> On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Ron >>>> >> > >>>>>> Parker >>>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> As was discussed in Vancouver, there are already many >>>> >> > >>>>>> existing ways >>>> >> > >>>> to >>>> >> > >>>>>> accomplish service chaining. But none of them provide >>>>a >>>> >> > >>>> sufficient >>>> >> > >>>>>> combination of interoperability, flexibility, and >>>>resiliency. >>>> >> > A >>>> >> > >>>> single >>>> >> > >>>>>> service chain encapsulation will go a long way to >>>> >> > >>>>>> ensuring these >>>> >> > >>>> goals. >>>> >> > >>>>>> It may not be the absolutely most efficient approach >>>> >> > >>>>>> for every >>>> >> > >>>> single >>>> >> > >>>>>> network topology and every single use case, but its >>>> >> > >>>>>> ubiquitous >>>> >> > >> nature >>>> >> > >>>>>> should improve its adoption. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Ron, >>>> >> > >>>>>> >>>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>>> >> > >>>>>> However >>>> >> > >>>> this >>>> >> > >>>>>> could be augmented with classification result, again one >>>> >> > >>>>>> more >>>> >> > >>>> example. >>>> >> > >>>>>> >>>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>>> >> > >>>>>>>> follow >>>> >> > the >>>> >> > >>>> same >>>> >> > >>>>>> chain. >>>> >> > >>>>>> Correct. It is also not necessary that all transaction >>>> >> > >>>>>> of the same >>>> >> > >>>> flow >>>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>>> >> > >>>>>> >>>> >> > >>>>>> Again the point here is that do we always need SFC >>>> >> > >>>>>> header or >>>> >>Not. >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Ron Parker >>>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> The intention of service function chaining is to allow >>>> >> > >>>>>> for operation >>>> >> > >>>> at >>>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>>> >> > >>>>>> the >>>> >> > >>>> transaction >>>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>>All >>>> >> > flows >>>> >> > >>>> from >>>> >> > >>>>>> the same source IP do not necessarily follow the same >>>>chain. >>>> >> > >> Source >>>> >> > >>>>>> IP, >>>> >> > >>>>>> therefore, does not identify the chain ID. Another >>>> >>intention >>>> >> > of >>>> >> > >>>>>> service function chaining is to operate over any network >>>> >> > topology >>>> >> > >> and >>>> >> > >>>>>> not >>>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>of >>>> >> > the >>>> >> > >>>>>> transport, it does not adequately identify the service >>>> >> > >>>>>> chain, >>>> >> > >> either. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Ron, >>>> >> > >>>>>> >>>> >> > >>>>>> The service header is meant to carry the context which >>>> >> > >>>>>> can >>>> >> > *also* >>>> >> > >>>>>> be derived (for example use source ip and vlan to >>>> >> > >>>>>> identify chainID and >>>> >> > >>>>>> position) or encapsulated as part of another tunnel >>>>header. >>>> >> > >>>>>> So this could be optional IMHO. >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Ron Parker >>>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>>> >> > >>>>>> SF or from >>>> >> > >>>> SF >>>> >> > >>>>>> to >>>> >> > >>>>>> SF will look like: >>>> >> > >>>>>> >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | "transport" | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | service header | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | original IP header | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | | original IP >>>> >> > >>>>>> | payload >>>> >> > | >>>> >> > >>>>>> | | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> >>>> >> > >>>>>> Where service header contains, at a minimum, enough >>>> >> > >>>>>> information to >>>> >> > >>>> allow >>>> >> > >>>>>> the packet to be propagated along the full length of the >>>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>>> >> > >>>>>> operation of >>>> >> > one >>>> >> > >>>>>> or >>>> >> > >> more >>>> >> > >>>>>> service functions. >>>> >> > >>>>>> >>>> >> > >>>>>> And where "transport" could conceivably be any of, but >>>> >> > >>>>>> not limited >>>> >> > >>>> to: >>>> >> > >>>>>> >>>> >> > >>>>>> * Ethernet >>>> >> > >>>>>> * Ethernet + LLC2 >>>> >> > >>>>>> * Ethernet + MPLS >>>> >> > >>>>>> * Ethernet + IP + GRE >>>> >> > >>>>>> * Ethernet + IP +UDP >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>>> >> > >>>>>> imply immutability, but rather to specify the packet >>>> >> > >>>>>> that is >>>> >> > propagated >>>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>>> >> > >>>>>> encapsulation. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>>> >> > >>>>>> On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Sumandra Majee >>>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>>> >> > >>>>>> document >>>> >>will >>>> >> > >>>>>> describe the single service-level data plane >>>> >> > >>>>>> encapsulation >>>> >> > >> format >>>> >> > >>>>>> for >>>> >> > >>>>>> conveying the service function chain and the service >>>> >> > >>>>>> function >>>> >> > >>>> path, >>>> >> > >>>>>> and for communicating context information between >>>> >> > >>>>>> nodes >>>> that >>>> >> > >>>>>> implement service functions. It is intended that the >>>> >> > >>>> encapsulation >>>> >> > >>>>>> be agnostic to the layer at which it is applied and >>>> >> > >>>>>> the service >>>> >> > >>>> that >>>> >> > >>>>>> is >>>> >> > >>>>>> being constructed. That is, the same encapsulation >>>> >> > >>>>>> may be >>>> >> > used >>>> >> > >> on >>>> >> > >>>>>> a service function path realized at the network layer >>>> >> > >>>>>> or at any other >>>> >> > >>>>>> layer, and the same encapsulation will apply for the >>>> >> > >> construction >>>> >> > >>>> of >>>> >> > >>>>>> service function paths regardless of the actual >>>>service. >>>> >> > >>>>>> >>>> >> > >>>>>> [SM] What does it mean by a single service-level >>>> >> > >>>>>> encapsulation, >>>> >> > a >>>> >> > >>>> new >>>> >> > >>>>>> encapsulation format >>>> >> > >>>>>> or an ability to select one encapsulation=20 >>>> >> > >>>>>> format that >>>> >> > >>>> fits >>>> >> > >>>>>> the >>>> >> > >>>>>> need for a given service chain? >>>> >> > >>>>>> The ability to select a specific encapsulation=20 >>>> >> > >>>>>> would be >>>> >> > >> a >>>> >> > >>>>>> management plane decision. >>>> >> > >>>>>> There are quite a few existing encapsulation=20 >>>> >> > >>>>>> methods that >>>> >> > >>>> can >>>> >> > >>>>>> possibly be reused to provide >>>> >> > >>>>>> context information between service nodes. I >>>>have >>>> >> > seen >>>> >> > >>>>>> mention >>>> >> > >>>>>> of GRE, for HTTP based >>>> >> > >>>>>> applications contexts are transferred via=20 >>>>headers. >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>>> >> > >>>>>> On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Thomas Narten >>>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>> >> > >>>>>> To: nsc@ietf.org >>>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Hi. >>>> >> > >>>>>> >>>> >> > >>>>>> Current charter can be found at >>>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>>> >> > >>>>>> ietf-sfc/. >>>> >> > >>>>>> >>>> >> > >>>>>> It contains the revised management text as well as=20 >>>> >> > >>>>>> updated >>>> >> > >>>> milestones. >>>> >> > >>>>>> >>>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>>> >> > >>>>>> remaining >>>> >> > >>>> issues, >>>> >> > >>>>>> please speak up! >>>> >> > >>>>>> >>>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>>> >> > >>>>>> >>>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>>> >> > >>>>>> applications, have all undergone significant change in=20 >>>> >> > >>>>>> recent years with the introduction >>>> >> > >> of >>>> >> > >>>>>> virtualization, network overlays, and orchestration. >>>> >> > >>>>>> Service >>>> >> > >> delivery >>>> >> > >>>> is >>>> >> > >>>>>> currently both a technical and organizational challenge=20 >>>> >> > >>>>>> that >>>> >> > >> involves >>>> >> > >>>>>> significant modification to the network configuration. >>>> >> > >>>>>> Services are typically implemented by the ordered=20 >>>> >> > >>>>>> combination of a number of service functions that are=20 >>>> >> > >>>>>> deployed at different points within >>>> >> > >> the >>>> >> > >>>>>> network. Today, a common deployment model has service=20 >>>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>>> >> > >>>>>> path between communicating peers. >>>> >> > >>>> Going >>>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>>> >> > >>>>>> different model, >>>> >> > >>>> where >>>> >> > >>>>>> service functions are not required to reside on the=20 >>>> >> > >>>>>> default data >>>> >> > >> path >>>> >> > >>>>>> and >>>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>>> >> > >>>>>> they are >>>> >> > >>>> deployed. >>>> >> > >>>>>> >>>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>>> >> > >>>>>> service functions and the order in which they are to be=20 >>>> >> > >>>>>> applied is >>>> >> > called >>>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>>> >> > >>>>>> function may be available on more than one node within a=20 >>>> >> > >>>>>> network, a Service Function Chain is instantiated >>>> >> > >>>> via >>>> >> > >>>>>> the selection of specific service function instances and=20 >>>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>>> >> > >>>>>> forming a service topology: >>>> >> > >>>>>> this is called a Service Function Path. The service=20 >>>> >> > >>>>>> functions >>>> >> > may >>>> >> > >>>>>> be applied at a specific layer within the network=20 >>>> >> > >>>>>> protocol stack >>>> >> > >>>> (network >>>> >> > >>>>>> layer, application layer, etc.). >>>> >> > >>>>>> >>>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>>> >> > >>>>>> develop new approaches to service delivery and deployment. >>>> >> > >>>>>> It will produce a framework for service function=20 >>>> >> > >>>>>> chaining that includes the necessary protocols >>>> >> > >>>> or >>>> >> > >>>>>> protocol extensions to convey the service path and=20 >>>> >> > >>>>>> service path information to nodes that implement service=20 >>>> >> > >>>>>> functions, as well >>>> >> > as >>>> >> > >>>>>> mechanisms for steering traffic through service functions. >>>> >> > >>>>>> The >>>> >> > >>>> working >>>> >> > >>>>>> group will also examine what information needs to be=20 >>>> >> > >>>>>> gathered from >>>> >> > >>>> the >>>> >> > >>>>>> network and service functions in support of service=20 >>>> >> > >>>>>> function >>>> >> > >> chaining >>>> >> > >>>>>> and >>>> >> > >>>>>> how that information may be made available to nodes that=20 >>>> >> > >>>>>> implement >>>> >> > >>>> the >>>> >> > >>>>>> service functions. >>>> >> > >>>>>> >>>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>>> following: >>>> >> > >>>>>> >>>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>>> >> > >>>>>> summary of >>>> >> > the >>>> >> > >>>>>> problem space to be addressed by the WG including=20 >>>> >> > >>>>>> example >>>> >> > high- >>>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>>> >> > >> nomenclature >>>> >> > >>>>>> and definitions for service function chaining. >>>> >> > >>>>>> >>>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>>> >> > >>>>>> description of >>>> >>the >>>> >> > >>>>>> architectural building blocks and their relationships >>>> >> > including >>>> >> > >>>>>> interconnection, placement of capabilities, management, >>>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>>> >> > >>>>>> well >>>> >>as >>>> >> > >>>>>> requirements on the protocol mechanisms. >>>> >> > >>>>>> >>>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>> >> > >>>>>> document >>>> >> > will >>>> >> > >>>>>> describe the single service-level data plane=20 >>>> >> > >>>>>> encapsulation >>>> >> > >> format >>>> >> > >>>>>> for >>>> >> > >>>>>> conveying the service function chain and the service=20 >>>> >> > >>>>>> function >>>> >> > >>>> path, >>>> >> > >>>>>> and for communicating context information between=20 >>>> >> > >>>>>> nodes >>>> that >>>> >> > >>>>>> implement service functions. It is intended that the >>>> >> > >>>> encapsulation >>>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>>> >> > >>>>>> the service >>>> >> > >>>> that >>>> >> > >>>>>> is >>>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>>> >> > >>>>>> may be >>>> >> > used >>>> >> > >> on >>>> >> > >>>>>> a service function path realized at the network layer=20 >>>> >> > >>>>>> or at any other >>>> >> > >>>>>> layer, and the same encapsulation will apply for the >>>> >> > >> construction >>>> >> > >>>> of >>>> >> > >>>>>> service function paths regardless of the actual=20 >>>>service. >>>> >> > >>>>>> >>>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>> >> > developed to >>>> >> > >>>>>> describe requirements and protocols necessary to=20 >>>> >> > >>>>>> convey >>>> >> > >>>> information >>>> >> > >>>>>> to service function implementation points. Where=20 >>>> >> > >>>>>> possible, >>>> >> > >>>> existing >>>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>>> >> > >>>>>> protocol >>>> >> > >> extensions >>>> >> > >>>>>> work should be carried out in the working groups=20 >>>> >> > >>>>>> responsible for >>>> >> > >>>> the >>>> >> > >>>>>> protocols being modified in coordination with this=20 >>>> >> > >>>>>> working >>>> >> > >> group, >>>> >> > >>>>>> but >>>> >> > >>>>>> may be done in this working group after agreement=20 >>>> >> > >>>>>> with all >>>> >> > the >>>> >> > >>>>>> relevant WG chairs and responsible ADs. >>>> >> > >>>>>> >>>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>>> >> > >>>>>> configuration of >>>> >> > >> service >>>> >> > >>>>>> functions in support of SFC components will certainly=20 >>>> >> > >>>>>> be >>>> >> > needed, >>>> >> > >>>>>> but first needs to be better understood and scoped. >>>> >> > >>>>>> >>>> >> > >>>>>> Proposed Milestones >>>> >> > >>>>>> >>>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>> >> > >>>>>> defining the >>>> >> > >>>> problem >>>> >> > >>>>>> statement and core use cases for Service Function=20 >>>> >> > >>>>>> Chaining >>>> >> > >>>>>> >>>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>> >> > >>>>>> modifications for management and configuration of SFC=20 >>>> >> > >>>>>> components >>>> >> > >>>>>> >>>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>> >> > >>>>>> the >>>> >> > >>>> architecture >>>> >> > >>>>>> for SFC >>>> >> > >>>>>> >>>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>> >> > >>>>>> service function chaining encapsulation protocol >>>> >> > >>>>>> >>>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>> >> > >>>>>> specifying the >>>> >> > >>>> generic >>>> >> > >>>>>> service function chaining header encapsulation >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> Thomas >>>> >> > >>>>>> >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>> _______________________________________________ >>>> >> > >>>>> nsc mailing list >>>> >> > >>>>> nsc@ietf.org >>>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > > >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From I.Smith@f5.com Thu Nov 14 07:38:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0C111E8163 for ; Thu, 14 Nov 2013 07:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.452 X-Spam-Level: X-Spam-Status: No, score=-10.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSwHgl5Njd3M for ; Thu, 14 Nov 2013 07:38:43 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4643421F9DAF for ; Thu, 14 Nov 2013 07:37:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1384443426; x=1415979426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7YmTis8CFcX103+FUin4J+d0JlS6Av80v/Zq1f6i/gw=; b=d9jJUwsMF8th2YVvmjlyw2UUxZNEMe4Xp3+wPUPWX3pxHagjEsKfLrZR HVb/IUNwWQF5FiHwygSrzupydZc4BoVrk2Cs42s2+mPRDXIBlYqG56msq u1b5Z3whbhI/G6WbjGGAE32MaJSv14ylPP2lLsyYQtOLuvAA8Hx8kVM7p 0=; X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="86956011" X-IPAS-Result: AqMEAMPshFLAqArr/2dsb2JhbABQCoM/v3SBNXSCJQEBAQECAQEBARcBHysCBwQHDAQCAQgNBAEDAQEBCQwJCQcPGAsUAwUBCAIECgQFCYdyE8ASF44cBAEFBoEACCsHAgQEhCcDlC6DYoZljk+BaAEI Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 14 Nov 2013 15:37:03 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 07:37:02 -0800 From: Ian Smith To: David Allan I Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQADB9SAAAC6NXAAAsJogAAAVUWQD//34URQ== Date: Thu, 14 Nov 2013 15:37:02 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Jim Guichard , "Hongyu Li \(Julio\)" Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:38:47 -0000 I think the metaphor is wrong: the service function chain is the train, th= e packets are the shipping containers loaded on the train, and the tracks a= re the data link/switching/routing infrastructure. How the cars of the train are arranged is a sfc configuration function. Which containers go onto the train is a function of classification. Where the tracks go is a function of network infrastructure. Which train goes on which track is a policy decision. David Allan I wrote: My point was once a function in participating in more than one chain, the p= arallel tracks Niulehong refers to, then conceptually there is no reason wh= y a switch in the function woundn't allow a train to change tracks. As I've indicated I think it is a rare case, causes traceability issues etc= . and therefore is actually undesirable but I'd rather not be prescriptive= on whether this is possible or not, or HOW it MUST be done....Conceptually= I think what you refer to as bypass is the far more likely dynamic chain b= ehavior we would expect... Dave -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, November 14, 2013 4:49 AM To: David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter Hi Dave, I am not sure I am catching your point. There is no doubt that a service fu= nction may appear in more than one chain; it must as otherwise you would be= spinning up service function instances that could only ever be used by tra= ffic flowing through a single service chain. Simple example is a chain a-b-= c; I see no reason why you could not also build a chain d-b-e where b is th= e same service function instance in both chains. Branching seems to me to b= e independent of how many service function instances you have for a given s= ervice function. On 11/13/13 10:45 AM, "David Allan I" wrote: >HI Hongyu: > >I think we will have scenarios where a service function appears in more >than one chain, as would be the case, for example, if some flows could >dynamically bypass DPI but still needed to transit a common set of >stateful service functions... > >Once you postulate a service function instance appearing in more than >one chain, it seems artificially restrictive not to permit such a >function to also implement branching, all the control structures would >already be there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is >a way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets= in >a chain. Branching should be performed by chain forwarding nodes, >possibly under control of a control node. The reason for this is in NFV >world, service functions may come from a third party, while chain is >provided by the infrastructure of the network. There must be a cushion >avoiding a service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user'= s >packet, as well as some info like metadata in a SFC header. As >classification is out of scope of SFC, we don't have to provide too >much details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not >the exclusive mechanism. Branching is a mechanism by which flow subsets >are exposed and mapped to a set of subchains such that it can be >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is >defined/set even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative >domain for some of the very reasons you point out. We need to keep >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism >>(recursive because a user-land application will ride with a specific >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this >>multi-domain issue - if I set a policy as a user, chances are I will >>be crossing several domain boundaries. Are we expecting the service >>headers to define the service chaining for the duration of the entire >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty >>relevant to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong >>> mapping between Policy and the inserted Service Header(s), we >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per >>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>> Of Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to >>> redefine it - it's been around for all the time middle boxes have >>> been or for that matter the L2/L3 devices. All we are talking about >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a >>> > chain is different than I originally inferred. If the chain is a >>> > tree with other "branching" points in it, then that limits the >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation >>> > could define bad service chains, is it the intent of SFC to only >>> > look at the simpler packet-level classification cases, or is it >>> > the intent to consider the case where a branching point is viewed >>> > as a re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D >>> >>reclassification, agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be >>> >> in a form of logic on a service function. Some service functions, >>> >> especially L7 based, can use value in a Database to determine >>> >> what is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after >>> >> > been processed by a certain service function, decision of which >>> >> > branches to go is made based on the result of service >>> >> > function's process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The >>> >> > details around how to convey the selection of the >>> >> > subtree/subgraph are still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question >>> >> > > about service header encapsulation, is it intended that a >>> >> > > chain that is re-classified will get a new chain ID which >>> >> > > fully describes a chain that is a superset of the original >>> >> > > chain ID, prior to DPI-based re-classification? (assuming >>> >> > > the goal is "a single chain ID that is commonly understood >>> >> > > along the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>> >> > > l >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>> >> > > every flow then be initially classified as ID 1, but >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of >>> >> > >>> service that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is >>> >> > >>> limited due to limitations in classification, that would be >>> >> > >>> and important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>> >> > >>> fork points of the service paths seem like >>> >> > >>> re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive >>> >> > >>> of DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general, >>> >> > >> as described in the arch draft, the collection of services >>> >> > >> form a graph, segments of which are service paths. Yes, >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any >>> >> > >> node along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is >>> >> > >>>> that such classification aids in traffic selection and >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except >>> >> > >>>> that the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network >>> >> > >>>> elements but the service functions as well. Some of this >>> >> > >>>> is described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network >>> >> > >>>>> or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some >>> >> > >>>>> of) the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies >>> >> > >>>>> packets based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID, >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service >>> >> > >>>>> function identifier lookup does not seem to be a >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach >>> >> > >>>>>> for every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction >>> >> > >>>>>> of the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC >>> >> > >>>>>> header or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the >>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>> >> > >>>>>> imply immutability, but rather to specify the packet >>> >> > >>>>>> that is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and >>> >> > >>>>>> applications, have all undergone significant change in >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered >>> >> > >>>>>> combination of a number of service functions that are >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service >>> >> > >>>>>> functions physically inserted on the data forwarding >>> >> > >>>>>> path between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required >>> >> > >>>>>> service functions and the order in which they are to be >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service >>> >> > >>>>>> function may be available on more than one node within a >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and >>> >> > >>>>>> the network nodes on which they are provided, thereby >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function >>> >> > >>>>>> chaining that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and >>> >> > >>>>>> service path information to nodes that implement service >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a >>> >> > >>>>>> description of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All >>> >> > >>>>>> protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement >>> >> > >>>>>> with all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s) >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter >>> >> > >>>>>> modifications for management and configuration of SFC >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Nov 14 07:40:49 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D477711E80F2 for ; Thu, 14 Nov 2013 07:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1l6iE5zY4aZ for ; Thu, 14 Nov 2013 07:40:45 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id 517C021F96CA for ; Thu, 14 Nov 2013 07:40:45 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 07:40:39 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , David Allan I , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oBTPtlYMFwdkW7YwvFgDvnV5ojd/8AgABdGwCAALQWgIAA0K0AgAAE9AD//3rfEIAAiWMA//97ebA= Date: Thu, 14 Nov 2013 15:40:38 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:40:49 -0000 Jim, I think that could be an implementation decision. One implementation appr= oach is that the SFC IP-layer transport tunnels are known at the forwarding= layer (like the way IP-in-IP and GRE tunnels are frequently supported -- a= s an IP interface). Another possible approach is to handle the SFC IP-lay= er transport tunnels at a level above the forwarding layer (like the way GT= P-U tunnels are frequently supported -- they are not represented as distinc= t IP interfaces). Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, November 14, 2013 10:30 AM To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter Hi Ron, I would not say that b modifies the transport header but rather b informs t= he forwarding component of it's intent so that it may insert the appropriat= e transport header to meet b's requirement. On 11/14/13 10:24 AM, "Ron Parker" wrote: >Hi, Jim. > >I agree that forwarding is affected indirectly. Whether function b >forwards to function c or function d is accomplished by b correctly=20 >adding (modifying) the transport header so that d is addressed or c is >addressed. In the most general case of utilizing an IP-based transport >encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is >not made at this level. The transport location (IP address) for c and d >may or may not share the same next-hop based on the newtwork topology=20 >(i.e., c and/or d may or may not be on the same subnet as b, may or may=20 >not be reached via the same next hop router). > > Ron > > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >Jim Guichard (jguichar) >Sent: Thursday, November 14, 2013 10:14 AM >To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >I think it is misleading to say that a service function does not impact=20 >packet forwarding. If branching occurs then the service function does=20 >impact packet forwarding, whether directly or indirectly, as otherwise=20 >packets would not take the new path as a result of the branch. For=20 >example, if the chain is a-b-c and b decides that for certain flows the=20 >traffic should go to d rather than c then it *must* force the=20 >forwarding component to direct traffic to the new next-hop. While the=20 >service function may not modify forwarding in terms of updating=20 >forwarding tables and so forth, it has to inform the forwarding=20 >component of its intent somehow. Also, I think what you describe Dave=20 >is a bypass operation rather than a branch? > >On 11/14/13 9:56 AM, "David Allan I" wrote: > >>I think it is going to be a rare event, as what is more likely is the=20 >>front end of the chain is dynamically modified so subsequent packets=20 >>in a flow skip certain functions. Hence a graph more often than not is=20 >>logically P2P. Facilitates testing amongst other benefits. >> >>As such I'd not want to be prescriptive as to how and where it is=20 >>done.... >> >>Dave >> >>-----Original Message----- >>From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>Sent: Wednesday, November 13, 2013 6:30 PM >>To: David Allan I; nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>Proposed SFC charter >> >>Hi Dave, >> >>Your inferred restriction may be not always true. In general, service=20 >>functions should be able to compose a chain arbitrarily. Particularly=20 >>for branching, as I suggested in previous email, service function=20 >>shall not directly impact packet forwarding. This precludes the=20 >>restriction you mentioned. Forwarding plane can decide whether a=20 >>branching action should be taken by reclassification or not per service c= hain. >> >>Does this make sense? >> >>Hongyu >> >>-----Original Message----- >>From: David Allan I [mailto:david.i.allan@ericsson.com] >>Sent: Wednesday, November 13, 2013 11:45 PM >>To: Hongyu Li (Julio); nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>Proposed SFC charter >> >>HI Hongyu: >> >>I think we will have scenarios where a service function appears in=20 >>more than one chain, as would be the case, for example, if some flows=20 >>could dynamically bypass DPI but still needed to transit a common set=20 >>of stateful service functions... >> >>Once you postulate a service function instance appearing in more than=20 >>one chain, it seems artificially restrictive not to permit such a=20 >>function to also implement branching, all the control structures would=20 >>already be there. >> >>Rgds >>Dave >> >>-----Original Message----- >>From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>Sent: Wednesday, November 13, 2013 2:12 AM >>To: David Allan I; nsc@ietf.org >>Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>Proposed SFC charter >> >>May I suggest summary of my views here: >> >>1. Branch is a sort of use case or scenario, while reclassification is=20 >>a way to solve the problem. >>2. Service Functions should be decoupled with the chain itself. >> Meaning, a SF shall not *directly* impact the forwarding of packets=20 >>in a chain. Branching should be performed by chain forwarding nodes,=20 >>possibly under control of a control node. The reason for this is in=20 >>NFV world, service functions may come from a third party, while chain=20 >>is provided by the infrastructure of the network. There must be a=20 >>cushion avoiding a service function operating infrastructure directly. >>3. (Re)classification is based on info in a packet. >> This is very general. Such info could be L2~L7 derived from a user's=20 >>packet, as well as some info like metadata in a SFC header. As=20 >>classification is out of scope of SFC, we don't have to provide too=20 >>much details of how to do classification. >>4. Chain segments stitching is relatively a easy way for branching. >>Compared with chains and subchains, which may require a more complex=20 >>header and forwarding capabilities. >>My two cents. >>Hongyu >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>David Allan I >>Sent: Wednesday, November 13, 2013 3:04 AM >>To: nsc@ietf.org >>Subject: [nsc] FW: re classification & branching, was: Current=20 >>Proposed SFC charter >> >>Hi: >>(resend with recipient list cleaned up) >> >>I agree we are discussing multiple concepts, classification and=20 >>flow-subsetting. Perhaps more ;-) >> >>Defining a flow subset can be a result of classification, but it is=20 >>not the exclusive mechanism. Branching is a mechanism by which flow=20 >>subsets are exposed and mapped to a set of subchains such that it can=20 >>be identified in the dataplane... >> >>That's the view from here >>Dave >> >>-----Original Message----- >>From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>David Lake (dlake) >>Sent: Tuesday, November 12, 2013 10:51 AM >>To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >>Parker; Linda Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: Re: [nsc] Current Proposed SFC charter >> >>Understood - maybe just a little localised warming of the sea then ? >>But I still think we need to consider where and how policy is=20 >>defined/set even for the single-domain instance. >> >>I don't think we can assume that any L1-3 device will be able to=20 >>determine much useful information from the data-plane. >> >>-----Original Message----- >>From: Jim Guichard (jguichar) >>Sent: 12 November 2013 10:44 >>To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >>Parker; Linda Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: Re: [nsc] Current Proposed SFC charter >> >>As discussed during the BOF our initial work is single administrative=20 >>domain for some of the very reasons you point out. We need to keep=20 >>focused without trying to boil the ocean right off the bat. >> >>On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >> >>>Exactly. But how can network-components "terminate" an application ???? >>> >>>I think we need a good understanding of a recursive policy mechanism=20 >>>(recursive because a user-land application will ride with a specific=20 >>>policy across potentially different sets of carrier policies). >>> >>>I hate to bring this up now, but we also need to think about this=20 >>>multi-domain issue - if I set a policy as a user, chances are I will=20 >>>be crossing several domain boundaries. Are we expecting the service=20 >>>headers to define the service chaining for the duration of the entire=20 >>>flow across all domains, or just across a single one ? >>> >>>In which case, do I have to re-set policy as I traverse domains and >>>where does that policy get set ? It would be much better to set policy >>>once based on L5-7 needs, and have that instantiated across the=20 >>>multiple domains. >>> >>>Again, this appears to be outside the scope of SFC, but pretty=20 >>>relevant to how it would operate in the real world. >>> >>>David >>> >>>-----Original Message----- >>>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>Sent: 12 November 2013 10:27 >>>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>>Dunbar; Hongyu Li (Julio) >>>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>Subject: RE: [nsc] Current Proposed SFC charter >>> >>>> In those circumstances, only the end applications themselves or a=20 >>>> reasonably broad-brushed classification (really traffic steering=20 >>>> based on what we can see at ingress) is going to be useful - is=20 >>>> THAT what we're aiming for here ? >>> >>>I would certainly hope not, but that has been my concern as well. >>>Application layer termination and re-classification seems a must? >>> >>>-- Kevin J. Ma >>> >>>> -----Original Message----- >>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>>> Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >>>> Policy may be outside of the scope of SFC, but without strong=20 >>>> mapping between Policy and the inserted Service Header(s), we=20 >>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>> >>>> For example, in a world where the network has "gone dark," (as per=20 >>>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>>> policy based on DPI of packets-in-flight ? >>>> >>>> In those circumstances, only the end applications themselves or a=20 >>>> reasonably broad-brushed classification (really traffic steering=20 >>>> based on what we can see at ingress) is going to be useful - is=20 >>>> THAT what we're aiming for here ? >>>> >>>> David >>>> >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>> Of Surendra Kumar (smkumar) >>>> Sent: 12 November 2013 09:26 >>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >>>> Ron, >>>> >>>> Classification of traffic is well understood and we do not have to=20 >>>> redefine it - it's been around for all the time middle boxes have=20 >>>> been or for that matter the L2/L3 devices. All we are talking about=20 >>>> is the applicability of the classification to branching in SFC. >>>> >>>> You are right, it is all about policy which is outside the scope of=20 >>>>SFC. >>>> >>>> Surendra. >>>> >>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>wrote: >>>> >>>> >I think the lack of definition of "reclassification" may be=20 >>>> >causing >>>>some >>>> >misunderstandings here. A branch would occur for some >>>>policy-driven >>>> >reason based on the behavior and conclusions of the service function, >>>> >itself. The graph would represent the fact that there is a branch >>>> >point, but the service function, itself, being aware that it is a=20 >>>> >branching point would contain the policy and logic to decide on which >>>> >branch to take. Specifying that policy and logic is out of scope, >>>>IMO. >>>> > >>>> > Ron >>>> > >>>> > >>>> >-----Original Message----- >>>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>> >Sent: Tuesday, November 12, 2013 10:49 AM >>>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>> >Sumandra Majee >>>> >Subject: RE: [nsc] Current Proposed SFC charter >>>> > >>>> >Hi Linda, >>>> > >>>> > Are you saying that a branching point is "never" a=20 >>>> > reclassification point, or are you saying that a branching point >>>>"does not have to be" >>>> > a reclassification point? >>>> > >>>> > I think this is an important distinction that needs to be >>>>clarified. >>>> > If branching is never reclassification, then the meaning of a=20 >>>> > chain is different than I originally inferred. If the chain is a=20 >>>> > tree with other "branching" points in it, then that limits the=20 >>>> > scope of the problem statement goals. >>>> > >>>> > While this could be a degenerate case, and any implementation=20 >>>> > could define bad service chains, is it the intent of SFC to only=20 >>>> > look at the simpler packet-level classification cases, or is it=20 >>>> > the intent to consider the case where a branching point is viewed=20 >>>> > as a re-classification point? >>>> > >>>> >thanx. >>>> > >>>> >-- Kevin J. Ma >>>> > >>>> >> -----Original Message----- >>>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>> >> Sumandra Majee >>>> >> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> >>>> >> Ron, >>>> >> >>>> >> First, want to make it clear that "branching" !=3D=20 >>>> >>reclassification, agree? >>>> >> >>>> >> Second, the representation of branching (or service graph) can=20 >>>> >> be in a form of logic on a service function. Some service=20 >>>> >> functions, especially L7 based, can use value in a Database to=20 >>>> >> determine what is the next service function. >>>> >> >>>> >> Linda >>>> >> >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>> >> > Behalf Of Ron Parker >>>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>>> >> > To: Hongyu Li (Julio); Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Hongyu, >>>> >> > >>>> >> > I agree completely that re-classification is not limited to DPI. >>>> >> > >>>> >> > And also, that an area for us to explore as a group is how to >>>> >>represent >>>> >> > the service graph. Do we want to represent it as a proper graph >>>> with >>>> >> > an adjacency list or other representational model? Or, do we >>>>want >>>> to >>>> >> > represent it as a set of linear segments and if so, how are the >>>> >> > segments connected into a graph? Other ideas? >>>> >> > >>>> >> > Ron >>>> >> > >>>> >> > >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>> >> > Behalf Of Hongyu Li (Julio) >>>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>>> >> > To: Ron Parker; Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Branching/forking is a very interesting topic of SFC. About=20 >>>> >> > the >>>> >> > re- classification point, probably we shall not limit it to DPI. >>>> >> > It is also possible that packets go to different branches=20 >>>> >> > after been processed by a certain service function, decision=20 >>>> >> > of which branches to go is made based on the result of service=20 >>>> >> > function's process, i.e. not just re- classification by DPI. >>>> >> > >>>> >> > Hongyu >>>> >> > >>>> >> > -----Original Message----- >>>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>> >> > Behalf Of Ron Parker >>>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>>> >> > To: Kevin J Ma >>>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>> >> > Sumandra Majee >>>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >> > Hi, Kevin >>>> >> > >>>> >> > You ask a great question about branching the graph. The=20 >>>> >> > details around how to convey the selection of the=20 >>>> >> > subtree/subgraph are still >>>> >>to be >>>> >> > defined. Is it one chain id for the whole graph? Does each >>>>branch >>>> >> > have its own chain id? Some combination? >>>> >> > >>>> >> > Ron >>>> >> > >>>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>> >> > >>>> >> > wrote: >>>> >> > >>>> >> > >> Yes, reclassification can change the service path and=20 >>>> >> > >> re-classification may happen at any node along a service path. >>>> >> > > >>>> >> > > Just to expand on that, going back to the original question=20 >>>> >> > > about service header encapsulation, is it intended that a=20 >>>> >> > > chain that is re-classified will get a new chain ID which=20 >>>> >> > > fully describes a chain that is a superset of the original=20 >>>> >> > > chain ID, prior to DPI-based re-classification? (assuming=20 >>>> >> > > the goal is "a single chain ID that is commonly understood=20 >>>> >> > > along the entire service >>>> chain" >>>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>> >> > > m >>>> >> > > l >>>> >> > > ) >>>> >> > > >>>> >> > > And the applicable subset of the permutative list of service=20 >>>> >> > > paths would be configured at each appropriate service node? >>>> >> > > e.g., ID 1: NAT + firewall + DPI >>>> >> > > ID 2: NAT + firewall + DPI + AV >>>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>>> >> > > ID 4: NAT + firewall + DPI + NAT >>>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>>> >> > > ID 6: NAT + firewall + DPI + LB >>>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>>> >> > > ID 8: NAT + firewall + DPI + CACHE >>>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>>> >> > > every flow then be initially classified as ID 1, but=20 >>>> >> > > eventually get re- >>>> >> > classified >>>> >> > > to ID 2-11, after the DPI phase? >>>> >> > > >>>> >> > > thanx. >>>> >> > > >>>> >> > > -- Kevin J. Ma >>>> >> > > >>>> >> > >> -----Original Message----- >>>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>> >> > >> nsc@ietf.org >>>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >> >>>> >> > >> >>>> >> > >> >>>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>> >> > >>> >>>> >>wrote: >>>> >> > >>> >>>> >> > >>> Hi Surendra, >>>> >> > >>> >>>> >> > >>> Classification may be out of scope, but the level of=20 >>>> >> > >>> service that >>>> >> > is >>>> >> > >>> applicable is dependent upon the level of classification=20 >>>> >> > >>> that can >>>> >> > be >>>> >> > >>> performed. An assumption of packet level encapsulation=20 >>>> >> > >>> has >>>> >> > >> implications >>>> >> > >>> on the level of classification being performed? If the=20 >>>> >> > >>> stated >>>> >> > goals >>>> >> > >> are >>>> >> > >>> for firewall and load balancer functionality, then the=20 >>>> >> > >>> application >>>> >> > >> level >>>> >> > >>> nature of those functions needs to be taken into account? >>>> >> > >>> If, on the other hand, the service function scope is=20 >>>> >> > >>> limited due to limitations in classification, that would=20 >>>> >> > >>> be and important piece of >>>> >> > information? >>>> >> > >>> >>>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases=20 >>>> >> > >>> the fork points of the service paths seem like=20 >>>> >> > >>> re-classification >>>> points? >>>> >> > >>> Is that the interpretation from the architecture perspective? >>>> >> > >>> Or is the service function chain classification exclusive=20 >>>> >> > >>> of DPI >>>> >> > functionality? >>>> >> > >> I have not fully read that draft yet. But in general,=20 >>>> >> > >> as described in the arch draft, the collection of services=20 >>>> >> > >> form a graph, segments of which are service paths. Yes,=20 >>>> >> > >> reclassification can >>>> >> > change >>>> >> > >> the service path and re-classification may happen at any=20 >>>> >> > >> node along >>>> >> > a service path. >>>> >> > >> >>>> >> > >> Surendra. >>>> >> > >>> >>>> >> > >>> thanx. >>>> >> > >>> >>>> >> > >>> -- Kevin J. Ma >>>> >> > >>> >>>> >> > >>>> -----Original Message----- >>>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas=20 >>>> >> > >>>> Narten; nsc@ietf.org >>>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>> >>>> >> > >>>> Kevin, >>>> >> > >>>> >>>> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >>>> >> > >>>> can be based >>>> >> > >> on >>>> >> > >>>> the packet or information not in the packet(environmental=20 >>>> >> > >>>> attributes >>>> >> > >> for >>>> >> > >>>> instance) or a combination thereof. What is important is=20 >>>> >> > >>>> that such classification aids in traffic selection and=20 >>>> >> > >>>> service path identification. >>>> >> > >>>> It is no different from a policy in this regard except=20 >>>> >> > >>>> that the policy now specifies the service path. >>>> >> > >>>> Further, classification is not limited to the network=20 >>>> >> > >>>> elements but the service functions as well. Some of this=20 >>>> >> > >>>> is described in the >>>> >> > >> architecture >>>> >> > >>>> drafts as well - >>>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>> >> > >>>> >>>> >> > >>>> Surendra. >>>> >> > >>>> >>>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>> >> > >>>>> >>>> >> > wrote: >>>> >> > >>>>> >>>> >> > >>>>> Hi Ron, >>>> >> > >>>>> >>>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >>>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>>> >> > >>>>> section >>>> >> > >>>>> 2 of the >>>> >> > problem >>>> >> > >>>>> statement: >>>> >> > >>>>> >>>> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >>>> >> > >>>>> occurs at >>>> >> > each >>>> >> > >>>>> service, independent from previously applied=20 >>>> >> > >>>>> service >>>> >> > >>>> functions. >>>> >> > >>>>> These unrelated classification events consume=20 >>>> >> > >>>>> resources >>>> >> > per >>>> >> > >>>>> service. More importantly, the classification >>>> >> > functionality >>>> >> > >>>>> often differs per service function and service=20 >>>> >> > >>>>> function >>>> >> > >> cannot >>>> >> > >>>>> leverage the results from other deployed network=20 >>>> >> > >>>>> or >>>> >> > service. >>>> >> > >>>>> >>>> >> > >>>>> as it relates to section 5.2 of the framework document: >>>> >> > >>>>> >>>> >> > >>>>> The SFC Classifier classifies packets based on (some >>>> >> > >>>>> of) the >>>> >> > >>>> contents >>>> >> > >>>>> of the packet header. Concretely, it classifies=20 >>>> >> > >>>>> packets based on >>>> >> > >>>> the >>>> >> > >>>>> possible combination of one or more header fields,=20 >>>> >> > >>>>> such as >>>> >> > source >>>> >> > >>>>> address, destination address, DS field, protocol ID,=20 >>>> >> > >>>>> source >>>> >> > port >>>> >> > >>>> and >>>> >> > >>>>> destination port numbers, and any other information. >>>> >> > >>>>> >>>> >> > >>>>> A packet-based classifier as described in the framework=20 >>>> >> > >>>>> document >>>> >> > >>>> would >>>> >> > >>>>> seem to be limited in what it can classify? The service=20 >>>> >> > >>>>> function identifier lookup does not seem to be a=20 >>>> >> > >>>>> significant optimization >>>> >> > >> over >>>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>>> >> > >>>>> missing >>>> >> > >> detail >>>> >> > >>>>> wrt how classification information is determined and >>>>reused? >>>> >> > >>>>> >>>> >> > >>>>> When thinking about higher level services, e.g., HTTP=20 >>>> >> > >>>>> and TLS >>>> >> > >>>> encrypted >>>> >> > >>>>> flows, a packet-based classifier seems inadequate? I=20 >>>> >> > >>>>> was also >>>> >> > >>>> wondering >>>> >> > >>>>> how independent HLS segment requests might be classified=20 >>>> >> > >>>>> and >>>> >> > >>>> associated? >>>> >> > >>>>> Were these types of use cases discussed in the BoF? >>>> >> > >>>>> >>>> >> > >>>>> thanx. >>>> >> > >>>>> >>>> >> > >>>>> -- Kevin J. Ma >>>> >> > >>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org=20 >>>> >> > >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Ron >>>> >> > >>>>>> Parker >>>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >>>> >> > >>>>>> existing ways >>>> >> > >>>> to >>>> >> > >>>>>> accomplish service chaining. But none of them provide >>>>a >>>> >> > >>>> sufficient >>>> >> > >>>>>> combination of interoperability, flexibility, and >>>>resiliency. >>>> >> > A >>>> >> > >>>> single >>>> >> > >>>>>> service chain encapsulation will go a long way to=20 >>>> >> > >>>>>> ensuring these >>>> >> > >>>> goals. >>>> >> > >>>>>> It may not be the absolutely most efficient approach=20 >>>> >> > >>>>>> for every >>>> >> > >>>> single >>>> >> > >>>>>> network topology and every single use case, but its=20 >>>> >> > >>>>>> ubiquitous >>>> >> > >> nature >>>> >> > >>>>>> should improve its adoption. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Ron, >>>> >> > >>>>>> >>>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>>> >> > >>>>>> However >>>> >> > >>>> this >>>> >> > >>>>>> could be augmented with classification result, again=20 >>>> >> > >>>>>> one more >>>> >> > >>>> example. >>>> >> > >>>>>> >>>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >>>> >> > >>>>>>>> follow >>>> >> > the >>>> >> > >>>> same >>>> >> > >>>>>> chain. >>>> >> > >>>>>> Correct. It is also not necessary that all transaction=20 >>>> >> > >>>>>> of the same >>>> >> > >>>> flow >>>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>>> >> > >>>>>> >>>> >> > >>>>>> Again the point here is that do we always need SFC=20 >>>> >> > >>>>>> header or >>>> >>Not. >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Ron Parker >>>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> The intention of service function chaining is to allow=20 >>>> >> > >>>>>> for operation >>>> >> > >>>> at >>>> >> > >>>>>> the fully qualified flow level, or even finer grained=20 >>>> >> > >>>>>> at the >>>> >> > >>>> transaction >>>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>>All >>>> >> > flows >>>> >> > >>>> from >>>> >> > >>>>>> the same source IP do not necessarily follow the same >>>>chain. >>>> >> > >> Source >>>> >> > >>>>>> IP, >>>> >> > >>>>>> therefore, does not identify the chain ID. Another >>>> >>intention >>>> >> > of >>>> >> > >>>>>> service function chaining is to operate over any=20 >>>> >> > >>>>>> network >>>> >> > topology >>>> >> > >> and >>>> >> > >>>>>> not >>>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>of >>>> >> > the >>>> >> > >>>>>> transport, it does not adequately identify the service=20 >>>> >> > >>>>>> chain, >>>> >> > >> either. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Ron, >>>> >> > >>>>>> >>>> >> > >>>>>> The service header is meant to carry the context which=20 >>>> >> > >>>>>> can >>>> >> > *also* >>>> >> > >>>>>> be derived (for example use source ip and vlan to=20 >>>> >> > >>>>>> identify chainID and >>>> >> > >>>>>> position) or encapsulated as part of another tunnel >>>>header. >>>> >> > >>>>>> So this could be optional IMHO. >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: Ron Parker >>>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Sumandra, >>>> >> > >>>>>> >>>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP=20 >>>> >> > >>>>>> to SF or from >>>> >> > >>>> SF >>>> >> > >>>>>> to >>>> >> > >>>>>> SF will look like: >>>> >> > >>>>>> >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | "transport" | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | service header | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | original IP header | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> | | original=20 >>>> >> > >>>>>> | IP payload >>>> >> > | >>>> >> > >>>>>> | | >>>> >> > >>>>>> +------------------------+ >>>> >> > >>>>>> >>>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >>>> >> > >>>>>> information to >>>> >> > >>>> allow >>>> >> > >>>>>> the packet to be propagated along the full length of=20 >>>> >> > >>>>>> the chain, and optionally, other metadata that enhances=20 >>>> >> > >>>>>> the operation of >>>> >> > one >>>> >> > >>>>>> or >>>> >> > >> more >>>> >> > >>>>>> service functions. >>>> >> > >>>>>> >>>> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >>>> >> > >>>>>> not limited >>>> >> > >>>> to: >>>> >> > >>>>>> >>>> >> > >>>>>> * Ethernet >>>> >> > >>>>>> * Ethernet + LLC2 >>>> >> > >>>>>> * Ethernet + MPLS >>>> >> > >>>>>> * Ethernet + IP + GRE >>>> >> > >>>>>> * Ethernet + IP +UDP >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >>>> >> > >>>>>> imply immutability, but rather to specify the packet=20 >>>> >> > >>>>>> that is >>>> >> > propagated >>>> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >>>> >> > >>>>>> encapsulation. >>>> >> > >>>>>> >>>> >> > >>>>>> Ron >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org=20 >>>> >> > >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Sumandra Majee >>>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>> >> > >>>>>> document >>>> >>will >>>> >> > >>>>>> describe the single service-level data plane=20 >>>> >> > >>>>>> encapsulation >>>> >> > >> format >>>> >> > >>>>>> for >>>> >> > >>>>>> conveying the service function chain and the service=20 >>>> >> > >>>>>> function >>>> >> > >>>> path, >>>> >> > >>>>>> and for communicating context information between=20 >>>> >> > >>>>>> nodes >>>> that >>>> >> > >>>>>> implement service functions. It is intended that the >>>> >> > >>>> encapsulation >>>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>>> >> > >>>>>> the service >>>> >> > >>>> that >>>> >> > >>>>>> is >>>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>>> >> > >>>>>> may be >>>> >> > used >>>> >> > >> on >>>> >> > >>>>>> a service function path realized at the network=20 >>>> >> > >>>>>> layer or at any other >>>> >> > >>>>>> layer, and the same encapsulation will apply for the >>>> >> > >> construction >>>> >> > >>>> of >>>> >> > >>>>>> service function paths regardless of the actual >>>>service. >>>> >> > >>>>>> >>>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >>>> >> > >>>>>> encapsulation, >>>> >> > a >>>> >> > >>>> new >>>> >> > >>>>>> encapsulation format >>>> >> > >>>>>> or an ability to select one encapsulation=20 >>>> >> > >>>>>> format that >>>> >> > >>>> fits >>>> >> > >>>>>> the >>>> >> > >>>>>> need for a given service chain? >>>> >> > >>>>>> The ability to select a specific=20 >>>> >> > >>>>>> encapsulation would be >>>> >> > >> a >>>> >> > >>>>>> management plane decision. >>>> >> > >>>>>> There are quite a few existing encapsulation=20 >>>> >> > >>>>>> methods that >>>> >> > >>>> can >>>> >> > >>>>>> possibly be reused to provide >>>> >> > >>>>>> context information between service nodes. I >>>>have >>>> >> > seen >>>> >> > >>>>>> mention >>>> >> > >>>>>> of GRE, for HTTP based >>>> >> > >>>>>> applications contexts are transferred via >>>>headers. >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> -----Original Message----- >>>> >> > >>>>>> From: nsc-bounces@ietf.org=20 >>>> >> > >>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>> >> > >> Of >>>> >> > >>>>>> Thomas Narten >>>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>> >> > >>>>>> To: nsc@ietf.org >>>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>>> >> > >>>>>> >>>> >> > >>>>>> Hi. >>>> >> > >>>>>> >>>> >> > >>>>>> Current charter can be found at >>>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>>> >> > >>>>>> ietf-sfc/. >>>> >> > >>>>>> >>>> >> > >>>>>> It contains the revised management text as well as=20 >>>> >> > >>>>>> updated >>>> >> > >>>> milestones. >>>> >> > >>>>>> >>>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>>> >> > >>>>>> remaining >>>> >> > >>>> issues, >>>> >> > >>>>>> please speak up! >>>> >> > >>>>>> >>>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>>> >> > >>>>>> >>>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>>> >> > >>>>>> applications, have all undergone significant change in=20 >>>> >> > >>>>>> recent years with the introduction >>>> >> > >> of >>>> >> > >>>>>> virtualization, network overlays, and orchestration. >>>> >> > >>>>>> Service >>>> >> > >> delivery >>>> >> > >>>> is >>>> >> > >>>>>> currently both a technical and organizational challenge=20 >>>> >> > >>>>>> that >>>> >> > >> involves >>>> >> > >>>>>> significant modification to the network configuration. >>>> >> > >>>>>> Services are typically implemented by the ordered=20 >>>> >> > >>>>>> combination of a number of service functions that are=20 >>>> >> > >>>>>> deployed at different points within >>>> >> > >> the >>>> >> > >>>>>> network. Today, a common deployment model has service=20 >>>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>>> >> > >>>>>> path between communicating peers. >>>> >> > >>>> Going >>>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>>> >> > >>>>>> different model, >>>> >> > >>>> where >>>> >> > >>>>>> service functions are not required to reside on the=20 >>>> >> > >>>>>> default data >>>> >> > >> path >>>> >> > >>>>>> and >>>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>>> >> > >>>>>> they are >>>> >> > >>>> deployed. >>>> >> > >>>>>> >>>> >> > >>>>>> For a given service, the abstracted view of the=20 >>>> >> > >>>>>> required service functions and the order in which they=20 >>>> >> > >>>>>> are to be applied is >>>> >> > called >>>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>>> >> > >>>>>> function may be available on more than one node within=20 >>>> >> > >>>>>> a network, a Service Function Chain is instantiated >>>> >> > >>>> via >>>> >> > >>>>>> the selection of specific service function instances=20 >>>> >> > >>>>>> and the network nodes on which they are provided,=20 >>>> >> > >>>>>> thereby forming a service topology: >>>> >> > >>>>>> this is called a Service Function Path. The service=20 >>>> >> > >>>>>> functions >>>> >> > may >>>> >> > >>>>>> be applied at a specific layer within the network=20 >>>> >> > >>>>>> protocol stack >>>> >> > >>>> (network >>>> >> > >>>>>> layer, application layer, etc.). >>>> >> > >>>>>> >>>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>>> >> > >>>>>> develop new approaches to service delivery and deployment. >>>> >> > >>>>>> It will produce a framework for service function=20 >>>> >> > >>>>>> chaining that includes the necessary protocols >>>> >> > >>>> or >>>> >> > >>>>>> protocol extensions to convey the service path and=20 >>>> >> > >>>>>> service path information to nodes that implement=20 >>>> >> > >>>>>> service functions, as well >>>> >> > as >>>> >> > >>>>>> mechanisms for steering traffic through service functions. >>>> >> > >>>>>> The >>>> >> > >>>> working >>>> >> > >>>>>> group will also examine what information needs to be=20 >>>> >> > >>>>>> gathered from >>>> >> > >>>> the >>>> >> > >>>>>> network and service functions in support of service=20 >>>> >> > >>>>>> function >>>> >> > >> chaining >>>> >> > >>>>>> and >>>> >> > >>>>>> how that information may be made available to nodes=20 >>>> >> > >>>>>> that implement >>>> >> > >>>> the >>>> >> > >>>>>> service functions. >>>> >> > >>>>>> >>>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>>> following: >>>> >> > >>>>>> >>>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>>> >> > >>>>>> summary of >>>> >> > the >>>> >> > >>>>>> problem space to be addressed by the WG including=20 >>>> >> > >>>>>> example >>>> >> > high- >>>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>>> >> > >> nomenclature >>>> >> > >>>>>> and definitions for service function chaining. >>>> >> > >>>>>> >>>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>>> >> > >>>>>> description of >>>> >>the >>>> >> > >>>>>> architectural building blocks and their=20 >>>> >> > >>>>>> relationships >>>> >> > including >>>> >> > >>>>>> interconnection, placement of capabilities, management, >>>> >> > >>>>>> diagnostics, design analysis, and security models,=20 >>>> >> > >>>>>> as well >>>> >>as >>>> >> > >>>>>> requirements on the protocol mechanisms. >>>> >> > >>>>>> >>>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>> >> > >>>>>> document >>>> >> > will >>>> >> > >>>>>> describe the single service-level data plane=20 >>>> >> > >>>>>> encapsulation >>>> >> > >> format >>>> >> > >>>>>> for >>>> >> > >>>>>> conveying the service function chain and the service=20 >>>> >> > >>>>>> function >>>> >> > >>>> path, >>>> >> > >>>>>> and for communicating context information between=20 >>>> >> > >>>>>> nodes >>>> that >>>> >> > >>>>>> implement service functions. It is intended that the >>>> >> > >>>> encapsulation >>>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>>> >> > >>>>>> the service >>>> >> > >>>> that >>>> >> > >>>>>> is >>>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>>> >> > >>>>>> may be >>>> >> > used >>>> >> > >> on >>>> >> > >>>>>> a service function path realized at the network=20 >>>> >> > >>>>>> layer or at any other >>>> >> > >>>>>> layer, and the same encapsulation will apply for the >>>> >> > >> construction >>>> >> > >>>> of >>>> >> > >>>>>> service function paths regardless of the actual >>>>service. >>>> >> > >>>>>> >>>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>> >> > developed to >>>> >> > >>>>>> describe requirements and protocols necessary to=20 >>>> >> > >>>>>> convey >>>> >> > >>>> information >>>> >> > >>>>>> to service function implementation points. Where=20 >>>> >> > >>>>>> possible, >>>> >> > >>>> existing >>>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>>> >> > >>>>>> protocol >>>> >> > >> extensions >>>> >> > >>>>>> work should be carried out in the working groups=20 >>>> >> > >>>>>> responsible for >>>> >> > >>>> the >>>> >> > >>>>>> protocols being modified in coordination with this=20 >>>> >> > >>>>>> working >>>> >> > >> group, >>>> >> > >>>>>> but >>>> >> > >>>>>> may be done in this working group after agreement=20 >>>> >> > >>>>>> with all >>>> >> > the >>>> >> > >>>>>> relevant WG chairs and responsible ADs. >>>> >> > >>>>>> >>>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>>> >> > >>>>>> configuration of >>>> >> > >> service >>>> >> > >>>>>> functions in support of SFC components will=20 >>>> >> > >>>>>> certainly be >>>> >> > needed, >>>> >> > >>>>>> but first needs to be better understood and scoped. >>>> >> > >>>>>> >>>> >> > >>>>>> Proposed Milestones >>>> >> > >>>>>> >>>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>> >> > >>>>>> defining the >>>> >> > >>>> problem >>>> >> > >>>>>> statement and core use cases for Service Function=20 >>>> >> > >>>>>> Chaining >>>> >> > >>>>>> >>>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>> >> > >>>>>> modifications for management and configuration of SFC=20 >>>> >> > >>>>>> components >>>> >> > >>>>>> >>>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>> >> > >>>>>> the >>>> >> > >>>> architecture >>>> >> > >>>>>> for SFC >>>> >> > >>>>>> >>>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>> >> > >>>>>> service function chaining encapsulation protocol >>>> >> > >>>>>> >>>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>> >> > >>>>>> specifying the >>>> >> > >>>> generic >>>> >> > >>>>>> service function chaining header encapsulation >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> >>>> >> > >>>>>> Thomas >>>> >> > >>>>>> >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>>> _______________________________________________ >>>> >> > >>>>>> nsc mailing list >>>> >> > >>>>>> nsc@ietf.org >>>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > >>>>> _______________________________________________ >>>> >> > >>>>> nsc mailing list >>>> >> > >>>>> nsc@ietf.org >>>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >> > > >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >> > _______________________________________________ >>>> >> > nsc mailing list >>>> >> > nsc@ietf.org >>>> >> > https://www.ietf.org/mailman/listinfo/nsc >>>> >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>_______________________________________________ >>>nsc mailing list >>>nsc@ietf.org >>>https://www.ietf.org/mailman/listinfo/nsc >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Nov 14 07:46:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297EB11E814F for ; Thu, 14 Nov 2013 07:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEzzQkaqfNAY for ; Thu, 14 Nov 2013 07:46:25 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EA59211E8141 for ; Thu, 14 Nov 2013 07:46:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47145; q=dns/txt; s=iport; t=1384443985; x=1385653585; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FVJ5wTdW1aJAD8N9CXhWSaYzR4zdCYUr1mm9GumsCDg=; b=LExpbdYU/eL4x1VH2ndaxGx0wsVKyIESsymw0ItRtDddTPOFYpMTQxva mu5tmJJG53+TiAYfusTXK+PtVZsplIGxnf6aWPjTL2zZxMrBf96k02tec 5jvYx6z94nwvxLB+G7MnUcpYRhU/qQbbNBYKvo9IDLizs5aGYcCtSl2fk Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkSANDvhFKtJXG9/2dsb2JhbABQCoFxAgGBEzi/dIEfFnSCJQEBAQMBAQEBFwEfKwIHBAcFBwQCAQgRAQMBAQEVCQkHJwsUAwUBCAIECgQFCYdyBg3AM44WBgQBBQaBAAgrBwIEBIMWgREDlC6DYpIMgyiBaAEIFw X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284798646" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2013 15:46:23 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAEFkMhY029075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 15:46:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 09:46:22 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAALQWgIAA0K0A//+xHgCAAFaFAP//rb6AgABW5QD//50FlQ== Date: Thu, 14 Nov 2013 15:46:21 +0000 Message-ID: <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 15:46:30 -0000 Sure but architecturally the service function and forwarding components are= separate entities. Whether you choose to combine them in implementation is= your own choice. Sent from my iPhone > On Nov 14, 2013, at 10:40 AM, "Ron Parker" wrote: >=20 > Jim, >=20 > I think that could be an implementation decision. One implementation ap= proach is that the SFC IP-layer transport tunnels are known at the forwardi= ng layer (like the way IP-in-IP and GRE tunnels are frequently supported --= as an IP interface). Another possible approach is to handle the SFC IP-l= ayer transport tunnels at a level above the forwarding layer (like the way = GTP-U tunnels are frequently supported -- they are not represented as disti= nct IP interfaces). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 > Sent: Thursday, November 14, 2013 10:30 AM > To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org > Subject: Re: [nsc] FW: re classification & branching, was: Current Propos= ed SFC charter >=20 > Hi Ron, >=20 > I would not say that b modifies the transport header but rather b informs= the forwarding component of it's intent so that it may insert the appropri= ate transport header to meet b's requirement. >=20 >> On 11/14/13 10:24 AM, "Ron Parker" wro= te: >>=20 >> Hi, Jim. >>=20 >> I agree that forwarding is affected indirectly. Whether function b >> forwards to function c or function d is accomplished by b correctly=20 >> adding (modifying) the transport header so that d is addressed or c is >> addressed. In the most general case of utilizing an IP-based transport >> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is >> not made at this level. The transport location (IP address) for c and = d >> may or may not share the same next-hop based on the newtwork topology=20 >> (i.e., c and/or d may or may not be on the same subnet as b, may or may= =20 >> not be reached via the same next hop router). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Jim Guichard (jguichar) >> Sent: Thursday, November 14, 2013 10:14 AM >> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >> Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >> Proposed SFC charter >>=20 >> I think it is misleading to say that a service function does not impact= =20 >> packet forwarding. If branching occurs then the service function does=20 >> impact packet forwarding, whether directly or indirectly, as otherwise=20 >> packets would not take the new path as a result of the branch. For=20 >> example, if the chain is a-b-c and b decides that for certain flows the= =20 >> traffic should go to d rather than c then it *must* force the=20 >> forwarding component to direct traffic to the new next-hop. While the=20 >> service function may not modify forwarding in terms of updating=20 >> forwarding tables and so forth, it has to inform the forwarding=20 >> component of its intent somehow. Also, I think what you describe Dave=20 >> is a bypass operation rather than a branch? >>=20 >>> On 11/14/13 9:56 AM, "David Allan I" wrote= : >>>=20 >>> I think it is going to be a rare event, as what is more likely is the=20 >>> front end of the chain is dynamically modified so subsequent packets=20 >>> in a flow skip certain functions. Hence a graph more often than not is= =20 >>> logically P2P. Facilitates testing amongst other benefits. >>>=20 >>> As such I'd not want to be prescriptive as to how and where it is=20 >>> done.... >>>=20 >>> Dave >>>=20 >>> -----Original Message----- >>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>> Sent: Wednesday, November 13, 2013 6:30 PM >>> To: David Allan I; nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> Hi Dave, >>>=20 >>> Your inferred restriction may be not always true. In general, service=20 >>> functions should be able to compose a chain arbitrarily. Particularly=20 >>> for branching, as I suggested in previous email, service function=20 >>> shall not directly impact packet forwarding. This precludes the=20 >>> restriction you mentioned. Forwarding plane can decide whether a=20 >>> branching action should be taken by reclassification or not per service= chain. >>>=20 >>> Does this make sense? >>>=20 >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>> Sent: Wednesday, November 13, 2013 11:45 PM >>> To: Hongyu Li (Julio); nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> HI Hongyu: >>>=20 >>> I think we will have scenarios where a service function appears in=20 >>> more than one chain, as would be the case, for example, if some flows=20 >>> could dynamically bypass DPI but still needed to transit a common set=20 >>> of stateful service functions... >>>=20 >>> Once you postulate a service function instance appearing in more than=20 >>> one chain, it seems artificially restrictive not to permit such a=20 >>> function to also implement branching, all the control structures would= =20 >>> already be there. >>>=20 >>> Rgds >>> Dave >>>=20 >>> -----Original Message----- >>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>> Sent: Wednesday, November 13, 2013 2:12 AM >>> To: David Allan I; nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> May I suggest summary of my views here: >>>=20 >>> 1. Branch is a sort of use case or scenario, while reclassification is= =20 >>> a way to solve the problem. >>> 2. Service Functions should be decoupled with the chain itself. >>> Meaning, a SF shall not *directly* impact the forwarding of packets= =20 >>> in a chain. Branching should be performed by chain forwarding nodes,=20 >>> possibly under control of a control node. The reason for this is in=20 >>> NFV world, service functions may come from a third party, while chain=20 >>> is provided by the infrastructure of the network. There must be a=20 >>> cushion avoiding a service function operating infrastructure directly. >>> 3. (Re)classification is based on info in a packet. >>> This is very general. Such info could be L2~L7 derived from a user's= =20 >>> packet, as well as some info like metadata in a SFC header. As=20 >>> classification is out of scope of SFC, we don't have to provide too=20 >>> much details of how to do classification. >>> 4. Chain segments stitching is relatively a easy way for branching. >>> Compared with chains and subchains, which may require a more complex=20 >>> header and forwarding capabilities. >>> My two cents. >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>> David Allan I >>> Sent: Wednesday, November 13, 2013 3:04 AM >>> To: nsc@ietf.org >>> Subject: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> Hi: >>> (resend with recipient list cleaned up) >>>=20 >>> I agree we are discussing multiple concepts, classification and=20 >>> flow-subsetting. Perhaps more ;-) >>>=20 >>> Defining a flow subset can be a result of classification, but it is=20 >>> not the exclusive mechanism. Branching is a mechanism by which flow=20 >>> subsets are exposed and mapped to a set of subchains such that it can=20 >>> be identified in the dataplane... >>>=20 >>> That's the view from here >>> Dave >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >>> David Lake (dlake) >>> Sent: Tuesday, November 12, 2013 10:51 AM >>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron= =20 >>> Parker; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>> Understood - maybe just a little localised warming of the sea then ? >>> But I still think we need to consider where and how policy is=20 >>> defined/set even for the single-domain instance. >>>=20 >>> I don't think we can assume that any L1-3 device will be able to=20 >>> determine much useful information from the data-plane. >>>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) >>> Sent: 12 November 2013 10:44 >>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >>> Parker; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>> As discussed during the BOF our initial work is single administrative=20 >>> domain for some of the very reasons you point out. We need to keep=20 >>> focused without trying to boil the ocean right off the bat. >>>=20 >>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>=20 >>>> Exactly. But how can network-components "terminate" an application ??= ?? >>>>=20 >>>> I think we need a good understanding of a recursive policy mechanism=20 >>>> (recursive because a user-land application will ride with a specific=20 >>>> policy across potentially different sets of carrier policies). >>>>=20 >>>> I hate to bring this up now, but we also need to think about this=20 >>>> multi-domain issue - if I set a policy as a user, chances are I will=20 >>>> be crossing several domain boundaries. Are we expecting the service=20 >>>> headers to define the service chaining for the duration of the entire= =20 >>>> flow across all domains, or just across a single one ? >>>>=20 >>>> In which case, do I have to re-set policy as I traverse domains and >>>> where does that policy get set ? It would be much better to set poli= cy >>>> once based on L5-7 needs, and have that instantiated across the=20 >>>> multiple domains. >>>>=20 >>>> Again, this appears to be outside the scope of SFC, but pretty=20 >>>> relevant to how it would operate in the real world. >>>>=20 >>>> David >>>>=20 >>>> -----Original Message----- >>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>> Sent: 12 November 2013 10:27 >>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>>> Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>=20 >>>>> In those circumstances, only the end applications themselves or a=20 >>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>> THAT what we're aiming for here ? >>>>=20 >>>> I would certainly hope not, but that has been my concern as well. >>>> Application layer termination and re-classification seems a must? >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>>>> Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>=20 >>>>> Policy may be outside of the scope of SFC, but without strong=20 >>>>> mapping between Policy and the inserted Service Header(s), we=20 >>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>=20 >>>>> For example, in a world where the network has "gone dark," (as per=20 >>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>>>> policy based on DPI of packets-in-flight ? >>>>>=20 >>>>> In those circumstances, only the end applications themselves or a=20 >>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>> THAT what we're aiming for here ? >>>>>=20 >>>>> David >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>>> Of Surendra Kumar (smkumar) >>>>> Sent: 12 November 2013 09:26 >>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>=20 >>>>> Ron, >>>>>=20 >>>>> Classification of traffic is well understood and we do not have to=20 >>>>> redefine it - it's been around for all the time middle boxes have=20 >>>>> been or for that matter the L2/L3 devices. All we are talking about=20 >>>>> is the applicability of the classification to branching in SFC. >>>>>=20 >>>>> You are right, it is all about policy which is outside the scope of=20 >>>>> SFC. >>>>>=20 >>>>> Surendra. >>>>>=20 >>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>> wrote: >>>>>=20 >>>>>> I think the lack of definition of "reclassification" may be=20 >>>>>> causing >>>>> some >>>>>> misunderstandings here. A branch would occur for some >>>>> policy-driven >>>>>> reason based on the behavior and conclusions of the service function= , >>>>>> itself. The graph would represent the fact that there is a branch >>>>>> point, but the service function, itself, being aware that it is a=20 >>>>>> branching point would contain the policy and logic to decide on whic= h >>>>>> branch to take. Specifying that policy and logic is out of scope, >>>>> IMO. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>> Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Hi Linda, >>>>>>=20 >>>>>> Are you saying that a branching point is "never" a=20 >>>>>> reclassification point, or are you saying that a branching point >>>>> "does not have to be" >>>>>> a reclassification point? >>>>>>=20 >>>>>> I think this is an important distinction that needs to be >>>>> clarified. >>>>>> If branching is never reclassification, then the meaning of a=20 >>>>>> chain is different than I originally inferred. If the chain is a=20 >>>>>> tree with other "branching" points in it, then that limits the=20 >>>>>> scope of the problem statement goals. >>>>>>=20 >>>>>> While this could be a degenerate case, and any implementation=20 >>>>>> could define bad service chains, is it the intent of SFC to only=20 >>>>>> look at the simpler packet-level classification cases, or is it=20 >>>>>> the intent to consider the case where a branching point is viewed=20 >>>>>> as a re-classification point? >>>>>>=20 >>>>>> thanx. >>>>>>=20 >>>>>> -- Kevin J. Ma >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>> Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Ron, >>>>>>>=20 >>>>>>> First, want to make it clear that "branching" !=3D=20 >>>>>>> reclassification, agree? >>>>>>>=20 >>>>>>> Second, the representation of branching (or service graph) can=20 >>>>>>> be in a form of logic on a service function. Some service=20 >>>>>>> functions, especially L7 based, can use value in a Database to=20 >>>>>>> determine what is the next service function. >>>>>>>=20 >>>>>>> Linda >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Ron Parker >>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Hongyu, >>>>>>>>=20 >>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>=20 >>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>> represent >>>>>>>> the service graph. Do we want to represent it as a proper graph >>>>> with >>>>>>>> an adjacency list or other representational model? Or, do we >>>>> want >>>>> to >>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>=20 >>>>>>>> Ron >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Branching/forking is a very interesting topic of SFC. About=20 >>>>>>>> the >>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>> It is also possible that packets go to different branches=20 >>>>>>>> after been processed by a certain service function, decision=20 >>>>>>>> of which branches to go is made based on the result of service=20 >>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>=20 >>>>>>>> Hongyu >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Ron Parker >>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>> To: Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Hi, Kevin >>>>>>>>=20 >>>>>>>> You ask a great question about branching the graph. The=20 >>>>>>>> details around how to convey the selection of the=20 >>>>>>>> subtree/subgraph are still >>>>>>> to be >>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>> branch >>>>>>>> have its own chain id? Some combination? >>>>>>>>=20 >>>>>>>> Ron >>>>>>>>=20 >>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>> Yes, reclassification can change the service path and=20 >>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>=20 >>>>>>>>> Just to expand on that, going back to the original question=20 >>>>>>>>> about service header encapsulation, is it intended that a=20 >>>>>>>>> chain that is re-classified will get a new chain ID which=20 >>>>>>>>> fully describes a chain that is a superset of the original=20 >>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming=20 >>>>>>>>> the goal is "a single chain ID that is commonly understood=20 >>>>>>>>> along the entire service >>>>> chain" >>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>> m >>>>>>>>> l >>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>> And the applicable subset of the permutative list of service=20 >>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>>>>>>>> every flow then be initially classified as ID 1, but=20 >>>>>>>>> eventually get re- >>>>>>>> classified >>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>=20 >>>>>>>>> thanx. >>>>>>>>>=20 >>>>>>>>> -- Kevin J. Ma >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>>>>>>>> nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>> >>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Surendra, >>>>>>>>>>>=20 >>>>>>>>>>> Classification may be out of scope, but the level of=20 >>>>>>>>>>> service that >>>>>>>> is >>>>>>>>>>> applicable is dependent upon the level of classification=20 >>>>>>>>>>> that can >>>>>>>> be >>>>>>>>>>> performed. An assumption of packet level encapsulation=20 >>>>>>>>>>> has >>>>>>>>>> implications >>>>>>>>>>> on the level of classification being performed? If the=20 >>>>>>>>>>> stated >>>>>>>> goals >>>>>>>>>> are >>>>>>>>>>> for firewall and load balancer functionality, then the=20 >>>>>>>>>>> application >>>>>>>>>> level >>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>> If, on the other hand, the service function scope is=20 >>>>>>>>>>> limited due to limitations in classification, that would=20 >>>>>>>>>>> be and important piece of >>>>>>>> information? >>>>>>>>>>>=20 >>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases=20 >>>>>>>>>>> the fork points of the service paths seem like=20 >>>>>>>>>>> re-classification >>>>> points? >>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>> Or is the service function chain classification exclusive=20 >>>>>>>>>>> of DPI >>>>>>>> functionality? >>>>>>>>>> I have not fully read that draft yet. But in general,=20 >>>>>>>>>> as described in the arch draft, the collection of services=20 >>>>>>>>>> form a graph, segments of which are service paths. Yes,=20 >>>>>>>>>> reclassification can >>>>>>>> change >>>>>>>>>> the service path and re-classification may happen at any=20 >>>>>>>>>> node along >>>>>>>> a service path. >>>>>>>>>>=20 >>>>>>>>>> Surendra. >>>>>>>>>>>=20 >>>>>>>>>>> thanx. >>>>>>>>>>>=20 >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas=20 >>>>>>>>>>>> Narten; nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Kevin, >>>>>>>>>>>>=20 >>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It=20 >>>>>>>>>>>> can be based >>>>>>>>>> on >>>>>>>>>>>> the packet or information not in the packet(environmental=20 >>>>>>>>>>>> attributes >>>>>>>>>> for >>>>>>>>>>>> instance) or a combination thereof. What is important is=20 >>>>>>>>>>>> that such classification aids in traffic selection and=20 >>>>>>>>>>>> service path identification. >>>>>>>>>>>> It is no different from a policy in this regard except=20 >>>>>>>>>>>> that the policy now specifies the service path. >>>>>>>>>>>> Further, classification is not limited to the network=20 >>>>>>>>>>>> elements but the service functions as well. Some of this=20 >>>>>>>>>>>> is described in the >>>>>>>>>> architecture >>>>>>>>>>>> drafts as well - >>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>=20 >>>>>>>>>>>> Surendra. >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with=20 >>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>>>>>>>>>>>> section >>>>>>>>>>>>> 2 of the >>>>>>>> problem >>>>>>>>>>>>> statement: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification=20 >>>>>>>>>>>>> occurs at >>>>>>>> each >>>>>>>>>>>>> service, independent from previously applied=20 >>>>>>>>>>>>> service >>>>>>>>>>>> functions. >>>>>>>>>>>>> These unrelated classification events consume=20 >>>>>>>>>>>>> resources >>>>>>>> per >>>>>>>>>>>>> service. More importantly, the classification >>>>>>>> functionality >>>>>>>>>>>>> often differs per service function and service=20 >>>>>>>>>>>>> function >>>>>>>>>> cannot >>>>>>>>>>>>> leverage the results from other deployed network=20 >>>>>>>>>>>>> or >>>>>>>> service. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>> of) the >>>>>>>>>>>> contents >>>>>>>>>>>>> of the packet header. Concretely, it classifies=20 >>>>>>>>>>>>> packets based on >>>>>>>>>>>> the >>>>>>>>>>>>> possible combination of one or more header fields,=20 >>>>>>>>>>>>> such as >>>>>>>> source >>>>>>>>>>>>> address, destination address, DS field, protocol ID,=20 >>>>>>>>>>>>> source >>>>>>>> port >>>>>>>>>>>> and >>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A packet-based classifier as described in the framework=20 >>>>>>>>>>>>> document >>>>>>>>>>>> would >>>>>>>>>>>>> seem to be limited in what it can classify? The service=20 >>>>>>>>>>>>> function identifier lookup does not seem to be a=20 >>>>>>>>>>>>> significant optimization >>>>>>>>>> over >>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>>>>>>>>>>>> missing >>>>>>>>>> detail >>>>>>>>>>>>> wrt how classification information is determined and >>>>> reused? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP=20 >>>>>>>>>>>>> and TLS >>>>>>>>>>>> encrypted >>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I=20 >>>>>>>>>>>>> was also >>>>>>>>>>>> wondering >>>>>>>>>>>>> how independent HLS segment requests might be classified=20 >>>>>>>>>>>>> and >>>>>>>>>>>> associated? >>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> thanx. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>> Parker >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As was discussed in Vancouver, there are already many=20 >>>>>>>>>>>>>> existing ways >>>>>>>>>>>> to >>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>> a >>>>>>>>>>>> sufficient >>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>> resiliency. >>>>>>>> A >>>>>>>>>>>> single >>>>>>>>>>>>>> service chain encapsulation will go a long way to=20 >>>>>>>>>>>>>> ensuring these >>>>>>>>>>>> goals. >>>>>>>>>>>>>> It may not be the absolutely most efficient approach=20 >>>>>>>>>>>>>> for every >>>>>>>>>>>> single >>>>>>>>>>>>>> network topology and every single use case, but its=20 >>>>>>>>>>>>>> ubiquitous >>>>>>>>>> nature >>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>> However >>>>>>>>>>>> this >>>>>>>>>>>>>> could be augmented with classification result, again=20 >>>>>>>>>>>>>> one more >>>>>>>>>>>> example. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily=20 >>>>>>>>>>>>>>>> follow >>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>>>> chain. >>>>>>>>>>>>>> Correct. It is also not necessary that all transaction=20 >>>>>>>>>>>>>> of the same >>>>>>>>>>>> flow >>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Again the point here is that do we always need SFC=20 >>>>>>>>>>>>>> header or >>>>>>> Not. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The intention of service function chaining is to allow=20 >>>>>>>>>>>>>> for operation >>>>>>>>>>>> at >>>>>>>>>>>>>> the fully qualified flow level, or even finer grained=20 >>>>>>>>>>>>>> at the >>>>>>>>>>>> transaction >>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>> All >>>>>>>> flows >>>>>>>>>>>> from >>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>> chain. >>>>>>>>>> Source >>>>>>>>>>>>>> IP, >>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>> intention >>>>>>>> of >>>>>>>>>>>>>> service function chaining is to operate over any=20 >>>>>>>>>>>>>> network >>>>>>>> topology >>>>>>>>>> and >>>>>>>>>>>>>> not >>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>> of >>>>>>>> the >>>>>>>>>>>>>> transport, it does not adequately identify the service=20 >>>>>>>>>>>>>> chain, >>>>>>>>>> either. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The service header is meant to carry the context which=20 >>>>>>>>>>>>>> can >>>>>>>> *also* >>>>>>>>>>>>>> be derived (for example use source ip and vlan to=20 >>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>> header. >>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP=20 >>>>>>>>>>>>>> to SF or from >>>>>>>>>>>> SF >>>>>>>>>>>>>> to >>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | | original=20 >>>>>>>>>>>>>> | IP payload >>>>>>>> | >>>>>>>>>>>>>> | | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Where service header contains, at a minimum, enough=20 >>>>>>>>>>>>>> information to >>>>>>>>>>>> allow >>>>>>>>>>>>>> the packet to be propagated along the full length of=20 >>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances=20 >>>>>>>>>>>>>> the operation of >>>>>>>> one >>>>>>>>>>>>>> or >>>>>>>>>> more >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> And where "transport" could conceivably be any of, but=20 >>>>>>>>>>>>>> not limited >>>>>>>>>>>> to: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=20 >>>>>>>>>>>>>> imply immutability, but rather to specify the packet=20 >>>>>>>>>>>>>> that is >>>>>>>> propagated >>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>> document >>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for >>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>> function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>> nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>> the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is >>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>> may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> [SM] What does it mean by a single service-level=20 >>>>>>>>>>>>>> encapsulation, >>>>>>>> a >>>>>>>>>>>> new >>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>> or an ability to select one encapsulation=20 >>>>>>>>>>>>>> format that >>>>>>>>>>>> fits >>>>>>>>>>>>>> the >>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>> The ability to select a specific=20 >>>>>>>>>>>>>> encapsulation would be >>>>>>>>>> a >>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>> There are quite a few existing encapsulation=20 >>>>>>>>>>>>>> methods that >>>>>>>>>>>> can >>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>> context information between service nodes. I >>>>> have >>>>>>>> seen >>>>>>>>>>>>>> mention >>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>> applications contexts are transferred via >>>>> headers. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It contains the revised management text as well as=20 >>>>>>>>>>>>>> updated >>>>>>>>>>>> milestones. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> All known issues have been addressed. If there are any=20 >>>>>>>>>>>>>> remaining >>>>>>>>>>>> issues, >>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Networks, servers, storage technologies, and=20 >>>>>>>>>>>>>> applications, have all undergone significant change in=20 >>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>> of >>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>> Service >>>>>>>>>> delivery >>>>>>>>>>>> is >>>>>>>>>>>>>> currently both a technical and organizational challenge=20 >>>>>>>>>>>>>> that >>>>>>>>>> involves >>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>> Services are typically implemented by the ordered=20 >>>>>>>>>>>>>> combination of a number of service functions that are=20 >>>>>>>>>>>>>> deployed at different points within >>>>>>>>>> the >>>>>>>>>>>>>> network. Today, a common deployment model has service=20 >>>>>>>>>>>>>> functions physically inserted on the data forwarding=20 >>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>> Going >>>>>>>>>>>>>> forward, however, there is a desire to move to a=20 >>>>>>>>>>>>>> different model, >>>>>>>>>>>> where >>>>>>>>>>>>>> service functions are not required to reside on the=20 >>>>>>>>>>>>>> default data >>>>>>>>>> path >>>>>>>>>>>>>> and >>>>>>>>>>>>>> traffic is instead steered through services, wherever=20 >>>>>>>>>>>>>> they are >>>>>>>>>>>> deployed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For a given service, the abstracted view of the=20 >>>>>>>>>>>>>> required service functions and the order in which they=20 >>>>>>>>>>>>>> are to be applied is >>>>>>>> called >>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=20 >>>>>>>>>>>>>> function may be available on more than one node within=20 >>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>> via >>>>>>>>>>>>>> the selection of specific service function instances=20 >>>>>>>>>>>>>> and the network nodes on which they are provided,=20 >>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>> this is called a Service Function Path. The service=20 >>>>>>>>>>>>>> functions >>>>>>>> may >>>>>>>>>>>>>> be applied at a specific layer within the network=20 >>>>>>>>>>>>>> protocol stack >>>>>>>>>>>> (network >>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=20 >>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>> It will produce a framework for service function=20 >>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>> or >>>>>>>>>>>>>> protocol extensions to convey the service path and=20 >>>>>>>>>>>>>> service path information to nodes that implement=20 >>>>>>>>>>>>>> service functions, as well >>>>>>>> as >>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>> The >>>>>>>>>>>> working >>>>>>>>>>>>>> group will also examine what information needs to be=20 >>>>>>>>>>>>>> gathered from >>>>>>>>>>>> the >>>>>>>>>>>>>> network and service functions in support of service=20 >>>>>>>>>>>>>> function >>>>>>>>>> chaining >>>>>>>>>>>>>> and >>>>>>>>>>>>>> how that information may be made available to nodes=20 >>>>>>>>>>>>>> that implement >>>>>>>>>>>> the >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>> following: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=20 >>>>>>>>>>>>>> summary of >>>>>>>> the >>>>>>>>>>>>>> problem space to be addressed by the WG including=20 >>>>>>>>>>>>>> example >>>>>>>> high- >>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>> nomenclature >>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 2) Architecture: This document will provide a=20 >>>>>>>>>>>>>> description of >>>>>>> the >>>>>>>>>>>>>> architectural building blocks and their=20 >>>>>>>>>>>>>> relationships >>>>>>>> including >>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>> diagnostics, design analysis, and security models,=20 >>>>>>>>>>>>>> as well >>>>>>> as >>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>> document >>>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for >>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>> function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>> nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>> the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is >>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>> may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>> developed to >>>>>>>>>>>>>> describe requirements and protocols necessary to=20 >>>>>>>>>>>>>> convey >>>>>>>>>>>> information >>>>>>>>>>>>>> to service function implementation points. Where=20 >>>>>>>>>>>>>> possible, >>>>>>>>>>>> existing >>>>>>>>>>>>>> IETF protocols will be used and extended. All=20 >>>>>>>>>>>>>> protocol >>>>>>>>>> extensions >>>>>>>>>>>>>> work should be carried out in the working groups=20 >>>>>>>>>>>>>> responsible for >>>>>>>>>>>> the >>>>>>>>>>>>>> protocols being modified in coordination with this=20 >>>>>>>>>>>>>> working >>>>>>>>>> group, >>>>>>>>>>>>>> but >>>>>>>>>>>>>> may be done in this working group after agreement=20 >>>>>>>>>>>>>> with all >>>>>>>> the >>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 5) Manageability: Work on the management and=20 >>>>>>>>>>>>>> configuration of >>>>>>>>>> service >>>>>>>>>>>>>> functions in support of SFC components will=20 >>>>>>>>>>>>>> certainly be >>>>>>>> needed, >>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>>>>>>>>>>>> defining the >>>>>>>>>>>> problem >>>>>>>>>>>>>> statement and core use cases for Service Function=20 >>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>>>>>>>>>>>> modifications for management and configuration of SFC=20 >>>>>>>>>>>>>> components >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>>>>>>>>>>>> the >>>>>>>>>>>> architecture >>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>>>>>>>>>>>> specifying the >>>>>>>>>>>> generic >>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 From jmoisand@juniper.net Thu Nov 14 08:48:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB55521F9D8B for ; Thu, 14 Nov 2013 08:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.349 X-Spam-Level: X-Spam-Status: No, score=-4.349 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp7oqdo7r0sh for ; Thu, 14 Nov 2013 08:48:54 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9282421F9D5E for ; Thu, 14 Nov 2013 08:48:53 -0800 (PST) Received: from mail25-va3-R.bigfish.com (10.7.14.253) by VA3EHSOBE009.bigfish.com (10.7.40.29) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 16:48:52 +0000 Received: from mail25-va3 (localhost [127.0.0.1]) by mail25-va3-R.bigfish.com (Postfix) with ESMTP id 97F584400CE; Thu, 14 Nov 2013 16:48:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(z579ehzbb2dI98dI9371I542I1432Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail25-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(189002)(199002)(13464003)(51704005)(74706001)(81342001)(46102001)(2656002)(74366001)(69226001)(51856001)(56816003)(77982001)(77096001)(551934002)(63696002)(74502001)(74876001)(65816001)(66066001)(85306002)(54316002)(47736001)(56776001)(19580395003)(80022001)(19580405001)(53806001)(87266001)(83322001)(83072001)(87936001)(59766001)(81542001)(47446002)(80976001)(76482001)(47976001)(50986001)(74662001)(79102001)(15202345003)(49866001)(54356001)(76576001)(74316001)(33646001)(76786001)(15975445006)(76796001)(4396001)(81816001)(31966008)(81686001)(24736002)(559001)(579004)(569005); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB249; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail25-va3 (localhost.localdomain [127.0.0.1]) by mail25-va3 (MessageSwitch) id 1384447727912847_27062; Thu, 14 Nov 2013 16:48:47 +0000 (UTC) Received: from VA3EHSMHS025.bigfish.com (unknown [10.7.14.247]) by mail25-va3.bigfish.com (Postfix) with ESMTP id D2306240067; Thu, 14 Nov 2013 16:48:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS025.bigfish.com (10.7.99.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 16:48:47 +0000 Received: from BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 16:48:47 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB249.namprd05.prod.outlook.com (10.255.206.11) with Microsoft SMTP Server (TLS) id 15.0.810.5; Thu, 14 Nov 2013 16:48:45 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.83]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.180]) with mapi id 15.00.0815.000; Thu, 14 Nov 2013 16:48:45 +0000 From: Jerome Moisand To: David Allan I , "Jim Guichard (jguichar)" , "Hongyu Li (Julio)" , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQAB+5vwAAC6NXAAAsJogAAAVUWgAAApVXkA== Date: Thu, 14 Nov 2013 16:48:44 +0000 Message-ID: <5f57975eac3c4df794aaf11a34546c79@BN1PR05MB251.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 0030839EEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:48:58 -0000 All those discussions need to be grounded in concrete use cases... Seems relatively clear to me though that we'll see chains starting by a L3 = component with subscriber/service awareness (e.g. BNG or PGW), then going t= o a DPI or an IDP service function, and then forking out depending on the a= pplication being identified to one set of additional service functions or a= nother.=20 So yeah, changing tracks will likely be needed. And for sure, this is an SF= -driven decision (the DPI SF).=20 Although I'd like to see a network operator (SP or EN) clearly articulate s= uch a use case before jumping through hoops... Because this has all sorts o= f interesting implications in terms of programming APIs (sockets or else), = propagation of metadata, etc.=20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Allan I Sent: Thursday, November 14, 2013 10:22 AM To: Jim Guichard (jguichar); Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter My point was once a function in participating in more than one chain, the p= arallel tracks Niulehong refers to, then conceptually there is no reason wh= y a switch in the function woundn't allow a train to change tracks. As I've indicated I think it is a rare case, causes traceability issues etc= . and therefore is actually undesirable but I'd rather not be prescriptive= on whether this is possible or not, or HOW it MUST be done....Conceptually= I think what you refer to as bypass is the far more likely dynamic chain b= ehavior we would expect... Dave -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Thursday, November 14, 2013 4:49 AM To: David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter Hi Dave, I am not sure I am catching your point. There is no doubt that a service fu= nction may appear in more than one chain; it must as otherwise you would be= spinning up service function instances that could only ever be used by tra= ffic flowing through a single service chain. Simple example is a chain a-b-= c; I see no reason why you could not also build a chain d-b-e where b is th= e same service function instance in both chains. Branching seems to me to b= e independent of how many service function instances you have for a given s= ervice function. On 11/13/13 10:45 AM, "David Allan I" wrote: >HI Hongyu: > >I think we will have scenarios where a service function appears in more=20 >than one chain, as would be the case, for example, if some flows could=20 >dynamically bypass DPI but still needed to transit a common set of=20 >stateful service functions... > >Once you postulate a service function instance appearing in more than=20 >one chain, it seems artificially restrictive not to permit such a=20 >function to also implement branching, all the control structures would=20 >already be there. > >Rgds >Dave > >-----Original Message----- >From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >Sent: Wednesday, November 13, 2013 2:12 AM >To: David Allan I; nsc@ietf.org >Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >May I suggest summary of my views here: > >1. Branch is a sort of use case or scenario, while reclassification is=20 >a way to solve the problem. >2. Service Functions should be decoupled with the chain itself. > Meaning, a SF shall not *directly* impact the forwarding of packets in=20 >a chain. Branching should be performed by chain forwarding nodes,=20 >possibly under control of a control node. The reason for this is in NFV=20 >world, service functions may come from a third party, while chain is=20 >provided by the infrastructure of the network. There must be a cushion=20 >avoiding a service function operating infrastructure directly. >3. (Re)classification is based on info in a packet. > This is very general. Such info could be L2~L7 derived from a user's=20 >packet, as well as some info like metadata in a SFC header. As=20 >classification is out of scope of SFC, we don't have to provide too=20 >much details of how to do classification. >4. Chain segments stitching is relatively a easy way for branching. >Compared with chains and subchains, which may require a more complex=20 >header and forwarding capabilities. >My two cents. >Hongyu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Allan I >Sent: Wednesday, November 13, 2013 3:04 AM >To: nsc@ietf.org >Subject: [nsc] FW: re classification & branching, was: Current Proposed=20 >SFC charter > >Hi: >(resend with recipient list cleaned up) > >I agree we are discussing multiple concepts, classification and=20 >flow-subsetting. Perhaps more ;-) > >Defining a flow subset can be a result of classification, but it is not=20 >the exclusive mechanism. Branching is a mechanism by which flow subsets=20 >are exposed and mapped to a set of subchains such that it can be=20 >identified in the dataplane... > >That's the view from here >Dave > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >David Lake (dlake) >Sent: Tuesday, November 12, 2013 10:51 AM >To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is=20 >defined/set even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to=20 >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >Parker; Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative=20 >domain for some of the very reasons you point out. We need to keep=20 >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism=20 >>(recursive because a user-land application will ride with a specific=20 >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this=20 >>multi-domain issue - if I set a policy as a user, chances are I will=20 >>be crossing several domain boundaries. Are we expecting the service=20 >>headers to define the service chaining for the duration of the entire=20 >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the=20 >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty=20 >>relevant to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong=20 >>> mapping between Policy and the inserted Service Header(s), we=20 >>> run-the-risk of limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per=20 >>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a=20 >>> reasonably broad-brushed classification (really traffic steering=20 >>> based on what we can see at ingress) is going to be useful - is THAT=20 >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to=20 >>> redefine it - it's been around for all the time middle boxes have=20 >>> been or for that matter the L2/L3 devices. All we are talking about=20 >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of=20 >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a=20 >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a=20 >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a=20 >>> > chain is different than I originally inferred. If the chain is a=20 >>> > tree with other "branching" points in it, then that limits the=20 >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation=20 >>> > could define bad service chains, is it the intent of SFC to only=20 >>> > look at the simpler packet-level classification cases, or is it=20 >>> > the intent to consider the case where a branching point is viewed=20 >>> > as a re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D=20 >>> >>reclassification, agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be=20 >>> >> in a form of logic on a service function. Some service functions,=20 >>> >> especially L7 based, can use value in a Database to determine=20 >>> >> what is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after=20 >>> >> > been processed by a certain service function, decision of which=20 >>> >> > branches to go is made based on the result of service=20 >>> >> > function's process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The=20 >>> >> > details around how to convey the selection of the=20 >>> >> > subtree/subgraph are still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and=20 >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question=20 >>> >> > > about service header encapsulation, is it intended that a=20 >>> >> > > chain that is re-classified will get a new chain ID which=20 >>> >> > > fully describes a chain that is a superset of the original=20 >>> >> > > chain ID, prior to DPI-based re-classification? (assuming=20 >>> >> > > the goal is "a single chain ID that is commonly understood=20 >>> >> > > along the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.htm >>> >> > > l >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service=20 >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>> >> > > every flow then be initially classified as ID 1, but=20 >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of=20 >>> >> > >>> service that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification=20 >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the=20 >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the=20 >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is=20 >>> >> > >>> limited due to limitations in classification, that would be=20 >>> >> > >>> and important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >>> >> > >>> fork points of the service paths seem like=20 >>> >> > >>> re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive=20 >>> >> > >>> of DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general,=20 >>> >> > >> as described in the arch draft, the collection of services=20 >>> >> > >> form a graph, segments of which are service paths. Yes,=20 >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any=20 >>> >> > >> node along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental=20 >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is=20 >>> >> > >>>> that such classification aids in traffic selection and=20 >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except=20 >>> >> > >>>> that the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network=20 >>> >> > >>>> elements but the service functions as well. Some of this=20 >>> >> > >>>> is described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied=20 >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume=20 >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service=20 >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network=20 >>> >> > >>>>> or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some >>> >> > >>>>> of) the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies=20 >>> >> > >>>>> packets based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such=20 >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID,=20 >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework=20 >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service=20 >>> >> > >>>>> function identifier lookup does not seem to be a=20 >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified=20 >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to=20 >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach=20 >>> >> > >>>>>> for every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its=20 >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one=20 >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction=20 >>> >> > >>>>>> of the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC=20 >>> >> > >>>>>> header or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow=20 >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service=20 >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which=20 >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to=20 >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker >>> >> > >>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP=20 >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough=20 >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the=20 >>> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >>> >> > >>>>>> imply immutability, but rather to specify the packet=20 >>> >> > >>>>>> that is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level=20 >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation=20 >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation=20 >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation=20 >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as=20 >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any=20 >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and=20 >>> >> > >>>>>> applications, have all undergone significant change in=20 >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge=20 >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered=20 >>> >> > >>>>>> combination of a number of service functions that are=20 >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service=20 >>> >> > >>>>>> functions physically inserted on the data forwarding=20 >>> >> > >>>>>> path between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a=20 >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the=20 >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever=20 >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required=20 >>> >> > >>>>>> service functions and the order in which they are to be=20 >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >>> >> > >>>>>> function may be available on more than one node within a=20 >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and=20 >>> >> > >>>>>> the network nodes on which they are provided, thereby=20 >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service=20 >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network=20 >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function=20 >>> >> > >>>>>> chaining that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and=20 >>> >> > >>>>>> service path information to nodes that implement service=20 >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be=20 >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service=20 >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that=20 >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including=20 >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a=20 >>> >> > >>>>>> description of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane=20 >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service=20 >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between=20 >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation=20 >>> >> > >>>>>> may be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All=20 >>> >> > >>>>>> protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement=20 >>> >> > >>>>>> with all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Thu Nov 14 08:58:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ECD21E8056 for ; Thu, 14 Nov 2013 08:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sqbk5nJx4o2 for ; Thu, 14 Nov 2013 08:58:16 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1430711E8100 for ; Thu, 14 Nov 2013 08:58:16 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Thu, 14 Nov 2013 08:58:13 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oBTPtlYMFwdkW7YwvFgDvnV5ojd/8AgABdGwCAALQWgIAA0K0AgAAE9AD//3rfEIAAiWMA//97ebCAAIkwgP//i/pw Date: Thu, 14 Nov 2013 16:58:13 +0000 Message-ID: References: , <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.com> In-Reply-To: <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 16:58:20 -0000 Agree. But is it necessary for us to force the transport encapsulation in= to one or the other layer? Can we just say that there is, necessarily, a = transport de-encapsulation, sfc header de-encapsulation, service function p= rocessing, sfc header encapsulation, transport encapsulation, and finally f= orwarding and transmission of the fully encapsulated packet? Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Thursday, November 14, 2013 10:46 AM To: Ron Parker Cc: David Allan I; Hongyu Li (Julio); nsc@ietf.org Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter Sure but architecturally the service function and forwarding components are= separate entities. Whether you choose to combine them in implementation is= your own choice. Sent from my iPhone > On Nov 14, 2013, at 10:40 AM, "Ron Parker" wrote: >=20 > Jim, >=20 > I think that could be an implementation decision. One implementation ap= proach is that the SFC IP-layer transport tunnels are known at the forwardi= ng layer (like the way IP-in-IP and GRE tunnels are frequently supported --= as an IP interface). Another possible approach is to handle the SFC IP-l= ayer transport tunnels at a level above the forwarding layer (like the way = GTP-U tunnels are frequently supported -- they are not represented as disti= nct IP interfaces). >=20 > Ron >=20 >=20 > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Thursday, November 14, 2013 10:30 AM > To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org > Subject: Re: [nsc] FW: re classification & branching, was: Current=20 > Proposed SFC charter >=20 > Hi Ron, >=20 > I would not say that b modifies the transport header but rather b informs= the forwarding component of it's intent so that it may insert the appropri= ate transport header to meet b's requirement. >=20 >> On 11/14/13 10:24 AM, "Ron Parker" wro= te: >>=20 >> Hi, Jim. >>=20 >> I agree that forwarding is affected indirectly. Whether function b >> forwards to function c or function d is accomplished by b correctly=20 >> adding (modifying) the transport header so that d is addressed or c is >> addressed. In the most general case of utilizing an IP-based transport >> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop is >> not made at this level. The transport location (IP address) for c and = d >> may or may not share the same next-hop based on the newtwork topology=20 >> (i.e., c and/or d may or may not be on the same subnet as b, may or=20 >> may not be reached via the same next hop router). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Jim Guichard (jguichar) >> Sent: Thursday, November 14, 2013 10:14 AM >> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >> Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >> Proposed SFC charter >>=20 >> I think it is misleading to say that a service function does not=20 >> impact packet forwarding. If branching occurs then the service=20 >> function does impact packet forwarding, whether directly or=20 >> indirectly, as otherwise packets would not take the new path as a=20 >> result of the branch. For example, if the chain is a-b-c and b=20 >> decides that for certain flows the traffic should go to d rather than=20 >> c then it *must* force the forwarding component to direct traffic to=20 >> the new next-hop. While the service function may not modify=20 >> forwarding in terms of updating forwarding tables and so forth, it=20 >> has to inform the forwarding component of its intent somehow. Also, I=20 >> think what you describe Dave is a bypass operation rather than a branch? >>=20 >>> On 11/14/13 9:56 AM, "David Allan I" wrote= : >>>=20 >>> I think it is going to be a rare event, as what is more likely is=20 >>> the front end of the chain is dynamically modified so subsequent=20 >>> packets in a flow skip certain functions. Hence a graph more often=20 >>> than not is logically P2P. Facilitates testing amongst other benefits. >>>=20 >>> As such I'd not want to be prescriptive as to how and where it is=20 >>> done.... >>>=20 >>> Dave >>>=20 >>> -----Original Message----- >>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>> Sent: Wednesday, November 13, 2013 6:30 PM >>> To: David Allan I; nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> Hi Dave, >>>=20 >>> Your inferred restriction may be not always true. In general,=20 >>> service functions should be able to compose a chain arbitrarily.=20 >>> Particularly for branching, as I suggested in previous email,=20 >>> service function shall not directly impact packet forwarding. This=20 >>> precludes the restriction you mentioned. Forwarding plane can decide=20 >>> whether a branching action should be taken by reclassification or not p= er service chain. >>>=20 >>> Does this make sense? >>>=20 >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>> Sent: Wednesday, November 13, 2013 11:45 PM >>> To: Hongyu Li (Julio); nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> HI Hongyu: >>>=20 >>> I think we will have scenarios where a service function appears in=20 >>> more than one chain, as would be the case, for example, if some=20 >>> flows could dynamically bypass DPI but still needed to transit a=20 >>> common set of stateful service functions... >>>=20 >>> Once you postulate a service function instance appearing in more=20 >>> than one chain, it seems artificially restrictive not to permit such=20 >>> a function to also implement branching, all the control structures=20 >>> would already be there. >>>=20 >>> Rgds >>> Dave >>>=20 >>> -----Original Message----- >>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>> Sent: Wednesday, November 13, 2013 2:12 AM >>> To: David Allan I; nsc@ietf.org >>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> May I suggest summary of my views here: >>>=20 >>> 1. Branch is a sort of use case or scenario, while reclassification=20 >>> is a way to solve the problem. >>> 2. Service Functions should be decoupled with the chain itself. >>> Meaning, a SF shall not *directly* impact the forwarding of=20 >>> packets in a chain. Branching should be performed by chain=20 >>> forwarding nodes, possibly under control of a control node. The=20 >>> reason for this is in NFV world, service functions may come from a=20 >>> third party, while chain is provided by the infrastructure of the=20 >>> network. There must be a cushion avoiding a service function operating = infrastructure directly. >>> 3. (Re)classification is based on info in a packet. >>> This is very general. Such info could be L2~L7 derived from a=20 >>> user's packet, as well as some info like metadata in a SFC header.=20 >>> As classification is out of scope of SFC, we don't have to provide=20 >>> too much details of how to do classification. >>> 4. Chain segments stitching is relatively a easy way for branching. >>> Compared with chains and subchains, which may require a more complex=20 >>> header and forwarding capabilities. >>> My two cents. >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of David Allan I >>> Sent: Wednesday, November 13, 2013 3:04 AM >>> To: nsc@ietf.org >>> Subject: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> Hi: >>> (resend with recipient list cleaned up) >>>=20 >>> I agree we are discussing multiple concepts, classification and=20 >>> flow-subsetting. Perhaps more ;-) >>>=20 >>> Defining a flow subset can be a result of classification, but it is=20 >>> not the exclusive mechanism. Branching is a mechanism by which flow=20 >>> subsets are exposed and mapped to a set of subchains such that it=20 >>> can be identified in the dataplane... >>>=20 >>> That's the view from here >>> Dave >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of David Lake (dlake) >>> Sent: Tuesday, November 12, 2013 10:51 AM >>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar);=20 >>> Ron Parker; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>> Understood - maybe just a little localised warming of the sea then ? >>> But I still think we need to consider where and how policy is=20 >>> defined/set even for the single-domain instance. >>>=20 >>> I don't think we can assume that any L1-3 device will be able to=20 >>> determine much useful information from the data-plane. >>>=20 >>> -----Original Message----- >>> From: Jim Guichard (jguichar) >>> Sent: 12 November 2013 10:44 >>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >>> Parker; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>> As discussed during the BOF our initial work is single=20 >>> administrative domain for some of the very reasons you point out. We=20 >>> need to keep focused without trying to boil the ocean right off the bat= . >>>=20 >>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>=20 >>>> Exactly. But how can network-components "terminate" an application ??= ?? >>>>=20 >>>> I think we need a good understanding of a recursive policy=20 >>>> mechanism (recursive because a user-land application will ride with=20 >>>> a specific policy across potentially different sets of carrier policie= s). >>>>=20 >>>> I hate to bring this up now, but we also need to think about this=20 >>>> multi-domain issue - if I set a policy as a user, chances are I=20 >>>> will be crossing several domain boundaries. Are we expecting the=20 >>>> service headers to define the service chaining for the duration of=20 >>>> the entire flow across all domains, or just across a single one ? >>>>=20 >>>> In which case, do I have to re-set policy as I traverse domains and >>>> where does that policy get set ? It would be much better to set poli= cy >>>> once based on L5-7 needs, and have that instantiated across the=20 >>>> multiple domains. >>>>=20 >>>> Again, this appears to be outside the scope of SFC, but pretty=20 >>>> relevant to how it would operate in the real world. >>>>=20 >>>> David >>>>=20 >>>> -----Original Message----- >>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>> Sent: 12 November 2013 10:27 >>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >>>> Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>=20 >>>>> In those circumstances, only the end applications themselves or a=20 >>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>> THAT what we're aiming for here ? >>>>=20 >>>> I would certainly hope not, but that has been my concern as well. >>>> Application layer termination and re-classification seems a must? >>>>=20 >>>> -- Kevin J. Ma >>>>=20 >>>>> -----Original Message----- >>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda=20 >>>>> Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>=20 >>>>> Policy may be outside of the scope of SFC, but without strong=20 >>>>> mapping between Policy and the inserted Service Header(s), we=20 >>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>=20 >>>>> For example, in a world where the network has "gone dark," (as per=20 >>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >>>>> policy based on DPI of packets-in-flight ? >>>>>=20 >>>>> In those circumstances, only the end applications themselves or a=20 >>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>> THAT what we're aiming for here ? >>>>>=20 >>>>> David >>>>>=20 >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>>> Of Surendra Kumar (smkumar) >>>>> Sent: 12 November 2013 09:26 >>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>=20 >>>>> Ron, >>>>>=20 >>>>> Classification of traffic is well understood and we do not have to=20 >>>>> redefine it - it's been around for all the time middle boxes have=20 >>>>> been or for that matter the L2/L3 devices. All we are talking=20 >>>>> about is the applicability of the classification to branching in SFC. >>>>>=20 >>>>> You are right, it is all about policy which is outside the scope=20 >>>>> of SFC. >>>>>=20 >>>>> Surendra. >>>>>=20 >>>>> On 11/12/13 7:53 AM, "Ron Parker"=20 >>>>> >>>>> wrote: >>>>>=20 >>>>>> I think the lack of definition of "reclassification" may be=20 >>>>>> causing >>>>> some >>>>>> misunderstandings here. A branch would occur for some >>>>> policy-driven >>>>>> reason based on the behavior and conclusions of the service function= , >>>>>> itself. The graph would represent the fact that there is a branch >>>>>> point, but the service function, itself, being aware that it is a=20 >>>>>> branching point would contain the policy and logic to decide on whic= h >>>>>> branch to take. Specifying that policy and logic is out of scope, >>>>> IMO. >>>>>>=20 >>>>>> Ron >>>>>>=20 >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>> Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Hi Linda, >>>>>>=20 >>>>>> Are you saying that a branching point is "never" a=20 >>>>>> reclassification point, or are you saying that a branching point >>>>> "does not have to be" >>>>>> a reclassification point? >>>>>>=20 >>>>>> I think this is an important distinction that needs to be >>>>> clarified. >>>>>> If branching is never reclassification, then the meaning of a=20 >>>>>> chain is different than I originally inferred. If the chain is a=20 >>>>>> tree with other "branching" points in it, then that limits the=20 >>>>>> scope of the problem statement goals. >>>>>>=20 >>>>>> While this could be a degenerate case, and any implementation=20 >>>>>> could define bad service chains, is it the intent of SFC to only=20 >>>>>> look at the simpler packet-level classification cases, or is it=20 >>>>>> the intent to consider the case where a branching point is viewed=20 >>>>>> as a re-classification point? >>>>>>=20 >>>>>> thanx. >>>>>>=20 >>>>>> -- Kevin J. Ma >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>> Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Ron, >>>>>>>=20 >>>>>>> First, want to make it clear that "branching" !=3D=20 >>>>>>> reclassification, agree? >>>>>>>=20 >>>>>>> Second, the representation of branching (or service graph) can=20 >>>>>>> be in a form of logic on a service function. Some service=20 >>>>>>> functions, especially L7 based, can use value in a Database to=20 >>>>>>> determine what is the next service function. >>>>>>>=20 >>>>>>> Linda >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Ron Parker >>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Hongyu, >>>>>>>>=20 >>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>=20 >>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>> represent >>>>>>>> the service graph. Do we want to represent it as a proper graph >>>>> with >>>>>>>> an adjacency list or other representational model? Or, do we >>>>> want >>>>> to >>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>=20 >>>>>>>> Ron >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Branching/forking is a very interesting topic of SFC. About the >>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>> It is also possible that packets go to different branches after=20 >>>>>>>> been processed by a certain service function, decision of which=20 >>>>>>>> branches to go is made based on the result of service=20 >>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>=20 >>>>>>>> Hongyu >>>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>> Behalf Of Ron Parker >>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>> To: Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Hi, Kevin >>>>>>>>=20 >>>>>>>> You ask a great question about branching the graph. The=20 >>>>>>>> details around how to convey the selection of the=20 >>>>>>>> subtree/subgraph are still >>>>>>> to be >>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>> branch >>>>>>>> have its own chain id? Some combination? >>>>>>>>=20 >>>>>>>> Ron >>>>>>>>=20 >>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>>> Yes, reclassification can change the service path and=20 >>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>=20 >>>>>>>>> Just to expand on that, going back to the original question=20 >>>>>>>>> about service header encapsulation, is it intended that a=20 >>>>>>>>> chain that is re-classified will get a new chain ID which=20 >>>>>>>>> fully describes a chain that is a superset of the original=20 >>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming the=20 >>>>>>>>> goal is "a single chain ID that is commonly understood along=20 >>>>>>>>> the entire service >>>>> chain" >>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>> m >>>>>>>>> l >>>>>>>>> ) >>>>>>>>>=20 >>>>>>>>> And the applicable subset of the permutative list of service=20 >>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>>>>>>>> every flow then be initially classified as ID 1, but=20 >>>>>>>>> eventually get re- >>>>>>>> classified >>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>=20 >>>>>>>>> thanx. >>>>>>>>>=20 >>>>>>>>> -- Kevin J. Ma >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>>>>>>>> nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>> >>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Surendra, >>>>>>>>>>>=20 >>>>>>>>>>> Classification may be out of scope, but the level of service=20 >>>>>>>>>>> that >>>>>>>> is >>>>>>>>>>> applicable is dependent upon the level of classification=20 >>>>>>>>>>> that can >>>>>>>> be >>>>>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>>>>> implications >>>>>>>>>>> on the level of classification being performed? If the=20 >>>>>>>>>>> stated >>>>>>>> goals >>>>>>>>>> are >>>>>>>>>>> for firewall and load balancer functionality, then the=20 >>>>>>>>>>> application >>>>>>>>>> level >>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>> If, on the other hand, the service function scope is limited=20 >>>>>>>>>>> due to limitations in classification, that would be and=20 >>>>>>>>>>> important piece of >>>>>>>> information? >>>>>>>>>>>=20 >>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases >>>>>>>>>>> the fork points of the service paths seem like=20 >>>>>>>>>>> re-classification >>>>> points? >>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>> Or is the service function chain classification exclusive of=20 >>>>>>>>>>> DPI >>>>>>>> functionality? >>>>>>>>>> I have not fully read that draft yet. But in general, as=20 >>>>>>>>>> described in the arch draft, the collection of services form=20 >>>>>>>>>> a graph, segments of which are service paths. Yes,=20 >>>>>>>>>> reclassification can >>>>>>>> change >>>>>>>>>> the service path and re-classification may happen at any node=20 >>>>>>>>>> along >>>>>>>> a service path. >>>>>>>>>>=20 >>>>>>>>>> Surendra. >>>>>>>>>>>=20 >>>>>>>>>>> thanx. >>>>>>>>>>>=20 >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Kevin, >>>>>>>>>>>>=20 >>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It=20 >>>>>>>>>>>> can be based >>>>>>>>>> on >>>>>>>>>>>> the packet or information not in the packet(environmental=20 >>>>>>>>>>>> attributes >>>>>>>>>> for >>>>>>>>>>>> instance) or a combination thereof. What is important is=20 >>>>>>>>>>>> that such classification aids in traffic selection and=20 >>>>>>>>>>>> service path identification. >>>>>>>>>>>> It is no different from a policy in this regard except that=20 >>>>>>>>>>>> the policy now specifies the service path. >>>>>>>>>>>> Further, classification is not limited to the network=20 >>>>>>>>>>>> elements but the service functions as well. Some of this is=20 >>>>>>>>>>>> described in the >>>>>>>>>> architecture >>>>>>>>>>>> drafts as well - >>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>=20 >>>>>>>>>>>> Surendra. >>>>>>>>>>>>=20 >>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with=20 >>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>>>>>>>>>>>> section >>>>>>>>>>>>> 2 of the >>>>>>>> problem >>>>>>>>>>>>> statement: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification=20 >>>>>>>>>>>>> occurs at >>>>>>>> each >>>>>>>>>>>>> service, independent from previously applied service >>>>>>>>>>>> functions. >>>>>>>>>>>>> These unrelated classification events consume=20 >>>>>>>>>>>>> resources >>>>>>>> per >>>>>>>>>>>>> service. More importantly, the classification >>>>>>>> functionality >>>>>>>>>>>>> often differs per service function and service=20 >>>>>>>>>>>>> function >>>>>>>>>> cannot >>>>>>>>>>>>> leverage the results from other deployed network or >>>>>>>> service. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>> of) the >>>>>>>>>>>> contents >>>>>>>>>>>>> of the packet header. Concretely, it classifies=20 >>>>>>>>>>>>> packets based on >>>>>>>>>>>> the >>>>>>>>>>>>> possible combination of one or more header fields,=20 >>>>>>>>>>>>> such as >>>>>>>> source >>>>>>>>>>>>> address, destination address, DS field, protocol ID,=20 >>>>>>>>>>>>> source >>>>>>>> port >>>>>>>>>>>> and >>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> A packet-based classifier as described in the framework=20 >>>>>>>>>>>>> document >>>>>>>>>>>> would >>>>>>>>>>>>> seem to be limited in what it can classify? The service=20 >>>>>>>>>>>>> function identifier lookup does not seem to be a=20 >>>>>>>>>>>>> significant optimization >>>>>>>>>> over >>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>>>>>>>>>>>> missing >>>>>>>>>> detail >>>>>>>>>>>>> wrt how classification information is determined and >>>>> reused? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP=20 >>>>>>>>>>>>> and TLS >>>>>>>>>>>> encrypted >>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I=20 >>>>>>>>>>>>> was also >>>>>>>>>>>> wondering >>>>>>>>>>>>> how independent HLS segment requests might be classified=20 >>>>>>>>>>>>> and >>>>>>>>>>>> associated? >>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>=20 >>>>>>>>>>>>> thanx. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>> Parker >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As was discussed in Vancouver, there are already many=20 >>>>>>>>>>>>>> existing ways >>>>>>>>>>>> to >>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>> a >>>>>>>>>>>> sufficient >>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>> resiliency. >>>>>>>> A >>>>>>>>>>>> single >>>>>>>>>>>>>> service chain encapsulation will go a long way to=20 >>>>>>>>>>>>>> ensuring these >>>>>>>>>>>> goals. >>>>>>>>>>>>>> It may not be the absolutely most efficient approach=20 >>>>>>>>>>>>>> for every >>>>>>>>>>>> single >>>>>>>>>>>>>> network topology and every single use case, but its=20 >>>>>>>>>>>>>> ubiquitous >>>>>>>>>> nature >>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>> However >>>>>>>>>>>> this >>>>>>>>>>>>>> could be augmented with classification result, again=20 >>>>>>>>>>>>>> one more >>>>>>>>>>>> example. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily=20 >>>>>>>>>>>>>>>> follow >>>>>>>> the >>>>>>>>>>>> same >>>>>>>>>>>>>> chain. >>>>>>>>>>>>>> Correct. It is also not necessary that all transaction=20 >>>>>>>>>>>>>> of the same >>>>>>>>>>>> flow >>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Again the point here is that do we always need SFC=20 >>>>>>>>>>>>>> header or >>>>>>> Not. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The intention of service function chaining is to allow=20 >>>>>>>>>>>>>> for operation >>>>>>>>>>>> at >>>>>>>>>>>>>> the fully qualified flow level, or even finer grained=20 >>>>>>>>>>>>>> at the >>>>>>>>>>>> transaction >>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>> All >>>>>>>> flows >>>>>>>>>>>> from >>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>> chain. >>>>>>>>>> Source >>>>>>>>>>>>>> IP, >>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>> intention >>>>>>>> of >>>>>>>>>>>>>> service function chaining is to operate over any=20 >>>>>>>>>>>>>> network >>>>>>>> topology >>>>>>>>>> and >>>>>>>>>>>>>> not >>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>> of >>>>>>>> the >>>>>>>>>>>>>> transport, it does not adequately identify the service=20 >>>>>>>>>>>>>> chain, >>>>>>>>>> either. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The service header is meant to carry the context which=20 >>>>>>>>>>>>>> can >>>>>>>> *also* >>>>>>>>>>>>>> be derived (for example use source ip and vlan to=20 >>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>> header. >>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP=20 >>>>>>>>>>>>>> to SF or from >>>>>>>>>>>> SF >>>>>>>>>>>>>> to >>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>> | | original=20 >>>>>>>>>>>>>> | IP payload >>>>>>>> | >>>>>>>>>>>>>> | | >>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Where service header contains, at a minimum, enough=20 >>>>>>>>>>>>>> information to >>>>>>>>>>>> allow >>>>>>>>>>>>>> the packet to be propagated along the full length of=20 >>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances=20 >>>>>>>>>>>>>> the operation of >>>>>>>> one >>>>>>>>>>>>>> or >>>>>>>>>> more >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> And where "transport" could conceivably be any of, but=20 >>>>>>>>>>>>>> not limited >>>>>>>>>>>> to: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=20 >>>>>>>>>>>>>> imply immutability, but rather to specify the packet=20 >>>>>>>>>>>>>> that is >>>>>>>> propagated >>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>> document >>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for >>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>> function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>> nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>> the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is >>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>> may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> [SM] What does it mean by a single service-level=20 >>>>>>>>>>>>>> encapsulation, >>>>>>>> a >>>>>>>>>>>> new >>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>> or an ability to select one encapsulation=20 >>>>>>>>>>>>>> format that >>>>>>>>>>>> fits >>>>>>>>>>>>>> the >>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>> The ability to select a specific=20 >>>>>>>>>>>>>> encapsulation would be >>>>>>>>>> a >>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>> There are quite a few existing encapsulation=20 >>>>>>>>>>>>>> methods that >>>>>>>>>>>> can >>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>> context information between service nodes. I >>>>> have >>>>>>>> seen >>>>>>>>>>>>>> mention >>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>> applications contexts are transferred via >>>>> headers. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>> Of >>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> It contains the revised management text as well as=20 >>>>>>>>>>>>>> updated >>>>>>>>>>>> milestones. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> All known issues have been addressed. If there are any=20 >>>>>>>>>>>>>> remaining >>>>>>>>>>>> issues, >>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Networks, servers, storage technologies, and=20 >>>>>>>>>>>>>> applications, have all undergone significant change in=20 >>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>> of >>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>> Service >>>>>>>>>> delivery >>>>>>>>>>>> is >>>>>>>>>>>>>> currently both a technical and organizational challenge=20 >>>>>>>>>>>>>> that >>>>>>>>>> involves >>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>> Services are typically implemented by the ordered=20 >>>>>>>>>>>>>> combination of a number of service functions that are=20 >>>>>>>>>>>>>> deployed at different points within >>>>>>>>>> the >>>>>>>>>>>>>> network. Today, a common deployment model has service=20 >>>>>>>>>>>>>> functions physically inserted on the data forwarding=20 >>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>> Going >>>>>>>>>>>>>> forward, however, there is a desire to move to a=20 >>>>>>>>>>>>>> different model, >>>>>>>>>>>> where >>>>>>>>>>>>>> service functions are not required to reside on the=20 >>>>>>>>>>>>>> default data >>>>>>>>>> path >>>>>>>>>>>>>> and >>>>>>>>>>>>>> traffic is instead steered through services, wherever=20 >>>>>>>>>>>>>> they are >>>>>>>>>>>> deployed. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> For a given service, the abstracted view of the=20 >>>>>>>>>>>>>> required service functions and the order in which they=20 >>>>>>>>>>>>>> are to be applied is >>>>>>>> called >>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=20 >>>>>>>>>>>>>> function may be available on more than one node within=20 >>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>> via >>>>>>>>>>>>>> the selection of specific service function instances=20 >>>>>>>>>>>>>> and the network nodes on which they are provided,=20 >>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>> this is called a Service Function Path. The service=20 >>>>>>>>>>>>>> functions >>>>>>>> may >>>>>>>>>>>>>> be applied at a specific layer within the network=20 >>>>>>>>>>>>>> protocol stack >>>>>>>>>>>> (network >>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=20 >>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>> It will produce a framework for service function=20 >>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>> or >>>>>>>>>>>>>> protocol extensions to convey the service path and=20 >>>>>>>>>>>>>> service path information to nodes that implement=20 >>>>>>>>>>>>>> service functions, as well >>>>>>>> as >>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>> The >>>>>>>>>>>> working >>>>>>>>>>>>>> group will also examine what information needs to be=20 >>>>>>>>>>>>>> gathered from >>>>>>>>>>>> the >>>>>>>>>>>>>> network and service functions in support of service=20 >>>>>>>>>>>>>> function >>>>>>>>>> chaining >>>>>>>>>>>>>> and >>>>>>>>>>>>>> how that information may be made available to nodes=20 >>>>>>>>>>>>>> that implement >>>>>>>>>>>> the >>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>> following: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=20 >>>>>>>>>>>>>> summary of >>>>>>>> the >>>>>>>>>>>>>> problem space to be addressed by the WG including=20 >>>>>>>>>>>>>> example >>>>>>>> high- >>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>> nomenclature >>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 2) Architecture: This document will provide a=20 >>>>>>>>>>>>>> description of >>>>>>> the >>>>>>>>>>>>>> architectural building blocks and their=20 >>>>>>>>>>>>>> relationships >>>>>>>> including >>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>> diagnostics, design analysis, and security models,=20 >>>>>>>>>>>>>> as well >>>>>>> as >>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>> document >>>>>>>> will >>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>> encapsulation >>>>>>>>>> format >>>>>>>>>>>>>> for >>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>> function >>>>>>>>>>>> path, >>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>> nodes >>>>> that >>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>> encapsulation >>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>> the service >>>>>>>>>>>> that >>>>>>>>>>>>>> is >>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>> may be >>>>>>>> used >>>>>>>>>> on >>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>> construction >>>>>>>>>>>> of >>>>>>>>>>>>>> service function paths regardless of the actual >>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>> developed to >>>>>>>>>>>>>> describe requirements and protocols necessary to=20 >>>>>>>>>>>>>> convey >>>>>>>>>>>> information >>>>>>>>>>>>>> to service function implementation points. Where=20 >>>>>>>>>>>>>> possible, >>>>>>>>>>>> existing >>>>>>>>>>>>>> IETF protocols will be used and extended. All=20 >>>>>>>>>>>>>> protocol >>>>>>>>>> extensions >>>>>>>>>>>>>> work should be carried out in the working groups=20 >>>>>>>>>>>>>> responsible for >>>>>>>>>>>> the >>>>>>>>>>>>>> protocols being modified in coordination with this=20 >>>>>>>>>>>>>> working >>>>>>>>>> group, >>>>>>>>>>>>>> but >>>>>>>>>>>>>> may be done in this working group after agreement=20 >>>>>>>>>>>>>> with all >>>>>>>> the >>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 5) Manageability: Work on the management and=20 >>>>>>>>>>>>>> configuration of >>>>>>>>>> service >>>>>>>>>>>>>> functions in support of SFC components will=20 >>>>>>>>>>>>>> certainly be >>>>>>>> needed, >>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>>>>>>>>>>>> defining the >>>>>>>>>>>> problem >>>>>>>>>>>>>> statement and core use cases for Service Function=20 >>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>>>>>>>>>>>> modifications for management and configuration of SFC=20 >>>>>>>>>>>>>> components >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>>>>>>>>>>>> the >>>>>>>>>>>> architecture >>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>>>>>>>>>>>> specifying the >>>>>>>>>>>> generic >>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> _______________________________________________ >>>>>>>> nsc mailing list >>>>>>>> nsc@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 From jguichar@cisco.com Thu Nov 14 09:05:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE64621E8056 for ; Thu, 14 Nov 2013 09:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOjcSMrDxJit for ; Thu, 14 Nov 2013 09:05:10 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7E00611E815E for ; Thu, 14 Nov 2013 09:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48845; q=dns/txt; s=iport; t=1384448709; x=1385658309; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TwV6FPHnz/0D9NL9Pytgql7jAYK5DYL03r34corj284=; b=WfGcEXttDvEv1336BQYvTCV2XnVvZnGsIPVljyIiraTOOLYv4GjAAFS0 NsmdmZcg9H+thVdA9W8duJltU/hdtYqDICDGwUrOCw7IE+FnO30BjbKVz +MtnTcVFTRE1ZqtpavitgUx5KLkBcL4wejIiAYHCiGMIETy5XaFTEw5tz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKYBhVKtJXHB/2dsb2JhbABQCoMHOFO/IYEfFnSCJQEBAQQBAQEXAUoCBwQHDAYBCBEBAwEBARUSLgsUAwUBCAIECgQFCYd4DcAvjhYGBAEFBoEIKwcCBASEJwOJCoskg2KSDIMogWgBCBci X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284649531" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 14 Nov 2013 17:05:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAEH56YA016717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 17:05:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:05:06 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhySQGOv9+0OA2EkpFU9tVZojVngAgABdGwCAALQWgIAA0K0A//+xHgCAAFaFAP//rb6AgABW5QD//50FlQAPFR6A//+uF4A= Date: Thu, 14 Nov 2013 17:05:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:05:14 -0000 I don=B9t think we are forcing anything into a layer but simply call out different components of the overall system that will work together in forming the SFC architecture. If an implementor wishes to combine the service function and forwarding components I see no reason why this would not be compliant with the architecture. On 11/14/13 11:58 AM, "Ron Parker" wrote: >Agree. But is it necessary for us to force the transport encapsulation >into one or the other layer? Can we just say that there is, >necessarily, a transport de-encapsulation, sfc header de-encapsulation, >service function processing, sfc header encapsulation, transport >encapsulation, and finally forwarding and transmission of the fully >encapsulated packet? > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Thursday, November 14, 2013 10:46 AM >To: Ron Parker >Cc: David Allan I; Hongyu Li (Julio); nsc@ietf.org >Subject: Re: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >Sure but architecturally the service function and forwarding components >are separate entities. Whether you choose to combine them in >implementation is your own choice. > >Sent from my iPhone > >> On Nov 14, 2013, at 10:40 AM, "Ron Parker" >> wrote: >>=20 >> Jim, >>=20 >> I think that could be an implementation decision. One implementation >>approach is that the SFC IP-layer transport tunnels are known at the >>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently >>supported -- as an IP interface). Another possible approach is to >>handle the SFC IP-layer transport tunnels at a level above the >>forwarding layer (like the way GTP-U tunnels are frequently supported -- >>they are not represented as distinct IP interfaces). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, November 14, 2013 10:30 AM >> To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org >> Subject: Re: [nsc] FW: re classification & branching, was: Current >> Proposed SFC charter >>=20 >> Hi Ron, >>=20 >> I would not say that b modifies the transport header but rather b >>informs the forwarding component of it's intent so that it may insert >>the appropriate transport header to meet b's requirement. >>=20 >>> On 11/14/13 10:24 AM, "Ron Parker" >>>wrote: >>>=20 >>> Hi, Jim. >>>=20 >>> I agree that forwarding is affected indirectly. Whether function b >>> forwards to function c or function d is accomplished by b correctly >>> adding (modifying) the transport header so that d is addressed or c is >>> addressed. In the most general case of utilizing an IP-based >>>transport >>> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop >>>is >>> not made at this level. The transport location (IP address) for c >>>and d >>> may or may not share the same next-hop based on the newtwork topology >>> (i.e., c and/or d may or may not be on the same subnet as b, may or >>> may not be reached via the same next hop router). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Jim Guichard (jguichar) >>> Sent: Thursday, November 14, 2013 10:14 AM >>> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >>> Subject: Re: [nsc] FW: re classification & branching, was: Current >>> Proposed SFC charter >>>=20 >>> I think it is misleading to say that a service function does not >>> impact packet forwarding. If branching occurs then the service >>> function does impact packet forwarding, whether directly or >>> indirectly, as otherwise packets would not take the new path as a >>> result of the branch. For example, if the chain is a-b-c and b >>> decides that for certain flows the traffic should go to d rather than >>> c then it *must* force the forwarding component to direct traffic to >>> the new next-hop. While the service function may not modify >>> forwarding in terms of updating forwarding tables and so forth, it >>> has to inform the forwarding component of its intent somehow. Also, I >>> think what you describe Dave is a bypass operation rather than a >>>branch? >>>=20 >>>> On 11/14/13 9:56 AM, "David Allan I" >>>>wrote: >>>>=20 >>>> I think it is going to be a rare event, as what is more likely is >>>> the front end of the chain is dynamically modified so subsequent >>>> packets in a flow skip certain functions. Hence a graph more often >>>> than not is logically P2P. Facilitates testing amongst other benefits. >>>>=20 >>>> As such I'd not want to be prescriptive as to how and where it is >>>> done.... >>>>=20 >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 6:30 PM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> Hi Dave, >>>>=20 >>>> Your inferred restriction may be not always true. In general, >>>> service functions should be able to compose a chain arbitrarily. >>>> Particularly for branching, as I suggested in previous email, >>>> service function shall not directly impact packet forwarding. This >>>> precludes the restriction you mentioned. Forwarding plane can decide >>>> whether a branching action should be taken by reclassification or not >>>>per service chain. >>>>=20 >>>> Does this make sense? >>>>=20 >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> Sent: Wednesday, November 13, 2013 11:45 PM >>>> To: Hongyu Li (Julio); nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> HI Hongyu: >>>>=20 >>>> I think we will have scenarios where a service function appears in >>>> more than one chain, as would be the case, for example, if some >>>> flows could dynamically bypass DPI but still needed to transit a >>>> common set of stateful service functions... >>>>=20 >>>> Once you postulate a service function instance appearing in more >>>> than one chain, it seems artificially restrictive not to permit such >>>> a function to also implement branching, all the control structures >>>> would already be there. >>>>=20 >>>> Rgds >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 2:12 AM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> May I suggest summary of my views here: >>>>=20 >>>> 1. Branch is a sort of use case or scenario, while reclassification >>>> is a way to solve the problem. >>>> 2. Service Functions should be decoupled with the chain itself. >>>> Meaning, a SF shall not *directly* impact the forwarding of >>>> packets in a chain. Branching should be performed by chain >>>> forwarding nodes, possibly under control of a control node. The >>>> reason for this is in NFV world, service functions may come from a >>>> third party, while chain is provided by the infrastructure of the >>>> network. There must be a cushion avoiding a service function >>>>operating infrastructure directly. >>>> 3. (Re)classification is based on info in a packet. >>>> This is very general. Such info could be L2~L7 derived from a >>>> user's packet, as well as some info like metadata in a SFC header. >>>> As classification is out of scope of SFC, we don't have to provide >>>> too much details of how to do classification. >>>> 4. Chain segments stitching is relatively a easy way for branching. >>>> Compared with chains and subchains, which may require a more complex >>>> header and forwarding capabilities. >>>> My two cents. >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of David Allan I >>>> Sent: Wednesday, November 13, 2013 3:04 AM >>>> To: nsc@ietf.org >>>> Subject: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> Hi: >>>> (resend with recipient list cleaned up) >>>>=20 >>>> I agree we are discussing multiple concepts, classification and >>>> flow-subsetting. Perhaps more ;-) >>>>=20 >>>> Defining a flow subset can be a result of classification, but it is >>>> not the exclusive mechanism. Branching is a mechanism by which flow >>>> subsets are exposed and mapped to a set of subchains such that it >>>> can be identified in the dataplane... >>>>=20 >>>> That's the view from here >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>> Of David Lake (dlake) >>>> Sent: Tuesday, November 12, 2013 10:51 AM >>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); >>>> Ron Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> Understood - maybe just a little localised warming of the sea then ? >>>> But I still think we need to consider where and how policy is >>>> defined/set even for the single-domain instance. >>>>=20 >>>> I don't think we can assume that any L1-3 device will be able to >>>> determine much useful information from the data-plane. >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) >>>> Sent: 12 November 2013 10:44 >>>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron >>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> As discussed during the BOF our initial work is single >>>> administrative domain for some of the very reasons you point out. We >>>> need to keep focused without trying to boil the ocean right off the >>>>bat. >>>>=20 >>>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>>=20 >>>>> Exactly. But how can network-components "terminate" an application >>>>>???? >>>>>=20 >>>>> I think we need a good understanding of a recursive policy >>>>> mechanism (recursive because a user-land application will ride with >>>>> a specific policy across potentially different sets of carrier >>>>>policies). >>>>>=20 >>>>> I hate to bring this up now, but we also need to think about this >>>>> multi-domain issue - if I set a policy as a user, chances are I >>>>> will be crossing several domain boundaries. Are we expecting the >>>>> service headers to define the service chaining for the duration of >>>>> the entire flow across all domains, or just across a single one ? >>>>>=20 >>>>> In which case, do I have to re-set policy as I traverse domains and >>>>> where does that policy get set ? It would be much better to set >>>>>policy >>>>> once based on L5-7 needs, and have that instantiated across the >>>>> multiple domains. >>>>>=20 >>>>> Again, this appears to be outside the scope of SFC, but pretty >>>>> relevant to how it would operate in the real world. >>>>>=20 >>>>> David >>>>>=20 >>>>> -----Original Message----- >>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>> Sent: 12 November 2013 10:27 >>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>>>> Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a >>>>>> reasonably broad-brushed classification (really traffic steering >>>>>> based on what we can see at ingress) is going to be useful - is >>>>>> THAT what we're aiming for here ? >>>>>=20 >>>>> I would certainly hope not, but that has been my concern as well. >>>>> Application layer termination and re-classification seems a must? >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda >>>>>> Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Policy may be outside of the scope of SFC, but without strong >>>>>> mapping between Policy and the inserted Service Header(s), we >>>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>>=20 >>>>>> For example, in a world where the network has "gone dark," (as per >>>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>>>>> policy based on DPI of packets-in-flight ? >>>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a >>>>>> reasonably broad-brushed classification (really traffic steering >>>>>> based on what we can see at ingress) is going to be useful - is >>>>>> THAT what we're aiming for here ? >>>>>>=20 >>>>>> David >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>> Of Surendra Kumar (smkumar) >>>>>> Sent: 12 November 2013 09:26 >>>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Classification of traffic is well understood and we do not have to >>>>>> redefine it - it's been around for all the time middle boxes have >>>>>> been or for that matter the L2/L3 devices. All we are talking >>>>>> about is the applicability of the classification to branching in >>>>>>SFC. >>>>>>=20 >>>>>> You are right, it is all about policy which is outside the scope >>>>>> of SFC. >>>>>>=20 >>>>>> Surendra. >>>>>>=20 >>>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> I think the lack of definition of "reclassification" may be >>>>>>> causing >>>>>> some >>>>>>> misunderstandings here. A branch would occur for some >>>>>> policy-driven >>>>>>> reason based on the behavior and conclusions of the service >>>>>>>function, >>>>>>> itself. The graph would represent the fact that there is a branch >>>>>>> point, but the service function, itself, being aware that it is a >>>>>>> branching point would contain the policy and logic to decide on >>>>>>>which >>>>>>> branch to take. Specifying that policy and logic is out of scope, >>>>>> IMO. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>> Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Hi Linda, >>>>>>>=20 >>>>>>> Are you saying that a branching point is "never" a >>>>>>> reclassification point, or are you saying that a branching point >>>>>> "does not have to be" >>>>>>> a reclassification point? >>>>>>>=20 >>>>>>> I think this is an important distinction that needs to be >>>>>> clarified. >>>>>>> If branching is never reclassification, then the meaning of a >>>>>>> chain is different than I originally inferred. If the chain is a >>>>>>> tree with other "branching" points in it, then that limits the >>>>>>> scope of the problem statement goals. >>>>>>>=20 >>>>>>> While this could be a degenerate case, and any implementation >>>>>>> could define bad service chains, is it the intent of SFC to only >>>>>>> look at the simpler packet-level classification cases, or is it >>>>>>> the intent to consider the case where a branching point is viewed >>>>>>> as a re-classification point? >>>>>>>=20 >>>>>>> thanx. >>>>>>>=20 >>>>>>> -- Kevin J. Ma >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>> Sumandra Majee >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Ron, >>>>>>>>=20 >>>>>>>> First, want to make it clear that "branching" !=3D >>>>>>>> reclassification, agree? >>>>>>>>=20 >>>>>>>> Second, the representation of branching (or service graph) can >>>>>>>> be in a form of logic on a service function. Some service >>>>>>>> functions, especially L7 based, can use value in a Database to >>>>>>>> determine what is the next service function. >>>>>>>>=20 >>>>>>>> Linda >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hongyu, >>>>>>>>>=20 >>>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>>=20 >>>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>>> represent >>>>>>>>> the service graph. Do we want to represent it as a proper graph >>>>>> with >>>>>>>>> an adjacency list or other representational model? Or, do we >>>>>> want >>>>>> to >>>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Branching/forking is a very interesting topic of SFC. About the >>>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>>> It is also possible that packets go to different branches after >>>>>>>>> been processed by a certain service function, decision of which >>>>>>>>> branches to go is made based on the result of service >>>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>>=20 >>>>>>>>> Hongyu >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>>> To: Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hi, Kevin >>>>>>>>>=20 >>>>>>>>> You ask a great question about branching the graph. The >>>>>>>>> details around how to convey the selection of the >>>>>>>>> subtree/subgraph are still >>>>>>>> to be >>>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>>> branch >>>>>>>>> have its own chain id? Some combination? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>> Yes, reclassification can change the service path and >>>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>>=20 >>>>>>>>>> Just to expand on that, going back to the original question >>>>>>>>>> about service header encapsulation, is it intended that a >>>>>>>>>> chain that is re-classified will get a new chain ID which >>>>>>>>>> fully describes a chain that is a superset of the original >>>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming the >>>>>>>>>> goal is "a single chain ID that is commonly understood along >>>>>>>>>> the entire service >>>>>> chain" >>>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>>> m >>>>>>>>>> l >>>>>>>>>> ) >>>>>>>>>>=20 >>>>>>>>>> And the applicable subset of the permutative list of service >>>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>>>>>>>>> every flow then be initially classified as ID 1, but >>>>>>>>>> eventually get re- >>>>>>>>> classified >>>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>>=20 >>>>>>>>>> thanx. >>>>>>>>>>=20 >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Surendra, >>>>>>>>>>>>=20 >>>>>>>>>>>> Classification may be out of scope, but the level of service >>>>>>>>>>>> that >>>>>>>>> is >>>>>>>>>>>> applicable is dependent upon the level of classification >>>>>>>>>>>> that can >>>>>>>>> be >>>>>>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>>>>>> implications >>>>>>>>>>>> on the level of classification being performed? If the >>>>>>>>>>>> stated >>>>>>>>> goals >>>>>>>>>>> are >>>>>>>>>>>> for firewall and load balancer functionality, then the >>>>>>>>>>>> application >>>>>>>>>>> level >>>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>>> If, on the other hand, the service function scope is limited >>>>>>>>>>>> due to limitations in classification, that would be and >>>>>>>>>>>> important piece of >>>>>>>>> information? >>>>>>>>>>>>=20 >>>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases >>>>>>>>>>>> the fork points of the service paths seem like >>>>>>>>>>>> re-classification >>>>>> points? >>>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>>> Or is the service function chain classification exclusive of >>>>>>>>>>>> DPI >>>>>>>>> functionality? >>>>>>>>>>> I have not fully read that draft yet. But in general, as >>>>>>>>>>> described in the arch draft, the collection of services form >>>>>>>>>>> a graph, segments of which are service paths. Yes, >>>>>>>>>>> reclassification can >>>>>>>>> change >>>>>>>>>>> the service path and re-classification may happen at any node >>>>>>>>>>> along >>>>>>>>> a service path. >>>>>>>>>>>=20 >>>>>>>>>>> Surendra. >>>>>>>>>>>>=20 >>>>>>>>>>>> thanx. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Kevin, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It >>>>>>>>>>>>> can be based >>>>>>>>>>> on >>>>>>>>>>>>> the packet or information not in the packet(environmental >>>>>>>>>>>>> attributes >>>>>>>>>>> for >>>>>>>>>>>>> instance) or a combination thereof. What is important is >>>>>>>>>>>>> that such classification aids in traffic selection and >>>>>>>>>>>>> service path identification. >>>>>>>>>>>>> It is no different from a policy in this regard except that >>>>>>>>>>>>> the policy now specifies the service path. >>>>>>>>>>>>> Further, classification is not limited to the network >>>>>>>>>>>>> elements but the service functions as well. Some of this is >>>>>>>>>>>>> described in the >>>>>>>>>>> architecture >>>>>>>>>>>>> drafts as well - >>>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Surendra. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with >>>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in >>>>>>>>>>>>>> section >>>>>>>>>>>>>> 2 of the >>>>>>>>> problem >>>>>>>>>>>>>> statement: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification >>>>>>>>>>>>>> occurs at >>>>>>>>> each >>>>>>>>>>>>>> service, independent from previously applied service >>>>>>>>>>>>> functions. >>>>>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>>>>> resources >>>>>>>>> per >>>>>>>>>>>>>> service. More importantly, the classification >>>>>>>>> functionality >>>>>>>>>>>>>> often differs per service function and service >>>>>>>>>>>>>> function >>>>>>>>>>> cannot >>>>>>>>>>>>>> leverage the results from other deployed network or >>>>>>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>>> of) the >>>>>>>>>>>>> contents >>>>>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>>>>> packets based on >>>>>>>>>>>>> the >>>>>>>>>>>>>> possible combination of one or more header fields, >>>>>>>>>>>>>> such as >>>>>>>>> source >>>>>>>>>>>>>> address, destination address, DS field, protocol ID, >>>>>>>>>>>>>> source >>>>>>>>> port >>>>>>>>>>>>> and >>>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A packet-based classifier as described in the framework >>>>>>>>>>>>>> document >>>>>>>>>>>>> would >>>>>>>>>>>>>> seem to be limited in what it can classify? The service >>>>>>>>>>>>>> function identifier lookup does not seem to be a >>>>>>>>>>>>>> significant optimization >>>>>>>>>>> over >>>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some >>>>>>>>>>>>>> missing >>>>>>>>>>> detail >>>>>>>>>>>>>> wrt how classification information is determined and >>>>>> reused? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP >>>>>>>>>>>>>> and TLS >>>>>>>>>>>>> encrypted >>>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I >>>>>>>>>>>>>> was also >>>>>>>>>>>>> wondering >>>>>>>>>>>>>> how independent HLS segment requests might be classified >>>>>>>>>>>>>> and >>>>>>>>>>>>> associated? >>>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> thanx. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>> Parker >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As was discussed in Vancouver, there are already many >>>>>>>>>>>>>>> existing ways >>>>>>>>>>>>> to >>>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>>> a >>>>>>>>>>>>> sufficient >>>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>>> resiliency. >>>>>>>>> A >>>>>>>>>>>>> single >>>>>>>>>>>>>>> service chain encapsulation will go a long way to >>>>>>>>>>>>>>> ensuring these >>>>>>>>>>>>> goals. >>>>>>>>>>>>>>> It may not be the absolutely most efficient approach >>>>>>>>>>>>>>> for every >>>>>>>>>>>>> single >>>>>>>>>>>>>>> network topology and every single use case, but its >>>>>>>>>>>>>>> ubiquitous >>>>>>>>>>> nature >>>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>>> However >>>>>>>>>>>>> this >>>>>>>>>>>>>>> could be augmented with classification result, again >>>>>>>>>>>>>>> one more >>>>>>>>>>>>> example. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily >>>>>>>>>>>>>>>>> follow >>>>>>>>> the >>>>>>>>>>>>> same >>>>>>>>>>>>>>> chain. >>>>>>>>>>>>>>> Correct. It is also not necessary that all transaction >>>>>>>>>>>>>>> of the same >>>>>>>>>>>>> flow >>>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Again the point here is that do we always need SFC >>>>>>>>>>>>>>> header or >>>>>>>> Not. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The intention of service function chaining is to allow >>>>>>>>>>>>>>> for operation >>>>>>>>>>>>> at >>>>>>>>>>>>>>> the fully qualified flow level, or even finer grained >>>>>>>>>>>>>>> at the >>>>>>>>>>>>> transaction >>>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>>> All >>>>>>>>> flows >>>>>>>>>>>>> from >>>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>>> chain. >>>>>>>>>>> Source >>>>>>>>>>>>>>> IP, >>>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>>> intention >>>>>>>>> of >>>>>>>>>>>>>>> service function chaining is to operate over any >>>>>>>>>>>>>>> network >>>>>>>>> topology >>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>>> of >>>>>>>>> the >>>>>>>>>>>>>>> transport, it does not adequately identify the service >>>>>>>>>>>>>>> chain, >>>>>>>>>>> either. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The service header is meant to carry the context which >>>>>>>>>>>>>>> can >>>>>>>>> *also* >>>>>>>>>>>>>>> be derived (for example use source ip and vlan to >>>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>>> header. >>>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP >>>>>>>>>>>>>>> to SF or from >>>>>>>>>>>>> SF >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | | original=20 >>>>>>>>>>>>>>> | IP payload >>>>>>>>> | >>>>>>>>>>>>>>> | | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Where service header contains, at a minimum, enough=20 >>>>>>>>>>>>>>> information to >>>>>>>>>>>>> allow >>>>>>>>>>>>>>> the packet to be propagated along the full length of=20 >>>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances=20 >>>>>>>>>>>>>>> the operation of >>>>>>>>> one >>>>>>>>>>>>>>> or >>>>>>>>>>> more >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> And where "transport" could conceivably be any of, but=20 >>>>>>>>>>>>>>> not limited >>>>>>>>>>>>> to: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=20 >>>>>>>>>>>>>>> imply immutability, but rather to specify the packet=20 >>>>>>>>>>>>>>> that is >>>>>>>>> propagated >>>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [SM] What does it mean by a single service-level=20 >>>>>>>>>>>>>>> encapsulation, >>>>>>>>> a >>>>>>>>>>>>> new >>>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>>> or an ability to select one encapsulation=20 >>>>>>>>>>>>>>> format that >>>>>>>>>>>>> fits >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>>> The ability to select a specific=20 >>>>>>>>>>>>>>> encapsulation would be >>>>>>>>>>> a >>>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>>> There are quite a few existing encapsulation=20 >>>>>>>>>>>>>>> methods that >>>>>>>>>>>>> can >>>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>>> context information between service nodes. I >>>>>> have >>>>>>>>> seen >>>>>>>>>>>>>>> mention >>>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>>> applications contexts are transferred via >>>>>> headers. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> It contains the revised management text as well as=20 >>>>>>>>>>>>>>> updated >>>>>>>>>>>>> milestones. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> All known issues have been addressed. If there are any=20 >>>>>>>>>>>>>>> remaining >>>>>>>>>>>>> issues, >>>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Networks, servers, storage technologies, and=20 >>>>>>>>>>>>>>> applications, have all undergone significant change in=20 >>>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>>> of >>>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>>> Service >>>>>>>>>>> delivery >>>>>>>>>>>>> is >>>>>>>>>>>>>>> currently both a technical and organizational challenge=20 >>>>>>>>>>>>>>> that >>>>>>>>>>> involves >>>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>>> Services are typically implemented by the ordered=20 >>>>>>>>>>>>>>> combination of a number of service functions that are=20 >>>>>>>>>>>>>>> deployed at different points within >>>>>>>>>>> the >>>>>>>>>>>>>>> network. Today, a common deployment model has service=20 >>>>>>>>>>>>>>> functions physically inserted on the data forwarding=20 >>>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>>> Going >>>>>>>>>>>>>>> forward, however, there is a desire to move to a=20 >>>>>>>>>>>>>>> different model, >>>>>>>>>>>>> where >>>>>>>>>>>>>>> service functions are not required to reside on the=20 >>>>>>>>>>>>>>> default data >>>>>>>>>>> path >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> traffic is instead steered through services, wherever=20 >>>>>>>>>>>>>>> they are >>>>>>>>>>>>> deployed. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> For a given service, the abstracted view of the=20 >>>>>>>>>>>>>>> required service functions and the order in which they=20 >>>>>>>>>>>>>>> are to be applied is >>>>>>>>> called >>>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=20 >>>>>>>>>>>>>>> function may be available on more than one node within=20 >>>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>>> via >>>>>>>>>>>>>>> the selection of specific service function instances=20 >>>>>>>>>>>>>>> and the network nodes on which they are provided,=20 >>>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>>> this is called a Service Function Path. The service=20 >>>>>>>>>>>>>>> functions >>>>>>>>> may >>>>>>>>>>>>>>> be applied at a specific layer within the network=20 >>>>>>>>>>>>>>> protocol stack >>>>>>>>>>>>> (network >>>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=20 >>>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>>> It will produce a framework for service function=20 >>>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>>> or >>>>>>>>>>>>>>> protocol extensions to convey the service path and=20 >>>>>>>>>>>>>>> service path information to nodes that implement=20 >>>>>>>>>>>>>>> service functions, as well >>>>>>>>> as >>>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>>> The >>>>>>>>>>>>> working >>>>>>>>>>>>>>> group will also examine what information needs to be=20 >>>>>>>>>>>>>>> gathered from >>>>>>>>>>>>> the >>>>>>>>>>>>>>> network and service functions in support of service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>> chaining >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> how that information may be made available to nodes=20 >>>>>>>>>>>>>>> that implement >>>>>>>>>>>>> the >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>>> following: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=20 >>>>>>>>>>>>>>> summary of >>>>>>>>> the >>>>>>>>>>>>>>> problem space to be addressed by the WG including=20 >>>>>>>>>>>>>>> example >>>>>>>>> high- >>>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>>> nomenclature >>>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 2) Architecture: This document will provide a=20 >>>>>>>>>>>>>>> description of >>>>>>>> the >>>>>>>>>>>>>>> architectural building blocks and their=20 >>>>>>>>>>>>>>> relationships >>>>>>>>> including >>>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>>> diagnostics, design analysis, and security models,=20 >>>>>>>>>>>>>>> as well >>>>>>>> as >>>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>>> developed to >>>>>>>>>>>>>>> describe requirements and protocols necessary to=20 >>>>>>>>>>>>>>> convey >>>>>>>>>>>>> information >>>>>>>>>>>>>>> to service function implementation points. Where=20 >>>>>>>>>>>>>>> possible, >>>>>>>>>>>>> existing >>>>>>>>>>>>>>> IETF protocols will be used and extended. All=20 >>>>>>>>>>>>>>> protocol >>>>>>>>>>> extensions >>>>>>>>>>>>>>> work should be carried out in the working groups=20 >>>>>>>>>>>>>>> responsible for >>>>>>>>>>>>> the >>>>>>>>>>>>>>> protocols being modified in coordination with this=20 >>>>>>>>>>>>>>> working >>>>>>>>>>> group, >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> may be done in this working group after agreement=20 >>>>>>>>>>>>>>> with all >>>>>>>>> the >>>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 5) Manageability: Work on the management and=20 >>>>>>>>>>>>>>> configuration of >>>>>>>>>>> service >>>>>>>>>>>>>>> functions in support of SFC components will=20 >>>>>>>>>>>>>>> certainly be >>>>>>>>> needed, >>>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>>>>>>>>>>>>> defining the >>>>>>>>>>>>> problem >>>>>>>>>>>>>>> statement and core use cases for Service Function=20 >>>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>>>>>>>>>>>>> modifications for management and configuration of SFC=20 >>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>>>>>>>>>>>>> the >>>>>>>>>>>>> architecture >>>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>>>>>>>>>>>>> specifying the >>>>>>>>>>>>> generic >>>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 From andre.beliveau@ericsson.com Thu Nov 14 09:15:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A005E21E8098 for ; Thu, 14 Nov 2013 09:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-kQK9o+8p43 for ; Thu, 14 Nov 2013 09:15:27 -0800 (PST) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 327E821E8056 for ; Thu, 14 Nov 2013 09:15:23 -0800 (PST) X-AuditID: c6180641-b7fbd8e0000011cc-a1-52850529cab9 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 5C.44.04556.92505825; Thu, 14 Nov 2013 18:15:21 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 14 Nov 2013 12:15:19 -0500 From: Andre Beliveau To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQACoz9QAAC6NWAAAWgrqAABoVqQAAAJ6MAAAAVdUAAAAyXQAAAGINAAAAMxyAAAKCioAAAD1lgAAKTF0Q Date: Thu, 14 Nov 2013 17:15:18 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C2D8742@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXRPlK4ma2uQQf93FYsNU5awWSydp25x fN9+NosLT6cyO7B4vLjyjNljyu+NrB4tR96yeixZ8pMpgCWKyyYlNSezLLVI3y6BK+Px41cs BU3dzBXLZsxmbmC8doapi5GTQ0LARGLb2dksELaYxIV769m6GLk4hASOMErsPfGFGcJZziix 6t5JRpAqNgEjifdXJgHZHBwiAkkSt357goSZBaol/vw/xgpiCwtESRxuecIGYosIREs8n3+B BWSOiEATo8ShN1PAEiwCqhLfbt9iB7F5BXwlJvV0QS1rYJRYsO0v2HmcAgYS0+ftAbMZBWQl Nkz8xgKxTVzi1pP5UC8ISCzZc54ZwhaVePn4HyuErSyx5Ml+qHo9iRtTIRYzC2hLLFv4mhli saDEyZlPWCYwis1CMnYWkpZZSFpmIWlZwMiyipGjtDi1LDfdyHATIzCmjkmwOe5gXPDJ8hCj NAeLkjjvl7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYa9pThBy89nT/O3FdS796wdGF X3y6LTN461a3fP535bz1YtuUFcx8/VIXSx8f9Xh883m6rZv4L/53m325Q3T4pt8o7T1qEvFr 4Tdxzs2RZe5cR1n36Omum5gx++/MqpS5OZlxqqvO6qz4+HTRS4dNN4VK1FXaPWyK+ndfbr90 yqFiErOJzIFSJZbijERDLeai4kQA6iI13HcCAAA= Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:15:32 -0000 Hi,=20 In draft-beliveau-sfc-architecture, I was explicit to describe 3 separate l= ogical set of components: the services (SF), the Service Chaining enforcem= ent functions and the transport functions because we want to keep those sep= arate from each other and have clear interface between them. And for now, = we should discuss about them in logical term and not physical nodes as one = physical node might very well include all 3 functions. The SC enforcement functions should own service chains as defined by an ope= rator while an SF might decide to which chain (track) the packet should con= tinue its route it should not be able to create new chains (tracks). /AB -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: November-14-13 12:05 PM To: Ron Parker Cc: nsc@ietf.org; Hongyu Li (Julio); David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed= SFC charter I don=B9t think we are forcing anything into a layer but simply call out di= fferent components of the overall system that will work together in forming= the SFC architecture. If an implementor wishes to combine the service func= tion and forwarding components I see no reason why this would not be compli= ant with the architecture. On 11/14/13 11:58 AM, "Ron Parker" wrote: >Agree. But is it necessary for us to force the transport encapsulation >into one or the other layer? Can we just say that there is, >necessarily, a transport de-encapsulation, sfc header de-encapsulation,=20 >service function processing, sfc header encapsulation, transport=20 >encapsulation, and finally forwarding and transmission of the fully=20 >encapsulated packet? > > Ron > > >-----Original Message----- >From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >Sent: Thursday, November 14, 2013 10:46 AM >To: Ron Parker >Cc: David Allan I; Hongyu Li (Julio); nsc@ietf.org >Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >Proposed SFC charter > >Sure but architecturally the service function and forwarding components=20 >are separate entities. Whether you choose to combine them in=20 >implementation is your own choice. > >Sent from my iPhone > >> On Nov 14, 2013, at 10:40 AM, "Ron Parker" >> wrote: >>=20 >> Jim, >>=20 >> I think that could be an implementation decision. One implementation >>approach is that the SFC IP-layer transport tunnels are known at the=20 >>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently >>supported -- as an IP interface). Another possible approach is to >>handle the SFC IP-layer transport tunnels at a level above the=20 >>forwarding layer (like the way GTP-U tunnels are frequently supported=20 >>-- they are not represented as distinct IP interfaces). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, November 14, 2013 10:30 AM >> To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org >> Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >> Proposed SFC charter >>=20 >> Hi Ron, >>=20 >> I would not say that b modifies the transport header but rather b=20 >>informs the forwarding component of it's intent so that it may insert=20 >>the appropriate transport header to meet b's requirement. >>=20 >>> On 11/14/13 10:24 AM, "Ron Parker" >>>wrote: >>>=20 >>> Hi, Jim. >>>=20 >>> I agree that forwarding is affected indirectly. Whether function b >>> forwards to function c or function d is accomplished by b correctly =20 >>>adding (modifying) the transport header so that d is addressed or c is >>> addressed. In the most general case of utilizing an IP-based >>>transport >>> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next=20 >>>hop is >>> not made at this level. The transport location (IP address) for c >>>and d >>> may or may not share the same next-hop based on the newtwork=20 >>>topology (i.e., c and/or d may or may not be on the same subnet as=20 >>>b, may or may not be reached via the same next hop router). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>> Of Jim Guichard (jguichar) >>> Sent: Thursday, November 14, 2013 10:14 AM >>> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >>> Subject: Re: [nsc] FW: re classification & branching, was: Current=20 >>> Proposed SFC charter >>>=20 >>> I think it is misleading to say that a service function does not =20 >>>impact packet forwarding. If branching occurs then the service =20 >>>function does impact packet forwarding, whether directly or =20 >>>indirectly, as otherwise packets would not take the new path as a =20 >>>result of the branch. For example, if the chain is a-b-c and b =20 >>>decides that for certain flows the traffic should go to d rather than =20 >>>c then it *must* force the forwarding component to direct traffic to =20 >>>the new next-hop. While the service function may not modify =20 >>>forwarding in terms of updating forwarding tables and so forth, it =20 >>>has to inform the forwarding component of its intent somehow. Also, I =20 >>>think what you describe Dave is a bypass operation rather than a=20 >>>branch? >>>=20 >>>> On 11/14/13 9:56 AM, "David Allan I" >>>>wrote: >>>>=20 >>>> I think it is going to be a rare event, as what is more likely is=20 >>>> the front end of the chain is dynamically modified so subsequent=20 >>>> packets in a flow skip certain functions. Hence a graph more often=20 >>>> than not is logically P2P. Facilitates testing amongst other benefits. >>>>=20 >>>> As such I'd not want to be prescriptive as to how and where it is=20 >>>> done.... >>>>=20 >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 6:30 PM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>>> Proposed SFC charter >>>>=20 >>>> Hi Dave, >>>>=20 >>>> Your inferred restriction may be not always true. In general, =20 >>>>service functions should be able to compose a chain arbitrarily. >>>> Particularly for branching, as I suggested in previous email, =20 >>>>service function shall not directly impact packet forwarding. This =20 >>>>precludes the restriction you mentioned. Forwarding plane can decide =20 >>>>whether a branching action should be taken by reclassification or=20 >>>>not per service chain. >>>>=20 >>>> Does this make sense? >>>>=20 >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> Sent: Wednesday, November 13, 2013 11:45 PM >>>> To: Hongyu Li (Julio); nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>>> Proposed SFC charter >>>>=20 >>>> HI Hongyu: >>>>=20 >>>> I think we will have scenarios where a service function appears in=20 >>>> more than one chain, as would be the case, for example, if some=20 >>>> flows could dynamically bypass DPI but still needed to transit a=20 >>>> common set of stateful service functions... >>>>=20 >>>> Once you postulate a service function instance appearing in more=20 >>>> than one chain, it seems artificially restrictive not to permit=20 >>>> such a function to also implement branching, all the control=20 >>>> structures would already be there. >>>>=20 >>>> Rgds >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 2:12 AM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=20 >>>> Proposed SFC charter >>>>=20 >>>> May I suggest summary of my views here: >>>>=20 >>>> 1. Branch is a sort of use case or scenario, while reclassification =20 >>>>is a way to solve the problem. >>>> 2. Service Functions should be decoupled with the chain itself. >>>> Meaning, a SF shall not *directly* impact the forwarding of =20 >>>>packets in a chain. Branching should be performed by chain =20 >>>>forwarding nodes, possibly under control of a control node. The =20 >>>>reason for this is in NFV world, service functions may come from a =20 >>>>third party, while chain is provided by the infrastructure of the =20 >>>>network. There must be a cushion avoiding a service function=20 >>>>operating infrastructure directly. >>>> 3. (Re)classification is based on info in a packet. >>>> This is very general. Such info could be L2~L7 derived from a =20 >>>>user's packet, as well as some info like metadata in a SFC header. >>>> As classification is out of scope of SFC, we don't have to provide =20 >>>>too much details of how to do classification. >>>> 4. Chain segments stitching is relatively a easy way for branching. >>>> Compared with chains and subchains, which may require a more=20 >>>>complex header and forwarding capabilities. >>>> My two cents. >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>> Of David Allan I >>>> Sent: Wednesday, November 13, 2013 3:04 AM >>>> To: nsc@ietf.org >>>> Subject: [nsc] FW: re classification & branching, was: Current=20 >>>> Proposed SFC charter >>>>=20 >>>> Hi: >>>> (resend with recipient list cleaned up) >>>>=20 >>>> I agree we are discussing multiple concepts, classification and=20 >>>> flow-subsetting. Perhaps more ;-) >>>>=20 >>>> Defining a flow subset can be a result of classification, but it is=20 >>>> not the exclusive mechanism. Branching is a mechanism by which flow=20 >>>> subsets are exposed and mapped to a set of subchains such that it=20 >>>> can be identified in the dataplane... >>>>=20 >>>> That's the view from here >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf=20 >>>> Of David Lake (dlake) >>>> Sent: Tuesday, November 12, 2013 10:51 AM >>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar);=20 >>>> Ron Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> Understood - maybe just a little localised warming of the sea then ? >>>> But I still think we need to consider where and how policy is=20 >>>> defined/set even for the single-domain instance. >>>>=20 >>>> I don't think we can assume that any L1-3 device will be able to=20 >>>> determine much useful information from the data-plane. >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) >>>> Sent: 12 November 2013 10:44 >>>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=20 >>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> As discussed during the BOF our initial work is single =20 >>>>administrative domain for some of the very reasons you point out. We =20 >>>>need to keep focused without trying to boil the ocean right off the=20 >>>>bat. >>>>=20 >>>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>>=20 >>>>> Exactly. But how can network-components "terminate" an=20 >>>>>application ???? >>>>>=20 >>>>> I think we need a good understanding of a recursive policy =20 >>>>>mechanism (recursive because a user-land application will ride with =20 >>>>>a specific policy across potentially different sets of carrier=20 >>>>>policies). >>>>>=20 >>>>> I hate to bring this up now, but we also need to think about this=20 >>>>> multi-domain issue - if I set a policy as a user, chances are I=20 >>>>> will be crossing several domain boundaries. Are we expecting the=20 >>>>> service headers to define the service chaining for the duration of=20 >>>>> the entire flow across all domains, or just across a single one ? >>>>>=20 >>>>> In which case, do I have to re-set policy as I traverse domains and >>>>> where does that policy get set ? It would be much better to set >>>>>policy >>>>> once based on L5-7 needs, and have that instantiated across the =20 >>>>>multiple domains. >>>>>=20 >>>>> Again, this appears to be outside the scope of SFC, but pretty=20 >>>>> relevant to how it would operate in the real world. >>>>>=20 >>>>> David >>>>>=20 >>>>> -----Original Message----- >>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>> Sent: 12 November 2013 10:27 >>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker;=20 >>>>> Linda Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a=20 >>>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>>> THAT what we're aiming for here ? >>>>>=20 >>>>> I would certainly hope not, but that has been my concern as well. >>>>> Application layer termination and re-classification seems a must? >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda=20 >>>>>> Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Policy may be outside of the scope of SFC, but without strong=20 >>>>>> mapping between Policy and the inserted Service Header(s), we=20 >>>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>>=20 >>>>>> For example, in a world where the network has "gone dark," (as=20 >>>>>> per the IETF Technical Plenary ?:-) ) what is our ability to=20 >>>>>> determine policy based on DPI of packets-in-flight ? >>>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a=20 >>>>>> reasonably broad-brushed classification (really traffic steering=20 >>>>>> based on what we can see at ingress) is going to be useful - is=20 >>>>>> THAT what we're aiming for here ? >>>>>>=20 >>>>>> David >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>> Behalf Of Surendra Kumar (smkumar) >>>>>> Sent: 12 November 2013 09:26 >>>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Classification of traffic is well understood and we do not have=20 >>>>>>to redefine it - it's been around for all the time middle boxes=20 >>>>>>have been or for that matter the L2/L3 devices. All we are=20 >>>>>>talking about is the applicability of the classification to=20 >>>>>>branching in SFC. >>>>>>=20 >>>>>> You are right, it is all about policy which is outside the scope=20 >>>>>> of SFC. >>>>>>=20 >>>>>> Surendra. >>>>>>=20 >>>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>>> >>>>>> wrote: >>>>>>=20 >>>>>>> I think the lack of definition of "reclassification" may be=20 >>>>>>> causing >>>>>> some >>>>>>> misunderstandings here. A branch would occur for some >>>>>> policy-driven >>>>>>> reason based on the behavior and conclusions of the service=20 >>>>>>>function, >>>>>>> itself. The graph would represent the fact that there is a branch >>>>>>> point, but the service function, itself, being aware that it is=20 >>>>>>>a branching point would contain the policy and logic to decide=20 >>>>>>>on which >>>>>>> branch to take. Specifying that policy and logic is out of scope, >>>>>> IMO. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>> Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Hi Linda, >>>>>>>=20 >>>>>>> Are you saying that a branching point is "never" a=20 >>>>>>> reclassification point, or are you saying that a branching point >>>>>> "does not have to be" >>>>>>> a reclassification point? >>>>>>>=20 >>>>>>> I think this is an important distinction that needs to be >>>>>> clarified. >>>>>>> If branching is never reclassification, then the meaning of a=20 >>>>>>> chain is different than I originally inferred. If the chain is=20 >>>>>>> a tree with other "branching" points in it, then that limits the=20 >>>>>>> scope of the problem statement goals. >>>>>>>=20 >>>>>>> While this could be a degenerate case, and any implementation=20 >>>>>>> could define bad service chains, is it the intent of SFC to only=20 >>>>>>> look at the simpler packet-level classification cases, or is it=20 >>>>>>> the intent to consider the case where a branching point is=20 >>>>>>> viewed as a re-classification point? >>>>>>>=20 >>>>>>> thanx. >>>>>>>=20 >>>>>>> -- Kevin J. Ma >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>> Sumandra Majee >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Ron, >>>>>>>>=20 >>>>>>>> First, want to make it clear that "branching" !=3D=20 >>>>>>>> reclassification, agree? >>>>>>>>=20 >>>>>>>> Second, the representation of branching (or service graph) can=20 >>>>>>>> be in a form of logic on a service function. Some service=20 >>>>>>>> functions, especially L7 based, can use value in a Database to=20 >>>>>>>> determine what is the next service function. >>>>>>>>=20 >>>>>>>> Linda >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hongyu, >>>>>>>>>=20 >>>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>>=20 >>>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>>> represent >>>>>>>>> the service graph. Do we want to represent it as a proper graph >>>>>> with >>>>>>>>> an adjacency list or other representational model? Or, do we >>>>>> want >>>>>> to >>>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Branching/forking is a very interesting topic of SFC. About=20 >>>>>>>>> the >>>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>>> It is also possible that packets go to different branches=20 >>>>>>>>> after been processed by a certain service function, decision=20 >>>>>>>>> of which branches to go is made based on the result of service=20 >>>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>>=20 >>>>>>>>> Hongyu >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>>> To: Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hi, Kevin >>>>>>>>>=20 >>>>>>>>> You ask a great question about branching the graph. The=20 >>>>>>>>> details around how to convey the selection of the=20 >>>>>>>>> subtree/subgraph are still >>>>>>>> to be >>>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>>> branch >>>>>>>>> have its own chain id? Some combination? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>> Yes, reclassification can change the service path and=20 >>>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>>=20 >>>>>>>>>> Just to expand on that, going back to the original question=20 >>>>>>>>>> about service header encapsulation, is it intended that a=20 >>>>>>>>>> chain that is re-classified will get a new chain ID which=20 >>>>>>>>>> fully describes a chain that is a superset of the original=20 >>>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming=20 >>>>>>>>>> the goal is "a single chain ID that is commonly understood=20 >>>>>>>>>> along the entire service >>>>>> chain" >>>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>>> m >>>>>>>>>> l >>>>>>>>>> ) >>>>>>>>>>=20 >>>>>>>>>> And the applicable subset of the permutative list of service=20 >>>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >>>>>>>>>> every flow then be initially classified as ID 1, but=20 >>>>>>>>>> eventually get re- >>>>>>>>> classified >>>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>>=20 >>>>>>>>>> thanx. >>>>>>>>>>=20 >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Surendra, >>>>>>>>>>>>=20 >>>>>>>>>>>> Classification may be out of scope, but the level of=20 >>>>>>>>>>>> service that >>>>>>>>> is >>>>>>>>>>>> applicable is dependent upon the level of classification=20 >>>>>>>>>>>> that can >>>>>>>>> be >>>>>>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>>>>>> implications >>>>>>>>>>>> on the level of classification being performed? If the=20 >>>>>>>>>>>> stated >>>>>>>>> goals >>>>>>>>>>> are >>>>>>>>>>>> for firewall and load balancer functionality, then the=20 >>>>>>>>>>>> application >>>>>>>>>>> level >>>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>>> If, on the other hand, the service function scope is=20 >>>>>>>>>>>> limited due to limitations in classification, that would be=20 >>>>>>>>>>>> and important piece of >>>>>>>>> information? >>>>>>>>>>>>=20 >>>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases >>>>>>>>>>>> the fork points of the service paths seem like=20 >>>>>>>>>>>> re-classification >>>>>> points? >>>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>>> Or is the service function chain classification exclusive=20 >>>>>>>>>>>> of DPI >>>>>>>>> functionality? >>>>>>>>>>> I have not fully read that draft yet. But in general,=20 >>>>>>>>>>> as described in the arch draft, the collection of services=20 >>>>>>>>>>> form a graph, segments of which are service paths. Yes,=20 >>>>>>>>>>> reclassification can >>>>>>>>> change >>>>>>>>>>> the service path and re-classification may happen at any=20 >>>>>>>>>>> node along >>>>>>>>> a service path. >>>>>>>>>>>=20 >>>>>>>>>>> Surendra. >>>>>>>>>>>>=20 >>>>>>>>>>>> thanx. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Kevin, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It=20 >>>>>>>>>>>>> can be based >>>>>>>>>>> on >>>>>>>>>>>>> the packet or information not in the packet(environmental=20 >>>>>>>>>>>>> attributes >>>>>>>>>>> for >>>>>>>>>>>>> instance) or a combination thereof. What is important is=20 >>>>>>>>>>>>> that such classification aids in traffic selection and=20 >>>>>>>>>>>>> service path identification. >>>>>>>>>>>>> It is no different from a policy in this regard except=20 >>>>>>>>>>>>> that the policy now specifies the service path. >>>>>>>>>>>>> Further, classification is not limited to the network=20 >>>>>>>>>>>>> elements but the service functions as well. Some of this=20 >>>>>>>>>>>>> is described in the >>>>>>>>>>> architecture >>>>>>>>>>>>> drafts as well - >>>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Surendra. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with=20 >>>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >>>>>>>>>>>>>> section >>>>>>>>>>>>>> 2 of the >>>>>>>>> problem >>>>>>>>>>>>>> statement: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification=20 >>>>>>>>>>>>>> occurs at >>>>>>>>> each >>>>>>>>>>>>>> service, independent from previously applied=20 >>>>>>>>>>>>>> service >>>>>>>>>>>>> functions. >>>>>>>>>>>>>> These unrelated classification events consume=20 >>>>>>>>>>>>>> resources >>>>>>>>> per >>>>>>>>>>>>>> service. More importantly, the classification >>>>>>>>> functionality >>>>>>>>>>>>>> often differs per service function and service=20 >>>>>>>>>>>>>> function >>>>>>>>>>> cannot >>>>>>>>>>>>>> leverage the results from other deployed network or >>>>>>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>>> of) the >>>>>>>>>>>>> contents >>>>>>>>>>>>>> of the packet header. Concretely, it classifies packets=20 >>>>>>>>>>>>>> based on >>>>>>>>>>>>> the >>>>>>>>>>>>>> possible combination of one or more header fields, such=20 >>>>>>>>>>>>>> as >>>>>>>>> source >>>>>>>>>>>>>> address, destination address, DS field, protocol ID,=20 >>>>>>>>>>>>>> source >>>>>>>>> port >>>>>>>>>>>>> and >>>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A packet-based classifier as described in the framework=20 >>>>>>>>>>>>>> document >>>>>>>>>>>>> would >>>>>>>>>>>>>> seem to be limited in what it can classify? The service=20 >>>>>>>>>>>>>> function identifier lookup does not seem to be a=20 >>>>>>>>>>>>>> significant optimization >>>>>>>>>>> over >>>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some=20 >>>>>>>>>>>>>> missing >>>>>>>>>>> detail >>>>>>>>>>>>>> wrt how classification information is determined and >>>>>> reused? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP and=20 >>>>>>>>>>>>>> TLS >>>>>>>>>>>>> encrypted >>>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I was=20 >>>>>>>>>>>>>> also >>>>>>>>>>>>> wondering >>>>>>>>>>>>>> how independent HLS segment requests might be classified=20 >>>>>>>>>>>>>> and >>>>>>>>>>>>> associated? >>>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> thanx. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >>>>>>>>>>>>>>> On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>> Parker >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As was discussed in Vancouver, there are already many=20 >>>>>>>>>>>>>>> existing ways >>>>>>>>>>>>> to >>>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>>> a >>>>>>>>>>>>> sufficient >>>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>>> resiliency. >>>>>>>>> A >>>>>>>>>>>>> single >>>>>>>>>>>>>>> service chain encapsulation will go a long way to=20 >>>>>>>>>>>>>>> ensuring these >>>>>>>>>>>>> goals. >>>>>>>>>>>>>>> It may not be the absolutely most efficient approach=20 >>>>>>>>>>>>>>> for every >>>>>>>>>>>>> single >>>>>>>>>>>>>>> network topology and every single use case, but its=20 >>>>>>>>>>>>>>> ubiquitous >>>>>>>>>>> nature >>>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>>> However >>>>>>>>>>>>> this >>>>>>>>>>>>>>> could be augmented with classification result, again one=20 >>>>>>>>>>>>>>> more >>>>>>>>>>>>> example. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily=20 >>>>>>>>>>>>>>>>> follow >>>>>>>>> the >>>>>>>>>>>>> same >>>>>>>>>>>>>>> chain. >>>>>>>>>>>>>>> Correct. It is also not necessary that all transaction=20 >>>>>>>>>>>>>>> of the same >>>>>>>>>>>>> flow >>>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Again the point here is that do we always need SFC=20 >>>>>>>>>>>>>>> header or >>>>>>>> Not. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The intention of service function chaining is to allow=20 >>>>>>>>>>>>>>> for operation >>>>>>>>>>>>> at >>>>>>>>>>>>>>> the fully qualified flow level, or even finer grained at=20 >>>>>>>>>>>>>>> the >>>>>>>>>>>>> transaction >>>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>>> All >>>>>>>>> flows >>>>>>>>>>>>> from >>>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>>> chain. >>>>>>>>>>> Source >>>>>>>>>>>>>>> IP, >>>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>>> intention >>>>>>>>> of >>>>>>>>>>>>>>> service function chaining is to operate over any network >>>>>>>>> topology >>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>>> of >>>>>>>>> the >>>>>>>>>>>>>>> transport, it does not adequately identify the service >>>>>>>>>>>>>>> chain, >>>>>>>>>>> either. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The service header is meant to carry the context which >>>>>>>>>>>>>>> can >>>>>>>>> *also* >>>>>>>>>>>>>>> be derived (for example use source ip and vlan to >>>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>>> header. >>>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP >>>>>>>>>>>>>>> to SF or from >>>>>>>>>>>>> SF >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | | original=20 >>>>>>>>>>>>>>> | IP payload >>>>>>>>> | >>>>>>>>>>>>>>> | | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Where service header contains, at a minimum, enough=20 >>>>>>>>>>>>>>> information to >>>>>>>>>>>>> allow >>>>>>>>>>>>>>> the packet to be propagated along the full length of=20 >>>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances=20 >>>>>>>>>>>>>>> the operation of >>>>>>>>> one >>>>>>>>>>>>>>> or >>>>>>>>>>> more >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> And where "transport" could conceivably be any of, but=20 >>>>>>>>>>>>>>> not limited >>>>>>>>>>>>> to: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=20 >>>>>>>>>>>>>>> imply immutability, but rather to specify the packet=20 >>>>>>>>>>>>>>> that is >>>>>>>>> propagated >>>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [SM] What does it mean by a single service-level=20 >>>>>>>>>>>>>>> encapsulation, >>>>>>>>> a >>>>>>>>>>>>> new >>>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>>> or an ability to select one encapsulation=20 >>>>>>>>>>>>>>> format that >>>>>>>>>>>>> fits >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>>> The ability to select a specific=20 >>>>>>>>>>>>>>> encapsulation would be >>>>>>>>>>> a >>>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>>> There are quite a few existing encapsulation=20 >>>>>>>>>>>>>>> methods that >>>>>>>>>>>>> can >>>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>>> context information between service nodes. I >>>>>> have >>>>>>>>> seen >>>>>>>>>>>>>>> mention >>>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>>> applications contexts are transferred via >>>>>> headers. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> It contains the revised management text as well as=20 >>>>>>>>>>>>>>> updated >>>>>>>>>>>>> milestones. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> All known issues have been addressed. If there are any=20 >>>>>>>>>>>>>>> remaining >>>>>>>>>>>>> issues, >>>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Networks, servers, storage technologies, and=20 >>>>>>>>>>>>>>> applications, have all undergone significant change in=20 >>>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>>> of >>>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>>> Service >>>>>>>>>>> delivery >>>>>>>>>>>>> is >>>>>>>>>>>>>>> currently both a technical and organizational challenge=20 >>>>>>>>>>>>>>> that >>>>>>>>>>> involves >>>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>>> Services are typically implemented by the ordered=20 >>>>>>>>>>>>>>> combination of a number of service functions that are=20 >>>>>>>>>>>>>>> deployed at different points within >>>>>>>>>>> the >>>>>>>>>>>>>>> network. Today, a common deployment model has service=20 >>>>>>>>>>>>>>> functions physically inserted on the data forwarding=20 >>>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>>> Going >>>>>>>>>>>>>>> forward, however, there is a desire to move to a=20 >>>>>>>>>>>>>>> different model, >>>>>>>>>>>>> where >>>>>>>>>>>>>>> service functions are not required to reside on the=20 >>>>>>>>>>>>>>> default data >>>>>>>>>>> path >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> traffic is instead steered through services, wherever=20 >>>>>>>>>>>>>>> they are >>>>>>>>>>>>> deployed. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> For a given service, the abstracted view of the=20 >>>>>>>>>>>>>>> required service functions and the order in which they=20 >>>>>>>>>>>>>>> are to be applied is >>>>>>>>> called >>>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=20 >>>>>>>>>>>>>>> function may be available on more than one node within=20 >>>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>>> via >>>>>>>>>>>>>>> the selection of specific service function instances=20 >>>>>>>>>>>>>>> and the network nodes on which they are provided,=20 >>>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>>> this is called a Service Function Path. The service=20 >>>>>>>>>>>>>>> functions >>>>>>>>> may >>>>>>>>>>>>>>> be applied at a specific layer within the network=20 >>>>>>>>>>>>>>> protocol stack >>>>>>>>>>>>> (network >>>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=20 >>>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>>> It will produce a framework for service function=20 >>>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>>> or >>>>>>>>>>>>>>> protocol extensions to convey the service path and=20 >>>>>>>>>>>>>>> service path information to nodes that implement=20 >>>>>>>>>>>>>>> service functions, as well >>>>>>>>> as >>>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>>> The >>>>>>>>>>>>> working >>>>>>>>>>>>>>> group will also examine what information needs to be=20 >>>>>>>>>>>>>>> gathered from >>>>>>>>>>>>> the >>>>>>>>>>>>>>> network and service functions in support of service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>> chaining >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> how that information may be made available to nodes=20 >>>>>>>>>>>>>>> that implement >>>>>>>>>>>>> the >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>>> following: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=20 >>>>>>>>>>>>>>> summary of >>>>>>>>> the >>>>>>>>>>>>>>> problem space to be addressed by the WG including=20 >>>>>>>>>>>>>>> example >>>>>>>>> high- >>>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>>> nomenclature >>>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 2) Architecture: This document will provide a=20 >>>>>>>>>>>>>>> description of >>>>>>>> the >>>>>>>>>>>>>>> architectural building blocks and their=20 >>>>>>>>>>>>>>> relationships >>>>>>>>> including >>>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>>> diagnostics, design analysis, and security models,=20 >>>>>>>>>>>>>>> as well >>>>>>>> as >>>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>>> developed to >>>>>>>>>>>>>>> describe requirements and protocols necessary to=20 >>>>>>>>>>>>>>> convey >>>>>>>>>>>>> information >>>>>>>>>>>>>>> to service function implementation points. Where=20 >>>>>>>>>>>>>>> possible, >>>>>>>>>>>>> existing >>>>>>>>>>>>>>> IETF protocols will be used and extended. All=20 >>>>>>>>>>>>>>> protocol >>>>>>>>>>> extensions >>>>>>>>>>>>>>> work should be carried out in the working groups=20 >>>>>>>>>>>>>>> responsible for >>>>>>>>>>>>> the >>>>>>>>>>>>>>> protocols being modified in coordination with this=20 >>>>>>>>>>>>>>> working >>>>>>>>>>> group, >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> may be done in this working group after agreement=20 >>>>>>>>>>>>>>> with all >>>>>>>>> the >>>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 5) Manageability: Work on the management and=20 >>>>>>>>>>>>>>> configuration of >>>>>>>>>>> service >>>>>>>>>>>>>>> functions in support of SFC components will=20 >>>>>>>>>>>>>>> certainly be >>>>>>>>> needed, >>>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>>>>>>>>>>>>> defining the >>>>>>>>>>>>> problem >>>>>>>>>>>>>>> statement and core use cases for Service Function=20 >>>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>>>>>>>>>>>>> modifications for management and configuration of SFC=20 >>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>>>>>>>>>>>>> the >>>>>>>>>>>>> architecture >>>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>>>>>>>>>>>>> specifying the >>>>>>>>>>>>> generic >>>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Thu Nov 14 09:22:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50121E80C7 for ; Thu, 14 Nov 2013 09:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JppzUXOnS--g for ; Thu, 14 Nov 2013 09:22:15 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ABFB121E8098 for ; Thu, 14 Nov 2013 09:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48272; q=dns/txt; s=iport; t=1384449734; x=1385659334; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=X3Y9RTXb2FTSQ8SOAqR5aHGba5/X3NR9piGaUxZR3uw=; b=GBKoi2EbmxyIFS4nr/SU8mdx6M2ubb6/+PjGDgaR2Ee+u/inqL1KIDm1 VOkmk69PHuht1MYKrGI2Rgoa6N6oLj6dZL574NvdttT36ru76moh/DrJS Cz7VW1mfodSE0EiOBlraqyeHR7WYcLDzDDIZtN08wOJgOknWxl+4yckJp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAGsFhVKtJV2Y/2dsb2JhbABQCoMHOFO/IYEgFnSCJQEBAQQBAQEXAR8rAgcEBwwGAQgRAQMBAQEVCQkuCxQDBQEIAgQBCQQFCYd4DcA0jhYGBAEFBoEIKwcCBASEJwOULoNikgyDKIFoAQgXIg X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="281856475" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 14 Nov 2013 17:22:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAEHMCYr026853 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 17:22:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:22:12 -0600 From: "Surendra Kumar (smkumar)" To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDwl0nN7MhlEaYEgafQy16wpojVngAgABdGwCAALQWgIAA0K0AgAAE9ACAAAKvAIAAAZMAgAADEACAAAGZgP//lKkA Date: Thu, 14 Nov 2013 17:22:11 +0000 Message-ID: In-Reply-To: <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.112.86] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:22:19 -0000 This separation is a very important architecture consideration IMO. Select services can dictate the forwarding path at a higher level through the service path. Actual forwarding may be left to the forwarding components. Surendra. On 11/14/13 7:46 AM, "Jim Guichard (jguichar)" wrote: >Sure but architecturally the service function and forwarding components >are separate entities. Whether you choose to combine them in >implementation is your own choice. > >Sent from my iPhone > >> On Nov 14, 2013, at 10:40 AM, "Ron Parker" >> wrote: >>=20 >> Jim, >>=20 >> I think that could be an implementation decision. One implementation >>approach is that the SFC IP-layer transport tunnels are known at the >>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently >>supported -- as an IP interface). Another possible approach is to >>handle the SFC IP-layer transport tunnels at a level above the >>forwarding layer (like the way GTP-U tunnels are frequently supported -- >>they are not represented as distinct IP interfaces). >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >> Sent: Thursday, November 14, 2013 10:30 AM >> To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org >> Subject: Re: [nsc] FW: re classification & branching, was: Current >>Proposed SFC charter >>=20 >> Hi Ron, >>=20 >> I would not say that b modifies the transport header but rather b >>informs the forwarding component of it's intent so that it may insert >>the appropriate transport header to meet b's requirement. >>=20 >>> On 11/14/13 10:24 AM, "Ron Parker" >>>wrote: >>>=20 >>> Hi, Jim. >>>=20 >>> I agree that forwarding is affected indirectly. Whether function b >>> forwards to function c or function d is accomplished by b correctly >>> adding (modifying) the transport header so that d is addressed or c is >>> addressed. In the most general case of utilizing an IP-based >>>transport >>> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop >>>is >>> not made at this level. The transport location (IP address) for c >>>and d >>> may or may not share the same next-hop based on the newtwork topology >>> (i.e., c and/or d may or may not be on the same subnet as b, may or >>>may=20 >>> not be reached via the same next hop router). >>>=20 >>> Ron >>>=20 >>>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Jim Guichard (jguichar) >>> Sent: Thursday, November 14, 2013 10:14 AM >>> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >>> Subject: Re: [nsc] FW: re classification & branching, was: Current >>> Proposed SFC charter >>>=20 >>> I think it is misleading to say that a service function does not >>>impact=20 >>> packet forwarding. If branching occurs then the service function does >>> impact packet forwarding, whether directly or indirectly, as otherwise >>> packets would not take the new path as a result of the branch. For >>> example, if the chain is a-b-c and b decides that for certain flows >>>the=20 >>> traffic should go to d rather than c then it *must* force the >>> forwarding component to direct traffic to the new next-hop. While the >>> service function may not modify forwarding in terms of updating >>> forwarding tables and so forth, it has to inform the forwarding >>> component of its intent somehow. Also, I think what you describe Dave >>> is a bypass operation rather than a branch? >>>=20 >>>> On 11/14/13 9:56 AM, "David Allan I" >>>>wrote: >>>>=20 >>>> I think it is going to be a rare event, as what is more likely is the >>>> front end of the chain is dynamically modified so subsequent packets >>>> in a flow skip certain functions. Hence a graph more often than not >>>>is=20 >>>> logically P2P. Facilitates testing amongst other benefits. >>>>=20 >>>> As such I'd not want to be prescriptive as to how and where it is >>>> done.... >>>>=20 >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 6:30 PM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> Hi Dave, >>>>=20 >>>> Your inferred restriction may be not always true. In general, service >>>> functions should be able to compose a chain arbitrarily. Particularly >>>> for branching, as I suggested in previous email, service function >>>> shall not directly impact packet forwarding. This precludes the >>>> restriction you mentioned. Forwarding plane can decide whether a >>>> branching action should be taken by reclassification or not per >>>>service chain. >>>>=20 >>>> Does this make sense? >>>>=20 >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>>> Sent: Wednesday, November 13, 2013 11:45 PM >>>> To: Hongyu Li (Julio); nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> HI Hongyu: >>>>=20 >>>> I think we will have scenarios where a service function appears in >>>> more than one chain, as would be the case, for example, if some flows >>>> could dynamically bypass DPI but still needed to transit a common set >>>> of stateful service functions... >>>>=20 >>>> Once you postulate a service function instance appearing in more than >>>> one chain, it seems artificially restrictive not to permit such a >>>> function to also implement branching, all the control structures >>>>would=20 >>>> already be there. >>>>=20 >>>> Rgds >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>> Sent: Wednesday, November 13, 2013 2:12 AM >>>> To: David Allan I; nsc@ietf.org >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> May I suggest summary of my views here: >>>>=20 >>>> 1. Branch is a sort of use case or scenario, while reclassification >>>>is=20 >>>> a way to solve the problem. >>>> 2. Service Functions should be decoupled with the chain itself. >>>> Meaning, a SF shall not *directly* impact the forwarding of >>>>packets=20 >>>> in a chain. Branching should be performed by chain forwarding nodes, >>>> possibly under control of a control node. The reason for this is in >>>> NFV world, service functions may come from a third party, while chain >>>> is provided by the infrastructure of the network. There must be a >>>> cushion avoiding a service function operating infrastructure directly. >>>> 3. (Re)classification is based on info in a packet. >>>> This is very general. Such info could be L2~L7 derived from a >>>>user's=20 >>>> packet, as well as some info like metadata in a SFC header. As >>>> classification is out of scope of SFC, we don't have to provide too >>>> much details of how to do classification. >>>> 4. Chain segments stitching is relatively a easy way for branching. >>>> Compared with chains and subchains, which may require a more complex >>>> header and forwarding capabilities. >>>> My two cents. >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>> David Allan I >>>> Sent: Wednesday, November 13, 2013 3:04 AM >>>> To: nsc@ietf.org >>>> Subject: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>>=20 >>>> Hi: >>>> (resend with recipient list cleaned up) >>>>=20 >>>> I agree we are discussing multiple concepts, classification and >>>> flow-subsetting. Perhaps more ;-) >>>>=20 >>>> Defining a flow subset can be a result of classification, but it is >>>> not the exclusive mechanism. Branching is a mechanism by which flow >>>> subsets are exposed and mapped to a set of subchains such that it can >>>> be identified in the dataplane... >>>>=20 >>>> That's the view from here >>>> Dave >>>>=20 >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>> David Lake (dlake) >>>> Sent: Tuesday, November 12, 2013 10:51 AM >>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); >>>>Ron=20 >>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> Understood - maybe just a little localised warming of the sea then ? >>>> But I still think we need to consider where and how policy is >>>> defined/set even for the single-domain instance. >>>>=20 >>>> I don't think we can assume that any L1-3 device will be able to >>>> determine much useful information from the data-plane. >>>>=20 >>>> -----Original Message----- >>>> From: Jim Guichard (jguichar) >>>> Sent: 12 November 2013 10:44 >>>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron >>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>=20 >>>> As discussed during the BOF our initial work is single administrative >>>> domain for some of the very reasons you point out. We need to keep >>>> focused without trying to boil the ocean right off the bat. >>>>=20 >>>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>>=20 >>>>> Exactly. But how can network-components "terminate" an application >>>>>???? >>>>>=20 >>>>> I think we need a good understanding of a recursive policy mechanism >>>>> (recursive because a user-land application will ride with a specific >>>>> policy across potentially different sets of carrier policies). >>>>>=20 >>>>> I hate to bring this up now, but we also need to think about this >>>>> multi-domain issue - if I set a policy as a user, chances are I will >>>>> be crossing several domain boundaries. Are we expecting the service >>>>> headers to define the service chaining for the duration of the >>>>>entire=20 >>>>> flow across all domains, or just across a single one ? >>>>>=20 >>>>> In which case, do I have to re-set policy as I traverse domains and >>>>> where does that policy get set ? It would be much better to set >>>>>policy >>>>> once based on L5-7 needs, and have that instantiated across the >>>>> multiple domains. >>>>>=20 >>>>> Again, this appears to be outside the scope of SFC, but pretty >>>>> relevant to how it would operate in the real world. >>>>>=20 >>>>> David >>>>>=20 >>>>> -----Original Message----- >>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>> Sent: 12 November 2013 10:27 >>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>>>> Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a >>>>>> reasonably broad-brushed classification (really traffic steering >>>>>> based on what we can see at ingress) is going to be useful - is >>>>>> THAT what we're aiming for here ? >>>>>=20 >>>>> I would certainly hope not, but that has been my concern as well. >>>>> Application layer termination and re-classification seems a must? >>>>>=20 >>>>> -- Kevin J. Ma >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>>>>> Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Policy may be outside of the scope of SFC, but without strong >>>>>> mapping between Policy and the inserted Service Header(s), we >>>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>>=20 >>>>>> For example, in a world where the network has "gone dark," (as per >>>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>>>>> policy based on DPI of packets-in-flight ? >>>>>>=20 >>>>>> In those circumstances, only the end applications themselves or a >>>>>> reasonably broad-brushed classification (really traffic steering >>>>>> based on what we can see at ingress) is going to be useful - is >>>>>> THAT what we're aiming for here ? >>>>>>=20 >>>>>> David >>>>>>=20 >>>>>> -----Original Message----- >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>> Of Surendra Kumar (smkumar) >>>>>> Sent: 12 November 2013 09:26 >>>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>=20 >>>>>> Ron, >>>>>>=20 >>>>>> Classification of traffic is well understood and we do not have to >>>>>> redefine it - it's been around for all the time middle boxes have >>>>>> been or for that matter the L2/L3 devices. All we are talking about >>>>>> is the applicability of the classification to branching in SFC. >>>>>>=20 >>>>>> You are right, it is all about policy which is outside the scope of >>>>>> SFC. >>>>>>=20 >>>>>> Surendra. >>>>>>=20 >>>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>>> wrote: >>>>>>=20 >>>>>>> I think the lack of definition of "reclassification" may be >>>>>>> causing >>>>>> some >>>>>>> misunderstandings here. A branch would occur for some >>>>>> policy-driven >>>>>>> reason based on the behavior and conclusions of the service >>>>>>>function, >>>>>>> itself. The graph would represent the fact that there is a branch >>>>>>> point, but the service function, itself, being aware that it is a >>>>>>> branching point would contain the policy and logic to decide on >>>>>>>which >>>>>>> branch to take. Specifying that policy and logic is out of scope, >>>>>> IMO. >>>>>>>=20 >>>>>>> Ron >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>> Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>> Hi Linda, >>>>>>>=20 >>>>>>> Are you saying that a branching point is "never" a >>>>>>> reclassification point, or are you saying that a branching point >>>>>> "does not have to be" >>>>>>> a reclassification point? >>>>>>>=20 >>>>>>> I think this is an important distinction that needs to be >>>>>> clarified. >>>>>>> If branching is never reclassification, then the meaning of a >>>>>>> chain is different than I originally inferred. If the chain is a >>>>>>> tree with other "branching" points in it, then that limits the >>>>>>> scope of the problem statement goals. >>>>>>>=20 >>>>>>> While this could be a degenerate case, and any implementation >>>>>>> could define bad service chains, is it the intent of SFC to only >>>>>>> look at the simpler packet-level classification cases, or is it >>>>>>> the intent to consider the case where a branching point is viewed >>>>>>> as a re-classification point? >>>>>>>=20 >>>>>>> thanx. >>>>>>>=20 >>>>>>> -- Kevin J. Ma >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>> Sumandra Majee >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>> Ron, >>>>>>>>=20 >>>>>>>> First, want to make it clear that "branching" !=3D >>>>>>>> reclassification, agree? >>>>>>>>=20 >>>>>>>> Second, the representation of branching (or service graph) can >>>>>>>> be in a form of logic on a service function. Some service >>>>>>>> functions, especially L7 based, can use value in a Database to >>>>>>>> determine what is the next service function. >>>>>>>>=20 >>>>>>>> Linda >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hongyu, >>>>>>>>>=20 >>>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>>=20 >>>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>>> represent >>>>>>>>> the service graph. Do we want to represent it as a proper graph >>>>>> with >>>>>>>>> an adjacency list or other representational model? Or, do we >>>>>> want >>>>>> to >>>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Branching/forking is a very interesting topic of SFC. About >>>>>>>>> the >>>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>>> It is also possible that packets go to different branches >>>>>>>>> after been processed by a certain service function, decision >>>>>>>>> of which branches to go is made based on the result of service >>>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>>=20 >>>>>>>>> Hongyu >>>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>> Behalf Of Ron Parker >>>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>>> To: Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Hi, Kevin >>>>>>>>>=20 >>>>>>>>> You ask a great question about branching the graph. The >>>>>>>>> details around how to convey the selection of the >>>>>>>>> subtree/subgraph are still >>>>>>>> to be >>>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>>> branch >>>>>>>>> have its own chain id? Some combination? >>>>>>>>>=20 >>>>>>>>> Ron >>>>>>>>>=20 >>>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>> Yes, reclassification can change the service path and >>>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>>=20 >>>>>>>>>> Just to expand on that, going back to the original question >>>>>>>>>> about service header encapsulation, is it intended that a >>>>>>>>>> chain that is re-classified will get a new chain ID which >>>>>>>>>> fully describes a chain that is a superset of the original >>>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming >>>>>>>>>> the goal is "a single chain ID that is commonly understood >>>>>>>>>> along the entire service >>>>>> chain" >>>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>>> m >>>>>>>>>> l >>>>>>>>>> ) >>>>>>>>>>=20 >>>>>>>>>> And the applicable subset of the permutative list of service >>>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>>>>>>>>> every flow then be initially classified as ID 1, but >>>>>>>>>> eventually get re- >>>>>>>>> classified >>>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>>=20 >>>>>>>>>> thanx. >>>>>>>>>>=20 >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>>> >>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Surendra, >>>>>>>>>>>>=20 >>>>>>>>>>>> Classification may be out of scope, but the level of >>>>>>>>>>>> service that >>>>>>>>> is >>>>>>>>>>>> applicable is dependent upon the level of classification >>>>>>>>>>>> that can >>>>>>>>> be >>>>>>>>>>>> performed. An assumption of packet level encapsulation >>>>>>>>>>>> has >>>>>>>>>>> implications >>>>>>>>>>>> on the level of classification being performed? If the >>>>>>>>>>>> stated >>>>>>>>> goals >>>>>>>>>>> are >>>>>>>>>>>> for firewall and load balancer functionality, then the >>>>>>>>>>>> application >>>>>>>>>>> level >>>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>>> If, on the other hand, the service function scope is >>>>>>>>>>>> limited due to limitations in classification, that would >>>>>>>>>>>> be and important piece of >>>>>>>>> information? >>>>>>>>>>>>=20 >>>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases >>>>>>>>>>>> the fork points of the service paths seem like >>>>>>>>>>>> re-classification >>>>>> points? >>>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>>> Or is the service function chain classification exclusive >>>>>>>>>>>> of DPI >>>>>>>>> functionality? >>>>>>>>>>> I have not fully read that draft yet. But in general, >>>>>>>>>>> as described in the arch draft, the collection of services >>>>>>>>>>> form a graph, segments of which are service paths. Yes, >>>>>>>>>>> reclassification can >>>>>>>>> change >>>>>>>>>>> the service path and re-classification may happen at any >>>>>>>>>>> node along >>>>>>>>> a service path. >>>>>>>>>>>=20 >>>>>>>>>>> Surendra. >>>>>>>>>>>>=20 >>>>>>>>>>>> thanx. >>>>>>>>>>>>=20 >>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>=20 >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas >>>>>>>>>>>>> Narten; nsc@ietf.org >>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Kevin, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It >>>>>>>>>>>>> can be based >>>>>>>>>>> on >>>>>>>>>>>>> the packet or information not in the packet(environmental >>>>>>>>>>>>> attributes >>>>>>>>>>> for >>>>>>>>>>>>> instance) or a combination thereof. What is important is >>>>>>>>>>>>> that such classification aids in traffic selection and >>>>>>>>>>>>> service path identification. >>>>>>>>>>>>> It is no different from a policy in this regard except >>>>>>>>>>>>> that the policy now specifies the service path. >>>>>>>>>>>>> Further, classification is not limited to the network >>>>>>>>>>>>> elements but the service functions as well. Some of this >>>>>>>>>>>>> is described in the >>>>>>>>>>> architecture >>>>>>>>>>>>> drafts as well - >>>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Surendra. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with >>>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in >>>>>>>>>>>>>> section >>>>>>>>>>>>>> 2 of the >>>>>>>>> problem >>>>>>>>>>>>>> statement: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification >>>>>>>>>>>>>> occurs at >>>>>>>>> each >>>>>>>>>>>>>> service, independent from previously applied >>>>>>>>>>>>>> service >>>>>>>>>>>>> functions. >>>>>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>>>>> resources >>>>>>>>> per >>>>>>>>>>>>>> service. More importantly, the classification >>>>>>>>> functionality >>>>>>>>>>>>>> often differs per service function and service >>>>>>>>>>>>>> function >>>>>>>>>>> cannot >>>>>>>>>>>>>> leverage the results from other deployed network >>>>>>>>>>>>>> or >>>>>>>>> service. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>>> of) the >>>>>>>>>>>>> contents >>>>>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>>>>> packets based on >>>>>>>>>>>>> the >>>>>>>>>>>>>> possible combination of one or more header fields, >>>>>>>>>>>>>> such as >>>>>>>>> source >>>>>>>>>>>>>> address, destination address, DS field, protocol ID, >>>>>>>>>>>>>> source >>>>>>>>> port >>>>>>>>>>>>> and >>>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> A packet-based classifier as described in the framework >>>>>>>>>>>>>> document >>>>>>>>>>>>> would >>>>>>>>>>>>>> seem to be limited in what it can classify? The service >>>>>>>>>>>>>> function identifier lookup does not seem to be a >>>>>>>>>>>>>> significant optimization >>>>>>>>>>> over >>>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some >>>>>>>>>>>>>> missing >>>>>>>>>>> detail >>>>>>>>>>>>>> wrt how classification information is determined and >>>>>> reused? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP >>>>>>>>>>>>>> and TLS >>>>>>>>>>>>> encrypted >>>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I >>>>>>>>>>>>>> was also >>>>>>>>>>>>> wondering >>>>>>>>>>>>>> how independent HLS segment requests might be classified >>>>>>>>>>>>>> and >>>>>>>>>>>>> associated? >>>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> thanx. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>> Parker >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As was discussed in Vancouver, there are already many >>>>>>>>>>>>>>> existing ways >>>>>>>>>>>>> to >>>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>>> a >>>>>>>>>>>>> sufficient >>>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>>> resiliency. >>>>>>>>> A >>>>>>>>>>>>> single >>>>>>>>>>>>>>> service chain encapsulation will go a long way to >>>>>>>>>>>>>>> ensuring these >>>>>>>>>>>>> goals. >>>>>>>>>>>>>>> It may not be the absolutely most efficient approach >>>>>>>>>>>>>>> for every >>>>>>>>>>>>> single >>>>>>>>>>>>>>> network topology and every single use case, but its >>>>>>>>>>>>>>> ubiquitous >>>>>>>>>>> nature >>>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>>> However >>>>>>>>>>>>> this >>>>>>>>>>>>>>> could be augmented with classification result, again >>>>>>>>>>>>>>> one more >>>>>>>>>>>>> example. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily >>>>>>>>>>>>>>>>> follow >>>>>>>>> the >>>>>>>>>>>>> same >>>>>>>>>>>>>>> chain. >>>>>>>>>>>>>>> Correct. It is also not necessary that all transaction >>>>>>>>>>>>>>> of the same >>>>>>>>>>>>> flow >>>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Again the point here is that do we always need SFC >>>>>>>>>>>>>>> header or >>>>>>>> Not. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The intention of service function chaining is to allow >>>>>>>>>>>>>>> for operation >>>>>>>>>>>>> at >>>>>>>>>>>>>>> the fully qualified flow level, or even finer grained >>>>>>>>>>>>>>> at the >>>>>>>>>>>>> transaction >>>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>>> All >>>>>>>>> flows >>>>>>>>>>>>> from >>>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>>> chain. >>>>>>>>>>> Source >>>>>>>>>>>>>>> IP, >>>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>>> intention >>>>>>>>> of >>>>>>>>>>>>>>> service function chaining is to operate over any >>>>>>>>>>>>>>> network >>>>>>>>> topology >>>>>>>>>>> and >>>>>>>>>>>>>>> not >>>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>>> of >>>>>>>>> the >>>>>>>>>>>>>>> transport, it does not adequately identify the service >>>>>>>>>>>>>>> chain, >>>>>>>>>>> either. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The service header is meant to carry the context which >>>>>>>>>>>>>>> can >>>>>>>>> *also* >>>>>>>>>>>>>>> be derived (for example use source ip and vlan to >>>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>>> header. >>>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP >>>>>>>>>>>>>>> to SF or from >>>>>>>>>>>>> SF >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>> | | original >>>>>>>>>>>>>>> | IP payload >>>>>>>>> | >>>>>>>>>>>>>>> | | >>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Where service header contains, at a minimum, enough >>>>>>>>>>>>>>> information to >>>>>>>>>>>>> allow >>>>>>>>>>>>>>> the packet to be propagated along the full length of >>>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances >>>>>>>>>>>>>>> the operation of >>>>>>>>> one >>>>>>>>>>>>>>> or >>>>>>>>>>> more >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> And where "transport" could conceivably be any of, but >>>>>>>>>>>>>>> not limited >>>>>>>>>>>>> to: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=20 >>>>>>>>>>>>>>> imply immutability, but rather to specify the packet=20 >>>>>>>>>>>>>>> that is >>>>>>>>> propagated >>>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=20 >>>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> [SM] What does it mean by a single service-level=20 >>>>>>>>>>>>>>> encapsulation, >>>>>>>>> a >>>>>>>>>>>>> new >>>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>>> or an ability to select one encapsulation=20 >>>>>>>>>>>>>>> format that >>>>>>>>>>>>> fits >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>>> The ability to select a specific=20 >>>>>>>>>>>>>>> encapsulation would be >>>>>>>>>>> a >>>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>>> There are quite a few existing encapsulation=20 >>>>>>>>>>>>>>> methods that >>>>>>>>>>>>> can >>>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>>> context information between service nodes. I >>>>>> have >>>>>>>>> seen >>>>>>>>>>>>>>> mention >>>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>>> applications contexts are transferred via >>>>>> headers. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=20 >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>> Of >>>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> It contains the revised management text as well as=20 >>>>>>>>>>>>>>> updated >>>>>>>>>>>>> milestones. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> All known issues have been addressed. If there are any=20 >>>>>>>>>>>>>>> remaining >>>>>>>>>>>>> issues, >>>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Networks, servers, storage technologies, and=20 >>>>>>>>>>>>>>> applications, have all undergone significant change in=20 >>>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>>> of >>>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>>> Service >>>>>>>>>>> delivery >>>>>>>>>>>>> is >>>>>>>>>>>>>>> currently both a technical and organizational challenge=20 >>>>>>>>>>>>>>> that >>>>>>>>>>> involves >>>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>>> Services are typically implemented by the ordered=20 >>>>>>>>>>>>>>> combination of a number of service functions that are=20 >>>>>>>>>>>>>>> deployed at different points within >>>>>>>>>>> the >>>>>>>>>>>>>>> network. Today, a common deployment model has service=20 >>>>>>>>>>>>>>> functions physically inserted on the data forwarding=20 >>>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>>> Going >>>>>>>>>>>>>>> forward, however, there is a desire to move to a=20 >>>>>>>>>>>>>>> different model, >>>>>>>>>>>>> where >>>>>>>>>>>>>>> service functions are not required to reside on the=20 >>>>>>>>>>>>>>> default data >>>>>>>>>>> path >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> traffic is instead steered through services, wherever=20 >>>>>>>>>>>>>>> they are >>>>>>>>>>>>> deployed. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> For a given service, the abstracted view of the=20 >>>>>>>>>>>>>>> required service functions and the order in which they=20 >>>>>>>>>>>>>>> are to be applied is >>>>>>>>> called >>>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=20 >>>>>>>>>>>>>>> function may be available on more than one node within=20 >>>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>>> via >>>>>>>>>>>>>>> the selection of specific service function instances=20 >>>>>>>>>>>>>>> and the network nodes on which they are provided,=20 >>>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>>> this is called a Service Function Path. The service=20 >>>>>>>>>>>>>>> functions >>>>>>>>> may >>>>>>>>>>>>>>> be applied at a specific layer within the network=20 >>>>>>>>>>>>>>> protocol stack >>>>>>>>>>>>> (network >>>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=20 >>>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>>> It will produce a framework for service function=20 >>>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>>> or >>>>>>>>>>>>>>> protocol extensions to convey the service path and=20 >>>>>>>>>>>>>>> service path information to nodes that implement=20 >>>>>>>>>>>>>>> service functions, as well >>>>>>>>> as >>>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>>> The >>>>>>>>>>>>> working >>>>>>>>>>>>>>> group will also examine what information needs to be=20 >>>>>>>>>>>>>>> gathered from >>>>>>>>>>>>> the >>>>>>>>>>>>>>> network and service functions in support of service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>> chaining >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> how that information may be made available to nodes=20 >>>>>>>>>>>>>>> that implement >>>>>>>>>>>>> the >>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>>> following: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=20 >>>>>>>>>>>>>>> summary of >>>>>>>>> the >>>>>>>>>>>>>>> problem space to be addressed by the WG including=20 >>>>>>>>>>>>>>> example >>>>>>>>> high- >>>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>>> nomenclature >>>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 2) Architecture: This document will provide a=20 >>>>>>>>>>>>>>> description of >>>>>>>> the >>>>>>>>>>>>>>> architectural building blocks and their=20 >>>>>>>>>>>>>>> relationships >>>>>>>>> including >>>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>>> diagnostics, design analysis, and security models,=20 >>>>>>>>>>>>>>> as well >>>>>>>> as >>>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >>>>>>>>>>>>>>> document >>>>>>>>> will >>>>>>>>>>>>>>> describe the single service-level data plane=20 >>>>>>>>>>>>>>> encapsulation >>>>>>>>>>> format >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>> conveying the service function chain and the service=20 >>>>>>>>>>>>>>> function >>>>>>>>>>>>> path, >>>>>>>>>>>>>>> and for communicating context information between=20 >>>>>>>>>>>>>>> nodes >>>>>> that >>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=20 >>>>>>>>>>>>>>> the service >>>>>>>>>>>>> that >>>>>>>>>>>>>>> is >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=20 >>>>>>>>>>>>>>> may be >>>>>>>>> used >>>>>>>>>>> on >>>>>>>>>>>>>>> a service function path realized at the network=20 >>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>> construction >>>>>>>>>>>>> of >>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>> service. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>>> developed to >>>>>>>>>>>>>>> describe requirements and protocols necessary to=20 >>>>>>>>>>>>>>> convey >>>>>>>>>>>>> information >>>>>>>>>>>>>>> to service function implementation points. Where=20 >>>>>>>>>>>>>>> possible, >>>>>>>>>>>>> existing >>>>>>>>>>>>>>> IETF protocols will be used and extended. All=20 >>>>>>>>>>>>>>> protocol >>>>>>>>>>> extensions >>>>>>>>>>>>>>> work should be carried out in the working groups=20 >>>>>>>>>>>>>>> responsible for >>>>>>>>>>>>> the >>>>>>>>>>>>>>> protocols being modified in coordination with this=20 >>>>>>>>>>>>>>> working >>>>>>>>>>> group, >>>>>>>>>>>>>>> but >>>>>>>>>>>>>>> may be done in this working group after agreement=20 >>>>>>>>>>>>>>> with all >>>>>>>>> the >>>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 5) Manageability: Work on the management and=20 >>>>>>>>>>>>>>> configuration of >>>>>>>>>>> service >>>>>>>>>>>>>>> functions in support of SFC components will=20 >>>>>>>>>>>>>>> certainly be >>>>>>>>> needed, >>>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>>>>>>>>>>>>>> defining the >>>>>>>>>>>>> problem >>>>>>>>>>>>>>> statement and core use cases for Service Function=20 >>>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=20 >>>>>>>>>>>>>>> modifications for management and configuration of SFC=20 >>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>>>>>>>>>>>>>> the >>>>>>>>>>>>> architecture >>>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>>>>>>>>>>>>>> specifying the >>>>>>>>>>>>> generic >>>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>> _______________________________________________ >>>>>>>>> nsc mailing list >>>>>>>>> nsc@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Thu Nov 14 09:51:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4B21F9D7A for ; Thu, 14 Nov 2013 09:51:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.349 X-Spam-Level: X-Spam-Status: No, score=-5.349 tagged_above=-999 required=5 tests=[AWL=1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDhUipf2gyby for ; Thu, 14 Nov 2013 09:51:25 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1424B21F9C7B for ; Thu, 14 Nov 2013 09:51:25 -0800 (PST) Received: from mail182-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE008.bigfish.com (10.236.130.71) with Microsoft SMTP Server id 14.1.225.22; Thu, 14 Nov 2013 17:51:24 +0000 Received: from mail182-co9 (localhost [127.0.0.1]) by mail182-co9-R.bigfish.com (Postfix) with ESMTP id 8F75C8401FF; Thu, 14 Nov 2013 17:51:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(z579ehzbb2dI98dI9371I542I1432I1418Id799hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail182-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(24454002)(51444003)(377454003)(479174003)(13464003)(51704005)(199002)(189002)(79102001)(50986001)(66066001)(47976001)(15975445006)(80022001)(54356001)(56816003)(83322001)(19580405001)(19580395003)(83072001)(49866001)(47736001)(4396001)(53806001)(74316001)(33646001)(74366001)(76786001)(76796001)(81816001)(77096001)(76576001)(65816001)(80976001)(87936001)(81342001)(74876001)(81542001)(63696002)(74662001)(2656002)(74502001)(87266001)(15202345003)(31966008)(74706001)(77982001)(51856001)(47446002)(76482001)(59766001)(81686001)(46102001)(85306002)(56776001)(551934002)(69226001)(54316002)(24736002)(579004)(569005); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.19; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail182-co9 (localhost.localdomain [127.0.0.1]) by mail182-co9 (MessageSwitch) id 1384451480604599_14108; Thu, 14 Nov 2013 17:51:20 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.232]) by mail182-co9.bigfish.com (Postfix) with ESMTP id 8F4D8D80071; Thu, 14 Nov 2013 17:51:20 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 14 Nov 2013 17:51:20 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 14 Nov 2013 17:51:17 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) with Microsoft SMTP Server (TLS) id 15.0.820.5; Thu, 14 Nov 2013 17:51:15 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) with mapi id 15.00.0820.005; Thu, 14 Nov 2013 17:51:15 +0000 From: Ken Gray To: "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5wAAT0kQAB+5vwAAC6NXAAAWgrqAABoVqAAAAJ6MAAAAVdUAAAAyXgAAAGINAAAAMxyAAANY0YAAAFBvSQ== Date: Thu, 14 Nov 2013 17:51:14 +0000 Message-ID: References: <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.19] x-forefront-prvs: 0030839EEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 17:51:30 -0000 +1 =0A= =0A= Fair-warning - I'm not a huge fan of a fan-out of interface definitions (ma= ny of which only seem to disappear in implementation because nobody really = was going to build anything so super-atomic).=0A= =0A= That said, from a practical perspective, a service function can operate on = a packet ... it can transform the packet ...I don't see how you can preclud= e this. In transforming the packet, it IS potentially altering the forward= ing on the egress side of the function - depending on the logic it used to = alter the packet. Unless we're proposing all of this sort of transformatio= n logic is going to suddenly be externalized for all service functions, the= n branching is logically going to happen - potentially driven by the servic= e function.=0A= =0A= Depending on how you do "fix-up" or whatever your company calls this handof= f, you involve (or don't) some additional actions in the forwarding compone= nt - implementation. So, we're arguing about implementation here in this t= hread, IMO. Yeah, go ahead and create your interface if it clarifies thing= s for you, but it's going to be a logical division and not a practical prot= ocol or API.=0A= =0A= Finally, without the possibility of branching (which was the fundamental qu= estion in the title, and we're straying away from it, IMO), you beg an enti= rely centralized control system (every chain, for every circumstance is pre= -defined). That too, IMO, is an implementation choice but it's enabled by = creating roof for it int he architecture. If you remove branching, you rem= ove the choice.=0A= =0A= My .02.=0A= ________________________________________=0A= From: nsc-bounces@ietf.org on behalf of Surendra Kum= ar (smkumar) =0A= Sent: Thursday, November 14, 2013 12:22 PM=0A= To: Jim Guichard (jguichar); Ron Parker=0A= Cc: nsc@ietf.org; Hongyu Li (Julio); David Allan I=0A= Subject: Re: [nsc] FW: re classification & branching, was: Current Propose= d SFC charter=0A= =0A= This separation is a very important architecture consideration IMO. Select= =0A= services can dictate the forwarding path at a higher level through the=0A= service path. Actual forwarding may be left to the forwarding components.= =0A= =0A= Surendra.=0A= =0A= On 11/14/13 7:46 AM, "Jim Guichard (jguichar)" wrote:= =0A= =0A= >Sure but architecturally the service function and forwarding components=0A= >are separate entities. Whether you choose to combine them in=0A= >implementation is your own choice.=0A= >=0A= >Sent from my iPhone=0A= >=0A= >> On Nov 14, 2013, at 10:40 AM, "Ron Parker"=0A= >> wrote:=0A= >>=0A= >> Jim,=0A= >>=0A= >> I think that could be an implementation decision. One implementation= =0A= >>approach is that the SFC IP-layer transport tunnels are known at the=0A= >>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently=0A= >>supported -- as an IP interface). Another possible approach is to=0A= >>handle the SFC IP-layer transport tunnels at a level above the=0A= >>forwarding layer (like the way GTP-U tunnels are frequently supported --= =0A= >>they are not represented as distinct IP interfaces).=0A= >>=0A= >> Ron=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=0A= >> Sent: Thursday, November 14, 2013 10:30 AM=0A= >> To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org=0A= >> Subject: Re: [nsc] FW: re classification & branching, was: Current=0A= >>Proposed SFC charter=0A= >>=0A= >> Hi Ron,=0A= >>=0A= >> I would not say that b modifies the transport header but rather b=0A= >>informs the forwarding component of it's intent so that it may insert=0A= >>the appropriate transport header to meet b's requirement.=0A= >>=0A= >>> On 11/14/13 10:24 AM, "Ron Parker" =0A= >>>wrote:=0A= >>>=0A= >>> Hi, Jim.=0A= >>>=0A= >>> I agree that forwarding is affected indirectly. Whether function b=0A= >>> forwards to function c or function d is accomplished by b correctly=0A= >>> adding (modifying) the transport header so that d is addressed or c is= =0A= >>> addressed. In the most general case of utilizing an IP-based=0A= >>>transport=0A= >>> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop= =0A= >>>is=0A= >>> not made at this level. The transport location (IP address) for c=0A= >>>and d=0A= >>> may or may not share the same next-hop based on the newtwork topology= =0A= >>> (i.e., c and/or d may or may not be on the same subnet as b, may or=0A= >>>may=0A= >>> not be reached via the same next hop router).=0A= >>>=0A= >>> Ron=0A= >>>=0A= >>>=0A= >>> -----Original Message-----=0A= >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of= =0A= >>> Jim Guichard (jguichar)=0A= >>> Sent: Thursday, November 14, 2013 10:14 AM=0A= >>> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org=0A= >>> Subject: Re: [nsc] FW: re classification & branching, was: Current=0A= >>> Proposed SFC charter=0A= >>>=0A= >>> I think it is misleading to say that a service function does not=0A= >>>impact=0A= >>> packet forwarding. If branching occurs then the service function does= =0A= >>> impact packet forwarding, whether directly or indirectly, as otherwise= =0A= >>> packets would not take the new path as a result of the branch. For=0A= >>> example, if the chain is a-b-c and b decides that for certain flows=0A= >>>the=0A= >>> traffic should go to d rather than c then it *must* force the=0A= >>> forwarding component to direct traffic to the new next-hop. While the= =0A= >>> service function may not modify forwarding in terms of updating=0A= >>> forwarding tables and so forth, it has to inform the forwarding=0A= >>> component of its intent somehow. Also, I think what you describe Dave= =0A= >>> is a bypass operation rather than a branch?=0A= >>>=0A= >>>> On 11/14/13 9:56 AM, "David Allan I" =0A= >>>>wrote:=0A= >>>>=0A= >>>> I think it is going to be a rare event, as what is more likely is the= =0A= >>>> front end of the chain is dynamically modified so subsequent packets= =0A= >>>> in a flow skip certain functions. Hence a graph more often than not=0A= >>>>is=0A= >>>> logically P2P. Facilitates testing amongst other benefits.=0A= >>>>=0A= >>>> As such I'd not want to be prescriptive as to how and where it is=0A= >>>> done....=0A= >>>>=0A= >>>> Dave=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com]=0A= >>>> Sent: Wednesday, November 13, 2013 6:30 PM=0A= >>>> To: David Allan I; nsc@ietf.org=0A= >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=0A= >>>> Proposed SFC charter=0A= >>>>=0A= >>>> Hi Dave,=0A= >>>>=0A= >>>> Your inferred restriction may be not always true. In general, service= =0A= >>>> functions should be able to compose a chain arbitrarily. Particularly= =0A= >>>> for branching, as I suggested in previous email, service function=0A= >>>> shall not directly impact packet forwarding. This precludes the=0A= >>>> restriction you mentioned. Forwarding plane can decide whether a=0A= >>>> branching action should be taken by reclassification or not per=0A= >>>>service chain.=0A= >>>>=0A= >>>> Does this make sense?=0A= >>>>=0A= >>>> Hongyu=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: David Allan I [mailto:david.i.allan@ericsson.com]=0A= >>>> Sent: Wednesday, November 13, 2013 11:45 PM=0A= >>>> To: Hongyu Li (Julio); nsc@ietf.org=0A= >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=0A= >>>> Proposed SFC charter=0A= >>>>=0A= >>>> HI Hongyu:=0A= >>>>=0A= >>>> I think we will have scenarios where a service function appears in=0A= >>>> more than one chain, as would be the case, for example, if some flows= =0A= >>>> could dynamically bypass DPI but still needed to transit a common set= =0A= >>>> of stateful service functions...=0A= >>>>=0A= >>>> Once you postulate a service function instance appearing in more than= =0A= >>>> one chain, it seems artificially restrictive not to permit such a=0A= >>>> function to also implement branching, all the control structures=0A= >>>>would=0A= >>>> already be there.=0A= >>>>=0A= >>>> Rgds=0A= >>>> Dave=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com]=0A= >>>> Sent: Wednesday, November 13, 2013 2:12 AM=0A= >>>> To: David Allan I; nsc@ietf.org=0A= >>>> Subject: RE: [nsc] FW: re classification & branching, was: Current=0A= >>>> Proposed SFC charter=0A= >>>>=0A= >>>> May I suggest summary of my views here:=0A= >>>>=0A= >>>> 1. Branch is a sort of use case or scenario, while reclassification=0A= >>>>is=0A= >>>> a way to solve the problem.=0A= >>>> 2. Service Functions should be decoupled with the chain itself.=0A= >>>> Meaning, a SF shall not *directly* impact the forwarding of=0A= >>>>packets=0A= >>>> in a chain. Branching should be performed by chain forwarding nodes,= =0A= >>>> possibly under control of a control node. The reason for this is in=0A= >>>> NFV world, service functions may come from a third party, while chain= =0A= >>>> is provided by the infrastructure of the network. There must be a=0A= >>>> cushion avoiding a service function operating infrastructure directly.= =0A= >>>> 3. (Re)classification is based on info in a packet.=0A= >>>> This is very general. Such info could be L2~L7 derived from a=0A= >>>>user's=0A= >>>> packet, as well as some info like metadata in a SFC header. As=0A= >>>> classification is out of scope of SFC, we don't have to provide too=0A= >>>> much details of how to do classification.=0A= >>>> 4. Chain segments stitching is relatively a easy way for branching.=0A= >>>> Compared with chains and subchains, which may require a more complex= =0A= >>>> header and forwarding capabilities.=0A= >>>> My two cents.=0A= >>>> Hongyu=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of= =0A= >>>> David Allan I=0A= >>>> Sent: Wednesday, November 13, 2013 3:04 AM=0A= >>>> To: nsc@ietf.org=0A= >>>> Subject: [nsc] FW: re classification & branching, was: Current=0A= >>>> Proposed SFC charter=0A= >>>>=0A= >>>> Hi:=0A= >>>> (resend with recipient list cleaned up)=0A= >>>>=0A= >>>> I agree we are discussing multiple concepts, classification and=0A= >>>> flow-subsetting. Perhaps more ;-)=0A= >>>>=0A= >>>> Defining a flow subset can be a result of classification, but it is=0A= >>>> not the exclusive mechanism. Branching is a mechanism by which flow=0A= >>>> subsets are exposed and mapped to a set of subchains such that it can= =0A= >>>> be identified in the dataplane...=0A= >>>>=0A= >>>> That's the view from here=0A= >>>> Dave=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of= =0A= >>>> David Lake (dlake)=0A= >>>> Sent: Tuesday, November 12, 2013 10:51 AM=0A= >>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar);=0A= >>>>Ron=0A= >>>> Parker; Linda Dunbar; Hongyu Li (Julio)=0A= >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>=0A= >>>> Understood - maybe just a little localised warming of the sea then ?= =0A= >>>> But I still think we need to consider where and how policy is=0A= >>>> defined/set even for the single-domain instance.=0A= >>>>=0A= >>>> I don't think we can assume that any L1-3 device will be able to=0A= >>>> determine much useful information from the data-plane.=0A= >>>>=0A= >>>> -----Original Message-----=0A= >>>> From: Jim Guichard (jguichar)=0A= >>>> Sent: 12 November 2013 10:44=0A= >>>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron=0A= >>>> Parker; Linda Dunbar; Hongyu Li (Julio)=0A= >>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>=0A= >>>> As discussed during the BOF our initial work is single administrative= =0A= >>>> domain for some of the very reasons you point out. We need to keep=0A= >>>> focused without trying to boil the ocean right off the bat.=0A= >>>>=0A= >>>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote:=0A= >>>>>=0A= >>>>> Exactly. But how can network-components "terminate" an application= =0A= >>>>>????=0A= >>>>>=0A= >>>>> I think we need a good understanding of a recursive policy mechanism= =0A= >>>>> (recursive because a user-land application will ride with a specific= =0A= >>>>> policy across potentially different sets of carrier policies).=0A= >>>>>=0A= >>>>> I hate to bring this up now, but we also need to think about this=0A= >>>>> multi-domain issue - if I set a policy as a user, chances are I will= =0A= >>>>> be crossing several domain boundaries. Are we expecting the service= =0A= >>>>> headers to define the service chaining for the duration of the=0A= >>>>>entire=0A= >>>>> flow across all domains, or just across a single one ?=0A= >>>>>=0A= >>>>> In which case, do I have to re-set policy as I traverse domains and= =0A= >>>>> where does that policy get set ? It would be much better to set=0A= >>>>>policy=0A= >>>>> once based on L5-7 needs, and have that instantiated across the=0A= >>>>> multiple domains.=0A= >>>>>=0A= >>>>> Again, this appears to be outside the scope of SFC, but pretty=0A= >>>>> relevant to how it would operate in the real world.=0A= >>>>>=0A= >>>>> David=0A= >>>>>=0A= >>>>> -----Original Message-----=0A= >>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=0A= >>>>> Sent: 12 November 2013 10:27=0A= >>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda= =0A= >>>>> Dunbar; Hongyu Li (Julio)=0A= >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>=0A= >>>>>> In those circumstances, only the end applications themselves or a=0A= >>>>>> reasonably broad-brushed classification (really traffic steering=0A= >>>>>> based on what we can see at ingress) is going to be useful - is=0A= >>>>>> THAT what we're aiming for here ?=0A= >>>>>=0A= >>>>> I would certainly hope not, but that has been my concern as well.=0A= >>>>> Application layer termination and re-classification seems a must?=0A= >>>>>=0A= >>>>> -- Kevin J. Ma=0A= >>>>>=0A= >>>>>> -----Original Message-----=0A= >>>>>> From: David Lake (dlake) [mailto:dlake@cisco.com]=0A= >>>>>> Sent: Tuesday, November 12, 2013 1:00 PM=0A= >>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;= =0A= >>>>>> Hongyu Li (Julio)=0A= >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>=0A= >>>>>> Policy may be outside of the scope of SFC, but without strong=0A= >>>>>> mapping between Policy and the inserted Service Header(s), we=0A= >>>>>> run-the-risk of limiting the efficacy of the protocol IMO.=0A= >>>>>>=0A= >>>>>> For example, in a world where the network has "gone dark," (as per= =0A= >>>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine= =0A= >>>>>> policy based on DPI of packets-in-flight ?=0A= >>>>>>=0A= >>>>>> In those circumstances, only the end applications themselves or a=0A= >>>>>> reasonably broad-brushed classification (really traffic steering=0A= >>>>>> based on what we can see at ingress) is going to be useful - is=0A= >>>>>> THAT what we're aiming for here ?=0A= >>>>>>=0A= >>>>>> David=0A= >>>>>>=0A= >>>>>> -----Original Message-----=0A= >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf= =0A= >>>>>> Of Surendra Kumar (smkumar)=0A= >>>>>> Sent: 12 November 2013 09:26=0A= >>>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio)=0A= >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>=0A= >>>>>> Ron,=0A= >>>>>>=0A= >>>>>> Classification of traffic is well understood and we do not have to= =0A= >>>>>> redefine it - it's been around for all the time middle boxes have=0A= >>>>>> been or for that matter the L2/L3 devices. All we are talking about= =0A= >>>>>> is the applicability of the classification to branching in SFC.=0A= >>>>>>=0A= >>>>>> You are right, it is all about policy which is outside the scope of= =0A= >>>>>> SFC.=0A= >>>>>>=0A= >>>>>> Surendra.=0A= >>>>>>=0A= >>>>>> On 11/12/13 7:53 AM, "Ron Parker" = =0A= >>>>>> wrote:=0A= >>>>>>=0A= >>>>>>> I think the lack of definition of "reclassification" may be=0A= >>>>>>> causing=0A= >>>>>> some=0A= >>>>>>> misunderstandings here. A branch would occur for some=0A= >>>>>> policy-driven=0A= >>>>>>> reason based on the behavior and conclusions of the service=0A= >>>>>>>function,=0A= >>>>>>> itself. The graph would represent the fact that there is a branch= =0A= >>>>>>> point, but the service function, itself, being aware that it is a= =0A= >>>>>>> branching point would contain the policy and logic to decide on=0A= >>>>>>>which=0A= >>>>>>> branch to take. Specifying that policy and logic is out of scope,= =0A= >>>>>> IMO.=0A= >>>>>>>=0A= >>>>>>> Ron=0A= >>>>>>>=0A= >>>>>>>=0A= >>>>>>> -----Original Message-----=0A= >>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=0A= >>>>>>> Sent: Tuesday, November 12, 2013 10:49 AM=0A= >>>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio)=0A= >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>>>>>> Sumandra Majee=0A= >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>=0A= >>>>>>> Hi Linda,=0A= >>>>>>>=0A= >>>>>>> Are you saying that a branching point is "never" a=0A= >>>>>>> reclassification point, or are you saying that a branching point=0A= >>>>>> "does not have to be"=0A= >>>>>>> a reclassification point?=0A= >>>>>>>=0A= >>>>>>> I think this is an important distinction that needs to be=0A= >>>>>> clarified.=0A= >>>>>>> If branching is never reclassification, then the meaning of a=0A= >>>>>>> chain is different than I originally inferred. If the chain is a= =0A= >>>>>>> tree with other "branching" points in it, then that limits the=0A= >>>>>>> scope of the problem statement goals.=0A= >>>>>>>=0A= >>>>>>> While this could be a degenerate case, and any implementation=0A= >>>>>>> could define bad service chains, is it the intent of SFC to only=0A= >>>>>>> look at the simpler packet-level classification cases, or is it=0A= >>>>>>> the intent to consider the case where a branching point is viewed= =0A= >>>>>>> as a re-classification point?=0A= >>>>>>>=0A= >>>>>>> thanx.=0A= >>>>>>>=0A= >>>>>>> -- Kevin J. Ma=0A= >>>>>>>=0A= >>>>>>>> -----Original Message-----=0A= >>>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= >>>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM=0A= >>>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma=0A= >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>>>>>>> Sumandra Majee=0A= >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>>=0A= >>>>>>>> Ron,=0A= >>>>>>>>=0A= >>>>>>>> First, want to make it clear that "branching" !=3D=0A= >>>>>>>> reclassification, agree?=0A= >>>>>>>>=0A= >>>>>>>> Second, the representation of branching (or service graph) can=0A= >>>>>>>> be in a form of logic on a service function. Some service=0A= >>>>>>>> functions, especially L7 based, can use value in a Database to=0A= >>>>>>>> determine what is the next service function.=0A= >>>>>>>>=0A= >>>>>>>> Linda=0A= >>>>>>>>=0A= >>>>>>>>> -----Original Message-----=0A= >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>>>>>>>> Behalf Of Ron Parker=0A= >>>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM=0A= >>>>>>>>> To: Hongyu Li (Julio); Kevin J Ma=0A= >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>>>>>>>> Sumandra Majee=0A= >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>=0A= >>>>>>>>> Hongyu,=0A= >>>>>>>>>=0A= >>>>>>>>> I agree completely that re-classification is not limited to DPI.= =0A= >>>>>>>>>=0A= >>>>>>>>> And also, that an area for us to explore as a group is how to=0A= >>>>>>>> represent=0A= >>>>>>>>> the service graph. Do we want to represent it as a proper graph= =0A= >>>>>> with=0A= >>>>>>>>> an adjacency list or other representational model? Or, do we=0A= >>>>>> want=0A= >>>>>> to=0A= >>>>>>>>> represent it as a set of linear segments and if so, how are the= =0A= >>>>>>>>> segments connected into a graph? Other ideas?=0A= >>>>>>>>>=0A= >>>>>>>>> Ron=0A= >>>>>>>>>=0A= >>>>>>>>>=0A= >>>>>>>>> -----Original Message-----=0A= >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>>>>>>>> Behalf Of Hongyu Li (Julio)=0A= >>>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM=0A= >>>>>>>>> To: Ron Parker; Kevin J Ma=0A= >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>>>>>>>> Sumandra Majee=0A= >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>=0A= >>>>>>>>> Branching/forking is a very interesting topic of SFC. About=0A= >>>>>>>>> the=0A= >>>>>>>>> re- classification point, probably we shall not limit it to DPI.= =0A= >>>>>>>>> It is also possible that packets go to different branches=0A= >>>>>>>>> after been processed by a certain service function, decision=0A= >>>>>>>>> of which branches to go is made based on the result of service=0A= >>>>>>>>> function's process, i.e. not just re- classification by DPI.=0A= >>>>>>>>>=0A= >>>>>>>>> Hongyu=0A= >>>>>>>>>=0A= >>>>>>>>> -----Original Message-----=0A= >>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>>>>>>>> Behalf Of Ron Parker=0A= >>>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM=0A= >>>>>>>>> To: Kevin J Ma=0A= >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>>>>>>>> Sumandra Majee=0A= >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>=0A= >>>>>>>>> Hi, Kevin=0A= >>>>>>>>>=0A= >>>>>>>>> You ask a great question about branching the graph. The=0A= >>>>>>>>> details around how to convey the selection of the=0A= >>>>>>>>> subtree/subgraph are still=0A= >>>>>>>> to be=0A= >>>>>>>>> defined. Is it one chain id for the whole graph? Does each=0A= >>>>>> branch=0A= >>>>>>>>> have its own chain id? Some combination?=0A= >>>>>>>>>=0A= >>>>>>>>> Ron=0A= >>>>>>>>>=0A= >>>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma"=0A= >>>>>>>>> =0A= >>>>>>>>> wrote:=0A= >>>>>>>>>=0A= >>>>>>>>>>> Yes, reclassification can change the service path and=0A= >>>>>>>>>>> re-classification may happen at any node along a service path.= =0A= >>>>>>>>>>=0A= >>>>>>>>>> Just to expand on that, going back to the original question=0A= >>>>>>>>>> about service header encapsulation, is it intended that a=0A= >>>>>>>>>> chain that is re-classified will get a new chain ID which=0A= >>>>>>>>>> fully describes a chain that is a superset of the original=0A= >>>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming=0A= >>>>>>>>>> the goal is "a single chain ID that is commonly understood=0A= >>>>>>>>>> along the entire service=0A= >>>>>> chain"=0A= >>>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht=0A= >>>>>>>>>> m=0A= >>>>>>>>>> l=0A= >>>>>>>>>> )=0A= >>>>>>>>>>=0A= >>>>>>>>>> And the applicable subset of the permutative list of service=0A= >>>>>>>>>> paths would be configured at each appropriate service node?=0A= >>>>>>>>>> e.g., ID 1: NAT + firewall + DPI=0A= >>>>>>>>>> ID 2: NAT + firewall + DPI + AV=0A= >>>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT=0A= >>>>>>>>>> ID 4: NAT + firewall + DPI + NAT=0A= >>>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB=0A= >>>>>>>>>> ID 6: NAT + firewall + DPI + LB=0A= >>>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE=0A= >>>>>>>>>> ID 8: NAT + firewall + DPI + CACHE=0A= >>>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB=0A= >>>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE=0A= >>>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would=0A= >>>>>>>>>> every flow then be initially classified as ID 1, but=0A= >>>>>>>>>> eventually get re-=0A= >>>>>>>>> classified=0A= >>>>>>>>>> to ID 2-11, after the DPI phase?=0A= >>>>>>>>>>=0A= >>>>>>>>>> thanx.=0A= >>>>>>>>>>=0A= >>>>>>>>>> -- Kevin J. Ma=0A= >>>>>>>>>>=0A= >>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=0A= >>>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM=0A= >>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=0A= >>>>>>>>>>> nsc@ietf.org=0A= >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>=0A= >>>>>>>>>>>=0A= >>>>>>>>>>>=0A= >>>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma"=0A= >>>>>>>>>>>> =0A= >>>>>>>> wrote:=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Hi Surendra,=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Classification may be out of scope, but the level of=0A= >>>>>>>>>>>> service that=0A= >>>>>>>>> is=0A= >>>>>>>>>>>> applicable is dependent upon the level of classification=0A= >>>>>>>>>>>> that can=0A= >>>>>>>>> be=0A= >>>>>>>>>>>> performed. An assumption of packet level encapsulation=0A= >>>>>>>>>>>> has=0A= >>>>>>>>>>> implications=0A= >>>>>>>>>>>> on the level of classification being performed? If the=0A= >>>>>>>>>>>> stated=0A= >>>>>>>>> goals=0A= >>>>>>>>>>> are=0A= >>>>>>>>>>>> for firewall and load balancer functionality, then the=0A= >>>>>>>>>>>> application=0A= >>>>>>>>>>> level=0A= >>>>>>>>>>>> nature of those functions needs to be taken into account?=0A= >>>>>>>>>>>> If, on the other hand, the service function scope is=0A= >>>>>>>>>>>> limited due to limitations in classification, that would=0A= >>>>>>>>>>>> be and important piece of=0A= >>>>>>>>> information?=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases=0A= >>>>>>>>>>>> the fork points of the service paths seem like=0A= >>>>>>>>>>>> re-classification=0A= >>>>>> points?=0A= >>>>>>>>>>>> Is that the interpretation from the architecture perspective?= =0A= >>>>>>>>>>>> Or is the service function chain classification exclusive=0A= >>>>>>>>>>>> of DPI=0A= >>>>>>>>> functionality?=0A= >>>>>>>>>>> I have not fully read that draft yet. But in general,=0A= >>>>>>>>>>> as described in the arch draft, the collection of services=0A= >>>>>>>>>>> form a graph, segments of which are service paths. Yes,=0A= >>>>>>>>>>> reclassification can=0A= >>>>>>>>> change=0A= >>>>>>>>>>> the service path and re-classification may happen at any=0A= >>>>>>>>>>> node along=0A= >>>>>>>>> a service path.=0A= >>>>>>>>>>>=0A= >>>>>>>>>>> Surendra.=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> thanx.=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>> -- Kevin J. Ma=0A= >>>>>>>>>>>>=0A= >>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=0A= >>>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM=0A= >>>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas=0A= >>>>>>>>>>>>> Narten; nsc@ietf.org=0A= >>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>> Kevin,=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It=0A= >>>>>>>>>>>>> can be based=0A= >>>>>>>>>>> on=0A= >>>>>>>>>>>>> the packet or information not in the packet(environmental=0A= >>>>>>>>>>>>> attributes=0A= >>>>>>>>>>> for=0A= >>>>>>>>>>>>> instance) or a combination thereof. What is important is=0A= >>>>>>>>>>>>> that such classification aids in traffic selection and=0A= >>>>>>>>>>>>> service path identification.=0A= >>>>>>>>>>>>> It is no different from a policy in this regard except=0A= >>>>>>>>>>>>> that the policy now specifies the service path.=0A= >>>>>>>>>>>>> Further, classification is not limited to the network=0A= >>>>>>>>>>>>> elements but the service functions as well. Some of this=0A= >>>>>>>>>>>>> is described in the=0A= >>>>>>>>>>> architecture=0A= >>>>>>>>>>>>> drafts as well -=0A= >>>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/".=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>> Surendra.=0A= >>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma"=0A= >>>>>>>>>>>>>> =0A= >>>>>>>>> wrote:=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> Hi Ron,=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with=0A= >>>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in=0A= >>>>>>>>>>>>>> section=0A= >>>>>>>>>>>>>> 2 of the=0A= >>>>>>>>> problem=0A= >>>>>>>>>>>>>> statement:=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification=0A= >>>>>>>>>>>>>> occurs at=0A= >>>>>>>>> each=0A= >>>>>>>>>>>>>> service, independent from previously applied=0A= >>>>>>>>>>>>>> service=0A= >>>>>>>>>>>>> functions.=0A= >>>>>>>>>>>>>> These unrelated classification events consume=0A= >>>>>>>>>>>>>> resources=0A= >>>>>>>>> per=0A= >>>>>>>>>>>>>> service. More importantly, the classification=0A= >>>>>>>>> functionality=0A= >>>>>>>>>>>>>> often differs per service function and service=0A= >>>>>>>>>>>>>> function=0A= >>>>>>>>>>> cannot=0A= >>>>>>>>>>>>>> leverage the results from other deployed network=0A= >>>>>>>>>>>>>> or=0A= >>>>>>>>> service.=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> as it relates to section 5.2 of the framework document:=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> The SFC Classifier classifies packets based on (some=0A= >>>>>>>>>>>>>> of) the=0A= >>>>>>>>>>>>> contents=0A= >>>>>>>>>>>>>> of the packet header. Concretely, it classifies=0A= >>>>>>>>>>>>>> packets based on=0A= >>>>>>>>>>>>> the=0A= >>>>>>>>>>>>>> possible combination of one or more header fields,=0A= >>>>>>>>>>>>>> such as=0A= >>>>>>>>> source=0A= >>>>>>>>>>>>>> address, destination address, DS field, protocol ID,=0A= >>>>>>>>>>>>>> source=0A= >>>>>>>>> port=0A= >>>>>>>>>>>>> and=0A= >>>>>>>>>>>>>> destination port numbers, and any other information.=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> A packet-based classifier as described in the framework=0A= >>>>>>>>>>>>>> document=0A= >>>>>>>>>>>>> would=0A= >>>>>>>>>>>>>> seem to be limited in what it can classify? The service=0A= >>>>>>>>>>>>>> function identifier lookup does not seem to be a=0A= >>>>>>>>>>>>>> significant optimization=0A= >>>>>>>>>>> over=0A= >>>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some=0A= >>>>>>>>>>>>>> missing=0A= >>>>>>>>>>> detail=0A= >>>>>>>>>>>>>> wrt how classification information is determined and=0A= >>>>>> reused?=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP=0A= >>>>>>>>>>>>>> and TLS=0A= >>>>>>>>>>>>> encrypted=0A= >>>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I=0A= >>>>>>>>>>>>>> was also=0A= >>>>>>>>>>>>> wondering=0A= >>>>>>>>>>>>>> how independent HLS segment requests might be classified=0A= >>>>>>>>>>>>>> and=0A= >>>>>>>>>>>>> associated?=0A= >>>>>>>>>>>>>> Were these types of use cases discussed in the BoF?=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> thanx.=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>> -- Kevin J. Ma=0A= >>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=0A= >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf=0A= >>>>>>>>>>> Of=0A= >>>>>>>>>>>>>>> Ron=0A= >>>>>>>>>>>>>>> Parker=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM=0A= >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Sumandra,=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> As was discussed in Vancouver, there are already many=0A= >>>>>>>>>>>>>>> existing ways=0A= >>>>>>>>>>>>> to=0A= >>>>>>>>>>>>>>> accomplish service chaining. But none of them provide= =0A= >>>>>> a=0A= >>>>>>>>>>>>> sufficient=0A= >>>>>>>>>>>>>>> combination of interoperability, flexibility, and=0A= >>>>>> resiliency.=0A= >>>>>>>>> A=0A= >>>>>>>>>>>>> single=0A= >>>>>>>>>>>>>>> service chain encapsulation will go a long way to=0A= >>>>>>>>>>>>>>> ensuring these=0A= >>>>>>>>>>>>> goals.=0A= >>>>>>>>>>>>>>> It may not be the absolutely most efficient approach=0A= >>>>>>>>>>>>>>> for every=0A= >>>>>>>>>>>>> single=0A= >>>>>>>>>>>>>>> network topology and every single use case, but its=0A= >>>>>>>>>>>>>>> ubiquitous=0A= >>>>>>>>>>> nature=0A= >>>>>>>>>>>>>>> should improve its adoption.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Ron=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM=0A= >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Ron,=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation.= =0A= >>>>>>>>>>>>>>> However=0A= >>>>>>>>>>>>> this=0A= >>>>>>>>>>>>>>> could be augmented with classification result, again=0A= >>>>>>>>>>>>>>> one more=0A= >>>>>>>>>>>>> example.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily=0A= >>>>>>>>>>>>>>>>> follow=0A= >>>>>>>>> the=0A= >>>>>>>>>>>>> same=0A= >>>>>>>>>>>>>>> chain.=0A= >>>>>>>>>>>>>>> Correct. It is also not necessary that all transaction=0A= >>>>>>>>>>>>>>> of the same=0A= >>>>>>>>>>>>> flow=0A= >>>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself.= =0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Again the point here is that do we always need SFC=0A= >>>>>>>>>>>>>>> header or=0A= >>>>>>>> Not.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Sumandra=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: Ron Parker=0A= >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com]=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM=0A= >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Sumandra,=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> The intention of service function chaining is to allow=0A= >>>>>>>>>>>>>>> for operation=0A= >>>>>>>>>>>>> at=0A= >>>>>>>>>>>>>>> the fully qualified flow level, or even finer grained=0A= >>>>>>>>>>>>>>> at the=0A= >>>>>>>>>>>>> transaction=0A= >>>>>>>>>>>>>>> level (this is an implementation matter for the PDP).=0A= >>>>>> All=0A= >>>>>>>>> flows=0A= >>>>>>>>>>>>> from=0A= >>>>>>>>>>>>>>> the same source IP do not necessarily follow the same=0A= >>>>>> chain.=0A= >>>>>>>>>>> Source=0A= >>>>>>>>>>>>>>> IP,=0A= >>>>>>>>>>>>>>> therefore, does not identify the chain ID. Another=0A= >>>>>>>> intention=0A= >>>>>>>>> of=0A= >>>>>>>>>>>>>>> service function chaining is to operate over any=0A= >>>>>>>>>>>>>>> network=0A= >>>>>>>>> topology=0A= >>>>>>>>>>> and=0A= >>>>>>>>>>>>>>> not=0A= >>>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part= =0A= >>>>>> of=0A= >>>>>>>>> the=0A= >>>>>>>>>>>>>>> transport, it does not adequately identify the service=0A= >>>>>>>>>>>>>>> chain,=0A= >>>>>>>>>>> either.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Ron=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM=0A= >>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Ron,=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> The service header is meant to carry the context which=0A= >>>>>>>>>>>>>>> can=0A= >>>>>>>>> *also*=0A= >>>>>>>>>>>>>>> be derived (for example use source ip and vlan to=0A= >>>>>>>>>>>>>>> identify chainID and=0A= >>>>>>>>>>>>>>> position) or encapsulated as part of another tunnel=0A= >>>>>> header.=0A= >>>>>>>>>>>>>>> So this could be optional IMHO.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: Ron Parker=0A= >>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com]=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM=0A= >>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Sumandra,=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP=0A= >>>>>>>>>>>>>>> to SF or from=0A= >>>>>>>>>>>>> SF=0A= >>>>>>>>>>>>>>> to=0A= >>>>>>>>>>>>>>> SF will look like:=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> +------------------------+=0A= >>>>>>>>>>>>>>> | "transport" |=0A= >>>>>>>>>>>>>>> +------------------------+=0A= >>>>>>>>>>>>>>> | service header |=0A= >>>>>>>>>>>>>>> +------------------------+=0A= >>>>>>>>>>>>>>> | original IP header |=0A= >>>>>>>>>>>>>>> +------------------------+=0A= >>>>>>>>>>>>>>> | | original=0A= >>>>>>>>>>>>>>> | IP payload=0A= >>>>>>>>> |=0A= >>>>>>>>>>>>>>> | |=0A= >>>>>>>>>>>>>>> +------------------------+=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Where service header contains, at a minimum, enough=0A= >>>>>>>>>>>>>>> information to=0A= >>>>>>>>>>>>> allow=0A= >>>>>>>>>>>>>>> the packet to be propagated along the full length of=0A= >>>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances=0A= >>>>>>>>>>>>>>> the operation of=0A= >>>>>>>>> one=0A= >>>>>>>>>>>>>>> or=0A= >>>>>>>>>>> more=0A= >>>>>>>>>>>>>>> service functions.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> And where "transport" could conceivably be any of, but=0A= >>>>>>>>>>>>>>> not limited=0A= >>>>>>>>>>>>> to:=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> * Ethernet=0A= >>>>>>>>>>>>>>> * Ethernet + LLC2=0A= >>>>>>>>>>>>>>> * Ethernet + MPLS=0A= >>>>>>>>>>>>>>> * Ethernet + IP + GRE=0A= >>>>>>>>>>>>>>> * Ethernet + IP +UDP=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to=0A= >>>>>>>>>>>>>>> imply immutability, but rather to specify the packet=0A= >>>>>>>>>>>>>>> that is=0A= >>>>>>>>> propagated=0A= >>>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to=0A= >>>>>>>>>>>>>>> encapsulation.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Ron=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=0A= >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf=0A= >>>>>>>>>>> Of=0A= >>>>>>>>>>>>>>> Sumandra Majee=0A= >>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM=0A= >>>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A=0A= >>>>>>>>>>>>>>> document=0A= >>>>>>>> will=0A= >>>>>>>>>>>>>>> describe the single service-level data plane=0A= >>>>>>>>>>>>>>> encapsulation=0A= >>>>>>>>>>> format=0A= >>>>>>>>>>>>>>> for=0A= >>>>>>>>>>>>>>> conveying the service function chain and the service=0A= >>>>>>>>>>>>>>> function=0A= >>>>>>>>>>>>> path,=0A= >>>>>>>>>>>>>>> and for communicating context information between=0A= >>>>>>>>>>>>>>> nodes=0A= >>>>>> that=0A= >>>>>>>>>>>>>>> implement service functions. It is intended that the=0A= >>>>>>>>>>>>> encapsulation=0A= >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=0A= >>>>>>>>>>>>>>> the service=0A= >>>>>>>>>>>>> that=0A= >>>>>>>>>>>>>>> is=0A= >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=0A= >>>>>>>>>>>>>>> may be=0A= >>>>>>>>> used=0A= >>>>>>>>>>> on=0A= >>>>>>>>>>>>>>> a service function path realized at the network=0A= >>>>>>>>>>>>>>> layer or at any other=0A= >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the=0A= >>>>>>>>>>> construction=0A= >>>>>>>>>>>>> of=0A= >>>>>>>>>>>>>>> service function paths regardless of the actual=0A= >>>>>> service.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> [SM] What does it mean by a single service-level=0A= >>>>>>>>>>>>>>> encapsulation,=0A= >>>>>>>>> a=0A= >>>>>>>>>>>>> new=0A= >>>>>>>>>>>>>>> encapsulation format=0A= >>>>>>>>>>>>>>> or an ability to select one encapsulation=0A= >>>>>>>>>>>>>>> format that=0A= >>>>>>>>>>>>> fits=0A= >>>>>>>>>>>>>>> the=0A= >>>>>>>>>>>>>>> need for a given service chain?=0A= >>>>>>>>>>>>>>> The ability to select a specific=0A= >>>>>>>>>>>>>>> encapsulation would be=0A= >>>>>>>>>>> a=0A= >>>>>>>>>>>>>>> management plane decision.=0A= >>>>>>>>>>>>>>> There are quite a few existing encapsulation=0A= >>>>>>>>>>>>>>> methods that=0A= >>>>>>>>>>>>> can=0A= >>>>>>>>>>>>>>> possibly be reused to provide=0A= >>>>>>>>>>>>>>> context information between service nodes. I=0A= >>>>>> have=0A= >>>>>>>>> seen=0A= >>>>>>>>>>>>>>> mention=0A= >>>>>>>>>>>>>>> of GRE, for HTTP based=0A= >>>>>>>>>>>>>>> applications contexts are transferred via=0A= >>>>>> headers.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> -----Original Message-----=0A= >>>>>>>>>>>>>>> From: nsc-bounces@ietf.org=0A= >>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf=0A= >>>>>>>>>>> Of=0A= >>>>>>>>>>>>>>> Thomas Narten=0A= >>>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM=0A= >>>>>>>>>>>>>>> To: nsc@ietf.org=0A= >>>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Hi.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Current charter can be found at=0A= >>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter-=0A= >>>>>>>>>>>>>>> ietf-sfc/.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> It contains the revised management text as well as=0A= >>>>>>>>>>>>>>> updated=0A= >>>>>>>>>>>>> milestones.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> All known issues have been addressed. If there are any=0A= >>>>>>>>>>>>>>> remaining=0A= >>>>>>>>>>>>> issues,=0A= >>>>>>>>>>>>>>> please speak up!=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Networks, servers, storage technologies, and=0A= >>>>>>>>>>>>>>> applications, have all undergone significant change in=0A= >>>>>>>>>>>>>>> recent years with the introduction=0A= >>>>>>>>>>> of=0A= >>>>>>>>>>>>>>> virtualization, network overlays, and orchestration.=0A= >>>>>>>>>>>>>>> Service=0A= >>>>>>>>>>> delivery=0A= >>>>>>>>>>>>> is=0A= >>>>>>>>>>>>>>> currently both a technical and organizational challenge=0A= >>>>>>>>>>>>>>> that=0A= >>>>>>>>>>> involves=0A= >>>>>>>>>>>>>>> significant modification to the network configuration.=0A= >>>>>>>>>>>>>>> Services are typically implemented by the ordered=0A= >>>>>>>>>>>>>>> combination of a number of service functions that are=0A= >>>>>>>>>>>>>>> deployed at different points within=0A= >>>>>>>>>>> the=0A= >>>>>>>>>>>>>>> network. Today, a common deployment model has service=0A= >>>>>>>>>>>>>>> functions physically inserted on the data forwarding=0A= >>>>>>>>>>>>>>> path between communicating peers.=0A= >>>>>>>>>>>>> Going=0A= >>>>>>>>>>>>>>> forward, however, there is a desire to move to a=0A= >>>>>>>>>>>>>>> different model,=0A= >>>>>>>>>>>>> where=0A= >>>>>>>>>>>>>>> service functions are not required to reside on the=0A= >>>>>>>>>>>>>>> default data=0A= >>>>>>>>>>> path=0A= >>>>>>>>>>>>>>> and=0A= >>>>>>>>>>>>>>> traffic is instead steered through services, wherever=0A= >>>>>>>>>>>>>>> they are=0A= >>>>>>>>>>>>> deployed.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> For a given service, the abstracted view of the=0A= >>>>>>>>>>>>>>> required service functions and the order in which they=0A= >>>>>>>>>>>>>>> are to be applied is=0A= >>>>>>>>> called=0A= >>>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service=0A= >>>>>>>>>>>>>>> function may be available on more than one node within=0A= >>>>>>>>>>>>>>> a network, a Service Function Chain is instantiated=0A= >>>>>>>>>>>>> via=0A= >>>>>>>>>>>>>>> the selection of specific service function instances=0A= >>>>>>>>>>>>>>> and the network nodes on which they are provided,=0A= >>>>>>>>>>>>>>> thereby forming a service topology:=0A= >>>>>>>>>>>>>>> this is called a Service Function Path. The service=0A= >>>>>>>>>>>>>>> functions=0A= >>>>>>>>> may=0A= >>>>>>>>>>>>>>> be applied at a specific layer within the network=0A= >>>>>>>>>>>>>>> protocol stack=0A= >>>>>>>>>>>>> (network=0A= >>>>>>>>>>>>>>> layer, application layer, etc.).=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will=0A= >>>>>>>>>>>>>>> develop new approaches to service delivery and deployment.= =0A= >>>>>>>>>>>>>>> It will produce a framework for service function=0A= >>>>>>>>>>>>>>> chaining that includes the necessary protocols=0A= >>>>>>>>>>>>> or=0A= >>>>>>>>>>>>>>> protocol extensions to convey the service path and=0A= >>>>>>>>>>>>>>> service path information to nodes that implement=0A= >>>>>>>>>>>>>>> service functions, as well=0A= >>>>>>>>> as=0A= >>>>>>>>>>>>>>> mechanisms for steering traffic through service functions.= =0A= >>>>>>>>>>>>>>> The=0A= >>>>>>>>>>>>> working=0A= >>>>>>>>>>>>>>> group will also examine what information needs to be=0A= >>>>>>>>>>>>>>> gathered from=0A= >>>>>>>>>>>>> the=0A= >>>>>>>>>>>>>>> network and service functions in support of service=0A= >>>>>>>>>>>>>>> function=0A= >>>>>>>>>>> chaining=0A= >>>>>>>>>>>>>>> and=0A= >>>>>>>>>>>>>>> how that information may be made available to nodes=0A= >>>>>>>>>>>>>>> that implement=0A= >>>>>>>>>>>>> the=0A= >>>>>>>>>>>>>>> service functions.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the=0A= >>>>>> following:=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> 1) Problem Statement: This document will provide a=0A= >>>>>>>>>>>>>>> summary of=0A= >>>>>>>>> the=0A= >>>>>>>>>>>>>>> problem space to be addressed by the WG including=0A= >>>>>>>>>>>>>>> example=0A= >>>>>>>>> high-=0A= >>>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize=0A= >>>>>>>>>>> nomenclature=0A= >>>>>>>>>>>>>>> and definitions for service function chaining.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> 2) Architecture: This document will provide a=0A= >>>>>>>>>>>>>>> description of=0A= >>>>>>>> the=0A= >>>>>>>>>>>>>>> architectural building blocks and their=0A= >>>>>>>>>>>>>>> relationships=0A= >>>>>>>>> including=0A= >>>>>>>>>>>>>>> interconnection, placement of capabilities, management,= =0A= >>>>>>>>>>>>>>> diagnostics, design analysis, and security models,=0A= >>>>>>>>>>>>>>> as well=0A= >>>>>>>> as=0A= >>>>>>>>>>>>>>> requirements on the protocol mechanisms.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A=0A= >>>>>>>>>>>>>>> document=0A= >>>>>>>>> will=0A= >>>>>>>>>>>>>>> describe the single service-level data plane=0A= >>>>>>>>>>>>>>> encapsulation=0A= >>>>>>>>>>> format=0A= >>>>>>>>>>>>>>> for=0A= >>>>>>>>>>>>>>> conveying the service function chain and the service=0A= >>>>>>>>>>>>>>> function=0A= >>>>>>>>>>>>> path,=0A= >>>>>>>>>>>>>>> and for communicating context information between=0A= >>>>>>>>>>>>>>> nodes=0A= >>>>>> that=0A= >>>>>>>>>>>>>>> implement service functions. It is intended that the=0A= >>>>>>>>>>>>> encapsulation=0A= >>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and=0A= >>>>>>>>>>>>>>> the service=0A= >>>>>>>>>>>>> that=0A= >>>>>>>>>>>>>>> is=0A= >>>>>>>>>>>>>>> being constructed. That is, the same encapsulation=0A= >>>>>>>>>>>>>>> may be=0A= >>>>>>>>> used=0A= >>>>>>>>>>> on=0A= >>>>>>>>>>>>>>> a service function path realized at the network=0A= >>>>>>>>>>>>>>> layer or at any other=0A= >>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the=0A= >>>>>>>>>>> construction=0A= >>>>>>>>>>>>> of=0A= >>>>>>>>>>>>>>> service function paths regardless of the actual=0A= >>>>>> service.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be=0A= >>>>>>>>> developed to=0A= >>>>>>>>>>>>>>> describe requirements and protocols necessary to=0A= >>>>>>>>>>>>>>> convey=0A= >>>>>>>>>>>>> information=0A= >>>>>>>>>>>>>>> to service function implementation points. Where=0A= >>>>>>>>>>>>>>> possible,=0A= >>>>>>>>>>>>> existing=0A= >>>>>>>>>>>>>>> IETF protocols will be used and extended. All=0A= >>>>>>>>>>>>>>> protocol=0A= >>>>>>>>>>> extensions=0A= >>>>>>>>>>>>>>> work should be carried out in the working groups=0A= >>>>>>>>>>>>>>> responsible for=0A= >>>>>>>>>>>>> the=0A= >>>>>>>>>>>>>>> protocols being modified in coordination with this=0A= >>>>>>>>>>>>>>> working=0A= >>>>>>>>>>> group,=0A= >>>>>>>>>>>>>>> but=0A= >>>>>>>>>>>>>>> may be done in this working group after agreement=0A= >>>>>>>>>>>>>>> with all=0A= >>>>>>>>> the=0A= >>>>>>>>>>>>>>> relevant WG chairs and responsible ADs.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> 5) Manageability: Work on the management and=0A= >>>>>>>>>>>>>>> configuration of=0A= >>>>>>>>>>> service=0A= >>>>>>>>>>>>>>> functions in support of SFC components will=0A= >>>>>>>>>>>>>>> certainly be=0A= >>>>>>>>> needed,=0A= >>>>>>>>>>>>>>> but first needs to be better understood and scoped.=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Proposed Milestones=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s)=0A= >>>>>>>>>>>>>>> defining the=0A= >>>>>>>>>>>>> problem=0A= >>>>>>>>>>>>>>> statement and core use cases for Service Function=0A= >>>>>>>>>>>>>>> Chaining=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter=0A= >>>>>>>>>>>>>>> modifications for management and configuration of SFC=0A= >>>>>>>>>>>>>>> components=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining=0A= >>>>>>>>>>>>>>> the=0A= >>>>>>>>>>>>> architecture=0A= >>>>>>>>>>>>>>> for SFC=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic=0A= >>>>>>>>>>>>>>> service function chaining encapsulation protocol=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document=0A= >>>>>>>>>>>>>>> specifying the=0A= >>>>>>>>>>>>> generic=0A= >>>>>>>>>>>>>>> service function chaining header encapsulation=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> Thomas=0A= >>>>>>>>>>>>>>>=0A= >>>>>>>>>>>>>>> _______________________________________________=0A= >>>>>>>>>>>>>>> nsc mailing list=0A= >>>>>>>>>>>>>>> nsc@ietf.org=0A= >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>>>>>>>> _______________________________________________=0A= >>>>>>>>>>>>>>> nsc mailing list=0A= >>>>>>>>>>>>>>> nsc@ietf.org=0A= >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>>>>>>>> _______________________________________________=0A= >>>>>>>>>>>>>>> nsc mailing list=0A= >>>>>>>>>>>>>>> nsc@ietf.org=0A= >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>>>>>>> _______________________________________________=0A= >>>>>>>>>>>>>> nsc mailing list=0A= >>>>>>>>>>>>>> nsc@ietf.org=0A= >>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>> _______________________________________________=0A= >>>>>>>>> nsc mailing list=0A= >>>>>>>>> nsc@ietf.org=0A= >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>> _______________________________________________=0A= >>>>>>>>> nsc mailing list=0A= >>>>>>>>> nsc@ietf.org=0A= >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>>>> _______________________________________________=0A= >>>>>>>>> nsc mailing list=0A= >>>>>>>>> nsc@ietf.org=0A= >>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>>>=0A= >>>>>> _______________________________________________=0A= >>>>>> nsc mailing list=0A= >>>>>> nsc@ietf.org=0A= >>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>> _______________________________________________=0A= >>>>> nsc mailing list=0A= >>>>> nsc@ietf.org=0A= >>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>>=0A= >>>> _______________________________________________=0A= >>>> nsc mailing list=0A= >>>> nsc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>> _______________________________________________=0A= >>>> nsc mailing list=0A= >>>> nsc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>> _______________________________________________=0A= >>>> nsc mailing list=0A= >>>> nsc@ietf.org=0A= >>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>>=0A= >>> _______________________________________________=0A= >>> nsc mailing list=0A= >>> nsc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>=0A= >_______________________________________________=0A= >nsc mailing list=0A= >nsc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= =0A= From hongyu.li@huawei.com Thu Nov 14 18:24:25 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F9611E8128 for ; Thu, 14 Nov 2013 18:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaFaJWyK2A3t for ; Thu, 14 Nov 2013 18:24:21 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D447411E8170 for ; Thu, 14 Nov 2013 18:24:17 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX34536; Fri, 15 Nov 2013 02:24:14 +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, 15 Nov 2013 02:23:10 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 02:24:11 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 10:24:03 +0800 From: "Hongyu Li (Julio)" To: "Joel M. Halpern" , David Allan I , "nsc@ietf.org" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhNOKetVd+0mYdBTNJtPCzpoi7T2A///bpACAAToXAIAAJk2AgAFpyfA= Date: Fri, 15 Nov 2013 02:24:02 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E9971ED@SZXEMA509-MBX.china.huawei.com> References: <6EB34CB5D82C4645B826C56144826EA97E996662@SZXEMA509-MBX.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E996ABB@SZXEMA509-MBX.china.huawei.com> <5284C627.2070906@joelhalpern.com> In-Reply-To: <5284C627.2070906@joelhalpern.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 Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 02:24:25 -0000 SEkgSm9lbCwNCg0KVGhlIHdvcmQgImFyYml0cmFyaWx5IiBoZXJlIG1heSBiZSB0b28gYXJiaXRy YXJpbHkgc2VsZWN0ZWQuIFdoYXQgSSByZWFsbHkgd2FudCB0byBzYXkgaXMgdGhhdCB3aGF0ZXZl ciB0aGUgb3BlcmF0b3JzIGRlZmluZXMgaXRzIHNlcnZpY2UgY2hhaW5zLCB0aGV5IHNob3VsZCBi ZSBhYmxlIHRvIGJlIGRlcGxveWVkLiBTbywgSSB0aGluayB3ZSBoYXZlIHRoZSBzYW1lIHZpZXcu DQoNCkhPbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpv ZWwgTS4gSGFscGVybg0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE0LCAyMDEzIDg6NDcgUE0N ClRvOiBIb25neXUgTGkgKEp1bGlvKTsgRGF2aWQgQWxsYW4gSTsgbnNjQGlldGYub3JnDQpTdWJq ZWN0OiBSZTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1 cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0KWW91IGFzc2VydCBpbiB0aGUgYmVsb3cgdGV4 dCB0aGF0ICJzZXJ2aWNlIGZ1bmN0aW9ucyBzaG91bGQgYmUgYWJsZSB0byBjb21wb3NlIGEgY2hh aW4gYXJiaXRyYXJpbHkuIg0KVGhhdCBkb2VzIG5vdCBzZWVtIHRvIGZvbGxvdy4NClRoZSBvcGVy YXRvciBkZWZpbmVzIHRoZSBzZXJ2aWNlIGNoYWlucyB0aGV5IHdhbnQuICBUaGV5IHByb3Zpc2lv biB0aG9zZSBzZXJ2aWNlIGNoYWlucy4NClRodXMsIEkgd291bGQgZXhwZWN0IHRoYXQgdGhlIGpv YiBvZiBhIHNlcnZpY2UgZnVuY3Rpb24gaXMgdG8gZGVsaXZlciBpdHMgc3BlY2lmaWMgc2Vydmlj ZS4gIEluIGdlbmVyYWwsIGl0IHNob3VsZCBub3QgbmVlZCB0byBrbm93IG9yIGNhcmUgYWJvdXQg dGhlIGNoYWlucyBpbiB3aGljaCBpdCBpcyBwYXJ0aWNpcGF0aW5nLg0KDQpZb3VycywNCkpvZWwg TS4gSGFscGVybg0KDQpPbiAxMS8xMy8xMyA5OjI5IFBNLCBIb25neXUgTGkgKEp1bGlvKSB3cm90 ZToNCj4gSGkgRGF2ZSwNCj4NCj4gWW91ciBpbmZlcnJlZCByZXN0cmljdGlvbiBtYXkgYmUgbm90 IGFsd2F5cyB0cnVlLiBJbiBnZW5lcmFsLCBzZXJ2aWNlIA0KPiBmdW5jdGlvbnMgc2hvdWxkIGJl IGFibGUgdG8gY29tcG9zZSBhIGNoYWluIGFyYml0cmFyaWx5LiBQYXJ0aWN1bGFybHkgDQo+IGZv ciBicmFuY2hpbmcsIGFzIEkgc3VnZ2VzdGVkIGluIHByZXZpb3VzIGVtYWlsLCBzZXJ2aWNlIGZ1 bmN0aW9uIA0KPiBzaGFsbCBub3QgZGlyZWN0bHkgaW1wYWN0IHBhY2tldCBmb3J3YXJkaW5nLiBU aGlzIHByZWNsdWRlcyB0aGUgDQo+IHJlc3RyaWN0aW9uIHlvdSBtZW50aW9uZWQuIEZvcndhcmRp bmcgcGxhbmUgY2FuIGRlY2lkZSB3aGV0aGVyIGEgDQo+IGJyYW5jaGluZyBhY3Rpb24gc2hvdWxk IGJlIHRha2VuIGJ5IHJlY2xhc3NpZmljYXRpb24gb3Igbm90IHBlciANCj4gc2VydmljZSBjaGFp bi4NCj4NCj4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+DQo+IEhvbmd5dQ0KPg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBEYXZpZCBBbGxhbiBJIA0KPiBbbWFpbHRvOmRhdmlk LmkuYWxsYW5AZXJpY3Nzb24uY29tXSBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLA0KPiAy MDEzIDExOjQ1IFBNIFRvOiBIb25neXUgTGkgKEp1bGlvKTsgbnNjQGlldGYub3JnIFN1YmplY3Q6 IFJFOiBbbnNjXQ0KPiBGVzogcmUgY2xhc3NpZmljYXRpb24gJiBicmFuY2hpbmcsIHdhczogQ3Vy cmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPg0KPiBISSBIb25neXU6DQo+DQo+IEkgdGhpbmsg d2Ugd2lsbCBoYXZlIHNjZW5hcmlvcyB3aGVyZSBhIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFycyBp biANCj4gbW9yZSB0aGFuIG9uZSBjaGFpbiwgYXMgd291bGQgYmUgdGhlIGNhc2UsIGZvciBleGFt cGxlLCBpZiBzb21lIGZsb3dzIA0KPiBjb3VsZCBkeW5hbWljYWxseSBieXBhc3MgRFBJIGJ1dCBz dGlsbCBuZWVkZWQgdG8gdHJhbnNpdCBhIGNvbW1vbiBzZXQgDQo+IG9mIHN0YXRlZnVsIHNlcnZp Y2UgZnVuY3Rpb25zLi4uDQo+DQo+IE9uY2UgeW91IHBvc3R1bGF0ZSBhIHNlcnZpY2UgZnVuY3Rp b24gaW5zdGFuY2UgYXBwZWFyaW5nIGluIG1vcmUgdGhhbiANCj4gb25lIGNoYWluLCBpdCBzZWVt cyBhcnRpZmljaWFsbHkgcmVzdHJpY3RpdmUgbm90IHRvIHBlcm1pdCBzdWNoIGEgDQo+IGZ1bmN0 aW9uIHRvIGFsc28gaW1wbGVtZW50IGJyYW5jaGluZywgYWxsIHRoZSBjb250cm9sIHN0cnVjdHVy ZXMgd291bGQgDQo+IGFscmVhZHkgYmUgdGhlcmUuDQo+DQo+IFJnZHMgRGF2ZQ0KPg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBIb25neXUgTGkgKEp1bGlvKSANCj4gW21haWx0 bzpob25neXUubGlAaHVhd2VpLmNvbV0gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAx MyAyOjEyIA0KPiBBTSBUbzogRGF2aWQgQWxsYW4gSTsgbnNjQGlldGYub3JnIFN1YmplY3Q6IFJF OiBbbnNjXSBGVzogcmUgDQo+IGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJl bnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4NCj4gTWF5IEkgc3VnZ2VzdCBzdW1tYXJ5IG9mIG15 IHZpZXdzIGhlcmU6DQo+DQo+IDEuIEJyYW5jaCBpcyBhIHNvcnQgb2YgdXNlIGNhc2Ugb3Igc2Nl bmFyaW8sIHdoaWxlIHJlY2xhc3NpZmljYXRpb24gaXMgDQo+IGEgd2F5IHRvIHNvbHZlIHRoZSBw cm9ibGVtLiAyLiBTZXJ2aWNlIEZ1bmN0aW9ucyBzaG91bGQgYmUgZGVjb3VwbGVkIA0KPiB3aXRo IHRoZSBjaGFpbiBpdHNlbGYuIE1lYW5pbmcsIGEgU0Ygc2hhbGwgbm90ICpkaXJlY3RseSogaW1w YWN0IHRoZSANCj4gZm9yd2FyZGluZyBvZiBwYWNrZXRzIGluIGEgY2hhaW4uIEJyYW5jaGluZyBz aG91bGQgYmUgcGVyZm9ybWVkIGJ5IA0KPiBjaGFpbiBmb3J3YXJkaW5nIG5vZGVzLCBwb3NzaWJs eSB1bmRlciBjb250cm9sIG9mIGEgY29udHJvbCBub2RlLiBUaGUgDQo+IHJlYXNvbiBmb3IgdGhp cyBpcyBpbiBORlYgd29ybGQsIHNlcnZpY2UgZnVuY3Rpb25zIG1heSBjb21lIGZyb20gYSANCj4g dGhpcmQgcGFydHksIHdoaWxlIGNoYWluIGlzIHByb3ZpZGVkIGJ5IHRoZSBpbmZyYXN0cnVjdHVy ZSBvZiB0aGUgDQo+IG5ldHdvcmsuIFRoZXJlIG11c3QgYmUgYSBjdXNoaW9uIGF2b2lkaW5nIGEg c2VydmljZSBmdW5jdGlvbiBvcGVyYXRpbmcgDQo+IGluZnJhc3RydWN0dXJlIGRpcmVjdGx5LiAz Lg0KPiAoUmUpY2xhc3NpZmljYXRpb24gaXMgYmFzZWQgb24gaW5mbyBpbiBhIHBhY2tldC4gVGhp cyBpcyB2ZXJ5IGdlbmVyYWwuIA0KPiBTdWNoIGluZm8gY291bGQgYmUgTDJ+TDcgZGVyaXZlZCBm cm9tIGEgdXNlcidzIHBhY2tldCwgYXMgd2VsbCBhcyBzb21lIA0KPiBpbmZvIGxpa2UgbWV0YWRh dGEgaW4gYSBTRkMgaGVhZGVyLiBBcyBjbGFzc2lmaWNhdGlvbiBpcyBvdXQgb2Ygc2NvcGUgDQo+ IG9mIFNGQywgd2UgZG9uJ3QgaGF2ZSB0byBwcm92aWRlIHRvbyBtdWNoIGRldGFpbHMgb2YgaG93 IHRvIGRvIA0KPiBjbGFzc2lmaWNhdGlvbi4gNC4gQ2hhaW4gc2VnbWVudHMgc3RpdGNoaW5nIGlz IHJlbGF0aXZlbHkgYSBlYXN5IHdheSANCj4gZm9yIGJyYW5jaGluZy4gQ29tcGFyZWQgd2l0aCBj aGFpbnMgYW5kIHN1YmNoYWlucywgd2hpY2ggbWF5IHJlcXVpcmUgYSANCj4gbW9yZSBjb21wbGV4 IGhlYWRlciBhbmQgZm9yd2FyZGluZyBjYXBhYmlsaXRpZXMuIE15IHR3byBjZW50cy4gSG9uZ3l1 DQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IG5zYy1ib3VuY2VzQGlldGYu b3JnIA0KPiBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGF2aWQg QWxsYW4gSSBTZW50Og0KPiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDM6MDQgQU0gVG86 IG5zY0BpZXRmLm9yZyBTdWJqZWN0OiBbbnNjXQ0KPiBGVzogcmUgY2xhc3NpZmljYXRpb24gJiBi cmFuY2hpbmcsIHdhczogQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPg0KPiBIaTogKHJl c2VuZCB3aXRoIHJlY2lwaWVudCBsaXN0IGNsZWFuZWQgdXApDQo+DQo+IEkgYWdyZWUgd2UgYXJl IGRpc2N1c3NpbmcgbXVsdGlwbGUgY29uY2VwdHMsIGNsYXNzaWZpY2F0aW9uIGFuZCANCj4gZmxv dy1zdWJzZXR0aW5nLiBQZXJoYXBzIG1vcmUgOy0pDQo+DQo+IERlZmluaW5nIGEgZmxvdyBzdWJz ZXQgY2FuIGJlIGEgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9uLCBidXQgaXQgaXMgDQo+IG5vdCB0 aGUgZXhjbHVzaXZlIG1lY2hhbmlzbS4gQnJhbmNoaW5nIGlzIGEgbWVjaGFuaXNtIGJ5IHdoaWNo IGZsb3cgDQo+IHN1YnNldHMgYXJlIGV4cG9zZWQgYW5kIG1hcHBlZCB0byBhIHNldCBvZiBzdWJj aGFpbnMgc3VjaCB0aGF0IGl0IGNhbiANCj4gYmUgaWRlbnRpZmllZCBpbiB0aGUgZGF0YXBsYW5l Li4uDQo+DQo+IFRoYXQncyB0aGUgdmlldyBmcm9tIGhlcmUgRGF2ZQ0KPg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyANCj4gW21haWx0bzpu c2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIERhdmlkIExha2UgKGRsYWtlKSBTZW50 Og0KPiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxMDo1MSBBTSBUbzogSmltIEd1aWNoYXJk IChqZ3VpY2hhcik7IEtldmluIA0KPiBKIE1hOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJv biBQYXJrZXI7IExpbmRhIER1bmJhcjsgSG9uZ3l1IExpIA0KPiAoSnVsaW8pIENjOiBUaG9tYXMg TmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+IFN1YmplY3Q6IFJlOiBbbnNj XSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+DQo+IFVuZGVyc3Rvb2QgLSBtYXliZSBq dXN0IGEgbGl0dGxlIGxvY2FsaXNlZCB3YXJtaW5nIG9mIHRoZSBzZWEgdGhlbiA/DQo+IEJ1dCBJ IHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gY29uc2lkZXIgd2hlcmUgYW5kIGhvdyBwb2xpY3kgaXMg DQo+IGRlZmluZWQvc2V0IGV2ZW4gZm9yIHRoZSBzaW5nbGUtZG9tYWluIGluc3RhbmNlLg0KPg0K PiBJIGRvbid0IHRoaW5rIHdlIGNhbiBhc3N1bWUgdGhhdCBhbnkgTDEtMyBkZXZpY2Ugd2lsbCBi ZSBhYmxlIHRvIA0KPiBkZXRlcm1pbmUgbXVjaCB1c2VmdWwgaW5mb3JtYXRpb24gZnJvbSB0aGUg ZGF0YS1wbGFuZS4NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogSmltIEd1 aWNoYXJkIChqZ3VpY2hhcikgU2VudDogMTIgDQo+IE5vdmVtYmVyIDIwMTMgMTA6NDQgVG86IERh dmlkIExha2UgKGRsYWtlKTsgS2V2aW4gSiBNYTsgU3VyZW5kcmEgS3VtYXIgDQo+IChzbWt1bWFy KTsgUm9uIFBhcmtlcjsgTGluZGEgRHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKSBDYzoNCj4gVGhv bWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZSBTdWJqZWN0OiBSZTogW25z Y10gQ3VycmVudCANCj4gUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4NCj4gQXMgZGlzY3Vzc2VkIGR1 cmluZyB0aGUgQk9GIG91ciBpbml0aWFsIHdvcmsgaXMgc2luZ2xlIGFkbWluaXN0cmF0aXZlIA0K PiBkb21haW4gZm9yIHNvbWUgb2YgdGhlIHZlcnkgcmVhc29ucyB5b3UgcG9pbnQgb3V0LiBXZSBu ZWVkIHRvIGtlZXAgDQo+IGZvY3VzZWQgd2l0aG91dCB0cnlpbmcgdG8gYm9pbCB0aGUgb2NlYW4g cmlnaHQgb2ZmIHRoZSBiYXQuDQo+DQo+IE9uIDExLzEyLzEzIDE6MzYgUE0sICJEYXZpZCBMYWtl IChkbGFrZSkiIDxkbGFrZUBjaXNjby5jb20+IHdyb3RlOg0KPg0KPj4gRXhhY3RseS4gIEJ1dCBo b3cgY2FuIG5ldHdvcmstY29tcG9uZW50cyAidGVybWluYXRlIiBhbiBhcHBsaWNhdGlvbiANCj4+ ID8/Pz8NCj4+DQo+PiBJIHRoaW5rIHdlIG5lZWQgYSBnb29kIHVuZGVyc3RhbmRpbmcgb2YgYSBy ZWN1cnNpdmUgcG9saWN5IG1lY2hhbmlzbSANCj4+IChyZWN1cnNpdmUgYmVjYXVzZSBhIHVzZXIt bGFuZCBhcHBsaWNhdGlvbiB3aWxsIHJpZGUgd2l0aCBhIHNwZWNpZmljIA0KPj4gcG9saWN5IGFj cm9zcyBwb3RlbnRpYWxseSBkaWZmZXJlbnQgc2V0cyBvZiBjYXJyaWVyIHBvbGljaWVzKS4NCj4+ DQo+PiBJIGhhdGUgdG8gYnJpbmcgdGhpcyB1cCBub3csIGJ1dCB3ZSBhbHNvIG5lZWQgdG8gdGhp bmsgYWJvdXQgdGhpcyANCj4+IG11bHRpLWRvbWFpbiBpc3N1ZSAtIGlmIEkgc2V0IGEgcG9saWN5 IGFzIGEgdXNlciwgY2hhbmNlcyBhcmUgSSB3aWxsIA0KPj4gYmUgY3Jvc3Npbmcgc2V2ZXJhbCBk b21haW4gYm91bmRhcmllcy4gIEFyZSB3ZSBleHBlY3RpbmcgdGhlIHNlcnZpY2UgDQo+PiBoZWFk ZXJzIHRvIGRlZmluZSB0aGUgc2VydmljZSBjaGFpbmluZyBmb3IgdGhlIGR1cmF0aW9uIG9mIHRo ZSBlbnRpcmUgDQo+PiBmbG93IGFjcm9zcyBhbGwgZG9tYWlucywgb3IganVzdCBhY3Jvc3MgYSBz aW5nbGUgb25lID8NCj4+DQo+PiBJbiB3aGljaCBjYXNlLCBkbyBJIGhhdmUgdG8gcmUtc2V0IHBv bGljeSBhcyBJIHRyYXZlcnNlIGRvbWFpbnMNCj4+IGFuZCB3aGVyZSBkb2VzIHRoYXQgcG9saWN5 IGdldCBzZXQgPyAgIEl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvDQo+PiBzZXQgcG9saWN5IG9u Y2UgYmFzZWQgb24gTDUtNyBuZWVkcywgYW5kIGhhdmUgdGhhdCBpbnN0YW50aWF0ZWQgDQo+PiBh Y3Jvc3MgdGhlIG11bHRpcGxlIGRvbWFpbnMuDQo+Pg0KPj4gQWdhaW4sIHRoaXMgYXBwZWFycyB0 byBiZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBTRkMsIGJ1dCBwcmV0dHkgDQo+PiByZWxldmFudCB0 byBob3cgaXQgd291bGQgb3BlcmF0ZSBpbiB0aGUgcmVhbCB3b3JsZC4NCj4+DQo+PiBEYXZpZA0K Pj4NCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEtldmluIEogTWEgDQo+PiBb bWFpbHRvOmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb21dIFNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMg MTA6MjcgVG86DQo+PiBEYXZpZCBMYWtlIChkbGFrZSk7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFy KTsgUm9uIFBhcmtlcjsgTGluZGEgDQo+PiBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pIENjOiBU aG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIA0KPj4gTWFqZWUgU3ViamVjdDog UkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+DQo+Pj4gSW4gdGhvc2Ug Y2lyY3Vtc3RhbmNlcywgb25seSB0aGUgZW5kIGFwcGxpY2F0aW9ucyB0aGVtc2VsdmVzIG9yIGEg DQo+Pj4gcmVhc29uYWJseSBicm9hZC1icnVzaGVkIGNsYXNzaWZpY2F0aW9uIChyZWFsbHkgdHJh ZmZpYyBzdGVlcmluZyANCj4+PiBiYXNlZCBvbiB3aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykg aXMgZ29pbmcgdG8gYmUgdXNlZnVsIC0gaXMgVEhBVCANCj4+PiB3aGF0IHdlJ3JlIGFpbWluZyBm b3IgaGVyZSA/DQo+Pg0KPj4gSSB3b3VsZCBjZXJ0YWlubHkgaG9wZSBub3QsIGJ1dCB0aGF0IGhh cyBiZWVuIG15IGNvbmNlcm4gYXMgd2VsbC4NCj4+IEFwcGxpY2F0aW9uIGxheWVyIHRlcm1pbmF0 aW9uIGFuZCByZS1jbGFzc2lmaWNhdGlvbiBzZWVtcyBhIG11c3Q/DQo+Pg0KPj4gLS0gIEtldmlu IEouIE1hDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IERhdmlkIExh a2UgKGRsYWtlKSANCj4+PiBbbWFpbHRvOmRsYWtlQGNpc2NvLmNvbV0gU2VudDogVHVlc2RheSwg Tm92ZW1iZXIgMTIsIDIwMTMgMTowMCBQTSANCj4+PiBUbzogU3VyZW5kcmEgS3VtYXIgKHNta3Vt YXIpOyBSb24gUGFya2VyOyBLZXZpbiBKIE1hOyBMaW5kYSBEdW5iYXI7IA0KPj4+IEhvbmd5dSBM aSAoSnVsaW8pIENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVl IA0KPj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ Pj4NCj4+PiBQb2xpY3kgbWF5IGJlIG91dHNpZGUgb2YgdGhlIHNjb3BlIG9mIFNGQywgYnV0IHdp dGhvdXQgc3Ryb25nIA0KPj4+IG1hcHBpbmcgYmV0d2VlbiBQb2xpY3kgYW5kIHRoZSBpbnNlcnRl ZCBTZXJ2aWNlIEhlYWRlcihzKSwgd2UgDQo+Pj4gcnVuLXRoZS1yaXNrIG9mIGxpbWl0aW5nIHRo ZSBlZmZpY2FjeSBvZiB0aGUgcHJvdG9jb2wgSU1PLg0KPj4+DQo+Pj4gRm9yIGV4YW1wbGUsIGlu IGEgd29ybGQgd2hlcmUgdGhlIG5ldHdvcmsgaGFzICJnb25lIGRhcmssIiAoYXMgcGVyIA0KPj4+ IHRoZSBJRVRGIFRlY2huaWNhbCBQbGVuYXJ5ID86LSkgKSB3aGF0IGlzIG91ciBhYmlsaXR5IHRv IGRldGVybWluZSANCj4+PiBwb2xpY3kgYmFzZWQgb24gRFBJIG9mIHBhY2tldHMtaW4tZmxpZ2h0 ID8NCj4+Pg0KPj4+IEluIHRob3NlIGNpcmN1bXN0YW5jZXMsIG9ubHkgdGhlIGVuZCBhcHBsaWNh dGlvbnMgdGhlbXNlbHZlcyBvciBhIA0KPj4+IHJlYXNvbmFibHkgYnJvYWQtYnJ1c2hlZCBjbGFz c2lmaWNhdGlvbiAocmVhbGx5IHRyYWZmaWMgc3RlZXJpbmcgDQo+Pj4gYmFzZWQgb24gd2hhdCB3 ZSBjYW4gc2VlIGF0IGluZ3Jlc3MpIGlzIGdvaW5nIHRvIGJlIHVzZWZ1bCAtIGlzIFRIQVQgDQo+ Pj4gd2hhdCB3ZSdyZSBhaW1pbmcgZm9yIGhlcmUgPw0KPj4+DQo+Pj4gRGF2aWQNCj4+Pg0KPj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIA0K Pj4+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdXJlbmRyYSBL dW1hcg0KPj4+IChzbWt1bWFyKSBTZW50OiAxMiBOb3ZlbWJlciAyMDEzIDA5OjI2IFRvOiBSb24g UGFya2VyOyBLZXZpbiBKIE1hOyANCj4+PiBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8p IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IA0KPj4+IFN1bWFuZHJhIE1hamVlIFN1 YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4NCj4+PiBS b24sDQo+Pj4NCj4+PiBDbGFzc2lmaWNhdGlvbiBvZiB0cmFmZmljIGlzIHdlbGwgdW5kZXJzdG9v ZCBhbmQgd2UgZG8gbm90IGhhdmUgdG8gDQo+Pj4gcmVkZWZpbmUgaXQgLSBpdCdzIGJlZW4gYXJv dW5kIGZvciBhbGwgdGhlIHRpbWUgbWlkZGxlIGJveGVzIGhhdmUgDQo+Pj4gYmVlbiBvciBmb3Ig dGhhdCBtYXR0ZXIgdGhlIEwyL0wzIGRldmljZXMuIEFsbCB3ZSBhcmUgdGFsa2luZyBhYm91dCAN Cj4+PiBpcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgY2xhc3NpZmljYXRpb24gdG8gYnJhbmNo aW5nIGluIFNGQy4NCj4+Pg0KPj4+IFlvdSBhcmUgcmlnaHQsIGl0IGlzIGFsbCBhYm91dCBwb2xp Y3kgd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgDQo+Pj4gU0ZDLg0KPj4+DQo+Pj4gU3Vy ZW5kcmEuDQo+Pj4NCj4+PiBPbiAxMS8xMi8xMyA3OjUzIEFNLCAiUm9uIFBhcmtlciINCj4+PiA8 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4gSSB0aGlu ayB0aGUgbGFjayBvZiBkZWZpbml0aW9uIG9mICJyZWNsYXNzaWZpY2F0aW9uIiBtYXkgYmUgY2F1 c2luZw0KPj4+IHNvbWUNCj4+Pj4gbWlzdW5kZXJzdGFuZGluZ3MgaGVyZS4gICAgQSBicmFuY2gg d291bGQgb2NjdXIgZm9yIHNvbWUNCj4+Pj4gcG9saWN5LWRyaXZlbiByZWFzb24gYmFzZWQgb24g dGhlIGJlaGF2aW9yIGFuZCBjb25jbHVzaW9ucyBvZg0KPj4+PiB0aGUgc2VydmljZSBmdW5jdGlv biwgaXRzZWxmLiAgIFRoZSBncmFwaCB3b3VsZCByZXByZXNlbnQgdGhlDQo+Pj4+IGZhY3QgdGhh dCB0aGVyZSBpcyBhIGJyYW5jaCBwb2ludCwgYnV0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uLCANCj4+ Pj4gaXRzZWxmLCBiZWluZyBhd2FyZSB0aGF0IGl0IGlzIGEgYnJhbmNoaW5nIHBvaW50IHdvdWxk IGNvbnRhaW4gdGhlIA0KPj4+PiBwb2xpY3kgYW5kIGxvZ2ljIHRvIGRlY2lkZSBvbiB3aGljaCBi cmFuY2ggdG8gdGFrZS4NCj4+Pj4gU3BlY2lmeWluZyB0aGF0IHBvbGljeSBhbmQgbG9naWMgaXMg b3V0IG9mIHNjb3BlLA0KPj4+IElNTy4NCj4+Pj4NCj4+Pj4gUm9uDQo+Pj4+DQo+Pj4+DQo+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEtldmluIEogTWEgDQo+Pj4+IFttYWls dG86a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIs DQo+Pj4+IDIwMTMgMTA6NDkgQU0gVG86IExpbmRhIER1bmJhcjsgUm9uIFBhcmtlcjsgSG9uZ3l1 IExpIChKdWxpbykNCj4+Pj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VyZW5k cmEgS3VtYXIgKHNta3VtYXIpOyBTdW1hbmRyYSANCj4+Pj4gTWFqZWUgU3ViamVjdDogUkU6IFtu c2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4NCj4+Pj4gSGkgTGluZGEsDQo+ Pj4+DQo+Pj4+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgYSBicmFuY2hpbmcgcG9pbnQgaXMgIm5ldmVy IiBhIHJlY2xhc3NpZmljYXRpb24gDQo+Pj4+IHBvaW50LCBvciBhcmUgeW91IHNheWluZyB0aGF0 IGEgYnJhbmNoaW5nIHBvaW50ICJkb2VzIG5vdCBoYXZlIHRvIA0KPj4+PiBiZSIgYSByZWNsYXNz aWZpY2F0aW9uIHBvaW50Pw0KPj4+Pg0KPj4+PiBJIHRoaW5rIHRoaXMgaXMgYW4gaW1wb3J0YW50 IGRpc3RpbmN0aW9uIHRoYXQgbmVlZHMgdG8gYmUgDQo+Pj4+IGNsYXJpZmllZC4gSWYgYnJhbmNo aW5nIGlzIG5ldmVyIHJlY2xhc3NpZmljYXRpb24sIHRoZW4gdGhlIG1lYW5pbmcgDQo+Pj4+IG9m IGEgY2hhaW4gaXMgZGlmZmVyZW50IHRoYW4gSSBvcmlnaW5hbGx5IGluZmVycmVkLiAgSWYgdGhl IGNoYWluIA0KPj4+PiBpcyBhIHRyZWUgd2l0aCBvdGhlciAiYnJhbmNoaW5nIiBwb2ludHMgaW4g aXQsIHRoZW4gdGhhdCBsaW1pdHMgdGhlIA0KPj4+PiBzY29wZSBvZiB0aGUgcHJvYmxlbSBzdGF0 ZW1lbnQgZ29hbHMuDQo+Pj4+DQo+Pj4+IFdoaWxlIHRoaXMgY291bGQgYmUgYSBkZWdlbmVyYXRl IGNhc2UsIGFuZCBhbnkgaW1wbGVtZW50YXRpb24gY291bGQgDQo+Pj4+IGRlZmluZSBiYWQgc2Vy dmljZSBjaGFpbnMsIGlzIGl0IHRoZSBpbnRlbnQgb2YgU0ZDIHRvIG9ubHkgbG9vayBhdCANCj4+ Pj4gdGhlIHNpbXBsZXIgcGFja2V0LWxldmVsIGNsYXNzaWZpY2F0aW9uIGNhc2VzLCBvciBpcyBp dCB0aGUgaW50ZW50IA0KPj4+PiB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIGJyYW5jaGlu ZyBwb2ludCBpcyB2aWV3ZWQgYXMgYSANCj4+Pj4gcmUtY2xhc3NpZmljYXRpb24gcG9pbnQ/DQo+ Pj4+DQo+Pj4+IHRoYW54Lg0KPj4+Pg0KPj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+Pj4NCj4+Pj4+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IExpbmRhIER1bmJhciANCj4+Pj4+IFtt YWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dIFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEy LA0KPj4+Pj4gMjAxMyAxMDozNCBBTSBUbzogUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbyk7 IEtldmluIEogTWENCj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVu ZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+Pj4+PiBTdW1hbmRyYSBNYWplZSBTdWJqZWN0OiBSRTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4NCj4+Pj4+IFJvbiwNCj4+ Pj4+DQo+Pj4+PiBGaXJzdCwgd2FudCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgImJyYW5jaGluZyIg IT0gcmVjbGFzc2lmaWNhdGlvbiwgDQo+Pj4+PiBhZ3JlZT8NCj4+Pj4+DQo+Pj4+PiBTZWNvbmQs IHRoZSByZXByZXNlbnRhdGlvbiBvZiBicmFuY2hpbmcgKG9yIHNlcnZpY2UgZ3JhcGgpIGNhbiBi ZSANCj4+Pj4+IGluIGEgZm9ybSBvZiBsb2dpYyBvbiBhIHNlcnZpY2UgZnVuY3Rpb24uIFNvbWUg c2VydmljZSBmdW5jdGlvbnMsIA0KPj4+Pj4gZXNwZWNpYWxseSBMNyBiYXNlZCwgY2FuIHVzZSB2 YWx1ZSBpbiBhIERhdGFiYXNlIHRvIGRldGVybWluZSB3aGF0IA0KPj4+Pj4gaXMgdGhlIG5leHQg c2VydmljZSBmdW5jdGlvbi4NCj4+Pj4+DQo+Pj4+PiBMaW5kYQ0KPj4+Pj4NCj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyANCj4+Pj4+ PiBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uIFBhcmtlciBT ZW50Og0KPj4+Pj4+IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDg6MTYgQU0gVG86IEhvbmd5 dSBMaSAoSnVsaW8pOyBLZXZpbiBKIA0KPj4+Pj4+IE1hIENjOiBUaG9tYXMgTmFydGVuOyBuc2NA aWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+Pj4+Pj4gU3VtYW5kcmEgTWFq ZWUgU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ Pg0KPj4+Pj4+IEhvbmd5dSwNCj4+Pj4+Pg0KPj4+Pj4+IEkgYWdyZWUgY29tcGxldGVseSB0aGF0 IHJlLWNsYXNzaWZpY2F0aW9uIGlzIG5vdCBsaW1pdGVkIHRvIERQSS4NCj4+Pj4+Pg0KPj4+Pj4+ IEFuZCBhbHNvLCB0aGF0IGFuIGFyZWEgZm9yIHVzIHRvIGV4cGxvcmUgYXMgYSBncm91cCBpcyBo b3cgdG8NCj4+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+IHRoZSBzZXJ2aWNlIGdyYXBoLiAgIERvIHdl IHdhbnQgdG8gcmVwcmVzZW50IGl0IGFzIGEgcHJvcGVyDQo+Pj4+Pj4gZ3JhcGgNCj4+PiB3aXRo DQo+Pj4+Pj4gYW4gYWRqYWNlbmN5IGxpc3Qgb3Igb3RoZXIgcmVwcmVzZW50YXRpb25hbCBtb2Rl bD8gICBPciwgZG8NCj4+Pj4+PiB3ZSB3YW50DQo+Pj4gdG8NCj4+Pj4+PiByZXByZXNlbnQgaXQg YXMgYSBzZXQgb2YgbGluZWFyIHNlZ21lbnRzIGFuZCBpZiBzbywgaG93IGFyZQ0KPj4+Pj4+IHRo ZSBzZWdtZW50cyBjb25uZWN0ZWQgaW50byBhIGdyYXBoPyAgIE90aGVyIGlkZWFzPw0KPj4+Pj4+ DQo+Pj4+Pj4gUm9uDQo+Pj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tIEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIA0KPj4+Pj4+IFttYWlsdG86bnNjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBIb25neXUgTGkNCj4+Pj4+PiAoSnVsaW8pIFNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDY6NTcgQU0gVG86IFJvbiBQYXJrZXI7IA0K Pj4+Pj4+IEtldmluIEogTWEgQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VyZW5k cmEgS3VtYXIgDQo+Pj4+Pj4gKHNta3VtYXIpOyBTdW1hbmRyYSBNYWplZSBTdWJqZWN0OiBSZTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgDQo+Pj4+Pj4gY2hhcnRlcg0KPj4+Pj4+DQo+Pj4+ Pj4gQnJhbmNoaW5nL2ZvcmtpbmcgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIHRvcGljIG9mIFNGQy4g QWJvdXQgdGhlIA0KPj4+Pj4+IHJlLSBjbGFzc2lmaWNhdGlvbiBwb2ludCwgcHJvYmFibHkgd2Ug c2hhbGwgbm90IGxpbWl0IGl0IHRvIERQSS4gDQo+Pj4+Pj4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0 aGF0IHBhY2tldHMgZ28gdG8gZGlmZmVyZW50IGJyYW5jaGVzIGFmdGVyIA0KPj4+Pj4+IGJlZW4g cHJvY2Vzc2VkIGJ5IGEgY2VydGFpbiBzZXJ2aWNlIGZ1bmN0aW9uLCBkZWNpc2lvbiBvZiB3aGlj aCANCj4+Pj4+PiBicmFuY2hlcyB0byBnbyBpcyBtYWRlIGJhc2VkIG9uIHRoZSByZXN1bHQgb2Yg c2VydmljZSBmdW5jdGlvbidzIA0KPj4+Pj4+IHByb2Nlc3MsIGkuZS4gbm90IGp1c3QgcmUtIGNs YXNzaWZpY2F0aW9uIGJ5IERQSS4NCj4+Pj4+Pg0KPj4+Pj4+IEhvbmd5dQ0KPj4+Pj4+DQo+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcg DQo+Pj4+Pj4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbiBQ YXJrZXIgU2VudDoNCj4+Pj4+PiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyA3OjQ1IFBNIFRv OiBLZXZpbiBKIE1hIENjOg0KPj4+Pj4+IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3Vy ZW5kcmEgS3VtYXIgKHNta3VtYXIpOyBTdW1hbmRyYSANCj4+Pj4+PiBNYWplZSBTdWJqZWN0OiBS ZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+DQo+Pj4+Pj4gSGks IEtldmluDQo+Pj4+Pj4NCj4+Pj4+PiBZb3UgYXNrIGEgZ3JlYXQgcXVlc3Rpb24gYWJvdXQgYnJh bmNoaW5nIHRoZSBncmFwaC4gIFRoZSBkZXRhaWxzIA0KPj4+Pj4+IGFyb3VuZCBob3cgdG8gY29u dmV5IHRoZSBzZWxlY3Rpb24gb2YgdGhlIHN1YnRyZWUvc3ViZ3JhcGggYXJlIA0KPj4+Pj4+IHN0 aWxsDQo+Pj4+PiB0byBiZQ0KPj4+Pj4+IGRlZmluZWQuICAgSXMgaXQgb25lIGNoYWluIGlkIGZv ciB0aGUgd2hvbGUgZ3JhcGg/ICAgRG9lcw0KPj4+Pj4+IGVhY2gNCj4+PiBicmFuY2gNCj4+Pj4+ PiBoYXZlIGl0cyBvd24gY2hhaW4gaWQ/ICAgU29tZSBjb21iaW5hdGlvbj8NCj4+Pj4+Pg0KPj4+ Pj4+IFJvbg0KPj4+Pj4+DQo+Pj4+Pj4gT24gTm92IDEyLCAyMDEzLCBhdCAxOjUyIEFNLCAiS2V2 aW4gSiBNYSINCj4+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+Pj4+ Pj4NCj4+Pj4+Pj4+IFllcywgcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRoZSBzZXJ2aWNl IHBhdGggYW5kIA0KPj4+Pj4+Pj4gcmUtY2xhc3NpZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkg bm9kZSBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gSnVzdCB0byBleHBh bmQgb24gdGhhdCwgZ29pbmcgYmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gDQo+Pj4+Pj4+ IGFib3V0IHNlcnZpY2UgaGVhZGVyIGVuY2Fwc3VsYXRpb24sIGlzIGl0IGludGVuZGVkIHRoYXQg YSBjaGFpbiANCj4+Pj4+Pj4gdGhhdCBpcyByZS1jbGFzc2lmaWVkIHdpbGwgZ2V0IGEgbmV3IGNo YWluIElEIHdoaWNoIGZ1bGx5IA0KPj4+Pj4+PiBkZXNjcmliZXMgYSBjaGFpbiB0aGF0IGlzIGEg c3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFsIGNoYWluIElELCANCj4+Pj4+Pj4gcHJpb3IgdG8gRFBJ LWJhc2VkIHJlLWNsYXNzaWZpY2F0aW9uPyAgKGFzc3VtaW5nIHRoZSBnb2FsIGlzICJhIA0KPj4+ Pj4+PiBzaW5nbGUgY2hhaW4gSUQgdGhhdCBpcyBjb21tb25seSB1bmRlcnN0b29kIGFsb25nIHRo ZSBlbnRpcmUgDQo+Pj4+Pj4+IHNlcnZpY2UNCj4+PiBjaGFpbiINCj4+Pj4+Pj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25zYy9jdXJyZW50L21zZzAwNjM4Lmh0bWwNCj4+ Pj4+Pj4NCj4+Pj4+Pj4NCikNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQW5kIHRoZSBhcHBsaWNhYmxlIHN1 YnNldCBvZiB0aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlIA0KPj4+Pj4+PiBwYXRocyB3 b3VsZCBiZSBjb25maWd1cmVkIGF0IGVhY2ggYXBwcm9wcmlhdGUgc2VydmljZSBub2RlPyANCj4+ Pj4+Pj4gZS5nLiwgSUQgMTogTkFUICsgZmlyZXdhbGwgKyBEUEkgSUQgMjogTkFUDQo+Pj4+Pj4+ ICsgZmlyZXdhbGwgKyBEUEkgKyBBViBJRCAzOiBOQVQgKyBmaXJld2FsbCArIERQSSArIEFWICsN Cj4+Pj4+Pj4gTkFUIElEIDQ6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTkFUIElEIDU6IE5BVCAr IGZpcmV3YWxsDQo+Pj4+Pj4+ICsgRFBJICsgQVYgKyBMQiBJRCA2OiBOQVQgKyBmaXJld2FsbCAr IERQSSArIExCIElEIDc6IE5BVCANCj4+Pj4+Pj4gKyBmaXJld2FsbCArIERQSSArIExCICsgQ0FD SEUgSUQgODogTkFUICsgZmlyZXdhbGwgKyBEUEkgQ0FDSEUgDQo+Pj4+Pj4+ICsgSUQgOTogTkFU ICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQiBJRA0KPj4+Pj4+PiAxMDogTkFUICsg ZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBMQiArIENBQ0hFIElEIDExOg0KPj4+Pj4+PiBO QVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIENBQ0hFIFdvdWxkIGV2ZXJ5IGZsb3cg dGhlbiANCj4+Pj4+Pj4gYmUgaW5pdGlhbGx5IGNsYXNzaWZpZWQgYXMgSUQgMSwgYnV0IGV2ZW50 dWFsbHkgZ2V0DQo+Pj4+Pj4+IHJlLQ0KPj4+Pj4+IGNsYXNzaWZpZWQNCj4+Pj4+Pj4gdG8gSUQg Mi0xMSwgYWZ0ZXIgdGhlIERQSSBwaGFzZT8NCj4+Pj4+Pj4NCj4+Pj4+Pj4gdGhhbnguDQo+Pj4+ Pj4+DQo+Pj4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0KPj4+Pj4+Pg0KPj4+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3VyZW5kcmEgS3VtYXINCj4+Pj4+Pj4+IChzbWt1bWFy KSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXSBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciANCj4+ Pj4+Pj4+IDEyLCAyMDEzIDE6MDEgQU0gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1bWFu ZHJhIE1hamVlOyANCj4+Pj4+Pj4+IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZyBTdWJqZWN0 Og0KPj4+Pj4+Pj4gUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBPbiAxMS8xMS8xMyA5OjQ2IFBNLCAi S2V2aW4gSiBNYSINCj4+Pj4+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+Pj4+ IHdyb3RlOg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gSGkgU3VyZW5kcmEsDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBDbGFzc2lmaWNhdGlvbiBtYXkgYmUgb3V0IG9mIHNjb3BlLCBidXQgdGhlIGxldmVs IG9mIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4gYXBwbGlj YWJsZSBpcyBkZXBlbmRlbnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gdGhhdCAN Cj4+Pj4+Pj4+PiBjYW4NCj4+Pj4+PiBiZQ0KPj4+Pj4+Pj4+IHBlcmZvcm1lZC4gIEFuIGFzc3Vt cHRpb24gb2YgcGFja2V0IGxldmVsIGVuY2Fwc3VsYXRpb24gaGFzDQo+Pj4+Pj4+PiBpbXBsaWNh dGlvbnMNCj4+Pj4+Pj4+PiBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gYmVpbmcgcGVy Zm9ybWVkPyAgSWYgdGhlIHN0YXRlZA0KPj4+Pj4+IGdvYWxzDQo+Pj4+Pj4+PiBhcmUNCj4+Pj4+ Pj4+PiBmb3IgZmlyZXdhbGwgYW5kIGxvYWQgYmFsYW5jZXIgZnVuY3Rpb25hbGl0eSwgdGhlbiB0 aGUgDQo+Pj4+Pj4+Pj4gYXBwbGljYXRpb24NCj4+Pj4+Pj4+IGxldmVsDQo+Pj4+Pj4+Pj4gbmF0 dXJlIG9mIHRob3NlIGZ1bmN0aW9ucyBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/IElm LCANCj4+Pj4+Pj4+PiBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gc2Nv cGUgaXMgbGltaXRlZCBkdWUgDQo+Pj4+Pj4+Pj4gdG8gbGltaXRhdGlvbnMgaW4gY2xhc3NpZmlj YXRpb24sIHRoYXQgd291bGQgYmUgYW5kIGltcG9ydGFudCANCj4+Pj4+Pj4+PiBwaWVjZSBvZg0K Pj4+Pj4+IGluZm9ybWF0aW9uPw0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gV3J0IHNlY3Rpb24gNC40 IG9mDQo+Pj4+Pj4+Pj4gZHJhZnQtbGl1LXNlcnZpY2UtY2hhaW5pbmctdXNlLWNhc2VzIHRoZSBm b3JrIHBvaW50cyBvZiB0aGUgDQo+Pj4+Pj4+Pj4gc2VydmljZSBwYXRocyBzZWVtIGxpa2UgcmUt Y2xhc3NpZmljYXRpb24NCj4+PiBwb2ludHM/DQo+Pj4+Pj4+Pj4gSXMgdGhhdCB0aGUgaW50ZXJw cmV0YXRpb24gZnJvbSB0aGUgYXJjaGl0ZWN0dXJlIHBlcnNwZWN0aXZlPyANCj4+Pj4+Pj4+PiBP ciBpcyB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBjbGFzc2lmaWNhdGlvbiBleGNsdXNpdmUg b2YgDQo+Pj4+Pj4+Pj4gRFBJDQo+Pj4+Pj4gZnVuY3Rpb25hbGl0eT8NCj4+Pj4+Pj4+IDxTSz4g SSBoYXZlIG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwgYXMg DQo+Pj4+Pj4+PiBkZXNjcmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9m IHNlcnZpY2VzIGZvcm0gYSANCj4+Pj4+Pj4+IGdyYXBoLCBzZWdtZW50cyBvZiB3aGljaCBhcmUg c2VydmljZSBwYXRocy4gWWVzLCANCj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuDQo+Pj4+ Pj4gY2hhbmdlDQo+Pj4+Pj4+PiB0aGUgc2VydmljZSBwYXRoIGFuZCByZS1jbGFzc2lmaWNhdGlv biBtYXkgaGFwcGVuIGF0IGFueSBub2RlIA0KPj4+Pj4+Pj4gYWxvbmcNCj4+Pj4+PiBhIHNlcnZp Y2UgcGF0aC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBTdXJlbmRyYS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+IHRoYW54Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogU3VyZW5kcmEg S3VtYXINCj4+Pj4+Pj4+Pj4gKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dIFNl bnQ6IFR1ZXNkYXksIE5vdmVtYmVyIA0KPj4+Pj4+Pj4+PiAxMiwgMjAxMyAxMjowOCBBTSBUbzog S2V2aW4gSiBNYTsgUm9uIFBhcmtlcjsgU3VtYW5kcmEgTWFqZWU7IA0KPj4+Pj4+Pj4+PiBUaG9t YXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcgU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgDQo+Pj4+ Pj4+Pj4+IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEtldmlu LA0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBDbGFzc2lmaWNhdGlvbiBtZWNoYW5pc20gaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgU0ZDLiBJdCBjYW4gDQo+Pj4+Pj4+Pj4+IGJlIGJhc2VkDQo+Pj4+ Pj4+PiBvbg0KPj4+Pj4+Pj4+PiB0aGUgcGFja2V0IG9yIGluZm9ybWF0aW9uIG5vdCBpbiB0aGUg cGFja2V0KGVudmlyb25tZW50YWwgDQo+Pj4+Pj4+Pj4+IGF0dHJpYnV0ZXMNCj4+Pj4+Pj4+IGZv cg0KPj4+Pj4+Pj4+PiBpbnN0YW5jZSkgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlz IGltcG9ydGFudCBpcyB0aGF0IA0KPj4+Pj4+Pj4+PiBzdWNoIGNsYXNzaWZpY2F0aW9uIGFpZHMg aW4gdHJhZmZpYyBzZWxlY3Rpb24gYW5kIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+IHBhdGggaWRlbnRp ZmljYXRpb24uDQo+Pj4+Pj4+Pj4+IEl0IGlzIG5vIGRpZmZlcmVudCBmcm9tIGEgcG9saWN5IGlu IHRoaXMgcmVnYXJkIGV4Y2VwdCB0aGF0IA0KPj4+Pj4+Pj4+PiB0aGUgcG9saWN5IG5vdyBzcGVj aWZpZXMgdGhlIHNlcnZpY2UgcGF0aC4gRnVydGhlciwgDQo+Pj4+Pj4+Pj4+IGNsYXNzaWZpY2F0 aW9uIGlzIG5vdCBsaW1pdGVkIHRvIHRoZSBuZXR3b3JrIGVsZW1lbnRzIGJ1dCB0aGUgDQo+Pj4+ Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwuDQo+Pj4+Pj4+Pj4+IFNvbWUgb2YgdGhp cyBpcyBkZXNjcmliZWQgaW4gdGhlDQo+Pj4+Pj4+PiBhcmNoaXRlY3R1cmUNCj4+Pj4+Pj4+Pj4g ZHJhZnRzIGFzIHdlbGwgLQ0KPj4+Pj4+Pj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtcXVpbm4tc2ZjLWFyY2gvIi4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4NClN1cmVuZHJhLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gT24gMTEvMTEvMTMg NzozMyBQTSwgIktldmluIEogTWEiDQo+Pj4+Pj4+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1z LmNvbT4NCj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBIaSBSb24sDQo+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSSB3YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNGQyBCb0Yg ZHVlIHRvIGEgY29uZmxpY3Qgd2l0aCANCj4+Pj4+Pj4+Pj4+IENETkksIGJ1dCBJIGhhZCBhIHNp bWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxldCAxMSBpbiBzZWN0aW9uIA0KPj4+Pj4+Pj4+Pj4gMiBv ZiB0aGUNCj4+Pj4+PiBwcm9ibGVtDQo+Pj4+Pj4+Pj4+PiBzdGF0ZW1lbnQ6DQo+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4gMTEuICBQZXItU2VydmljZSAocmUpQ2xhc3NpZmljYXRpb246DQo+Pj4+ Pj4+Pj4+PiBDbGFzc2lmaWNhdGlvbiBvY2N1cnMgYXQNCj4+Pj4+PiBlYWNoDQo+Pj4+Pj4+Pj4+ PiBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZpb3VzbHkgYXBwbGllZCBzZXJ2aWNlDQo+ Pj4+Pj4+Pj4+IGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+Pj4+IFRoZXNlIHVucmVsYXRlZCBjbGFzc2lm aWNhdGlvbiBldmVudHMgY29uc3VtZSByZXNvdXJjZXMNCj4+Pj4+PiBwZXINCj4+Pj4+Pj4+Pj4+ IHNlcnZpY2UuICBNb3JlIGltcG9ydGFudGx5LCB0aGUgY2xhc3NpZmljYXRpb24NCj4+Pj4+PiBm dW5jdGlvbmFsaXR5DQo+Pj4+Pj4+Pj4+PiBvZnRlbiBkaWZmZXJzIHBlciBzZXJ2aWNlIGZ1bmN0 aW9uIGFuZCBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+Pj4+PiBjYW5ub3QNCj4+Pj4+Pj4+Pj4+IGxl dmVyYWdlIHRoZSByZXN1bHRzIGZyb20gb3RoZXIgZGVwbG95ZWQgbmV0d29yayBvcg0KPj4+Pj4+ IHNlcnZpY2UuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gYXMgaXQgcmVsYXRlcyB0byBzZWN0 aW9uIDUuMiBvZiB0aGUgZnJhbWV3b3JrDQo+Pj4+Pj4+Pj4+PiBkb2N1bWVudDoNCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiBUaGUgU0ZDIENsYXNzaWZpZXIgY2xhc3NpZmllcyBwYWNrZXRzIGJh c2VkIG9uDQo+Pj4+Pj4+Pj4+PiAoc29tZSBvZikgdGhlDQo+Pj4+Pj4+Pj4+IGNvbnRlbnRzDQo+ Pj4+Pj4+Pj4+PiBvZiB0aGUgcGFja2V0IGhlYWRlci4gIENvbmNyZXRlbHksIGl0IGNsYXNzaWZp ZXMNCj4+Pj4+Pj4+Pj4+IHBhY2tldHMgYmFzZWQgb24NCj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+ Pj4+PiBwb3NzaWJsZSBjb21iaW5hdGlvbiBvZiBvbmUgb3IgbW9yZSBoZWFkZXINCj4+Pj4+Pj4+ Pj4+IGZpZWxkcywgc3VjaCBhcw0KPj4+Pj4+IHNvdXJjZQ0KPj4+Pj4+Pj4+Pj4gYWRkcmVzcywg ZGVzdGluYXRpb24gYWRkcmVzcywgRFMgZmllbGQsIHByb3RvY29sDQo+Pj4+Pj4+Pj4+PiBJRCwg c291cmNlDQo+Pj4+Pj4gcG9ydA0KPj4+Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+Pj4+IGRlc3RpbmF0 aW9uIHBvcnQgbnVtYmVycywgYW5kIGFueSBvdGhlcg0KPj4+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24u DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBhcyBk ZXNjcmliZWQgaW4gdGhlDQo+Pj4+Pj4+Pj4+PiBmcmFtZXdvcmsgZG9jdW1lbnQNCj4+Pj4+Pj4+ Pj4gd291bGQNCj4+Pj4+Pj4+Pj4+IHNlZW0gdG8gYmUgbGltaXRlZCBpbiB3aGF0IGl0IGNhbiBj bGFzc2lmeT8gIFRoZQ0KPj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBpZGVudGlmaWVyIGxv b2t1cCBkb2VzIG5vdCBzZWVtDQo+Pj4+Pj4+Pj4+PiB0byBiZSBhIHNpZ25pZmljYW50IG9wdGlt aXphdGlvbg0KPj4+Pj4+Pj4gb3Zlcg0KPj4+Pj4+Pj4+Pj4gYSBwYWNrZXQtYmFzZWQgNS10dXBs ZSBsb29rdXA/ICBUaGVyZSBzZWVtcyB0byBiZQ0KPj4+Pj4+Pj4+Pj4gc29tZSBtaXNzaW5nDQo+ Pj4+Pj4+PiBkZXRhaWwNCj4+Pj4+Pj4+Pj4+IHdydCBob3cgY2xhc3NpZmljYXRpb24gaW5mb3Jt YXRpb24gaXMgZGV0ZXJtaW5lZA0KPj4+Pj4+Pj4+Pj4gYW5kIHJldXNlZD8NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiBXaGVuIHRoaW5raW5nIGFib3V0IGhpZ2hlciBsZXZlbCBzZXJ2aWNlcywg ZS5nLiwNCj4+Pj4+Pj4+Pj4+IEhUVFAgYW5kIFRMUw0KPj4+Pj4+Pj4+PiBlbmNyeXB0ZWQNCj4+ Pj4+Pj4+Pj4+IGZsb3dzLCBhIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVyIHNlZW1zDQo+Pj4+Pj4+ Pj4+PiBpbmFkZXF1YXRlPyAgSSB3YXMgYWxzbw0KPj4+Pj4+Pj4+PiB3b25kZXJpbmcNCj4+Pj4+ Pj4+Pj4+IGhvdyBpbmRlcGVuZGVudCBITFMgc2VnbWVudCByZXF1ZXN0cyBtaWdodCBiZQ0KPj4+ Pj4+Pj4+Pj4gY2xhc3NpZmllZCBhbmQNCj4+Pj4+Pj4+Pj4gYXNzb2NpYXRlZD8NCj4+Pj4+Pj4+ Pj4+IFdlcmUgdGhlc2UgdHlwZXMgb2YgdXNlIGNhc2VzIGRpc2N1c3NlZCBpbiB0aGUNCj4+Pj4+ Pj4+Pj4+IEJvRj8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiB0aGFueC4NCj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbToNCj4+Pj4+Pj4+Pj4+PiBuc2MtYm91bmNl c0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPj4+Pj4+Pj4gT2YNCj4+Pj4+Pj4+Pj4+PiBSb24gUGFya2VyIFNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMTEsIDIwMTMNCj4+Pj4+Pj4+Pj4+PiAxMDoxNiBQTSBUbzogU3VtYW5kcmEg TWFqZWU7IFRob21hcyBOYXJ0ZW47DQo+Pj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnIFN1YmplY3Q6 IFJlOiBbbnNjXSBDdXJyZW50DQo+Pj4+Pj4+Pj4+Pj4gUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFN1bWFuZHJhLA0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4gQXMgd2FzIGRpc2N1c3NlZCBpbiBWYW5jb3V2ZXIsIHRoZXJlIGFyZQ0KPj4+Pj4+Pj4+ Pj4+IGFscmVhZHkgbWFueSBleGlzdGluZyB3YXlzDQo+Pj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+ Pj4gYWNjb21wbGlzaCBzZXJ2aWNlIGNoYWluaW5nLiAgICAgQnV0IG5vbmUgb2YNCj4+Pj4+Pj4+ Pj4+PiB0aGVtIHByb3ZpZGUgYQ0KPj4+Pj4+Pj4+PiBzdWZmaWNpZW50DQo+Pj4+Pj4+Pj4+Pj4g Y29tYmluYXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSwgZmxleGliaWxpdHksDQo+Pj4+Pj4+Pj4+ Pj4gYW5kDQo+Pj4gcmVzaWxpZW5jeS4NCj4+Pj4+PiBBDQo+Pj4+Pj4+Pj4+IHNpbmdsZQ0KPj4+ Pj4+Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gZW5jYXBzdWxhdGlvbiB3aWxsIGdvIGEgbG9uZyB3YXkN Cj4+Pj4+Pj4+Pj4+PiB0byBlbnN1cmluZyB0aGVzZQ0KPj4+Pj4+Pj4+PiBnb2Fscy4NCj4+Pj4+ Pj4+Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBtb3N0IGVmZmljaWVudA0KPj4+ Pj4+Pj4+Pj4+IGFwcHJvYWNoIGZvciBldmVyeQ0KPj4+Pj4+Pj4+PiBzaW5nbGUNCj4+Pj4+Pj4+ Pj4+PiBuZXR3b3JrIHRvcG9sb2d5IGFuZCBldmVyeSBzaW5nbGUgdXNlIGNhc2UsIGJ1dA0KPj4+ Pj4+Pj4+Pj4+IGl0cyB1YmlxdWl0b3VzDQo+Pj4+Pj4+PiBuYXR1cmUNCj4+Pj4+Pj4+Pj4+PiBz aG91bGQgaW1wcm92ZSBpdHMgYWRvcHRpb24uDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBS b24NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gRnJvbTogU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+Pj4+PiBbbWFpbHRv OlMuTWFqZWVARjUuY29tXSBTZW50OiBNb25kYXksIE5vdmVtYmVyDQo+Pj4+Pj4+Pj4+Pj4gMTEs IDIwMTMgMTA6MTAgUE0gVG86IFJvbiBQYXJrZXI7IFRob21hcw0KPj4+Pj4+Pj4+Pj4+IE5hcnRl bjsgbnNjQGlldGYub3JnIFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50DQo+Pj4+Pj4+Pj4+Pj4g UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFJvbiwNCj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFuIGV4YW1wbGUg b2Ygb25lIHR5cGUgb2YNCj4+Pj4+Pj4+Pj4+PiBkZXJpdmF0aW9uLiBIb3dldmVyDQo+Pj4+Pj4+ Pj4+IHRoaXMNCj4+Pj4+Pj4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQgd2l0aCBjbGFzc2lmaWNh dGlvbiByZXN1bHQsDQo+Pj4+Pj4+Pj4+Pj4gYWdhaW4gb25lIG1vcmUNCj4+Pj4+Pj4+Pj4gZXhh bXBsZS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gQWxsIGZsb3dzIGZyb20gdGhlIHNh bWUgc291cmNlIElQIGRvIG5vdA0KPj4+Pj4+Pj4+Pj4+Pj4gbmVjZXNzYXJpbHkgZm9sbG93DQo+ Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+IHNhbWUNCj4+Pj4+Pj4+Pj4+PiBjaGFpbi4gQ29ycmVjdC4g SXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQNCj4+Pj4+Pj4+Pj4+PiBhbGwgdHJhbnNhY3Rp b24gb2YgdGhlIHNhbWUNCj4+Pj4+Pj4+Pj4gZmxvdw0KPj4+Pj4+Pj4+Pj4+IGZvbGxvdyB0aGUg c2FtZSBjaGFpbiBlaXRoZXIuIFNvIHdoeSBzdG9wIGF0DQo+Pj4+Pj4+Pj4+Pj4gZmxvdyBpdHNl bGYuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBBZ2FpbiB0aGUgcG9pbnQgaGVyZSBpcyB0 aGF0IGRvIHdlIGFsd2F5cyBuZWVkDQo+Pj4+Pj4+Pj4+Pj4gU0ZDIGhlYWRlciBvcg0KPj4+Pj4g Tm90Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gU3VtYW5kcmENCj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJv bTogUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+Pj4+IFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbV0gU2VudDoNCj4+Pj4+Pj4+Pj4+PiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEz IDc6MDIgUE0gVG86IFN1bWFuZHJhDQo+Pj4+Pj4+Pj4+Pj4gTWFqZWU7IFRob21hcyBOYXJ0ZW47 IG5zY0BpZXRmLm9yZyBTdWJqZWN0OiBSRToNCj4+Pj4+Pj4+Pj4+PiBbbnNjXSBDdXJyZW50IFBy b3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwN Cj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFRoZSBpbnRlbnRpb24gb2Ygc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZyBpcw0KPj4+Pj4+Pj4+Pj4+IHRvIGFsbG93IGZvciBvcGVyYXRpb24NCj4+ Pj4+Pj4+Pj4gYXQNCj4+Pj4+Pj4+Pj4+PiB0aGUgZnVsbHkgcXVhbGlmaWVkIGZsb3cgbGV2ZWws IG9yIGV2ZW4gZmluZXINCj4+Pj4+Pj4+Pj4+PiBncmFpbmVkIGF0IHRoZQ0KPj4+Pj4+Pj4+PiB0 cmFuc2FjdGlvbg0KPj4+Pj4+Pj4+Pj4+IGxldmVsICh0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9u IG1hdHRlciBmb3IgdGhlDQo+Pj4+Pj4+Pj4+Pj4gUERQKS4NCj4+PiBBbGwNCj4+Pj4+PiBmbG93 cw0KPj4+Pj4+Pj4+PiBmcm9tDQo+Pj4+Pj4+Pj4+Pj4gdGhlIHNhbWUgc291cmNlIElQIGRvIG5v dCBuZWNlc3NhcmlseSBmb2xsb3cNCj4+Pj4+Pj4+Pj4+PiB0aGUgc2FtZSBjaGFpbi4NCj4+Pj4+ Pj4+IFNvdXJjZQ0KPj4+Pj4+Pj4+Pj4+IElQLCB0aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlm eSB0aGUgY2hhaW4gSUQuDQo+Pj4+Pj4+Pj4+Pj4gQW5vdGhlcg0KPj4+Pj4gaW50ZW50aW9uDQo+ Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHRvIG9w ZXJhdGUgb3Zlcg0KPj4+Pj4+Pj4+Pj4+IGFueSBuZXR3b3JrDQo+Pj4+Pj4gdG9wb2xvZ3kNCj4+ Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4+IG5vdCBiZSBsaW1pdGVkIHRvIGEgc2luZ2xlIExBTi4g ICBUaHVzLCB3aGlsZQ0KPj4+Pj4+Pj4+Pj4+IFZMQU4gbWF5IGJlIHBhcnQNCj4+PiBvZg0KPj4+ Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+IHRyYW5zcG9ydCwgaXQgZG9lcyBub3QgYWRlcXVhdGVseSBp ZGVudGlmeSB0aGUNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGNoYWluLA0KPj4+Pj4+Pj4gZWl0aGVy Lg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gUm9uDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IFN1bWFu ZHJhIE1hamVlDQo+Pj4+Pj4+Pj4+Pj4gW21haWx0bzpTLk1hamVlQEY1LmNvbV0gU2VudDogTW9u ZGF5LCBOb3ZlbWJlcg0KPj4+Pj4+Pj4+Pj4+IDExLCAyMDEzIDk6NTYgUE0gVG86IFJvbiBQYXJr ZXI7IFRob21hcyBOYXJ0ZW47DQo+Pj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnIFN1YmplY3Q6IFJF OiBbbnNjXSBDdXJyZW50DQo+Pj4+Pj4+Pj4+Pj4gUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFJvbiwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFRo ZSBzZXJ2aWNlIGhlYWRlciBpcyBtZWFudCB0byBjYXJyeSB0aGUNCj4+Pj4+Pj4+Pj4+PiBjb250 ZXh0IHdoaWNoIGNhbg0KPj4+Pj4+ICphbHNvKg0KPj4+Pj4+Pj4+Pj4+IGJlIGRlcml2ZWQgKGZv ciBleGFtcGxlIHVzZSBzb3VyY2UgaXAgYW5kIHZsYW4NCj4+Pj4+Pj4+Pj4+PiB0byBpZGVudGlm eSBjaGFpbklEIGFuZCBwb3NpdGlvbikgb3INCj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0ZWQgYXMg cGFydCBvZiBhbm90aGVyIHR1bm5lbCBoZWFkZXIuDQo+Pj4+Pj4+Pj4+Pj4gU28gdGhpcyBjb3Vs ZCBiZSBvcHRpb25hbCBJTUhPLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+Pj4+IFttYWlsdG86 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0gU2VudDoNCj4+Pj4+Pj4+Pj4+PiBNb25k YXksIE5vdmVtYmVyIDExLCAyMDEzIDQ6MzYgUE0gVG86IFN1bWFuZHJhDQo+Pj4+Pj4+Pj4+Pj4g TWFqZWU7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZyBTdWJqZWN0OiBSRToNCj4+Pj4+Pj4+ Pj4+PiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEFzIEkgdW5k ZXJzdGFuZCBpdCwgYW4gU0ZDIHBhY2tldCB0cmF2ZXJzaW5nDQo+Pj4+Pj4+Pj4+Pj4gZnJvbSBQ RFAgdG8gU0Ygb3IgZnJvbQ0KPj4+Pj4+Pj4+PiBTRg0KPj4+Pj4+Pj4+Pj4+IHRvIFNGIHdpbGwg bG9vayBsaWtlOg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSsgfCAgICAgICAgInRyYW5zcG9ydCINCj4+Pj4+Pj4+Pj4+PiB8ICstLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rIHwgICAgICBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4gaGVhZGVyICAgIHwg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgfA0KPj4+Pj4+Pj4+Pj4+IG9yaWdpbmFsIElQIGhl YWRlciAgfA0KPj4+Pj4+Pj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rIHwNCj4+Pj4+ Pj4+Pj4+PiB8ICBvcmlnaW5hbCBJUCB8IHBheWxvYWQNCj4+Pj4+PiB8DQo+Pj4+Pj4+Pj4+Pj4g fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+Pj4+Pj4+Pj4+ ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBX aGVyZSBzZXJ2aWNlIGhlYWRlciBjb250YWlucywgYXQgYSBtaW5pbXVtLA0KPj4+Pj4+Pj4+Pj4+ IGVub3VnaCBpbmZvcm1hdGlvbiB0bw0KPj4+Pj4+Pj4+PiBhbGxvdw0KPj4+Pj4+Pj4+Pj4+IHRo ZSBwYWNrZXQgdG8gYmUgcHJvcGFnYXRlZCBhbG9uZyB0aGUgZnVsbA0KPj4+Pj4+Pj4+Pj4+IGxl bmd0aCBvZiB0aGUgY2hhaW4sIGFuZCBvcHRpb25hbGx5LCBvdGhlcg0KPj4+Pj4+Pj4+Pj4+IG1l dGFkYXRhIHRoYXQgZW5oYW5jZXMgdGhlIG9wZXJhdGlvbiBvZg0KPj4+Pj4+IG9uZQ0KPj4+Pj4+ Pj4+Pj4+IG9yDQo+Pj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMu DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBBbmQgd2hlcmUgInRyYW5zcG9ydCIgY291bGQg Y29uY2VpdmFibHkgYmUgYW55DQo+Pj4+Pj4+Pj4+Pj4gb2YsIGJ1dCBub3QgbGltaXRlZA0KPj4+ Pj4+Pj4+PiB0bzoNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ICogRXRoZXJuZXQgKiBFdGhl cm5ldCArIExMQzIgKiBFdGhlcm5ldCArIE1QTFMNCj4+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsg SVAgKyBHUkUgKiBFdGhlcm5ldCArIElQICtVRFANCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4gQWxzbywgIm9yaWdpbmFsIiBpbiB0aGUgZGlhZ3JhbSBhYm92ZSBpcyBu b3QNCj4+Pj4+Pj4+Pj4+PiBtZWFudCB0byBpbXBseSBpbW11dGFiaWxpdHksIGJ1dCByYXRoZXIg dG8NCj4+Pj4+Pj4+Pj4+PiBzcGVjaWZ5IHRoZSBwYWNrZXQgdGhhdCBpcw0KPj4+Pj4+IHByb3Bh Z2F0ZWQNCj4+Pj4+Pj4+Pj4+PiBmcm9tIHByZWNlZGluZyBlbnRpdHkgdG8gc3VjY2VlZGluZyBl bnRpdHksDQo+Pj4+Pj4+Pj4+Pj4gcHJpb3IgdG8gZW5jYXBzdWxhdGlvbi4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IFJvbg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOg0KPj4+Pj4+Pj4+Pj4+IG5zYy1i b3VuY2VzQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmDQo+Pj4+Pj4+PiBPZg0KPj4+Pj4+Pj4+Pj4+IFN1bWFuZHJhIE1hamVlIFNl bnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMNCj4+Pj4+Pj4+Pj4+PiA2OjQ2IFBNIFRvOiBU aG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW25z Y10gQ3VycmVudCBQcm9wb3NlZCBTRkMNCj4+Pj4+Pj4+Pj4+PiBjaGFydGVyDQo+Pj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+PiBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcNCj4+Pj4+ Pj4+Pj4+PiBFbmNhcHN1bGF0aW9uOiBBIGRvY3VtZW50DQo+Pj4+PiB3aWxsDQo+Pj4+Pj4+Pj4+ Pj4gZGVzY3JpYmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUNCj4+Pj4+Pj4+ Pj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+PiBmb3IgY29u dmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluIGFuZA0KPj4+Pj4+Pj4+Pj4+IHRoZSBz ZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+Pj4+Pj4+IHBhdGgsDQo+Pj4+Pj4+Pj4+Pj4gYW5kIGZvciBj b21tdW5pY2F0aW5nIGNvbnRleHQgaW5mb3JtYXRpb24NCj4+Pj4+Pj4+Pj4+PiBiZXR3ZWVuIG5v ZGVzDQo+Pj4gdGhhdA0KPj4+Pj4+Pj4+Pj4+IGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4g SXQgaXMgaW50ZW5kZWQNCj4+Pj4+Pj4+Pj4+PiB0aGF0IHRoZQ0KPj4+Pj4+Pj4+PiBlbmNhcHN1 bGF0aW9uDQo+Pj4+Pj4+Pj4+Pj4gYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0 IGlzIGFwcGxpZWQNCj4+Pj4+Pj4+Pj4+PiBhbmQgdGhlIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4gdGhh dA0KPj4+Pj4+Pj4+Pj4+IGlzIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2FtZQ0K Pj4+Pj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gbWF5IGJlDQo+Pj4+Pj4gdXNlZA0KPj4+Pj4+Pj4g b24NCj4+Pj4+Pj4+Pj4+PiBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUg bmV0d29yaw0KPj4+Pj4+Pj4+Pj4+IGxheWVyIG9yIGF0IGFueSBvdGhlciBsYXllciwgYW5kIHRo ZSBzYW1lDQo+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUNCj4+ Pj4+Pj4+IGNvbnN0cnVjdGlvbg0KPj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4+IHNlcnZpY2Ug ZnVuY3Rpb24gcGF0aHMgcmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsDQo+Pj4+Pj4+Pj4+Pj4gc2Vy dmljZS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IFtTTV0gV2hhdCBkb2VzIGl0IG1lYW4g YnkgYSBzaW5nbGUNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlLWxldmVsIGVuY2Fwc3VsYXRpb24sDQo+ Pj4+Pj4gYQ0KPj4+Pj4+Pj4+PiBuZXcNCj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uIGZvcm1h dCBvciBhbiBhYmlsaXR5IHRvIHNlbGVjdA0KPj4+Pj4+Pj4+Pj4+IG9uZSBlbmNhcHN1bGF0aW9u IGZvcm1hdCB0aGF0DQo+Pj4+Pj4+Pj4+IGZpdHMNCj4+Pj4+Pj4+Pj4+PiB0aGUgbmVlZCBmb3Ig YSBnaXZlbiBzZXJ2aWNlIGNoYWluPyBUaGUgYWJpbGl0eQ0KPj4+Pj4+Pj4+Pj4+IHRvIHNlbGVj dCBhIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gd291bGQgYmUNCj4+Pj4+Pj4+IGENCj4+Pj4+Pj4+ Pj4+PiBtYW5hZ2VtZW50IHBsYW5lIGRlY2lzaW9uLiBUaGVyZSBhcmUgcXVpdGUgYQ0KPj4+Pj4+ Pj4+Pj4+IGZldyBleGlzdGluZyBlbmNhcHN1bGF0aW9uIG1ldGhvZHMgdGhhdA0KPj4+Pj4+Pj4+ PiBjYW4NCj4+Pj4+Pj4+Pj4+PiBwb3NzaWJseSBiZSByZXVzZWQgdG8gcHJvdmlkZSBjb250ZXh0 DQo+Pj4+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMuIEkgaGF2 ZQ0KPj4+Pj4+IHNlZW4NCj4+Pj4+Pj4+Pj4+PiBtZW50aW9uIG9mIEdSRSwgZm9yIEhUVFAgYmFz ZWQgYXBwbGljYXRpb25zDQo+Pj4+Pj4+Pj4+Pj4gY29udGV4dHMgYXJlIHRyYW5zZmVycmVkIHZp YSBoZWFkZXJzLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSBGcm9tOg0KPj4+Pj4+Pj4+Pj4+IG5zYy1ib3VuY2VzQGll dGYub3JnDQo+Pj4+Pj4+Pj4+Pj4gW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmDQo+Pj4+Pj4+PiBPZg0KPj4+Pj4+Pj4+Pj4+IFRob21hcyBOYXJ0ZW4gU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAwNiwNCj4+Pj4+Pj4+Pj4+PiAyMDEzIDExOjA3IEFNIFRvOiBuc2NAaWV0 Zi5vcmcgU3ViamVjdDogW25zY10NCj4+Pj4+Pj4+Pj4+PiBDdXJyZW50IFByb3Bvc2VkIFNGQyBj aGFydGVyDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBIaS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+IEN1cnJlbnQgY2hhcnRlciBjYW4gYmUgZm91bmQgYXQNCj4+Pj4+Pj4+Pj4+PiBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLQ0KPj4+Pj4+Pj4+Pj4+IGll dGYtc2ZjLy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEl0IGNvbnRhaW5zIHRoZSByZXZp c2VkIG1hbmFnZW1lbnQgdGV4dCBhcyB3ZWxsDQo+Pj4+Pj4+Pj4+Pj4gYXMgdXBkYXRlZA0KPj4+ Pj4+Pj4+PiBtaWxlc3RvbmVzLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gQWxsIGtub3du IGlzc3VlcyBoYXZlIGJlZW4gYWRkcmVzc2VkLiBJZiB0aGVyZQ0KPj4+Pj4+Pj4+Pj4+IGFyZSBh bnkgcmVtYWluaW5nDQo+Pj4+Pj4+Pj4+IGlzc3VlcywNCj4+Pj4+Pj4+Pj4+PiBwbGVhc2Ugc3Bl YWsgdXAhDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBDaGFydGVyIGNoYXJ0ZXItaWV0Zi1z ZmMtMDAtMDQNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE5ldHdvcmtzLCBzZXJ2ZXJzLCBz dG9yYWdlIHRlY2hub2xvZ2llcywgYW5kDQo+Pj4+Pj4+Pj4+Pj4gYXBwbGljYXRpb25zLCBoYXZl IGFsbCB1bmRlcmdvbmUgc2lnbmlmaWNhbnQNCj4+Pj4+Pj4+Pj4+PiBjaGFuZ2UgaW4gcmVjZW50 IHllYXJzIHdpdGggdGhlIGludHJvZHVjdGlvbg0KPj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+PiB2 aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kDQo+Pj4+Pj4+Pj4+Pj4gb3JjaGVz dHJhdGlvbi4gU2VydmljZQ0KPj4+Pj4+Pj4gZGVsaXZlcnkNCj4+Pj4+Pj4+Pj4gaXMNCj4+Pj4+ Pj4+Pj4+PiBjdXJyZW50bHkgYm90aCBhIHRlY2huaWNhbCBhbmQgb3JnYW5pemF0aW9uYWwNCj4+ Pj4+Pj4+Pj4+PiBjaGFsbGVuZ2UgdGhhdA0KPj4+Pj4+Pj4gaW52b2x2ZXMNCj4+Pj4+Pj4+Pj4+ PiBzaWduaWZpY2FudCBtb2RpZmljYXRpb24gdG8gdGhlIG5ldHdvcmsNCj4+Pj4+Pj4+Pj4+PiBj b25maWd1cmF0aW9uLiBTZXJ2aWNlcyBhcmUgdHlwaWNhbGx5DQo+Pj4+Pj4+Pj4+Pj4gaW1wbGVt ZW50ZWQgYnkgdGhlIG9yZGVyZWQgY29tYmluYXRpb24gb2YgYQ0KPj4+Pj4+Pj4+Pj4+IG51bWJl ciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSBkZXBsb3llZA0KPj4+Pj4+Pj4+Pj4+IGF0 IGRpZmZlcmVudCBwb2ludHMgd2l0aGluDQo+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+PiBuZXR3 b3JrLiBUb2RheSwgYSBjb21tb24gZGVwbG95bWVudCBtb2RlbCBoYXMNCj4+Pj4+Pj4+Pj4+PiBz ZXJ2aWNlIGZ1bmN0aW9ucyBwaHlzaWNhbGx5IGluc2VydGVkIG9uIHRoZQ0KPj4+Pj4+Pj4+Pj4+ IGRhdGEgZm9yd2FyZGluZyBwYXRoIGJldHdlZW4gY29tbXVuaWNhdGluZw0KPj4+Pj4+Pj4+Pj4+ IHBlZXJzLg0KPj4+Pj4+Pj4+PiBHb2luZw0KPj4+Pj4+Pj4+Pj4+IGZvcndhcmQsIGhvd2V2ZXIs IHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdG8NCj4+Pj4+Pj4+Pj4+PiBhIGRpZmZlcmVudCBt b2RlbCwNCj4+Pj4+Pj4+Pj4gd2hlcmUNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBh cmUgbm90IHJlcXVpcmVkIHRvIHJlc2lkZSBvbg0KPj4+Pj4+Pj4+Pj4+IHRoZSBkZWZhdWx0IGRh dGENCj4+Pj4+Pj4+IHBhdGgNCj4+Pj4+Pj4+Pj4+PiBhbmQgdHJhZmZpYyBpcyBpbnN0ZWFkIHN0 ZWVyZWQgdGhyb3VnaA0KPj4+Pj4+Pj4+Pj4+IHNlcnZpY2VzLCB3aGVyZXZlciB0aGV5IGFyZQ0K Pj4+Pj4+Pj4+PiBkZXBsb3llZC4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEZvciBhIGdp dmVuIHNlcnZpY2UsIHRoZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlDQo+Pj4+Pj4+Pj4+Pj4gcmVx dWlyZWQgc2VydmljZSBmdW5jdGlvbnMgYW5kIHRoZSBvcmRlciBpbg0KPj4+Pj4+Pj4+Pj4+IHdo aWNoIHRoZXkgYXJlIHRvIGJlIGFwcGxpZWQgaXMNCj4+Pj4+PiBjYWxsZWQNCj4+Pj4+Pj4+Pj4+ PiBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gKFNGQykuIFNpbmNlIGEgZ2l2ZW4NCj4+Pj4+Pj4+ Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIG1heSBiZSBhdmFpbGFibGUgb24gbW9yZSB0aGFuDQo+Pj4+ Pj4+Pj4+Pj4gb25lIG5vZGUgd2l0aGluIGEgbmV0d29yaywgYSBTZXJ2aWNlIEZ1bmN0aW9uDQo+ Pj4+Pj4+Pj4+Pj4gQ2hhaW4gaXMgaW5zdGFudGlhdGVkDQo+Pj4+Pj4+Pj4+IHZpYQ0KPj4+Pj4+ Pj4+Pj4+IHRoZSBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbg0KPj4+Pj4+ Pj4+Pj4+IGluc3RhbmNlcyBhbmQgdGhlIG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhleQ0KPj4+ Pj4+Pj4+Pj4+IGFyZSBwcm92aWRlZCwgdGhlcmVieSBmb3JtaW5nIGEgc2VydmljZQ0KPj4+Pj4+ Pj4+Pj4+IHRvcG9sb2d5OiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24NCj4+Pj4+ Pj4+Pj4+PiBQYXRoLiBUaGUgc2VydmljZSBmdW5jdGlvbnMNCj4+Pj4+PiBtYXkNCj4+Pj4+Pj4+ Pj4+PiBiZSBhcHBsaWVkIGF0IGEgc3BlY2lmaWMgbGF5ZXIgd2l0aGluIHRoZQ0KPj4+Pj4+Pj4+ Pj4+IG5ldHdvcmsgcHJvdG9jb2wgc3RhY2sNCj4+Pj4+Pj4+Pj4gKG5ldHdvcmsNCj4+Pj4+Pj4+ Pj4+PiBsYXllciwgYXBwbGljYXRpb24gbGF5ZXIsIGV0Yy4pLg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pj4gVGhlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgd29ya2luZw0KPj4+ Pj4+Pj4+Pj4+IGdyb3VwIHdpbGwgZGV2ZWxvcCBuZXcgYXBwcm9hY2hlcyB0byBzZXJ2aWNlDQo+ Pj4+Pj4+Pj4+Pj4gZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuIEl0IHdpbGwgcHJvZHVjZSBhDQo+ Pj4+Pj4+Pj4+Pj4gZnJhbWV3b3JrIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIHRoYXQN Cj4+Pj4+Pj4+Pj4+PiBpbmNsdWRlcyB0aGUgbmVjZXNzYXJ5IHByb3RvY29scw0KPj4+Pj4+Pj4+ PiBvcg0KPj4+Pj4+Pj4+Pj4+IHByb3RvY29sIGV4dGVuc2lvbnMgdG8gY29udmV5IHRoZSBzZXJ2 aWNlIHBhdGgNCj4+Pj4+Pj4+Pj4+PiBhbmQgc2VydmljZSBwYXRoIGluZm9ybWF0aW9uIHRvIG5v ZGVzIHRoYXQNCj4+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMsIGFzIHdl bGwNCj4+Pj4+PiBhcw0KPj4+Pj4+Pj4+Pj4+IG1lY2hhbmlzbXMgZm9yIHN0ZWVyaW5nIHRyYWZm aWMgdGhyb3VnaCBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4gZnVuY3Rpb25zLiBUaGUNCj4+Pj4+Pj4+ Pj4gd29ya2luZw0KPj4+Pj4+Pj4+Pj4+IGdyb3VwIHdpbGwgYWxzbyBleGFtaW5lIHdoYXQgaW5m b3JtYXRpb24gbmVlZHMNCj4+Pj4+Pj4+Pj4+PiB0byBiZSBnYXRoZXJlZCBmcm9tDQo+Pj4+Pj4+ Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+IG5ldHdvcmsgYW5kIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1 cHBvcnQgb2YNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+Pj4+PiBjaGFpbmlu Zw0KPj4+Pj4+Pj4+Pj4+IGFuZCBob3cgdGhhdCBpbmZvcm1hdGlvbiBtYXkgYmUgbWFkZSBhdmFp bGFibGUNCj4+Pj4+Pj4+Pj4+PiB0byBub2RlcyB0aGF0IGltcGxlbWVudA0KPj4+Pj4+Pj4+PiB0 aGUNCj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IFNwZWNpZmljYWxseSwgdGhlIFNGQyBXRyBpcyBjaGFydGVyZWQgdG8NCj4+Pj4+Pj4+ Pj4+PiBkZWxpdmVyIHRoZQ0KPj4+IGZvbGxvd2luZzoNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+IDEpIFByb2JsZW0gU3RhdGVtZW50OiBUaGlzIGRvY3VtZW50IHdpbGwNCj4+Pj4+Pj4+Pj4+ PiBwcm92aWRlIGEgc3VtbWFyeSBvZg0KPj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+IHByb2JsZW0g c3BhY2UgdG8gYmUgYWRkcmVzc2VkIGJ5IHRoZSBXRw0KPj4+Pj4+Pj4+Pj4+IGluY2x1ZGluZyBl eGFtcGxlDQo+Pj4+Pj4gaGlnaC0NCj4+Pj4+Pj4+Pj4+PiBsZXZlbCB1c2UgY2FzZXMuIEFkZGl0 aW9uYWxseSwgdGhlIFdHIHdpbGwNCj4+Pj4+Pj4+Pj4+PiBub3JtYWxpemUNCj4+Pj4+Pj4+IG5v bWVuY2xhdHVyZQ0KPj4+Pj4+Pj4+Pj4+IGFuZCBkZWZpbml0aW9ucyBmb3Igc2VydmljZSBmdW5j dGlvbiBjaGFpbmluZy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IDIpIEFyY2hpdGVjdHVy ZTogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYQ0KPj4+Pj4+Pj4+Pj4+IGRlc2NyaXB0aW9u IG9mDQo+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+PiBhcmNoaXRlY3R1cmFsIGJ1aWxkaW5nIGJsb2Nr cyBhbmQgdGhlaXINCj4+Pj4+Pj4+Pj4+PiByZWxhdGlvbnNoaXBzDQo+Pj4+Pj4gaW5jbHVkaW5n DQo+Pj4+Pj4+Pj4+Pj4gaW50ZXJjb25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVz LA0KPj4+Pj4+Pj4+Pj4+IG1hbmFnZW1lbnQsIGRpYWdub3N0aWNzLCBkZXNpZ24gYW5hbHlzaXMs IGFuZA0KPj4+Pj4+Pj4+Pj4+IHNlY3VyaXR5IG1vZGVscywgYXMgd2VsbA0KPj4+Pj4gYXMNCj4+ Pj4+Pj4+Pj4+PiByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiAzKSBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5p bmcNCj4+Pj4+Pj4+Pj4+PiBFbmNhcHN1bGF0aW9uOiBBIGRvY3VtZW50DQo+Pj4+Pj4gd2lsbA0K Pj4+Pj4+Pj4+Pj4+IGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5l DQo+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4gZm9ybWF0DQo+Pj4+Pj4+Pj4+ Pj4gZm9yIGNvbnZleWluZyB0aGUgc2VydmljZSBmdW5jdGlvbiBjaGFpbiBhbmQNCj4+Pj4+Pj4+ Pj4+PiB0aGUgc2VydmljZSBmdW5jdGlvbg0KPj4+Pj4+Pj4+PiBwYXRoLA0KPj4+Pj4+Pj4+Pj4+ IGFuZCBmb3IgY29tbXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uDQo+Pj4+Pj4+Pj4+Pj4g YmV0d2VlbiBub2Rlcw0KPj4+IHRoYXQNCj4+Pj4+Pj4+Pj4+PiBpbXBsZW1lbnQgc2VydmljZSBm dW5jdGlvbnMuIEl0IGlzIGludGVuZGVkDQo+Pj4+Pj4+Pj4+Pj4gdGhhdCB0aGUNCj4+Pj4+Pj4+ Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4+IGJlIGFnbm9zdGljIHRvIHRoZSBsYXllciBh dCB3aGljaCBpdCBpcyBhcHBsaWVkDQo+Pj4+Pj4+Pj4+Pj4gYW5kIHRoZSBzZXJ2aWNlDQo+Pj4+ Pj4+Pj4+IHRoYXQNCj4+Pj4+Pj4+Pj4+PiBpcyBiZWluZyBjb25zdHJ1Y3RlZC4gVGhhdCBpcywg dGhlIHNhbWUNCj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uIG1heSBiZQ0KPj4+Pj4+IHVzZWQN Cj4+Pj4+Pj4+IG9uDQo+Pj4+Pj4+Pj4+Pj4gYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6 ZWQgYXQgdGhlIG5ldHdvcmsNCj4+Pj4+Pj4+Pj4+PiBsYXllciBvciBhdCBhbnkgb3RoZXIgbGF5 ZXIsIGFuZCB0aGUgc2FtZQ0KPj4+Pj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBm b3IgdGhlDQo+Pj4+Pj4+PiBjb25zdHJ1Y3Rpb24NCj4+Pj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+ PiBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbA0KPj4+Pj4+ Pj4+Pj4+IHNlcnZpY2UuDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiA0KSBDb250cm9sIFBs YW5lIE1lY2hhbmlzbXM6IEEgc2V0IG9mIGRvY3VtZW50cw0KPj4+Pj4+Pj4+Pj4+IHdpbGwgYmUN Cj4+Pj4+PiBkZXZlbG9wZWQgdG8NCj4+Pj4+Pj4+Pj4+PiBkZXNjcmliZSByZXF1aXJlbWVudHMg YW5kIHByb3RvY29scyBuZWNlc3NhcnkNCj4+Pj4+Pj4+Pj4+PiB0byBjb252ZXkNCj4+Pj4+Pj4+ Pj4gaW5mb3JtYXRpb24NCj4+Pj4+Pj4+Pj4+PiB0byBzZXJ2aWNlIGZ1bmN0aW9uIGltcGxlbWVu dGF0aW9uIHBvaW50cy4NCj4+Pj4+Pj4+Pj4+PiBXaGVyZSBwb3NzaWJsZSwNCj4+Pj4+Pj4+Pj4g ZXhpc3RpbmcNCj4+Pj4+Pj4+Pj4+PiBJRVRGIHByb3RvY29scyB3aWxsIGJlIHVzZWQgYW5kIGV4 dGVuZGVkLiBBbGwNCj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbA0KPj4+Pj4+Pj4gZXh0ZW5zaW9ucw0K Pj4+Pj4+Pj4+Pj4+IHdvcmsgc2hvdWxkIGJlIGNhcnJpZWQgb3V0IGluIHRoZSB3b3JraW5nDQo+ Pj4+Pj4+Pj4+Pj4gZ3JvdXBzIHJlc3BvbnNpYmxlIGZvcg0KPj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+ Pj4+Pj4+PiBwcm90b2NvbHMgYmVpbmcgbW9kaWZpZWQgaW4gY29vcmRpbmF0aW9uIHdpdGgNCj4+ Pj4+Pj4+Pj4+PiB0aGlzIHdvcmtpbmcNCj4+Pj4+Pj4+IGdyb3VwLA0KPj4+Pj4+Pj4+Pj4+IGJ1 dCBtYXkgYmUgZG9uZSBpbiB0aGlzIHdvcmtpbmcgZ3JvdXAgYWZ0ZXINCj4+Pj4+Pj4+Pj4+PiBh Z3JlZW1lbnQgd2l0aCBhbGwNCj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+PiByZWxldmFudCBXRyBj aGFpcnMgYW5kIHJlc3BvbnNpYmxlIEFEcy4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IDUp IE1hbmFnZWFiaWxpdHk6IFdvcmsgb24gdGhlIG1hbmFnZW1lbnQgYW5kDQo+Pj4+Pj4+Pj4+Pj4g Y29uZmlndXJhdGlvbiBvZg0KPj4+Pj4+Pj4gc2VydmljZQ0KPj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9u cyBpbiBzdXBwb3J0IG9mIFNGQyBjb21wb25lbnRzIHdpbGwNCj4+Pj4+Pj4+Pj4+PiBjZXJ0YWlu bHkgYmUNCj4+Pj4+PiBuZWVkZWQsDQo+Pj4+Pj4+Pj4+Pj4gYnV0IGZpcnN0IG5lZWRzIHRvIGJl IGJldHRlciB1bmRlcnN0b29kIGFuZA0KPj4+Pj4+Pj4+Pj4+IHNjb3BlZC4NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IFByb3Bvc2VkIE1pbGVzdG9uZXMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwNCj4+Pj4+Pj4+Pj4+ PiBkb2N1bWVudChzKSBkZWZpbmluZyB0aGUNCj4+Pj4+Pj4+Pj4gcHJvYmxlbQ0KPj4+Pj4+Pj4+ Pj4+IHN0YXRlbWVudCBhbmQgY29yZSB1c2UgY2FzZXMgZm9yIFNlcnZpY2UNCj4+Pj4+Pj4+Pj4+ PiBGdW5jdGlvbiBDaGFpbmluZw0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gTWF5IDIwMTQg Q29uc3VsdCB3aXRoIE9QUyBBcmVhIG9uIHBvc3NpYmxlDQo+Pj4+Pj4+Pj4+Pj4gY2hhcnRlciBt b2RpZmljYXRpb25zIGZvciBtYW5hZ2VtZW50IGFuZA0KPj4+Pj4+Pj4+Pj4+IGNvbmZpZ3VyYXRp b24gb2YgU0ZDIGNvbXBvbmVudHMNCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IEphbiAyMDE1 IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQNCj4+Pj4+Pj4+Pj4+PiBkZWZp bmluZyB0aGUNCj4+Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+Pj4+Pj4+Pj4gZm9yIFNGQw0K Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gSmFuIDIwMTUgU3VibWl0IHRvIElFU0cgcmVxdWly ZW1lbnRzIGZvciBhDQo+Pj4+Pj4+Pj4+Pj4gZ2VuZXJpYyBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu aW5nIGVuY2Fwc3VsYXRpb24NCj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbA0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gQXVnIDIwMTUgU3VibWl0IHRvIElFU0cgU3RhbmRhcmRzIFRyYWNrDQo+Pj4+ Pj4+Pj4+Pj4gZG9jdW1lbnQgc3BlY2lmeWluZyB0aGUNCj4+Pj4+Pj4+Pj4gZ2VuZXJpYw0KPj4+ Pj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgaGVhZGVyIGVuY2Fwc3VsYXRpb24N Cj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4gVGhvbWFzDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4NCm5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+PiBu c2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pg0KbnNjIG1haWxpbmcg bGlzdA0KPj4+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+DQpuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+ Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+ Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4NCj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBuc2MgbWFpbGlu Zw0KPj4+Pj4+IGxpc3QgbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXyBuc2MgbWFpbGluZw0KPj4+Pj4+IGxpc3QgbnNjQGlldGYub3Jn DQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBuc2MgbWFp bGluZw0KPj4+Pj4+IGxpc3QgbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fIG5zYyBtYWlsaW5nIGxpc3QNCj4+PiBuc2NAaWV0Zi5v cmcgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fIG5zYyBtYWlsaW5nIGxpc3QN Cj4+IG5zY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBu c2MgbWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXyBuc2MgbWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXyBuc2MgbWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZyBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5z Y0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From hongyu.li@huawei.com Thu Nov 14 18:31:54 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46B311E8119 for ; Thu, 14 Nov 2013 18:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB0f9ETehxBX for ; Thu, 14 Nov 2013 18:31:50 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A067B11E8169 for ; Thu, 14 Nov 2013 18:31:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXX35049; Fri, 15 Nov 2013 02:31:47 +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; Fri, 15 Nov 2013 02:31:26 +0000 Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 15 Nov 2013 02:31:46 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 10:31:41 +0800 From: "Hongyu Li (Julio)" To: Ken Gray , "Surendra Kumar (smkumar)" , "Jim Guichard (jguichar)" , "Ron Parker" Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDhNOKetVd+0mYdBTNJtPCzpoi7T2A///bpACAAToXAIAASqwAgAAE9QCAAAKuAIAAAZMAgAADEQCAAAGZgIAAGsaAgAAIHgCAARRiEA== Date: Fri, 15 Nov 2013 02:31:41 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E997203@SZXEMA509-MBX.china.huawei.com> References: <5677CCE3-617C-47C8-A539-F5585ADAF404@cisco.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 02:31:54 -0000 QmVmb3JlIHdlIG1vdmUgdG8gdmFyaWFudCBpbXBsZW1lbnRhdGlvbnMsIHdlIG5lZWQgdG8gaGF2 ZSBhIHJlYXNvbmFibGUgbG9naWNhbCBkZXNpZ24uIFRoYXQncyB3aHkgc2VwYXJhdGlvbiBvZiBk aWZmZXJlbnQgbGF5ZXJzIGlzIGltcG9ydGFudCBmb3IgdGhlIGFyY2hpdGVjdHVyZS4NCg0KSWYg d2UgaGF2ZSBpbiBtaW5kIHRoYXQgYmVzaWRlcyBvbW5pcG90ZW50IHBoeXNpY2FsIGJveCwgdGhl cmUgYXJlIGFsc28gZGVtYW5kcyBmcm9tIE5GViwgaXQgd291bGQgYmUgZWFzaWVyIHRvIGFncmVl IHRoYXQgc2VydmljZSBmdW5jdGlvbnMsIHNlcnZpY2UgY2hhaW4gZm9yd2FyZGluZyBsYXllciBh bmQgdHJhbnNwb3J0IGxheWVyIHNob3VsZCBiZSBzZXBhcmF0ZWQgaW4gdGhlIGFyY2hpdGVjdHVy ZS4gQmFzZWQgb24gdGhpcywgc2VydmljZSBmdW5jdGlvbnMgbWF5IGFsdGVyIGEgcGFja2V0LCBi dXQgdGhleSBkb24ndCBuZWVkIHRvIGFuZCBzaGFsbCBub3Qga25vdyB3aGF0J3MgdGhlIG5leHQg aG9wLCAnY2F1c2UgdGhpcyBpcyB0aGUgam9iIG9mIHNlcnZpY2UgY2hhaW4gZm9yd2FyZGluZyBs YXllci4NCg0KSG9uZ3l1DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBLZW4g R3JheSBbbWFpbHRvOmtncmF5QGp1bmlwZXIubmV0XSANClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIg MTUsIDIwMTMgMTo1MSBBTQ0KVG86IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgSmltIEd1aWNo YXJkIChqZ3VpY2hhcik7IFJvbiBQYXJrZXINCkNjOiBuc2NAaWV0Zi5vcmc7IEhvbmd5dSBMaSAo SnVsaW8pOyBEYXZpZCBBbGxhbiBJDQpTdWJqZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNzaWZp Y2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCg0K KzENCg0KRmFpci13YXJuaW5nIC0gSSdtIG5vdCBhIGh1Z2UgZmFuIG9mIGEgZmFuLW91dCBvZiBp bnRlcmZhY2UgZGVmaW5pdGlvbnMgKG1hbnkgb2Ygd2hpY2ggb25seSBzZWVtIHRvIGRpc2FwcGVh ciBpbiBpbXBsZW1lbnRhdGlvbiBiZWNhdXNlIG5vYm9keSByZWFsbHkgd2FzIGdvaW5nIHRvIGJ1 aWxkIGFueXRoaW5nIHNvIHN1cGVyLWF0b21pYykuDQoNClRoYXQgc2FpZCwgZnJvbSBhIHByYWN0 aWNhbCBwZXJzcGVjdGl2ZSwgYSBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBvcGVyYXRlIG9uIGEgcGFj a2V0IC4uLiBpdCBjYW4gdHJhbnNmb3JtIHRoZSBwYWNrZXQgLi4uSSBkb24ndCBzZWUgaG93IHlv dSBjYW4gcHJlY2x1ZGUgdGhpcy4gIEluIHRyYW5zZm9ybWluZyB0aGUgcGFja2V0LCBpdCBJUyBw b3RlbnRpYWxseSBhbHRlcmluZyB0aGUgZm9yd2FyZGluZyBvbiB0aGUgZWdyZXNzIHNpZGUgb2Yg dGhlIGZ1bmN0aW9uIC0gZGVwZW5kaW5nIG9uIHRoZSBsb2dpYyBpdCB1c2VkIHRvIGFsdGVyIHRo ZSBwYWNrZXQuICBVbmxlc3Mgd2UncmUgcHJvcG9zaW5nIGFsbCBvZiB0aGlzIHNvcnQgb2YgdHJh bnNmb3JtYXRpb24gbG9naWMgaXMgZ29pbmcgdG8gc3VkZGVubHkgYmUgZXh0ZXJuYWxpemVkIGZv ciBhbGwgc2VydmljZSBmdW5jdGlvbnMsIHRoZW4gYnJhbmNoaW5nIGlzIGxvZ2ljYWxseSBnb2lu ZyB0byBoYXBwZW4gLSBwb3RlbnRpYWxseSBkcml2ZW4gYnkgdGhlIHNlcnZpY2UgZnVuY3Rpb24u DQoNCkRlcGVuZGluZyBvbiBob3cgeW91IGRvICJmaXgtdXAiIG9yIHdoYXRldmVyIHlvdXIgY29t cGFueSBjYWxscyB0aGlzIGhhbmRvZmYsIHlvdSBpbnZvbHZlIChvciBkb24ndCkgc29tZSBhZGRp dGlvbmFsIGFjdGlvbnMgaW4gdGhlIGZvcndhcmRpbmcgY29tcG9uZW50IC0gaW1wbGVtZW50YXRp b24uICBTbywgd2UncmUgYXJndWluZyBhYm91dCBpbXBsZW1lbnRhdGlvbiBoZXJlIGluIHRoaXMg dGhyZWFkLCBJTU8uICBZZWFoLCBnbyBhaGVhZCBhbmQgY3JlYXRlIHlvdXIgaW50ZXJmYWNlIGlm IGl0IGNsYXJpZmllcyB0aGluZ3MgZm9yIHlvdSwgYnV0IGl0J3MgZ29pbmcgdG8gYmUgYSBsb2dp Y2FsIGRpdmlzaW9uIGFuZCBub3QgYSBwcmFjdGljYWwgcHJvdG9jb2wgb3IgQVBJLg0KDQpGaW5h bGx5LCB3aXRob3V0IHRoZSBwb3NzaWJpbGl0eSBvZiBicmFuY2hpbmcgKHdoaWNoIHdhcyB0aGUg ZnVuZGFtZW50YWwgcXVlc3Rpb24gaW4gdGhlIHRpdGxlLCBhbmQgd2UncmUgc3RyYXlpbmcgYXdh eSBmcm9tIGl0LCBJTU8pLCB5b3UgYmVnIGFuIGVudGlyZWx5IGNlbnRyYWxpemVkIGNvbnRyb2wg c3lzdGVtIChldmVyeSBjaGFpbiwgZm9yIGV2ZXJ5IGNpcmN1bXN0YW5jZSBpcyBwcmUtZGVmaW5l ZCkuICBUaGF0IHRvbywgSU1PLCBpcyBhbiBpbXBsZW1lbnRhdGlvbiBjaG9pY2UgYnV0IGl0J3Mg ZW5hYmxlZCBieSBjcmVhdGluZyByb29mIGZvciBpdCBpbnQgaGUgYXJjaGl0ZWN0dXJlLiAgSWYg eW91IHJlbW92ZSBicmFuY2hpbmcsIHlvdSByZW1vdmUgdGhlIGNob2ljZS4NCg0KTXkgLjAyLg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbnNjLWJvdW5j ZXNAaWV0Zi5vcmcgPG5zYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgU3VyZW5kcmEg S3VtYXIgKHNta3VtYXIpIDxzbWt1bWFyQGNpc2NvLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBOb3Zl bWJlciAxNCwgMjAxMyAxMjoyMiBQTQ0KVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBSb24g UGFya2VyDQpDYzogbnNjQGlldGYub3JnOyBIb25neXUgTGkgKEp1bGlvKTsgRGF2aWQgQWxsYW4g SQ0KU3ViamVjdDogUmU6IFtuc2NdIEZXOiAgcmUgY2xhc3NpZmljYXRpb24gJiBicmFuY2hpbmcs IHdhczogQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KDQpUaGlzIHNlcGFyYXRpb24gaXMg YSB2ZXJ5IGltcG9ydGFudCBhcmNoaXRlY3R1cmUgY29uc2lkZXJhdGlvbiBJTU8uIFNlbGVjdCBz ZXJ2aWNlcyBjYW4gZGljdGF0ZSB0aGUgZm9yd2FyZGluZyBwYXRoIGF0IGEgaGlnaGVyIGxldmVs IHRocm91Z2ggdGhlIHNlcnZpY2UgcGF0aC4gQWN0dWFsIGZvcndhcmRpbmcgbWF5IGJlIGxlZnQg dG8gdGhlIGZvcndhcmRpbmcgY29tcG9uZW50cy4NCg0KU3VyZW5kcmEuDQoNCk9uIDExLzE0LzEz IDc6NDYgQU0sICJKaW0gR3VpY2hhcmQgKGpndWljaGFyKSIgPGpndWljaGFyQGNpc2NvLmNvbT4g d3JvdGU6DQoNCj5TdXJlIGJ1dCBhcmNoaXRlY3R1cmFsbHkgdGhlIHNlcnZpY2UgZnVuY3Rpb24g YW5kIGZvcndhcmRpbmcgY29tcG9uZW50cyANCj5hcmUgc2VwYXJhdGUgZW50aXRpZXMuIFdoZXRo ZXIgeW91IGNob29zZSB0byBjb21iaW5lIHRoZW0gaW4gDQo+aW1wbGVtZW50YXRpb24gaXMgeW91 ciBvd24gY2hvaWNlLg0KPg0KPlNlbnQgZnJvbSBteSBpUGhvbmUNCj4NCj4+IE9uIE5vdiAxNCwg MjAxMywgYXQgMTA6NDAgQU0sICJSb24gUGFya2VyIg0KPj48Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSmltLA0KPj4NCj4+IEkgdGhpbmsgdGhhdCBjb3Vs ZCBiZSBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbi4gICBPbmUgaW1wbGVtZW50YXRpb24NCj4+ YXBwcm9hY2ggaXMgdGhhdCB0aGUgU0ZDIElQLWxheWVyIHRyYW5zcG9ydCB0dW5uZWxzIGFyZSBr bm93biBhdCB0aGUgDQo+PmZvcndhcmRpbmcgbGF5ZXIgKGxpa2UgdGhlIHdheSBJUC1pbi1JUCBh bmQgR1JFIHR1bm5lbHMgYXJlIGZyZXF1ZW50bHkNCj4+c3VwcG9ydGVkIC0tIGFzIGFuIElQIGlu dGVyZmFjZSkuICAgQW5vdGhlciBwb3NzaWJsZSBhcHByb2FjaCBpcyB0bw0KPj5oYW5kbGUgdGhl IFNGQyBJUC1sYXllciB0cmFuc3BvcnQgdHVubmVscyBhdCBhIGxldmVsIGFib3ZlIHRoZSANCj4+ Zm9yd2FyZGluZyBsYXllciAobGlrZSB0aGUgd2F5IEdUUC1VIHR1bm5lbHMgYXJlIGZyZXF1ZW50 bHkgc3VwcG9ydGVkIA0KPj4tLSB0aGV5IGFyZSBub3QgcmVwcmVzZW50ZWQgYXMgZGlzdGluY3Qg SVAgaW50ZXJmYWNlcykuDQo+Pg0KPj4gICAgUm9uDQo+Pg0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSBbbWFpbHRvOmpn dWljaGFyQGNpc2NvLmNvbV0NCj4+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAx MDozMCBBTQ0KPj4gVG86IFJvbiBQYXJrZXI7IERhdmlkIEFsbGFuIEk7IEhvbmd5dSBMaSAoSnVs aW8pOyBuc2NAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBGVzogcmUgY2xhc3NpZmlj YXRpb24gJiBicmFuY2hpbmcsIHdhczogQ3VycmVudCANCj4+UHJvcG9zZWQgU0ZDIGNoYXJ0ZXIN Cj4+DQo+PiBIaSBSb24sDQo+Pg0KPj4gSSB3b3VsZCBub3Qgc2F5IHRoYXQgYiBtb2RpZmllcyB0 aGUgdHJhbnNwb3J0IGhlYWRlciBidXQgcmF0aGVyIGIgDQo+PmluZm9ybXMgdGhlIGZvcndhcmRp bmcgY29tcG9uZW50IG9mIGl0J3MgaW50ZW50IHNvIHRoYXQgaXQgbWF5IGluc2VydCANCj4+dGhl IGFwcHJvcHJpYXRlIHRyYW5zcG9ydCBoZWFkZXIgdG8gbWVldCBiJ3MgcmVxdWlyZW1lbnQuDQo+ Pg0KPj4+IE9uIDExLzE0LzEzIDEwOjI0IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+DQo+Pj53cm90ZToNCj4+Pg0KPj4+IEhpLCBKaW0uDQo+Pj4NCj4+ PiBJIGFncmVlIHRoYXQgZm9yd2FyZGluZyBpcyBhZmZlY3RlZCBpbmRpcmVjdGx5LiAgIFdoZXRo ZXIgZnVuY3Rpb24gYg0KPj4+IGZvcndhcmRzIHRvIGZ1bmN0aW9uIGMgb3IgZnVuY3Rpb24gZCBp cyBhY2NvbXBsaXNoZWQgYnkgYiBjb3JyZWN0bHkgIA0KPj4+YWRkaW5nIChtb2RpZnlpbmcpIHRo ZSB0cmFuc3BvcnQgaGVhZGVyIHNvIHRoYXQgZCBpcyBhZGRyZXNzZWQgb3IgYyBpcw0KPj4+IGFk ZHJlc3NlZC4gICBJbiB0aGUgbW9zdCBnZW5lcmFsIGNhc2Ugb2YgdXRpbGl6aW5nIGFuIElQLWJh c2VkDQo+Pj50cmFuc3BvcnQNCj4+PiBlbmNhcHN1bGF0aW9uIChlLmcuLCBJUC9VRFAsIElQL0dS RSwgZXRjLiksIHRoZSBzZWxlY3Rpb24gb2YgbmV4dCANCj4+PmhvcCBpcw0KPj4+IG5vdCBtYWRl IGF0IHRoaXMgbGV2ZWwuICAgVGhlIHRyYW5zcG9ydCBsb2NhdGlvbiAoSVAgYWRkcmVzcykgZm9y IGMNCj4+PmFuZCBkDQo+Pj4gbWF5IG9yIG1heSBub3Qgc2hhcmUgdGhlIHNhbWUgbmV4dC1ob3Ag YmFzZWQgb24gdGhlIG5ld3R3b3JrIA0KPj4+dG9wb2xvZ3kgIChpLmUuLCBjIGFuZC9vciBkIG1h eSBvciBtYXkgbm90IGJlIG9uIHRoZSBzYW1lIHN1Ym5ldCBhcyANCj4+PmIsIG1heSBvciBtYXkg IG5vdCBiZSByZWFjaGVkIHZpYSB0aGUgc2FtZSBuZXh0IGhvcCByb3V0ZXIpLg0KPj4+DQo+Pj4g IFJvbg0KPj4+DQo+Pj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206 IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiANCj4+PiBPZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KPj4+IFNlbnQ6IFRodXJzZGF5 LCBOb3ZlbWJlciAxNCwgMjAxMyAxMDoxNCBBTQ0KPj4+IFRvOiBEYXZpZCBBbGxhbiBJOyBIb25n eXUgTGkgKEp1bGlvKTsgbnNjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEZXOiBy ZSBjbGFzc2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50IA0KPj4+IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4NCj4+PiBJIHRoaW5rIGl0IGlzIG1pc2xlYWRpbmcgdG8gc2F5IHRo YXQgYSBzZXJ2aWNlIGZ1bmN0aW9uIGRvZXMgbm90IA0KPj4+aW1wYWN0ICBwYWNrZXQgZm9yd2Fy ZGluZy4gSWYgYnJhbmNoaW5nIG9jY3VycyB0aGVuIHRoZSBzZXJ2aWNlIA0KPj4+ZnVuY3Rpb24g ZG9lcyAgaW1wYWN0IHBhY2tldCBmb3J3YXJkaW5nLCB3aGV0aGVyIGRpcmVjdGx5IG9yIA0KPj4+ aW5kaXJlY3RseSwgYXMgb3RoZXJ3aXNlICBwYWNrZXRzIHdvdWxkIG5vdCB0YWtlIHRoZSBuZXcg cGF0aCBhcyBhIA0KPj4+cmVzdWx0IG9mIHRoZSBicmFuY2guIEZvciAgZXhhbXBsZSwgaWYgdGhl IGNoYWluIGlzIGEtYi1jIGFuZCBiIA0KPj4+ZGVjaWRlcyB0aGF0IGZvciBjZXJ0YWluIGZsb3dz IHRoZSAgdHJhZmZpYyBzaG91bGQgZ28gdG8gZCByYXRoZXIgDQo+Pj50aGFuIGMgdGhlbiBpdCAq bXVzdCogZm9yY2UgdGhlICBmb3J3YXJkaW5nIGNvbXBvbmVudCB0byBkaXJlY3QgDQo+Pj50cmFm ZmljIHRvIHRoZSBuZXcgbmV4dC1ob3AuIFdoaWxlIHRoZSAgc2VydmljZSBmdW5jdGlvbiBtYXkg bm90IA0KPj4+bW9kaWZ5IGZvcndhcmRpbmcgaW4gdGVybXMgb2YgdXBkYXRpbmcgIGZvcndhcmRp bmcgdGFibGVzIGFuZCBzbyANCj4+PmZvcnRoLCBpdCBoYXMgdG8gaW5mb3JtIHRoZSBmb3J3YXJk aW5nICBjb21wb25lbnQgb2YgaXRzIGludGVudCANCj4+PnNvbWVob3cuIEFsc28sIEkgdGhpbmsg d2hhdCB5b3UgZGVzY3JpYmUgRGF2ZSAgaXMgYSBieXBhc3Mgb3BlcmF0aW9uIA0KPj4+cmF0aGVy IHRoYW4gYSBicmFuY2g/DQo+Pj4NCj4+Pj4gT24gMTEvMTQvMTMgOTo1NiBBTSwgIkRhdmlkIEFs bGFuIEkiIDxkYXZpZC5pLmFsbGFuQGVyaWNzc29uLmNvbT4NCj4+Pj53cm90ZToNCj4+Pj4NCj4+ Pj4gSSB0aGluayBpdCBpcyBnb2luZyB0byBiZSBhIHJhcmUgZXZlbnQsIGFzIHdoYXQgaXMgbW9y ZSBsaWtlbHkgaXMgDQo+Pj4+dGhlICBmcm9udCBlbmQgb2YgdGhlIGNoYWluIGlzIGR5bmFtaWNh bGx5IG1vZGlmaWVkIHNvIHN1YnNlcXVlbnQgDQo+Pj4+cGFja2V0cyAgaW4gYSBmbG93IHNraXAg Y2VydGFpbiBmdW5jdGlvbnMuIEhlbmNlIGEgZ3JhcGggbW9yZSBvZnRlbiANCj4+Pj50aGFuIG5v dCBpcyAgbG9naWNhbGx5IFAyUC4gRmFjaWxpdGF0ZXMgdGVzdGluZyBhbW9uZ3N0IG90aGVyIA0K Pj4+PmJlbmVmaXRzLg0KPj4+Pg0KPj4+PiBBcyBzdWNoIEknZCBub3Qgd2FudCB0byBiZSBwcmVz Y3JpcHRpdmUgYXMgdG8gaG93IGFuZCB3aGVyZSBpdCBpcyANCj4+Pj4gZG9uZS4uLi4NCj4+Pj4N Cj4+Pj4gRGF2ZQ0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBG cm9tOiBIb25neXUgTGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KPj4+ PiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDY6MzAgUE0NCj4+Pj4gVG86IERh dmlkIEFsbGFuIEk7IG5zY0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogW25zY10gRlc6IHJl IGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgDQo+Pj4+IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4+DQo+Pj4+IEhpIERhdmUsDQo+Pj4+DQo+Pj4+IFlvdXIgaW5mZXJy ZWQgcmVzdHJpY3Rpb24gbWF5IGJlIG5vdCBhbHdheXMgdHJ1ZS4gSW4gZ2VuZXJhbCwgDQo+Pj4+ c2VydmljZSAgZnVuY3Rpb25zIHNob3VsZCBiZSBhYmxlIHRvIGNvbXBvc2UgYSBjaGFpbiBhcmJp dHJhcmlseS4gDQo+Pj4+UGFydGljdWxhcmx5ICBmb3IgYnJhbmNoaW5nLCBhcyBJIHN1Z2dlc3Rl ZCBpbiBwcmV2aW91cyBlbWFpbCwgDQo+Pj4+c2VydmljZSBmdW5jdGlvbiAgc2hhbGwgbm90IGRp cmVjdGx5IGltcGFjdCBwYWNrZXQgZm9yd2FyZGluZy4gVGhpcyANCj4+Pj5wcmVjbHVkZXMgdGhl ICByZXN0cmljdGlvbiB5b3UgbWVudGlvbmVkLiBGb3J3YXJkaW5nIHBsYW5lIGNhbiANCj4+Pj5k ZWNpZGUgd2hldGhlciBhICBicmFuY2hpbmcgYWN0aW9uIHNob3VsZCBiZSB0YWtlbiBieSANCj4+ Pj5yZWNsYXNzaWZpY2F0aW9uIG9yIG5vdCBwZXIgc2VydmljZSBjaGFpbi4NCj4+Pj4NCj4+Pj4g RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+Pj4+DQo+Pj4+IEhvbmd5dQ0KPj4+Pg0KPj4+PiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBEYXZpZCBBbGxhbiBJIFttYWlsdG86 ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb21dDQo+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTMsIDIwMTMgMTE6NDUgUE0NCj4+Pj4gVG86IEhvbmd5dSBMaSAoSnVsaW8pOyBuc2NAaWV0 Zi5vcmcNCj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEZXOiByZSBjbGFzc2lmaWNhdGlvbiAmIGJy YW5jaGluZywgd2FzOiBDdXJyZW50IA0KPj4+PiBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pg0K Pj4+PiBISSBIb25neXU6DQo+Pj4+DQo+Pj4+IEkgdGhpbmsgd2Ugd2lsbCBoYXZlIHNjZW5hcmlv cyB3aGVyZSBhIHNlcnZpY2UgZnVuY3Rpb24gYXBwZWFycyBpbiANCj4+Pj4gbW9yZSB0aGFuIG9u ZSBjaGFpbiwgYXMgd291bGQgYmUgdGhlIGNhc2UsIGZvciBleGFtcGxlLCBpZiBzb21lIA0KPj4+ PiBmbG93cyBjb3VsZCBkeW5hbWljYWxseSBieXBhc3MgRFBJIGJ1dCBzdGlsbCBuZWVkZWQgdG8g dHJhbnNpdCBhIA0KPj4+PiBjb21tb24gc2V0IG9mIHN0YXRlZnVsIHNlcnZpY2UgZnVuY3Rpb25z Li4uDQo+Pj4+DQo+Pj4+IE9uY2UgeW91IHBvc3R1bGF0ZSBhIHNlcnZpY2UgZnVuY3Rpb24gaW5z dGFuY2UgYXBwZWFyaW5nIGluIG1vcmUgDQo+Pj4+dGhhbiAgb25lIGNoYWluLCBpdCBzZWVtcyBh cnRpZmljaWFsbHkgcmVzdHJpY3RpdmUgbm90IHRvIHBlcm1pdCANCj4+Pj5zdWNoIGEgIGZ1bmN0 aW9uIHRvIGFsc28gaW1wbGVtZW50IGJyYW5jaGluZywgYWxsIHRoZSBjb250cm9sIA0KPj4+PnN0 cnVjdHVyZXMgd291bGQgIGFscmVhZHkgYmUgdGhlcmUuDQo+Pj4+DQo+Pj4+IFJnZHMNCj4+Pj4g RGF2ZQ0KPj4+Pg0KPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+PiBGcm9tOiBI b25neXUgTGkgKEp1bGlvKSBbbWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KPj4+PiBTZW50 OiBXZWRuZXNkYXksIE5vdmVtYmVyIDEzLCAyMDEzIDI6MTIgQU0NCj4+Pj4gVG86IERhdmlkIEFs bGFuIEk7IG5zY0BpZXRmLm9yZw0KPj4+PiBTdWJqZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNz aWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQgDQo+Pj4+IFByb3Bvc2VkIFNGQyBj aGFydGVyDQo+Pj4+DQo+Pj4+IE1heSBJIHN1Z2dlc3Qgc3VtbWFyeSBvZiBteSB2aWV3cyBoZXJl Og0KPj4+Pg0KPj4+PiAxLiBCcmFuY2ggaXMgYSBzb3J0IG9mIHVzZSBjYXNlIG9yIHNjZW5hcmlv LCB3aGlsZSByZWNsYXNzaWZpY2F0aW9uIA0KPj4+PmlzICBhIHdheSB0byBzb2x2ZSB0aGUgcHJv YmxlbS4NCj4+Pj4gMi4gU2VydmljZSBGdW5jdGlvbnMgc2hvdWxkIGJlIGRlY291cGxlZCB3aXRo IHRoZSBjaGFpbiBpdHNlbGYuDQo+Pj4+ICAgIE1lYW5pbmcsIGEgU0Ygc2hhbGwgbm90ICpkaXJl Y3RseSogaW1wYWN0IHRoZSBmb3J3YXJkaW5nIG9mIA0KPj4+PnBhY2tldHMgIGluIGEgY2hhaW4u IEJyYW5jaGluZyBzaG91bGQgYmUgcGVyZm9ybWVkIGJ5IGNoYWluIA0KPj4+PmZvcndhcmRpbmcg bm9kZXMsICBwb3NzaWJseSB1bmRlciBjb250cm9sIG9mIGEgY29udHJvbCBub2RlLiBUaGUgDQo+ Pj4+cmVhc29uIGZvciB0aGlzIGlzIGluICBORlYgd29ybGQsIHNlcnZpY2UgZnVuY3Rpb25zIG1h eSBjb21lIGZyb20gYSANCj4+Pj50aGlyZCBwYXJ0eSwgd2hpbGUgY2hhaW4gIGlzIHByb3ZpZGVk IGJ5IHRoZSBpbmZyYXN0cnVjdHVyZSBvZiB0aGUgDQo+Pj4+bmV0d29yay4gVGhlcmUgbXVzdCBi ZSBhICBjdXNoaW9uIGF2b2lkaW5nIGEgc2VydmljZSBmdW5jdGlvbiANCj4+Pj5vcGVyYXRpbmcg aW5mcmFzdHJ1Y3R1cmUgZGlyZWN0bHkuDQo+Pj4+IDMuIChSZSljbGFzc2lmaWNhdGlvbiBpcyBi YXNlZCBvbiBpbmZvIGluIGEgcGFja2V0Lg0KPj4+PiAgICBUaGlzIGlzIHZlcnkgZ2VuZXJhbC4g U3VjaCBpbmZvIGNvdWxkIGJlIEwyfkw3IGRlcml2ZWQgZnJvbSBhIA0KPj4+PnVzZXIncyAgcGFj a2V0LCBhcyB3ZWxsIGFzIHNvbWUgaW5mbyBsaWtlIG1ldGFkYXRhIGluIGEgU0ZDIGhlYWRlci4g DQo+Pj4+QXMgIGNsYXNzaWZpY2F0aW9uIGlzIG91dCBvZiBzY29wZSBvZiBTRkMsIHdlIGRvbid0 IGhhdmUgdG8gcHJvdmlkZSANCj4+Pj50b28gIG11Y2ggZGV0YWlscyBvZiBob3cgdG8gZG8gY2xh c3NpZmljYXRpb24uDQo+Pj4+IDQuIENoYWluIHNlZ21lbnRzIHN0aXRjaGluZyBpcyByZWxhdGl2 ZWx5IGEgZWFzeSB3YXkgZm9yIGJyYW5jaGluZy4NCj4+Pj4gQ29tcGFyZWQgd2l0aCBjaGFpbnMg YW5kIHN1YmNoYWlucywgd2hpY2ggbWF5IHJlcXVpcmUgYSBtb3JlIA0KPj4+PmNvbXBsZXggIGhl YWRlciBhbmQgZm9yd2FyZGluZyBjYXBhYmlsaXRpZXMuDQo+Pj4+IE15IHR3byBjZW50cy4NCj4+ Pj4gSG9uZ3l1DQo+Pj4+DQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZy b206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiANCj4+Pj4gT2YgRGF2aWQgQWxsYW4gSQ0KPj4+PiBTZW50OiBXZWRuZXNkYXksIE5v dmVtYmVyIDEzLCAyMDEzIDM6MDQgQU0NCj4+Pj4gVG86IG5zY0BpZXRmLm9yZw0KPj4+PiBTdWJq ZWN0OiBbbnNjXSBGVzogcmUgY2xhc3NpZmljYXRpb24gJiBicmFuY2hpbmcsIHdhczogQ3VycmVu dCANCj4+Pj4gUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4NCj4+Pj4gSGk6DQo+Pj4+IChyZXNl bmQgd2l0aCByZWNpcGllbnQgbGlzdCBjbGVhbmVkIHVwKQ0KPj4+Pg0KPj4+PiBJIGFncmVlIHdl IGFyZSBkaXNjdXNzaW5nIG11bHRpcGxlIGNvbmNlcHRzLCBjbGFzc2lmaWNhdGlvbiBhbmQgDQo+ Pj4+IGZsb3ctc3Vic2V0dGluZy4gUGVyaGFwcyBtb3JlIDstKQ0KPj4+Pg0KPj4+PiBEZWZpbmlu ZyBhIGZsb3cgc3Vic2V0IGNhbiBiZSBhIHJlc3VsdCBvZiBjbGFzc2lmaWNhdGlvbiwgYnV0IGl0 IGlzIA0KPj4+PiBub3QgdGhlIGV4Y2x1c2l2ZSBtZWNoYW5pc20uIEJyYW5jaGluZyBpcyBhIG1l Y2hhbmlzbSBieSB3aGljaCBmbG93IA0KPj4+PiBzdWJzZXRzIGFyZSBleHBvc2VkIGFuZCBtYXBw ZWQgdG8gYSBzZXQgb2Ygc3ViY2hhaW5zIHN1Y2ggdGhhdCBpdCANCj4+Pj4gY2FuIGJlIGlkZW50 aWZpZWQgaW4gdGhlIGRhdGFwbGFuZS4uLg0KPj4+Pg0KPj4+PiBUaGF0J3MgdGhlIHZpZXcgZnJv bSBoZXJlDQo+Pj4+IERhdmUNCj4+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIA0KPj4+Pk9mICBEYXZpZCBMYWtlIChkbGFrZSkNCj4+Pj4gU2VudDog VHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTA6NTEgQU0NCj4+Pj4gVG86IEppbSBHdWljaGFy ZCAoamd1aWNoYXIpOyBLZXZpbiBKIE1hOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IA0KPj4+ PlJvbiAgUGFya2VyOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+IENjOiBU aG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+Pj4+IFN1YmplY3Q6 IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+DQo+Pj4+IFVuZGVy c3Rvb2QgLSBtYXliZSBqdXN0IGEgbGl0dGxlIGxvY2FsaXNlZCB3YXJtaW5nIG9mIHRoZSBzZWEg dGhlbiA/DQo+Pj4+IEJ1dCBJIHN0aWxsIHRoaW5rIHdlIG5lZWQgdG8gY29uc2lkZXIgd2hlcmUg YW5kIGhvdyBwb2xpY3kgaXMgDQo+Pj4+IGRlZmluZWQvc2V0IGV2ZW4gZm9yIHRoZSBzaW5nbGUt ZG9tYWluIGluc3RhbmNlLg0KPj4+Pg0KPj4+PiBJIGRvbid0IHRoaW5rIHdlIGNhbiBhc3N1bWUg dGhhdCBhbnkgTDEtMyBkZXZpY2Ugd2lsbCBiZSBhYmxlIHRvIA0KPj4+PiBkZXRlcm1pbmUgbXVj aCB1c2VmdWwgaW5mb3JtYXRpb24gZnJvbSB0aGUgZGF0YS1wbGFuZS4NCj4+Pj4NCj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hh cikNCj4+Pj4gU2VudDogMTIgTm92ZW1iZXIgMjAxMyAxMDo0NA0KPj4+PiBUbzogRGF2aWQgTGFr ZSAoZGxha2UpOyBLZXZpbiBKIE1hOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJvbiANCj4+ Pj4gUGFya2VyOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+IENjOiBUaG9t YXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1bWFuZHJhIE1hamVlDQo+Pj4+IFN1YmplY3Q6IFJl OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+DQo+Pj4+IEFzIGRpc2N1 c3NlZCBkdXJpbmcgdGhlIEJPRiBvdXIgaW5pdGlhbCB3b3JrIGlzIHNpbmdsZSANCj4+Pj4gYWRt aW5pc3RyYXRpdmUgZG9tYWluIGZvciBzb21lIG9mIHRoZSB2ZXJ5IHJlYXNvbnMgeW91IHBvaW50 IG91dC4gDQo+Pj4+IFdlIG5lZWQgdG8ga2VlcCBmb2N1c2VkIHdpdGhvdXQgdHJ5aW5nIHRvIGJv aWwgdGhlIG9jZWFuIHJpZ2h0IG9mZiB0aGUgYmF0Lg0KPj4+Pg0KPj4+Pj4gT24gMTEvMTIvMTMg MTozNiBQTSwgIkRhdmlkIExha2UgKGRsYWtlKSIgPGRsYWtlQGNpc2NvLmNvbT4gd3JvdGU6DQo+ Pj4+Pg0KPj4+Pj4gRXhhY3RseS4gIEJ1dCBob3cgY2FuIG5ldHdvcmstY29tcG9uZW50cyAidGVy bWluYXRlIiBhbiANCj4+Pj4+YXBwbGljYXRpb24gPz8/Pw0KPj4+Pj4NCj4+Pj4+IEkgdGhpbmsg d2UgbmVlZCBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiBhIHJlY3Vyc2l2ZSBwb2xpY3kgDQo+Pj4+ PiBtZWNoYW5pc20gKHJlY3Vyc2l2ZSBiZWNhdXNlIGEgdXNlci1sYW5kIGFwcGxpY2F0aW9uIHdp bGwgcmlkZSANCj4+Pj4+IHdpdGggYSBzcGVjaWZpYyBwb2xpY3kgYWNyb3NzIHBvdGVudGlhbGx5 IGRpZmZlcmVudCBzZXRzIG9mIGNhcnJpZXIgcG9saWNpZXMpLg0KPj4+Pj4NCj4+Pj4+IEkgaGF0 ZSB0byBicmluZyB0aGlzIHVwIG5vdywgYnV0IHdlIGFsc28gbmVlZCB0byB0aGluayBhYm91dCB0 aGlzICANCj4+Pj4+bXVsdGktZG9tYWluIGlzc3VlIC0gaWYgSSBzZXQgYSBwb2xpY3kgYXMgYSB1 c2VyLCBjaGFuY2VzIGFyZSBJIA0KPj4+Pj53aWxsICBiZSBjcm9zc2luZyBzZXZlcmFsIGRvbWFp biBib3VuZGFyaWVzLiAgQXJlIHdlIGV4cGVjdGluZyB0aGUgDQo+Pj4+PnNlcnZpY2UgIGhlYWRl cnMgdG8gZGVmaW5lIHRoZSBzZXJ2aWNlIGNoYWluaW5nIGZvciB0aGUgZHVyYXRpb24gb2YgDQo+ Pj4+PnRoZSBlbnRpcmUgIGZsb3cgYWNyb3NzIGFsbCBkb21haW5zLCBvciBqdXN0IGFjcm9zcyBh IHNpbmdsZSBvbmUgPw0KPj4+Pj4NCj4+Pj4+IEluIHdoaWNoIGNhc2UsIGRvIEkgaGF2ZSB0byBy ZS1zZXQgcG9saWN5IGFzIEkgdHJhdmVyc2UgZG9tYWlucyAgYW5kDQo+Pj4+PiB3aGVyZSBkb2Vz IHRoYXQgcG9saWN5IGdldCBzZXQgPyAgIEl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRvIHNldA0K Pj4+Pj5wb2xpY3kNCj4+Pj4+IG9uY2UgYmFzZWQgb24gTDUtNyBuZWVkcywgYW5kIGhhdmUgdGhh dCBpbnN0YW50aWF0ZWQgYWNyb3NzIHRoZSAgDQo+Pj4+Pm11bHRpcGxlIGRvbWFpbnMuDQo+Pj4+ Pg0KPj4+Pj4gQWdhaW4sIHRoaXMgYXBwZWFycyB0byBiZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBT RkMsIGJ1dCBwcmV0dHkgDQo+Pj4+PiByZWxldmFudCB0byBob3cgaXQgd291bGQgb3BlcmF0ZSBp biB0aGUgcmVhbCB3b3JsZC4NCj4+Pj4+DQo+Pj4+PiBEYXZpZA0KPj4+Pj4NCj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBLZXZpbiBKIE1hIFttYWlsdG86a2V2 aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbV0NCj4+Pj4+IFNlbnQ6IDEyIE5vdmVtYmVyIDIwMTMgMTA6 MjcNCj4+Pj4+IFRvOiBEYXZpZCBMYWtlIChkbGFrZSk7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFy KTsgUm9uIFBhcmtlcjsgDQo+Pj4+PiBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAoSnVsaW8pDQo+ Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4+ Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ DQo+Pj4+Pj4gSW4gdGhvc2UgY2lyY3Vtc3RhbmNlcywgb25seSB0aGUgZW5kIGFwcGxpY2F0aW9u cyB0aGVtc2VsdmVzIG9yIGEgDQo+Pj4+Pj4gcmVhc29uYWJseSBicm9hZC1icnVzaGVkIGNsYXNz aWZpY2F0aW9uIChyZWFsbHkgdHJhZmZpYyBzdGVlcmluZyANCj4+Pj4+PiBiYXNlZCBvbiB3aGF0 IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcgdG8gYmUgdXNlZnVsIC0gaXMgDQo+Pj4+ Pj4gVEhBVCB3aGF0IHdlJ3JlIGFpbWluZyBmb3IgaGVyZSA/DQo+Pj4+Pg0KPj4+Pj4gSSB3b3Vs ZCBjZXJ0YWlubHkgaG9wZSBub3QsIGJ1dCB0aGF0IGhhcyBiZWVuIG15IGNvbmNlcm4gYXMgd2Vs bC4NCj4+Pj4+IEFwcGxpY2F0aW9uIGxheWVyIHRlcm1pbmF0aW9uIGFuZCByZS1jbGFzc2lmaWNh dGlvbiBzZWVtcyBhIG11c3Q/DQo+Pj4+Pg0KPj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pg0K Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4gRnJvbTogRGF2aWQgTGFr ZSAoZGxha2UpIFttYWlsdG86ZGxha2VAY2lzY28uY29tXQ0KPj4+Pj4+IFNlbnQ6IFR1ZXNkYXks IE5vdmVtYmVyIDEyLCAyMDEzIDE6MDAgUE0NCj4+Pj4+PiBUbzogU3VyZW5kcmEgS3VtYXIgKHNt a3VtYXIpOyBSb24gUGFya2VyOyBLZXZpbiBKIE1hOyBMaW5kYSANCj4+Pj4+PiBEdW5iYXI7IEhv bmd5dSBMaSAoSnVsaW8pDQo+Pj4+Pj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsg U3VtYW5kcmEgTWFqZWUNCj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3Nl ZCBTRkMgY2hhcnRlcg0KPj4+Pj4+DQo+Pj4+Pj4gUG9saWN5IG1heSBiZSBvdXRzaWRlIG9mIHRo ZSBzY29wZSBvZiBTRkMsIGJ1dCB3aXRob3V0IHN0cm9uZyANCj4+Pj4+PiBtYXBwaW5nIGJldHdl ZW4gUG9saWN5IGFuZCB0aGUgaW5zZXJ0ZWQgU2VydmljZSBIZWFkZXIocyksIHdlIA0KPj4+Pj4+ IHJ1bi10aGUtcmlzayBvZiBsaW1pdGluZyB0aGUgZWZmaWNhY3kgb2YgdGhlIHByb3RvY29sIElN Ty4NCj4+Pj4+Pg0KPj4+Pj4+IEZvciBleGFtcGxlLCBpbiBhIHdvcmxkIHdoZXJlIHRoZSBuZXR3 b3JrIGhhcyAiZ29uZSBkYXJrLCIgKGFzIA0KPj4+Pj4+IHBlciB0aGUgSUVURiBUZWNobmljYWwg UGxlbmFyeSA/Oi0pICkgd2hhdCBpcyBvdXIgYWJpbGl0eSB0byANCj4+Pj4+PiBkZXRlcm1pbmUg cG9saWN5IGJhc2VkIG9uIERQSSBvZiBwYWNrZXRzLWluLWZsaWdodCA/DQo+Pj4+Pj4NCj4+Pj4+ PiBJbiB0aG9zZSBjaXJjdW1zdGFuY2VzLCBvbmx5IHRoZSBlbmQgYXBwbGljYXRpb25zIHRoZW1z ZWx2ZXMgb3IgYSANCj4+Pj4+PiByZWFzb25hYmx5IGJyb2FkLWJydXNoZWQgY2xhc3NpZmljYXRp b24gKHJlYWxseSB0cmFmZmljIHN0ZWVyaW5nIA0KPj4+Pj4+IGJhc2VkIG9uIHdoYXQgd2UgY2Fu IHNlZSBhdCBpbmdyZXNzKSBpcyBnb2luZyB0byBiZSB1c2VmdWwgLSBpcyANCj4+Pj4+PiBUSEFU IHdoYXQgd2UncmUgYWltaW5nIGZvciBoZXJlID8NCj4+Pj4+Pg0KPj4+Pj4+IERhdmlkDQo+Pj4+ Pj4NCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IG5zYy1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+ IEJlaGFsZiBPZiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikNCj4+Pj4+PiBTZW50OiAxMiBOb3Zl bWJlciAyMDEzIDA5OjI2DQo+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IExpbmRh IER1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNj QGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJy ZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4NCj4+Pj4+PiBSb24sDQo+Pj4+Pj4NCj4+ Pj4+PiBDbGFzc2lmaWNhdGlvbiBvZiB0cmFmZmljIGlzIHdlbGwgdW5kZXJzdG9vZCBhbmQgd2Ug ZG8gbm90IGhhdmUgDQo+Pj4+Pj4gdG8gcmVkZWZpbmUgaXQgLSBpdCdzIGJlZW4gYXJvdW5kIGZv ciBhbGwgdGhlIHRpbWUgbWlkZGxlIGJveGVzIA0KPj4+Pj4+IGhhdmUgYmVlbiBvciBmb3IgdGhh dCBtYXR0ZXIgdGhlIEwyL0wzIGRldmljZXMuIEFsbCB3ZSBhcmUgDQo+Pj4+Pj4gdGFsa2luZyBh Ym91dCBpcyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgY2xhc3NpZmljYXRpb24gdG8gYnJhbmNo aW5nIGluIFNGQy4NCj4+Pj4+Pg0KPj4+Pj4+IFlvdSBhcmUgcmlnaHQsIGl0IGlzIGFsbCBhYm91 dCBwb2xpY3kgd2hpY2ggaXMgb3V0c2lkZSB0aGUgc2NvcGUgDQo+Pj4+Pj4gb2YgU0ZDLg0KPj4+ Pj4+DQo+Pj4+Pj4gU3VyZW5kcmEuDQo+Pj4+Pj4NCj4+Pj4+PiBPbiAxMS8xMi8xMyA3OjUzIEFN LCAiUm9uIFBhcmtlciIgDQo+Pj4+Pj4gPFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb20+ DQo+Pj4+Pj4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+Pj4gSSB0aGluayB0aGUgbGFjayBvZiBkZWZp bml0aW9uIG9mICJyZWNsYXNzaWZpY2F0aW9uIiBtYXkgYmUgDQo+Pj4+Pj4+IGNhdXNpbmcNCj4+ Pj4+PiBzb21lDQo+Pj4+Pj4+IG1pc3VuZGVyc3RhbmRpbmdzIGhlcmUuICAgIEEgYnJhbmNoIHdv dWxkIG9jY3VyIGZvciBzb21lDQo+Pj4+Pj4gcG9saWN5LWRyaXZlbg0KPj4+Pj4+PiByZWFzb24g YmFzZWQgb24gdGhlIGJlaGF2aW9yIGFuZCBjb25jbHVzaW9ucyBvZiB0aGUgc2VydmljZSANCj4+ Pj4+Pj5mdW5jdGlvbiwNCj4+Pj4+Pj4gaXRzZWxmLiAgIFRoZSBncmFwaCB3b3VsZCByZXByZXNl bnQgdGhlIGZhY3QgdGhhdCB0aGVyZSBpcyBhIGJyYW5jaA0KPj4+Pj4+PiBwb2ludCwgYnV0IHRo ZSBzZXJ2aWNlIGZ1bmN0aW9uLCBpdHNlbGYsIGJlaW5nIGF3YXJlIHRoYXQgaXQgaXMgDQo+Pj4+ Pj4+YSAgYnJhbmNoaW5nIHBvaW50IHdvdWxkIGNvbnRhaW4gdGhlIHBvbGljeSBhbmQgbG9naWMg dG8gZGVjaWRlIA0KPj4+Pj4+Pm9uIHdoaWNoDQo+Pj4+Pj4+IGJyYW5jaCB0byB0YWtlLiAgIFNw ZWNpZnlpbmcgdGhhdCBwb2xpY3kgYW5kIGxvZ2ljIGlzIG91dCBvZiBzY29wZSwNCj4+Pj4+PiBJ TU8uDQo+Pj4+Pj4+DQo+Pj4+Pj4+ICBSb24NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogS2V2aW4gSiBNYSBbbWFpbHRv OmtldmluLm1hQGF6dWtpc3lzdGVtcy5jb21dDQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDEyLCAyMDEzIDEwOjQ5IEFNDQo+Pj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXI7IFJvbiBQYXJr ZXI7IEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0 Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+Pj4+Pj4+IFN1bWFuZHJhIE1hamVl DQo+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVy DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhpIExpbmRhLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBBcmUgeW91IHNh eWluZyB0aGF0IGEgYnJhbmNoaW5nIHBvaW50IGlzICJuZXZlciIgYSANCj4+Pj4+Pj4gcmVjbGFz c2lmaWNhdGlvbiBwb2ludCwgb3IgYXJlIHlvdSBzYXlpbmcgdGhhdCBhIGJyYW5jaGluZyBwb2lu dA0KPj4+Pj4+ICJkb2VzIG5vdCBoYXZlIHRvIGJlIg0KPj4+Pj4+PiBhIHJlY2xhc3NpZmljYXRp b24gcG9pbnQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgdGhpbmsgdGhpcyBpcyBhbiBpbXBvcnRhbnQg ZGlzdGluY3Rpb24gdGhhdCBuZWVkcyB0byBiZQ0KPj4+Pj4+IGNsYXJpZmllZC4NCj4+Pj4+Pj4g SWYgYnJhbmNoaW5nIGlzIG5ldmVyIHJlY2xhc3NpZmljYXRpb24sIHRoZW4gdGhlIG1lYW5pbmcg b2YgYSANCj4+Pj4+Pj4gY2hhaW4gaXMgZGlmZmVyZW50IHRoYW4gSSBvcmlnaW5hbGx5IGluZmVy cmVkLiAgSWYgdGhlIGNoYWluIGlzIA0KPj4+Pj4+PiBhIHRyZWUgd2l0aCBvdGhlciAiYnJhbmNo aW5nIiBwb2ludHMgaW4gaXQsIHRoZW4gdGhhdCBsaW1pdHMgdGhlIA0KPj4+Pj4+PiBzY29wZSBv ZiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZ29hbHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFdoaWxlIHRo aXMgY291bGQgYmUgYSBkZWdlbmVyYXRlIGNhc2UsIGFuZCBhbnkgaW1wbGVtZW50YXRpb24gDQo+ Pj4+Pj4+IGNvdWxkIGRlZmluZSBiYWQgc2VydmljZSBjaGFpbnMsIGlzIGl0IHRoZSBpbnRlbnQg b2YgU0ZDIHRvIG9ubHkgDQo+Pj4+Pj4+IGxvb2sgYXQgdGhlIHNpbXBsZXIgcGFja2V0LWxldmVs IGNsYXNzaWZpY2F0aW9uIGNhc2VzLCBvciBpcyBpdCANCj4+Pj4+Pj4gdGhlIGludGVudCB0byBj b25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIGJyYW5jaGluZyBwb2ludCBpcyANCj4+Pj4+Pj4gdmll d2VkIGFzIGEgcmUtY2xhc3NpZmljYXRpb24gcG9pbnQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IHRoYW54 Lg0KPj4+Pj4+Pg0KPj4+Pj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+Pj4+Pj4NCj4+Pj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+PiBGcm9tOiBMaW5kYSBEdW5iYXIgW21h aWx0bzpsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbV0NCj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5v dmVtYmVyIDEyLCAyMDEzIDEwOjM0IEFNDQo+Pj4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgSG9uZ3l1 IExpIChKdWxpbyk7IEtldmluIEogTWENCj4+Pj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NA aWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgDQo+Pj4+Pj4+PiBTdW1hbmRyYSBN YWplZQ0KPj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNo YXJ0ZXINCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBSb24sDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gRmlyc3Qs IHdhbnQgdG8gbWFrZSBpdCBjbGVhciB0aGF0ICJicmFuY2hpbmciICE9IA0KPj4+Pj4+Pj4gcmVj bGFzc2lmaWNhdGlvbiwgYWdyZWU/DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gU2Vjb25kLCB0aGUgcmVw cmVzZW50YXRpb24gb2YgYnJhbmNoaW5nIChvciBzZXJ2aWNlIGdyYXBoKSBjYW4gDQo+Pj4+Pj4+ PiBiZSBpbiBhIGZvcm0gb2YgbG9naWMgb24gYSBzZXJ2aWNlIGZ1bmN0aW9uLiBTb21lIHNlcnZp Y2UgDQo+Pj4+Pj4+PiBmdW5jdGlvbnMsIGVzcGVjaWFsbHkgTDcgYmFzZWQsIGNhbiB1c2UgdmFs dWUgaW4gYSBEYXRhYmFzZSB0byANCj4+Pj4+Pj4+IGRldGVybWluZSB3aGF0IGlzIHRoZSBuZXh0 IHNlcnZpY2UgZnVuY3Rpb24uDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTGluZGENCj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9tOiBuc2Mt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4+Pj4+ Pj4+PiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVt YmVyIDEyLCAyMDEzIDg6MTYgQU0NCj4+Pj4+Pj4+PiBUbzogSG9uZ3l1IExpIChKdWxpbyk7IEtl dmluIEogTWENCj4+Pj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJl bmRyYSBLdW1hciAoc21rdW1hcik7IA0KPj4+Pj4+Pj4+IFN1bWFuZHJhIE1hamVlDQo+Pj4+Pj4+ Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IEhvbmd5dSwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEkgYWdyZWUgY29t cGxldGVseSB0aGF0IHJlLWNsYXNzaWZpY2F0aW9uIGlzIG5vdCBsaW1pdGVkIHRvIERQSS4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEFuZCBhbHNvLCB0aGF0IGFuIGFyZWEgZm9yIHVzIHRvIGV4cGxv cmUgYXMgYSBncm91cCBpcyBob3cgdG8NCj4+Pj4+Pj4+IHJlcHJlc2VudA0KPj4+Pj4+Pj4+IHRo ZSBzZXJ2aWNlIGdyYXBoLiAgIERvIHdlIHdhbnQgdG8gcmVwcmVzZW50IGl0IGFzIGEgcHJvcGVy IGdyYXBoDQo+Pj4+Pj4gd2l0aA0KPj4+Pj4+Pj4+IGFuIGFkamFjZW5jeSBsaXN0IG9yIG90aGVy IHJlcHJlc2VudGF0aW9uYWwgbW9kZWw/ICAgT3IsIGRvIHdlDQo+Pj4+Pj4gd2FudA0KPj4+Pj4+ IHRvDQo+Pj4+Pj4+Pj4gcmVwcmVzZW50IGl0IGFzIGEgc2V0IG9mIGxpbmVhciBzZWdtZW50cyBh bmQgaWYgc28sIGhvdyBhcmUgdGhlDQo+Pj4+Pj4+Pj4gc2VnbWVudHMgY29ubmVjdGVkIGludG8g YSBncmFwaD8gICBPdGhlciBpZGVhcz8NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ICAgUm9uDQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0Bp ZXRmLm9yZ10gT24gDQo+Pj4+Pj4+Pj4gQmVoYWxmIE9mIEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+ Pj4+Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgNjo1NyBBTQ0KPj4+Pj4+Pj4+ IFRvOiBSb24gUGFya2VyOyBLZXZpbiBKIE1hDQo+Pj4+Pj4+Pj4gQ2M6IFRob21hcyBOYXJ0ZW47 IG5zY0BpZXRmLm9yZzsgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpOyANCj4+Pj4+Pj4+PiBTdW1h bmRyYSBNYWplZQ0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBCcmFuY2hpbmcvZm9ya2luZyBpcyBh IHZlcnkgaW50ZXJlc3RpbmcgdG9waWMgb2YgU0ZDLiBBYm91dCANCj4+Pj4+Pj4+PiB0aGUNCj4+ Pj4+Pj4+PiByZS0gY2xhc3NpZmljYXRpb24gcG9pbnQsIHByb2JhYmx5IHdlIHNoYWxsIG5vdCBs aW1pdCBpdCB0byBEUEkuDQo+Pj4+Pj4+Pj4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IHBhY2tl dHMgZ28gdG8gZGlmZmVyZW50IGJyYW5jaGVzIA0KPj4+Pj4+Pj4+IGFmdGVyIGJlZW4gcHJvY2Vz c2VkIGJ5IGEgY2VydGFpbiBzZXJ2aWNlIGZ1bmN0aW9uLCBkZWNpc2lvbiANCj4+Pj4+Pj4+PiBv ZiB3aGljaCBicmFuY2hlcyB0byBnbyBpcyBtYWRlIGJhc2VkIG9uIHRoZSByZXN1bHQgb2Ygc2Vy dmljZSANCj4+Pj4+Pj4+PiBmdW5jdGlvbidzIHByb2Nlc3MsIGkuZS4gbm90IGp1c3QgcmUtIGNs YXNzaWZpY2F0aW9uIGJ5IERQSS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IEhvbmd5dQ0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+PiBGcm9t OiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiAN Cj4+Pj4+Pj4+PiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXks IE5vdmVtYmVyIDEyLCAyMDEzIDc6NDUgUE0NCj4+Pj4+Pj4+PiBUbzogS2V2aW4gSiBNYQ0KPj4+ Pj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFyIChz bWt1bWFyKTsgDQo+Pj4+Pj4+Pj4gU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBS ZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gSGksIEtldmluDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBZb3UgYXNrIGEgZ3JlYXQgcXVlc3Rp b24gYWJvdXQgYnJhbmNoaW5nIHRoZSBncmFwaC4gIFRoZSANCj4+Pj4+Pj4+PiBkZXRhaWxzIGFy b3VuZCBob3cgdG8gY29udmV5IHRoZSBzZWxlY3Rpb24gb2YgdGhlIA0KPj4+Pj4+Pj4+IHN1YnRy ZWUvc3ViZ3JhcGggYXJlIHN0aWxsDQo+Pj4+Pj4+PiB0byBiZQ0KPj4+Pj4+Pj4+IGRlZmluZWQu ICAgSXMgaXQgb25lIGNoYWluIGlkIGZvciB0aGUgd2hvbGUgZ3JhcGg/ICAgRG9lcyBlYWNoDQo+ Pj4+Pj4gYnJhbmNoDQo+Pj4+Pj4+Pj4gaGF2ZSBpdHMgb3duIGNoYWluIGlkPyAgIFNvbWUgY29t YmluYXRpb24/DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAgIFJvbg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4gT24gTm92IDEyLCAyMDEzLCBhdCAxOjUyIEFNLCAiS2V2aW4gSiBNYSINCj4+Pj4+Pj4+PiA8 a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4gWWVzLCByZWNsYXNzaWZpY2F0aW9uIGNhbiBjaGFuZ2UgdGhlIHNlcnZpY2Ug cGF0aCBhbmQgDQo+Pj4+Pj4+Pj4+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFu eSBub2RlIGFsb25nIGEgc2VydmljZSBwYXRoLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBKdXN0 IHRvIGV4cGFuZCBvbiB0aGF0LCBnb2luZyBiYWNrIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlvbiAN Cj4+Pj4+Pj4+Pj4gYWJvdXQgc2VydmljZSBoZWFkZXIgZW5jYXBzdWxhdGlvbiwgaXMgaXQgaW50 ZW5kZWQgdGhhdCBhIA0KPj4+Pj4+Pj4+PiBjaGFpbiB0aGF0IGlzIHJlLWNsYXNzaWZpZWQgd2ls bCBnZXQgYSBuZXcgY2hhaW4gSUQgd2hpY2ggDQo+Pj4+Pj4+Pj4+IGZ1bGx5IGRlc2NyaWJlcyBh IGNoYWluIHRoYXQgaXMgYSBzdXBlcnNldCBvZiB0aGUgb3JpZ2luYWwgDQo+Pj4+Pj4+Pj4+IGNo YWluIElELCBwcmlvciB0byBEUEktYmFzZWQgcmUtY2xhc3NpZmljYXRpb24/ICAoYXNzdW1pbmcg DQo+Pj4+Pj4+Pj4+IHRoZSBnb2FsIGlzICJhIHNpbmdsZSBjaGFpbiBJRCB0aGF0IGlzIGNvbW1v bmx5IHVuZGVyc3Rvb2QgDQo+Pj4+Pj4+Pj4+IGFsb25nIHRoZSBlbnRpcmUgc2VydmljZQ0KPj4+ Pj4+IGNoYWluIg0KPj4+Pj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbnNjL2N1cnJlbnQvbXNnMDA2MzguaHQNCj4+Pj4+Pj4+Pj4gbQ0KPj4+Pj4+Pj4+PiBsDQo+ Pj4+Pj4+Pj4+ICkNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gQW5kIHRoZSBhcHBsaWNhYmxlIHN1 YnNldCBvZiB0aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlIA0KPj4+Pj4+Pj4+PiBwYXRo cyB3b3VsZCBiZSBjb25maWd1cmVkIGF0IGVhY2ggYXBwcm9wcmlhdGUgc2VydmljZSBub2RlPw0K Pj4+Pj4+Pj4+PiBlLmcuLCBJRCAxOiBOQVQgKyBmaXJld2FsbCArIERQSQ0KPj4+Pj4+Pj4+PiAg ICAgSUQgMjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBVg0KPj4+Pj4+Pj4+PiAgICAgSUQgMzog TkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViArIE5BVA0KPj4+Pj4+Pj4+PiAgICAgSUQgNDogTkFU ICsgZmlyZXdhbGwgKyBEUEkgKyBOQVQNCj4+Pj4+Pj4+Pj4gICAgIElEIDU6IE5BVCArIGZpcmV3 YWxsICsgRFBJICsgQVYgKyBMQg0KPj4+Pj4+Pj4+PiAgICAgSUQgNjogTkFUICsgZmlyZXdhbGwg KyBEUEkgKyBMQg0KPj4+Pj4+Pj4+PiAgICAgSUQgNzogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBM QiArIENBQ0hFDQo+Pj4+Pj4+Pj4+ICAgICBJRCA4OiBOQVQgKyBmaXJld2FsbCArIERQSSArIENB Q0hFDQo+Pj4+Pj4+Pj4+ICAgICBJRCA5OiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXpl ciArIExCDQo+Pj4+Pj4+Pj4+ICAgICBJRCAxMDogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRp bWl6ZXIgKyBMQiArIENBQ0hFDQo+Pj4+Pj4+Pj4+ICAgICBJRCAxMTogTkFUICsgZmlyZXdhbGwg KyBEUEkgKyBvcHRpbWl6ZXIgKyBDQUNIRSBXb3VsZCANCj4+Pj4+Pj4+Pj4gZXZlcnkgZmxvdyB0 aGVuIGJlIGluaXRpYWxseSBjbGFzc2lmaWVkIGFzIElEIDEsIGJ1dCANCj4+Pj4+Pj4+Pj4gZXZl bnR1YWxseSBnZXQgcmUtDQo+Pj4+Pj4+Pj4gY2xhc3NpZmllZA0KPj4+Pj4+Pj4+PiB0byBJRCAy LTExLCBhZnRlciB0aGUgRFBJIHBoYXNlPw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiB0aGFueC4N Cj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4gRnJvbTogU3Vy ZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+Pj4+Pj4+ Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+Pj4+Pj4+Pj4+ PiBUbzogS2V2aW4gSiBNYTsgUm9uIFBhcmtlcjsgU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0 ZW47IA0KPj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IE9uIDExLzExLzEzIDk6NDYgUE0sICJLZXZp biBKIE1hIg0KPj4+Pj4+Pj4+Pj4+IDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0KPj4+Pj4+ Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+PiBIaSBTdXJlbmRyYSwNCj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IENsYXNzaWZpY2F0aW9uIG1heSBiZSBvdXQgb2Ygc2NvcGUs IGJ1dCB0aGUgbGV2ZWwgb2YgDQo+Pj4+Pj4+Pj4+Pj4gc2VydmljZSB0aGF0DQo+Pj4+Pj4+Pj4g aXMNCj4+Pj4+Pj4+Pj4+PiBhcHBsaWNhYmxlIGlzIGRlcGVuZGVudCB1cG9uIHRoZSBsZXZlbCBv ZiBjbGFzc2lmaWNhdGlvbiANCj4+Pj4+Pj4+Pj4+PiB0aGF0IGNhbg0KPj4+Pj4+Pj4+IGJlDQo+ Pj4+Pj4+Pj4+Pj4gcGVyZm9ybWVkLiAgQW4gYXNzdW1wdGlvbiBvZiBwYWNrZXQgbGV2ZWwgZW5j YXBzdWxhdGlvbiBoYXMNCj4+Pj4+Pj4+Pj4+IGltcGxpY2F0aW9ucw0KPj4+Pj4+Pj4+Pj4+IG9u IHRoZSBsZXZlbCBvZiBjbGFzc2lmaWNhdGlvbiBiZWluZyBwZXJmb3JtZWQ/ICBJZiB0aGUgDQo+ Pj4+Pj4+Pj4+Pj4gc3RhdGVkDQo+Pj4+Pj4+Pj4gZ29hbHMNCj4+Pj4+Pj4+Pj4+IGFyZQ0KPj4+ Pj4+Pj4+Pj4+IGZvciBmaXJld2FsbCBhbmQgbG9hZCBiYWxhbmNlciBmdW5jdGlvbmFsaXR5LCB0 aGVuIHRoZSANCj4+Pj4+Pj4+Pj4+PiBhcHBsaWNhdGlvbg0KPj4+Pj4+Pj4+Pj4gbGV2ZWwNCj4+ Pj4+Pj4+Pj4+PiBuYXR1cmUgb2YgdGhvc2UgZnVuY3Rpb25zIG5lZWRzIHRvIGJlIHRha2VuIGlu dG8gYWNjb3VudD8NCj4+Pj4+Pj4+Pj4+PiBJZiwgb24gdGhlIG90aGVyIGhhbmQsIHRoZSBzZXJ2 aWNlIGZ1bmN0aW9uIHNjb3BlIGlzIA0KPj4+Pj4+Pj4+Pj4+IGxpbWl0ZWQgZHVlIHRvIGxpbWl0 YXRpb25zIGluIGNsYXNzaWZpY2F0aW9uLCB0aGF0IHdvdWxkIGJlIA0KPj4+Pj4+Pj4+Pj4+IGFu ZCBpbXBvcnRhbnQgcGllY2Ugb2YNCj4+Pj4+Pj4+PiBpbmZvcm1hdGlvbj8NCj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+IFdydCBzZWN0aW9uIDQuNCBvZiBkcmFmdC1saXUtc2VydmljZS1jaGFp bmluZy11c2UtY2FzZXMNCj4+Pj4+Pj4+Pj4+PiB0aGUgZm9yayBwb2ludHMgb2YgdGhlIHNlcnZp Y2UgcGF0aHMgc2VlbSBsaWtlIA0KPj4+Pj4+Pj4+Pj4+IHJlLWNsYXNzaWZpY2F0aW9uDQo+Pj4+ Pj4gcG9pbnRzPw0KPj4+Pj4+Pj4+Pj4+IElzIHRoYXQgdGhlIGludGVycHJldGF0aW9uIGZyb20g dGhlIGFyY2hpdGVjdHVyZSBwZXJzcGVjdGl2ZT8NCj4+Pj4+Pj4+Pj4+PiBPciBpcyB0aGUgc2Vy dmljZSBmdW5jdGlvbiBjaGFpbiBjbGFzc2lmaWNhdGlvbiBleGNsdXNpdmUgDQo+Pj4+Pj4+Pj4+ Pj4gb2YgRFBJDQo+Pj4+Pj4+Pj4gZnVuY3Rpb25hbGl0eT8NCj4+Pj4+Pj4+Pj4+IDxTSz4gSSBo YXZlIG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwgDQo+Pj4+ Pj4+Pj4+PiBhcyBkZXNjcmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9m IHNlcnZpY2VzIA0KPj4+Pj4+Pj4+Pj4gZm9ybSBhIGdyYXBoLCBzZWdtZW50cyBvZiB3aGljaCBh cmUgc2VydmljZSBwYXRocy4gWWVzLCANCj4+Pj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2Fu DQo+Pj4+Pj4+Pj4gY2hhbmdlDQo+Pj4+Pj4+Pj4+PiB0aGUgc2VydmljZSBwYXRoIGFuZCByZS1j bGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSANCj4+Pj4+Pj4+Pj4+IG5vZGUgYWxvbmcN Cj4+Pj4+Pj4+PiBhIHNlcnZpY2UgcGF0aC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBTdXJl bmRyYS4NCj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+IHRoYW54Lg0KPj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogU3VyZW5kcmEg S3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+Pj4+Pj4+Pj4+Pj4+ IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDEyOjA4IEFNDQo+Pj4+Pj4+Pj4+Pj4+ IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRl bjsgDQo+Pj4+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBS ZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+PiBLZXZpbiwNCj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4gQ2xhc3NpZmlj YXRpb24gbWVjaGFuaXNtIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNGQy4gSXQgDQo+Pj4+Pj4+ Pj4+Pj4+IGNhbiBiZSBiYXNlZA0KPj4+Pj4+Pj4+Pj4gb24NCj4+Pj4+Pj4+Pj4+Pj4gdGhlIHBh Y2tldCBvciBpbmZvcm1hdGlvbiBub3QgaW4gdGhlIHBhY2tldChlbnZpcm9ubWVudGFsIA0KPj4+ Pj4+Pj4+Pj4+PiBhdHRyaWJ1dGVzDQo+Pj4+Pj4+Pj4+PiBmb3INCj4+Pj4+Pj4+Pj4+Pj4gaW5z dGFuY2UpIG9yIGEgY29tYmluYXRpb24gdGhlcmVvZi4gV2hhdCBpcyBpbXBvcnRhbnQgaXMgDQo+ Pj4+Pj4+Pj4+Pj4+IHRoYXQgc3VjaCBjbGFzc2lmaWNhdGlvbiBhaWRzIGluIHRyYWZmaWMgc2Vs ZWN0aW9uIGFuZCANCj4+Pj4+Pj4+Pj4+Pj4gc2VydmljZSBwYXRoIGlkZW50aWZpY2F0aW9uLg0K Pj4+Pj4+Pj4+Pj4+PiBJdCBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHBvbGljeSBpbiB0aGlzIHJl Z2FyZCBleGNlcHQgDQo+Pj4+Pj4+Pj4+Pj4+IHRoYXQgdGhlIHBvbGljeSBub3cgc3BlY2lmaWVz IHRoZSBzZXJ2aWNlIHBhdGguDQo+Pj4+Pj4+Pj4+Pj4+IEZ1cnRoZXIsIGNsYXNzaWZpY2F0aW9u IGlzIG5vdCBsaW1pdGVkIHRvIHRoZSBuZXR3b3JrIA0KPj4+Pj4+Pj4+Pj4+PiBlbGVtZW50cyBi dXQgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwuIFNvbWUgb2YgdGhpcyANCj4+Pj4+Pj4+ Pj4+Pj4gaXMgZGVzY3JpYmVkIGluIHRoZQ0KPj4+Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+ Pj4+Pj4+Pj4+IGRyYWZ0cyBhcyB3ZWxsIC0NCj4+Pj4+Pj4+Pj4+Pj4gImh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXF1aW5uLXNmYy1hcmNoLyIuDQo+Pj4+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+Pj4+IFN1cmVuZHJhLg0KPj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4g T24gMTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiDQo+Pj4+Pj4+Pj4+Pj4+PiA8a2V2aW4u bWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+PiBIaSBSb24sDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gSSB3 YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNGQyBCb0YgZHVlIHRvIGEgY29uZmxpY3Qgd2l0aCANCj4+ Pj4+Pj4+Pj4+Pj4+IENETkksIGJ1dCBJIGhhZCBhIHNpbWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxl dCAxMSBpbiANCj4+Pj4+Pj4+Pj4+Pj4+IHNlY3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4+IDIgb2YgdGhl DQo+Pj4+Pj4+Pj4gcHJvYmxlbQ0KPj4+Pj4+Pj4+Pj4+Pj4gc3RhdGVtZW50Og0KPj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICAxMS4gIFBlci1TZXJ2aWNlIChyZSlDbGFzc2lmaWNhdGlv bjogQ2xhc3NpZmljYXRpb24gDQo+Pj4+Pj4+Pj4+Pj4+PiBvY2N1cnMgYXQNCj4+Pj4+Pj4+PiBl YWNoDQo+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZp b3VzbHkgYXBwbGllZCANCj4+Pj4+Pj4+Pj4+Pj4+IHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4gZnVu Y3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4gICAgICAgVGhlc2UgdW5yZWxhdGVkIGNsYXNzaWZpY2F0 aW9uIGV2ZW50cyBjb25zdW1lIA0KPj4+Pj4+Pj4+Pj4+Pj4gcmVzb3VyY2VzDQo+Pj4+Pj4+Pj4g cGVyDQo+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBzZXJ2aWNlLiAgTW9yZSBpbXBvcnRhbnRseSwgdGhl IGNsYXNzaWZpY2F0aW9uDQo+Pj4+Pj4+Pj4gZnVuY3Rpb25hbGl0eQ0KPj4+Pj4+Pj4+Pj4+Pj4g ICAgICAgb2Z0ZW4gZGlmZmVycyBwZXIgc2VydmljZSBmdW5jdGlvbiBhbmQgc2VydmljZSANCj4+ Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9uDQo+Pj4+Pj4+Pj4+PiBjYW5ub3QNCj4+Pj4+Pj4+Pj4+Pj4+ ICAgICAgIGxldmVyYWdlIHRoZSByZXN1bHRzIGZyb20gb3RoZXIgZGVwbG95ZWQgbmV0d29yayBv cg0KPj4+Pj4+Pj4+IHNlcnZpY2UuDQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gYXMg aXQgcmVsYXRlcyB0byBzZWN0aW9uIDUuMiBvZiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Og0KPj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ICBUaGUgU0ZDIENsYXNzaWZpZXIgY2xhc3NpZmll cyBwYWNrZXRzIGJhc2VkIG9uIChzb21lDQo+Pj4+Pj4+Pj4+Pj4+PiBvZikgdGhlDQo+Pj4+Pj4+ Pj4+Pj4+IGNvbnRlbnRzDQo+Pj4+Pj4+Pj4+Pj4+PiAgb2YgdGhlIHBhY2tldCBoZWFkZXIuICBD b25jcmV0ZWx5LCBpdCBjbGFzc2lmaWVzDQo+Pj4+Pj4+Pj4+Pj4+PiBwYWNrZXRzIGJhc2VkIG9u DQo+Pj4+Pj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4gIHBvc3NpYmxlIGNvbWJpbmF0aW9u IG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsDQo+Pj4+Pj4+Pj4+Pj4+PiBzdWNoIGFzDQo+ Pj4+Pj4+Pj4gc291cmNlDQo+Pj4+Pj4+Pj4+Pj4+PiAgYWRkcmVzcywgZGVzdGluYXRpb24gYWRk cmVzcywgRFMgZmllbGQsIHByb3RvY29sIElELA0KPj4+Pj4+Pj4+Pj4+Pj4gc291cmNlDQo+Pj4+ Pj4+Pj4gcG9ydA0KPj4+Pj4+Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+ICBkZXN0aW5hdGlv biBwb3J0IG51bWJlcnMsIGFuZCBhbnkgb3RoZXIgaW5mb3JtYXRpb24uDQo+Pj4+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4+Pj4gQSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBhcyBkZXNjcmliZWQg aW4gdGhlIGZyYW1ld29yaw0KPj4+Pj4+Pj4+Pj4+Pj4gZG9jdW1lbnQNCj4+Pj4+Pj4+Pj4+Pj4g d291bGQNCj4+Pj4+Pj4+Pj4+Pj4+IHNlZW0gdG8gYmUgbGltaXRlZCBpbiB3aGF0IGl0IGNhbiBj bGFzc2lmeT8gIFRoZSBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4+PiBmdW5jdGlvbiBpZGVudGlmaWVy IGxvb2t1cCBkb2VzIG5vdCBzZWVtIHRvIGJlIGENCj4+Pj4+Pj4+Pj4+Pj4+IHNpZ25pZmljYW50 IG9wdGltaXphdGlvbg0KPj4+Pj4+Pj4+Pj4gb3Zlcg0KPj4+Pj4+Pj4+Pj4+Pj4gYSBwYWNrZXQt YmFzZWQgNS10dXBsZSBsb29rdXA/ICBUaGVyZSBzZWVtcyB0byBiZSBzb21lDQo+Pj4+Pj4+Pj4+ Pj4+PiBtaXNzaW5nDQo+Pj4+Pj4+Pj4+PiBkZXRhaWwNCj4+Pj4+Pj4+Pj4+Pj4+IHdydCBob3cg Y2xhc3NpZmljYXRpb24gaW5mb3JtYXRpb24gaXMgZGV0ZXJtaW5lZCBhbmQNCj4+Pj4+PiByZXVz ZWQ/DQo+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4gV2hlbiB0aGlua2luZyBhYm91dCBo aWdoZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhUVFANCj4+Pj4+Pj4+Pj4+Pj4+IGFuZCBUTFMN Cj4+Pj4+Pj4+Pj4+Pj4gZW5jcnlwdGVkDQo+Pj4+Pj4+Pj4+Pj4+PiBmbG93cywgYSBwYWNrZXQt YmFzZWQgY2xhc3NpZmllciBzZWVtcyBpbmFkZXF1YXRlPyAgSQ0KPj4+Pj4+Pj4+Pj4+Pj4gd2Fz IGFsc28NCj4+Pj4+Pj4+Pj4+Pj4gd29uZGVyaW5nDQo+Pj4+Pj4+Pj4+Pj4+PiBob3cgaW5kZXBl bmRlbnQgSExTIHNlZ21lbnQgcmVxdWVzdHMgbWlnaHQgYmUgY2xhc3NpZmllZA0KPj4+Pj4+Pj4+ Pj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4+Pj4+IGFzc29jaWF0ZWQ/DQo+Pj4+Pj4+Pj4+Pj4+PiBXZXJl IHRoZXNlIHR5cGVzIG9mIHVzZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJvRj8NCj4+Pj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+PiB0aGFueC4NCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+PiAtLSAgS2V2aW4gSi4gTWENCj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNl c0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZg0KPj4+Pj4+Pj4+Pj4gT2YNCj4+Pj4+Pj4+Pj4+Pj4+PiBSb24NCj4+Pj4+Pj4+ Pj4+Pj4+PiBQYXJrZXINCj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDEx LCAyMDEzIDEwOjE2IFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVlOyBUaG9t YXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW25z Y10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4gU3VtYW5kcmEsDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBBcyB3 YXMgZGlzY3Vzc2VkIGluIFZhbmNvdXZlciwgdGhlcmUgYXJlIGFscmVhZHkgbWFueQ0KPj4+Pj4+ Pj4+Pj4+Pj4+IGV4aXN0aW5nIHdheXMNCj4+Pj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+Pj4+Pj4+ PiBhY2NvbXBsaXNoIHNlcnZpY2UgY2hhaW5pbmcuICAgICBCdXQgbm9uZSBvZiB0aGVtIHByb3Zp ZGUNCj4+Pj4+PiBhDQo+Pj4+Pj4+Pj4+Pj4+IHN1ZmZpY2llbnQNCj4+Pj4+Pj4+Pj4+Pj4+PiBj b21iaW5hdGlvbiBvZiBpbnRlcm9wZXJhYmlsaXR5LCBmbGV4aWJpbGl0eSwgYW5kDQo+Pj4+Pj4g cmVzaWxpZW5jeS4NCj4+Pj4+Pj4+PiBBDQo+Pj4+Pj4+Pj4+Pj4+IHNpbmdsZQ0KPj4+Pj4+Pj4+ Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gZW5jYXBzdWxhdGlvbiB3aWxsIGdvIGEgbG9uZyB3YXkgdG8N Cj4+Pj4+Pj4+Pj4+Pj4+PiBlbnN1cmluZyB0aGVzZQ0KPj4+Pj4+Pj4+Pj4+PiBnb2Fscy4NCj4+ Pj4+Pj4+Pj4+Pj4+PiBJdCAgbWF5IG5vdCBiZSB0aGUgYWJzb2x1dGVseSBtb3N0IGVmZmljaWVu dCBhcHByb2FjaA0KPj4+Pj4+Pj4+Pj4+Pj4+IGZvciBldmVyeQ0KPj4+Pj4+Pj4+Pj4+PiBzaW5n bGUNCj4+Pj4+Pj4+Pj4+Pj4+PiBuZXR3b3JrIHRvcG9sb2d5IGFuZCBldmVyeSBzaW5nbGUgdXNl IGNhc2UsIGJ1dCBpdHMNCj4+Pj4+Pj4+Pj4+Pj4+PiB1YmlxdWl0b3VzDQo+Pj4+Pj4+Pj4+PiBu YXR1cmUNCj4+Pj4+Pj4+Pj4+Pj4+PiBzaG91bGQgaW1wcm92ZSBpdHMgYWRvcHRpb24uDQo+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgUm9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNv bV0NCj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjEw IFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0ZW47IG5zY0Bp ZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bv c2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBSb24sDQo+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBBYnNvbHV0ZWx5LCB0aGF0IHdhcyBhbiBl eGFtcGxlIG9mIG9uZSB0eXBlIG9mIGRlcml2YXRpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gSG93ZXZl cg0KPj4+Pj4+Pj4+Pj4+PiB0aGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gY291bGQgYmUgYXVnbWVudGVk IHdpdGggY2xhc3NpZmljYXRpb24gcmVzdWx0LCBhZ2Fpbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG9uZSBt b3JlDQo+Pj4+Pj4+Pj4+Pj4+IGV4YW1wbGUuDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVjZXNzYXJp bHkNCj4+Pj4+Pj4+Pj4+Pj4+Pj4+IGZvbGxvdw0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+ PiBzYW1lDQo+Pj4+Pj4+Pj4+Pj4+Pj4gY2hhaW4uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gQ29ycmVjdC4g SXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQgYWxsIHRyYW5zYWN0aW9uDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gb2YgdGhlIHNhbWUNCj4+Pj4+Pj4+Pj4+Pj4gZmxvdw0KPj4+Pj4+Pj4+Pj4+Pj4+IGZv bGxvdyB0aGUgc2FtZSBjaGFpbiBlaXRoZXIuIFNvIHdoeSBzdG9wIGF0IGZsb3cgaXRzZWxmLg0K Pj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gQWdhaW4gdGhlIHBvaW50IGhlcmUgaXMg dGhhdCBkbyB3ZSBhbHdheXMgbmVlZCBTRkMNCj4+Pj4+Pj4+Pj4+Pj4+PiBoZWFkZXIgb3INCj4+ Pj4+Pj4+IE5vdC4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFN1bWFuZHJhDQo+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogUm9uIFBhcmtlcg0KPj4+ Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+ Pj4+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDc6MDIgUE0NCj4+ Pj4+Pj4+Pj4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRm Lm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwN Cj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFRoZSBpbnRlbnRpb24gb2Ygc2Vydmlj ZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBhbGxvdw0KPj4+Pj4+Pj4+Pj4+Pj4+IGZvciBvcGVy YXRpb24NCj4+Pj4+Pj4+Pj4+Pj4gYXQNCj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgZnVsbHkgcXVhbGlm aWVkIGZsb3cgbGV2ZWwsIG9yIGV2ZW4gZmluZXIgZ3JhaW5lZA0KPj4+Pj4+Pj4+Pj4+Pj4+IGF0 IHRoZQ0KPj4+Pj4+Pj4+Pj4+PiB0cmFuc2FjdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+IGxldmVsICh0 aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIG1hdHRlciBmb3IgdGhlIFBEUCkuDQo+Pj4+Pj4gQWxs DQo+Pj4+Pj4+Pj4gZmxvd3MNCj4+Pj4+Pj4+Pj4+Pj4gZnJvbQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHRo ZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVjZXNzYXJpbHkgZm9sbG93IHRoZSBzYW1lDQo+Pj4+ Pj4gY2hhaW4uDQo+Pj4+Pj4+Pj4+PiBTb3VyY2UNCj4+Pj4+Pj4+Pj4+Pj4+PiBJUCwNCj4+Pj4+ Pj4+Pj4+Pj4+PiB0aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlmeSB0aGUgY2hhaW4gSUQuICAg IEFub3RoZXINCj4+Pj4+Pj4+IGludGVudGlvbg0KPj4+Pj4+Pj4+IG9mDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBvcGVyYXRlIG92ZXIgYW55DQo+Pj4+ Pj4+Pj4+Pj4+Pj4gbmV0d29yaw0KPj4+Pj4+Pj4+IHRvcG9sb2d5DQo+Pj4+Pj4+Pj4+PiBhbmQN Cj4+Pj4+Pj4+Pj4+Pj4+PiBub3QNCj4+Pj4+Pj4+Pj4+Pj4+PiBiZSBsaW1pdGVkIHRvIGEgc2lu Z2xlIExBTi4gICBUaHVzLCB3aGlsZSBWTEFOIG1heSBiZSBwYXJ0DQo+Pj4+Pj4gb2YNCj4+Pj4+ Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+PiB0cmFuc3BvcnQsIGl0IGRvZXMgbm90IGFkZXF1YXRl bHkgaWRlbnRpZnkgdGhlIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4+PiBjaGFpbiwNCj4+Pj4+Pj4+ Pj4+IGVpdGhlci4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ICBSb24NCj4+Pj4+ Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFp bHRvOlMuTWFqZWVARjUuY29tXQ0KPj4+Pj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1i ZXIgMTEsIDIwMTMgOTo1NiBQTQ0KPj4+Pj4+Pj4+Pj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9t YXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW25z Y10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+Pj4+Pj4gUm9uLA0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIHNlcnZp Y2UgaGVhZGVyIGlzIG1lYW50IHRvIGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gY2FuDQo+Pj4+Pj4+Pj4gKmFsc28qDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYmUgZGVyaXZlZCAo Zm9yIGV4YW1wbGUgdXNlIHNvdXJjZSBpcCBhbmQgdmxhbiB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+IGlk ZW50aWZ5IGNoYWluSUQgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4gcG9zaXRpb24pIG9yIGVuY2Fwc3Vs YXRlZCBhcyBwYXJ0IG9mIGFub3RoZXIgdHVubmVsDQo+Pj4+Pj4gaGVhZGVyLg0KPj4+Pj4+Pj4+ Pj4+Pj4+IFNvIHRoaXMgY291bGQgYmUgb3B0aW9uYWwgSU1ITy4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gRnJvbTogUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Um9uX1BhcmtlckBh ZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVt YmVyIDExLCAyMDEzIDQ6MzYgUE0NCj4+Pj4+Pj4+Pj4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7 IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJF OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+ IEFzIEkgdW5kZXJzdGFuZCBpdCwgYW4gU0ZDIHBhY2tldCB0cmF2ZXJzaW5nIGZyb20gUERQDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gdG8gU0Ygb3IgZnJvbQ0KPj4+Pj4+Pj4+Pj4+PiBTRg0KPj4+Pj4+Pj4+ Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU0Ygd2lsbCBsb29rIGxpa2U6DQo+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+ Pj4+Pj4+Pj4+IHwgICAgICAgICJ0cmFuc3BvcnQiICAgICAgICAgfA0KPj4+Pj4+Pj4+Pj4+Pj4+ ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+Pj4+Pj4+Pj4gfCAgICAgIHNlcnZp Y2UgaGVhZGVyICAgIHwNCj4+Pj4+Pj4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t Kw0KPj4+Pj4+Pj4+Pj4+Pj4+IHwgICBvcmlnaW5hbCBJUCBoZWFkZXIgIHwNCj4+Pj4+Pj4+Pj4+ Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4+Pj4+Pj4+IHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIG9yaWdpbmFsDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gfCBJUCBwYXlsb2FkDQo+Pj4+Pj4+Pj4gfA0KPj4+Pj4+Pj4+Pj4+Pj4+IHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+Pj4+Pj4+Pj4+Pj4+PiArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4g V2hlcmUgc2VydmljZSBoZWFkZXIgY29udGFpbnMsIGF0IGEgbWluaW11bSwgZW5vdWdoDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gaW5mb3JtYXRpb24gdG8NCj4+Pj4+Pj4+Pj4+Pj4gYWxsb3cNCj4+Pj4+Pj4+ Pj4+Pj4+PiB0aGUgcGFja2V0IHRvIGJlIHByb3BhZ2F0ZWQgYWxvbmcgdGhlIGZ1bGwgbGVuZ3Ro IG9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIGNoYWluLCBhbmQgb3B0aW9uYWxseSwgb3RoZXIgbWV0 YWRhdGEgdGhhdCBlbmhhbmNlcw0KPj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBvcGVyYXRpb24gb2YNCj4+ Pj4+Pj4+PiBvbmUNCj4+Pj4+Pj4+Pj4+Pj4+PiBvcg0KPj4+Pj4+Pj4+Pj4gbW9yZQ0KPj4+Pj4+ Pj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ Pj4+Pj4gQW5kIHdoZXJlICJ0cmFuc3BvcnQiIGNvdWxkIGNvbmNlaXZhYmx5IGJlIGFueSBvZiwg YnV0DQo+Pj4+Pj4+Pj4+Pj4+Pj4gbm90IGxpbWl0ZWQNCj4+Pj4+Pj4+Pj4+Pj4gdG86DQo+Pj4+ Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0DQo+Pj4+Pj4+Pj4+Pj4+Pj4g KiBFdGhlcm5ldCArIExMQzINCj4+Pj4+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgTVBMUw0KPj4+ Pj4+Pj4+Pj4+Pj4+ICogRXRoZXJuZXQgKyBJUCArIEdSRQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICogRXRo ZXJuZXQgKyBJUCArVURQDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRpYWdyYW0gYWJvdmUgaXMgbm90IG1l YW50IHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4gaW1wbHkgaW1tdXRhYmlsaXR5LCBidXQgcmF0aGVyIHRv IHNwZWNpZnkgdGhlIHBhY2tldA0KPj4+Pj4+Pj4+Pj4+Pj4+IHRoYXQgaXMNCj4+Pj4+Pj4+PiBw cm9wYWdhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZnJvbSBwcmVjZWRpbmcgZW50aXR5IHRvIHN1Y2Nl ZWRpbmcgZW50aXR5LCBwcmlvciB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24uDQo+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAgUm9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+ Pj4+PiBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+Pj4+Pj4+ IE9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50 OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDY6NDYgUE0NCj4+Pj4+Pj4+Pj4+Pj4+PiBUbzog VGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+IEdlbmVyaWMgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBFbmNhcHN1bGF0 aW9uOiBBDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZG9jdW1lbnQNCj4+Pj4+Pj4+IHdpbGwNCj4+Pj4+Pj4+ Pj4+Pj4+PiAgIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4gZm9ybWF0DQo+Pj4+Pj4+ Pj4+Pj4+Pj4gZm9yDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVu Y3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZnVuY3Rpb24NCj4+ Pj4+Pj4+Pj4+Pj4gcGF0aCwNCj4+Pj4+Pj4+Pj4+Pj4+PiAgIGFuZCBmb3IgY29tbXVuaWNhdGlu ZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4NCj4+Pj4+Pj4+Pj4+Pj4+PiBub2Rlcw0KPj4+ Pj4+IHRoYXQNCj4+Pj4+Pj4+Pj4+Pj4+PiAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4g SXQgaXMgaW50ZW5kZWQgdGhhdCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4+ Pj4+Pj4+Pj4+Pj4+ICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFw cGxpZWQgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4gdGhh dA0KPj4+Pj4+Pj4+Pj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBiZWluZyBjb25zdHJ1Y3Rl ZC4gVGhhdCBpcywgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG1heSBi ZQ0KPj4+Pj4+Pj4+IHVzZWQNCj4+Pj4+Pj4+Pj4+IG9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBhIHNl cnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yaw0KPj4+Pj4+Pj4+Pj4+ Pj4+IGxheWVyIG9yIGF0IGFueSBvdGhlcg0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgbGF5ZXIsIGFuZCB0 aGUgc2FtZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4+Pj4+Pj4+Pj4gY29u c3RydWN0aW9uDQo+Pj4+Pj4+Pj4+Pj4+IG9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBzZXJ2aWNlIGZ1 bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbA0KPj4+Pj4+IHNlcnZpY2UuDQo+ Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBbU01dIFdoYXQgZG9lcyBpdCBtZWFuIGJ5 IGEgc2luZ2xlIHNlcnZpY2UtbGV2ZWwNCj4+Pj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uLA0K Pj4+Pj4+Pj4+IGENCj4+Pj4+Pj4+Pj4+Pj4gbmV3DQo+Pj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxh dGlvbiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICAgb3IgYW4gYWJpbGl0eSB0byBz ZWxlY3Qgb25lIGVuY2Fwc3VsYXRpb24NCj4+Pj4+Pj4+Pj4+Pj4+PiBmb3JtYXQgdGhhdA0KPj4+ Pj4+Pj4+Pj4+PiBmaXRzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbmVl ZCBmb3IgYSBnaXZlbiBzZXJ2aWNlIGNoYWluPw0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgIFRo ZSBhYmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNpZmljDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxh dGlvbiB3b3VsZCBiZQ0KPj4+Pj4+Pj4+Pj4gYQ0KPj4+Pj4+Pj4+Pj4+Pj4+IG1hbmFnZW1lbnQg cGxhbmUgZGVjaXNpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICAgICAgICBUaGVyZSBhcmUgcXVpdGUg YSBmZXcgZXhpc3RpbmcgZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG1ldGhvZHMgdGhh dA0KPj4+Pj4+Pj4+Pj4+PiBjYW4NCj4+Pj4+Pj4+Pj4+Pj4+PiBwb3NzaWJseSBiZSByZXVzZWQg dG8gcHJvdmlkZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgICAgICAgY29udGV4dCBpbmZvcm1hdGlvbiBi ZXR3ZWVuICAgc2VydmljZSBub2Rlcy4gSQ0KPj4+Pj4+IGhhdmUNCj4+Pj4+Pj4+PiBzZWVuDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gbWVudGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG9mIEdSRSwgZm9yIEhUVFAg YmFzZWQNCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgIGFwcGxpY2F0aW9ucyBjb250ZXh0cyBhcmUg dHJhbnNmZXJyZWQgdmlhDQo+Pj4+Pj4gaGVhZGVycy4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+ IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+Pj4+Pj4+Pj4gT2YN Cj4+Pj4+Pj4+Pj4+Pj4+PiBUaG9tYXMgTmFydGVuDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAwNiwgMjAxMyAxMTowNyBBTQ0KPj4+Pj4+Pj4+Pj4+Pj4+IFRvOiBu c2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBbbnNjXSBDdXJyZW50IFByb3Bv c2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBIaS4NCj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEN1cnJlbnQgY2hhcnRlciBjYW4gYmUgZm91 bmQgYXQNCj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9j aGFydGVyLQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGlldGYtc2ZjLy4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+IEl0IGNvbnRhaW5zIHRoZSByZXZpc2VkIG1hbmFnZW1lbnQgdGV4dCBhcyB3 ZWxsIGFzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdXBkYXRlZA0KPj4+Pj4+Pj4+Pj4+PiBtaWxlc3RvbmVz Lg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gQWxsIGtub3duIGlzc3VlcyBoYXZl IGJlZW4gYWRkcmVzc2VkLiBJZiB0aGVyZSBhcmUgYW55DQo+Pj4+Pj4+Pj4+Pj4+Pj4gcmVtYWlu aW5nDQo+Pj4+Pj4+Pj4+Pj4+IGlzc3VlcywNCj4+Pj4+Pj4+Pj4+Pj4+PiBwbGVhc2Ugc3BlYWsg dXAhDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBDaGFydGVyIGNoYXJ0ZXItaWV0 Zi1zZmMtMDAtMDQNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IE5ldHdvcmtzLCBz ZXJ2ZXJzLCBzdG9yYWdlIHRlY2hub2xvZ2llcywgYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYXBwbGlj YXRpb25zLCBoYXZlIGFsbCB1bmRlcmdvbmUgc2lnbmlmaWNhbnQgY2hhbmdlIGluDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gcmVjZW50IHllYXJzIHdpdGggdGhlIGludHJvZHVjdGlvbg0KPj4+Pj4+Pj4+Pj4g b2YNCj4+Pj4+Pj4+Pj4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5k IG9yY2hlc3RyYXRpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gU2VydmljZQ0KPj4+Pj4+Pj4+Pj4gZGVs aXZlcnkNCj4+Pj4+Pj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+Pj4+Pj4+PiBjdXJyZW50bHkgYm90aCBh IHRlY2huaWNhbCBhbmQgb3JnYW5pemF0aW9uYWwgY2hhbGxlbmdlDQo+Pj4+Pj4+Pj4+Pj4+Pj4g dGhhdA0KPj4+Pj4+Pj4+Pj4gaW52b2x2ZXMNCj4+Pj4+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBt b2RpZmljYXRpb24gdG8gdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+ PiBTZXJ2aWNlcyBhcmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGJ5IHRoZSBvcmRlcmVkDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gY29tYmluYXRpb24gb2YgYSBudW1iZXIgb2Ygc2VydmljZSBmdW5jdGlvbnMg dGhhdCBhcmUNCj4+Pj4+Pj4+Pj4+Pj4+PiBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcG9pbnRzIHdp dGhpbg0KPj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEg Y29tbW9uIGRlcGxveW1lbnQgbW9kZWwgaGFzIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4+PiBmdW5j dGlvbnMgcGh5c2ljYWxseSBpbnNlcnRlZCBvbiB0aGUgZGF0YSBmb3J3YXJkaW5nDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gcGF0aCBiZXR3ZWVuIGNvbW11bmljYXRpbmcgcGVlcnMuDQo+Pj4+Pj4+Pj4+Pj4+ IEdvaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZm9yd2FyZCwgaG93ZXZlciwgdGhlcmUgaXMgYSBkZXNp cmUgdG8gbW92ZSB0byBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gZGlmZmVyZW50IG1vZGVsLA0KPj4+Pj4+ Pj4+Pj4+PiB3aGVyZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBub3Qg cmVxdWlyZWQgdG8gcmVzaWRlIG9uIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGRlZmF1bHQgZGF0YQ0K Pj4+Pj4+Pj4+Pj4gcGF0aA0KPj4+Pj4+Pj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+IHRy YWZmaWMgaXMgaW5zdGVhZCBzdGVlcmVkIHRocm91Z2ggc2VydmljZXMsIHdoZXJldmVyDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gdGhleSBhcmUNCj4+Pj4+Pj4+Pj4+Pj4gZGVwbG95ZWQuDQo+Pj4+Pj4+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBGb3IgYSBnaXZlbiBzZXJ2aWNlLCB0aGUgYWJzdHJhY3Rl ZCB2aWV3IG9mIHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHJlcXVpcmVkIHNlcnZpY2UgZnVuY3Rpb25z IGFuZCB0aGUgb3JkZXIgaW4gd2hpY2ggdGhleQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGFyZSB0byBiZSBh cHBsaWVkIGlzDQo+Pj4+Pj4+Pj4gY2FsbGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYSBTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluIChTRkMpLiBTaW5jZSBhIGdpdmVuIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4+ PiBmdW5jdGlvbiBtYXkgYmUgYXZhaWxhYmxlIG9uIG1vcmUgdGhhbiBvbmUgbm9kZSB3aXRoaW4N Cj4+Pj4+Pj4+Pj4+Pj4+PiBhIG5ldHdvcmssIGEgU2VydmljZSBGdW5jdGlvbiBDaGFpbiBpcyBp bnN0YW50aWF0ZWQNCj4+Pj4+Pj4+Pj4+Pj4gdmlhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIHNlbGVj dGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcw0KPj4+Pj4+Pj4+Pj4+ Pj4+IGFuZCB0aGUgbmV0d29yayBub2RlcyBvbiB3aGljaCB0aGV5IGFyZSBwcm92aWRlZCwNCj4+ Pj4+Pj4+Pj4+Pj4+PiB0aGVyZWJ5IGZvcm1pbmcgYSBzZXJ2aWNlIHRvcG9sb2d5Og0KPj4+Pj4+ Pj4+Pj4+Pj4+IHRoaXMgaXMgY2FsbGVkIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoLiBUaGUgc2Vy dmljZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9ucw0KPj4+Pj4+Pj4+IG1heQ0KPj4+Pj4+Pj4+ Pj4+Pj4+IGJlIGFwcGxpZWQgYXQgYSBzcGVjaWZpYyBsYXllciB3aXRoaW4gdGhlIG5ldHdvcmsN Cj4+Pj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbCBzdGFjaw0KPj4+Pj4+Pj4+Pj4+PiAobmV0d29yaw0K Pj4+Pj4+Pj4+Pj4+Pj4+IGxheWVyLCBhcHBsaWNhdGlvbiBsYXllciwgZXRjLikuDQo+Pj4+Pj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAo U0ZDKSB3b3JraW5nIGdyb3VwIHdpbGwNCj4+Pj4+Pj4+Pj4+Pj4+PiBkZXZlbG9wIG5ldyBhcHBy b2FjaGVzIHRvIHNlcnZpY2UgZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gSXQgd2lsbCBwcm9kdWNlIGEgZnJhbWV3b3JrIGZvciBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gY2hhaW5pbmcgdGhhdCBpbmNsdWRlcyB0aGUgbmVjZXNzYXJ5IHByb3RvY29s cw0KPj4+Pj4+Pj4+Pj4+PiBvcg0KPj4+Pj4+Pj4+Pj4+Pj4+IHByb3RvY29sIGV4dGVuc2lvbnMg dG8gY29udmV5IHRoZSBzZXJ2aWNlIHBhdGggYW5kDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmljZSBw YXRoIGluZm9ybWF0aW9uIHRvIG5vZGVzIHRoYXQgaW1wbGVtZW50DQo+Pj4+Pj4+Pj4+Pj4+Pj4g c2VydmljZSBmdW5jdGlvbnMsIGFzIHdlbGwNCj4+Pj4+Pj4+PiBhcw0KPj4+Pj4+Pj4+Pj4+Pj4+ IG1lY2hhbmlzbXMgZm9yIHN0ZWVyaW5nIHRyYWZmaWMgdGhyb3VnaCBzZXJ2aWNlIGZ1bmN0aW9u cy4NCj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUNCj4+Pj4+Pj4+Pj4+Pj4gd29ya2luZw0KPj4+Pj4+Pj4+ Pj4+Pj4+IGdyb3VwIHdpbGwgYWxzbyBleGFtaW5lIHdoYXQgaW5mb3JtYXRpb24gbmVlZHMgdG8g YmUNCj4+Pj4+Pj4+Pj4+Pj4+PiBnYXRoZXJlZCBmcm9tDQo+Pj4+Pj4+Pj4+Pj4+IHRoZQ0KPj4+ Pj4+Pj4+Pj4+Pj4+IG5ldHdvcmsgYW5kIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2Yg c2VydmljZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9uDQo+Pj4+Pj4+Pj4+PiBjaGFpbmluZw0K Pj4+Pj4+Pj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+IGhvdyB0aGF0IGluZm9ybWF0aW9u IG1heSBiZSBtYWRlIGF2YWlsYWJsZSB0byBub2Rlcw0KPj4+Pj4+Pj4+Pj4+Pj4+IHRoYXQgaW1w bGVtZW50DQo+Pj4+Pj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rp b25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gU3BlY2lmaWNhbGx5LCB0aGUg U0ZDIFdHIGlzIGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZQ0KPj4+Pj4+IGZvbGxvd2luZzoNCj4+ Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IDEpIFByb2JsZW0gU3RhdGVtZW50OiBUaGlz IGRvY3VtZW50IHdpbGwgcHJvdmlkZSBhDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc3VtbWFyeSBvZg0KPj4+ Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgcHJvYmxlbSBzcGFjZSB0byBiZSBhZGRyZXNz ZWQgYnkgdGhlIFdHIGluY2x1ZGluZw0KPj4+Pj4+Pj4+Pj4+Pj4+IGV4YW1wbGUNCj4+Pj4+Pj4+ PiBoaWdoLQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgbGV2ZWwgdXNlIGNhc2VzLiBBZGRpdGlvbmFsbHks IHRoZSBXRyB3aWxsIG5vcm1hbGl6ZQ0KPj4+Pj4+Pj4+Pj4gbm9tZW5jbGF0dXJlDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gICBhbmQgZGVmaW5pdGlvbnMgZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcu DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+PiAyKSBBcmNoaXRlY3R1cmU6IFRoaXMg ZG9jdW1lbnQgd2lsbCBwcm92aWRlIGENCj4+Pj4+Pj4+Pj4+Pj4+PiBkZXNjcmlwdGlvbiBvZg0K Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBhcmNoaXRlY3R1cmFsIGJ1aWxkaW5nIGJs b2NrcyBhbmQgdGhlaXINCj4+Pj4+Pj4+Pj4+Pj4+PiByZWxhdGlvbnNoaXBzDQo+Pj4+Pj4+Pj4g aW5jbHVkaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBpbnRlcmNvbm5lY3Rpb24sIHBsYWNlbWVudCBv ZiBjYXBhYmlsaXRpZXMsIG1hbmFnZW1lbnQsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBkaWFnbm9zdGlj cywgZGVzaWduIGFuYWx5c2lzLCBhbmQgc2VjdXJpdHkgbW9kZWxzLA0KPj4+Pj4+Pj4+Pj4+Pj4+ IGFzIHdlbGwNCj4+Pj4+Pj4+IGFzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICByZXF1aXJlbWVudHMgb24g dGhlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+ PiAzKSBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQQ0K Pj4+Pj4+Pj4+Pj4+Pj4+IGRvY3VtZW50DQo+Pj4+Pj4+Pj4gd2lsbA0KPj4+Pj4+Pj4+Pj4+Pj4+ ICAgZGVzY3JpYmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUNCj4+Pj4+Pj4+ Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+Pj4+ PiBmb3INCj4+Pj4+Pj4+Pj4+Pj4+PiAgIGNvbnZleWluZyB0aGUgc2VydmljZSBmdW5jdGlvbiBj aGFpbiBhbmQgdGhlIHNlcnZpY2UNCj4+Pj4+Pj4+Pj4+Pj4+PiBmdW5jdGlvbg0KPj4+Pj4+Pj4+ Pj4+PiBwYXRoLA0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNvbnRl eHQgaW5mb3JtYXRpb24gYmV0d2Vlbg0KPj4+Pj4+Pj4+Pj4+Pj4+IG5vZGVzDQo+Pj4+Pj4gdGhh dA0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgaW1wbGVtZW50IHNlcnZpY2UgZnVuY3Rpb25zLiBJdCBpcyBp bnRlbmRlZCB0aGF0IHRoZQ0KPj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gICBiZSBhZ25vc3RpYyB0byB0aGUgbGF5ZXIgYXQgd2hpY2ggaXQgaXMgYXBwbGllZCBh bmQNCj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgc2VydmljZQ0KPj4+Pj4+Pj4+Pj4+PiB0aGF0DQo+Pj4+ Pj4+Pj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+Pj4+Pj4+PiAgIGJlaW5nIGNvbnN0cnVjdGVkLiBUaGF0 IGlzLCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbWF5IGJlDQo+Pj4+ Pj4+Pj4gdXNlZA0KPj4+Pj4+Pj4+Pj4gb24NCj4+Pj4+Pj4+Pj4+Pj4+PiAgIGEgc2VydmljZSBm dW5jdGlvbiBwYXRoIHJlYWxpemVkIGF0IHRoZSBuZXR3b3JrDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbGF5 ZXIgb3IgYXQgYW55IG90aGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBsYXllciwgYW5kIHRoZSBzYW1l IGVuY2Fwc3VsYXRpb24gd2lsbCBhcHBseSBmb3IgdGhlDQo+Pj4+Pj4+Pj4+PiBjb25zdHJ1Y3Rp b24NCj4+Pj4+Pj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+Pj4+PiAgIHNlcnZpY2UgZnVuY3Rpb24g cGF0aHMgcmVnYXJkbGVzcyBvZiB0aGUgYWN0dWFsDQo+Pj4+Pj4gc2VydmljZS4NCj4+Pj4+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IDQpIENvbnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBz ZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUNCj4+Pj4+Pj4+PiBkZXZlbG9wZWQgdG8NCj4+Pj4+Pj4+ Pj4+Pj4+PiAgIGRlc2NyaWJlIHJlcXVpcmVtZW50cyBhbmQgcHJvdG9jb2xzIG5lY2Vzc2FyeSB0 bw0KPj4+Pj4+Pj4+Pj4+Pj4+IGNvbnZleQ0KPj4+Pj4+Pj4+Pj4+PiBpbmZvcm1hdGlvbg0KPj4+ Pj4+Pj4+Pj4+Pj4+ICAgdG8gc2VydmljZSBmdW5jdGlvbiBpbXBsZW1lbnRhdGlvbiBwb2ludHMu IFdoZXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4gcG9zc2libGUsDQo+Pj4+Pj4+Pj4+Pj4+IGV4aXN0aW5n DQo+Pj4+Pj4+Pj4+Pj4+Pj4gICBJRVRGIHByb3RvY29scyB3aWxsIGJlIHVzZWQgYW5kIGV4dGVu ZGVkLiBBbGwNCj4+Pj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbA0KPj4+Pj4+Pj4+Pj4gZXh0ZW5zaW9u cw0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgd29yayBzaG91bGQgYmUgY2FycmllZCBvdXQgaW4gdGhlIHdv cmtpbmcgZ3JvdXBzDQo+Pj4+Pj4+Pj4+Pj4+Pj4gcmVzcG9uc2libGUgZm9yDQo+Pj4+Pj4+Pj4+ Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgcHJvdG9jb2xzIGJlaW5nIG1vZGlmaWVkIGluIGNv b3JkaW5hdGlvbiB3aXRoIHRoaXMNCj4+Pj4+Pj4+Pj4+Pj4+PiB3b3JraW5nDQo+Pj4+Pj4+Pj4+ PiBncm91cCwNCj4+Pj4+Pj4+Pj4+Pj4+PiBidXQNCj4+Pj4+Pj4+Pj4+Pj4+PiAgIG1heSBiZSBk b25lIGluIHRoaXMgd29ya2luZyBncm91cCBhZnRlciBhZ3JlZW1lbnQNCj4+Pj4+Pj4+Pj4+Pj4+ PiB3aXRoIGFsbA0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICAgcmVsZXZhbnQgV0cg Y2hhaXJzIGFuZCByZXNwb25zaWJsZSBBRHMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ Pj4+PiA1KSBNYW5hZ2VhYmlsaXR5OiBXb3JrIG9uIHRoZSBtYW5hZ2VtZW50IGFuZA0KPj4+Pj4+ Pj4+Pj4+Pj4+IGNvbmZpZ3VyYXRpb24gb2YNCj4+Pj4+Pj4+Pj4+IHNlcnZpY2UNCj4+Pj4+Pj4+ Pj4+Pj4+PiAgIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIFNGQyBjb21wb25lbnRzIHdpbGwNCj4+ Pj4+Pj4+Pj4+Pj4+PiBjZXJ0YWlubHkgYmUNCj4+Pj4+Pj4+PiBuZWVkZWQsDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gICBidXQgZmlyc3QgbmVlZHMgdG8gYmUgYmV0dGVyIHVuZGVyc3Rvb2QgYW5kIHNjb3Bl ZC4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IFByb3Bvc2VkIE1pbGVzdG9uZXMN Cj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNH IEluZm9ybWF0aW9uYWwgZG9jdW1lbnQocykNCj4+Pj4+Pj4+Pj4+Pj4+PiBkZWZpbmluZyB0aGUN Cj4+Pj4+Pj4+Pj4+Pj4gcHJvYmxlbQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHN0YXRlbWVudCBhbmQgY29y ZSB1c2UgY2FzZXMgZm9yIFNlcnZpY2UgRnVuY3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4+PiBDaGFpbmlu Zw0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gTWF5IDIwMTQgQ29uc3VsdCB3aXRo IE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+Pj4+PiBtb2RpZmljYXRp b25zIGZvciBtYW5hZ2VtZW50IGFuZCBjb25maWd1cmF0aW9uIG9mIFNGQw0KPj4+Pj4+Pj4+Pj4+ Pj4+IGNvbXBvbmVudHMNCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEphbiAyMDE1 IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcNCj4+Pj4+Pj4+ Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4g Zm9yIFNGQw0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gSmFuIDIwMTUgU3VibWl0 IHRvIElFU0cgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVyaWMNCj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCj4+Pj4+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4+Pj4+IEF1ZyAyMDE1IFN1Ym1pdCB0byBJRVNHIFN0YW5kYXJkcyBU cmFjayBkb2N1bWVudA0KPj4+Pj4+Pj4+Pj4+Pj4+IHNwZWNpZnlpbmcgdGhlDQo+Pj4+Pj4+Pj4+ Pj4+IGdlbmVyaWMNCj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGhl YWRlciBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4+Pj4+IFRob21hcw0KPj4+Pj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+PiBu c2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4+ Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+Pj4+Pj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+Pj4+PiBuc2NAaWV0 Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25zYw0KPj4+Pj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+ Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4+Pj4gbnNjIG1haWxp bmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4+Pj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4gbnNjIG1h aWxpbmcgbGlzdA0KPj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBs aXN0DQo+Pj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+ Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4g bnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uc2MNCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+DQo+Pj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5zYyBtYWls aW5nIGxpc3QNCj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4gbnNjQGlldGYub3Jn DQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5zYyBt YWlsaW5nIGxpc3QNCj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+PiBuc2NAaWV0 Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4N Cj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5zYyBt YWlsaW5nIGxpc3QNCj5uc2NAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KDQoNCg0K From smkumar@cisco.com Thu Nov 14 19:15:59 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3F11E817D for ; Thu, 14 Nov 2013 19:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.204 X-Spam-Level: X-Spam-Status: No, score=-5.204 tagged_above=-999 required=5 tests=[MIME_BASE64_TEXT=2.796, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6aB7wxNst+ro for ; Thu, 14 Nov 2013 19:15:54 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9A27B11E8170 for ; Thu, 14 Nov 2013 19:15:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69950; q=dns/txt; s=iport; t=1384485353; x=1385694953; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=I49xxV1SQjKjZEgUl4vJAXcySEVSnNNnvM4F+f07qAI=; b=OFbYUXwRsmw6PcKnI2Un6UV1Nkc7jtQGOkzNsxV63UXWaq5SG0WotcFG ugImg6RGkJoCM3LuvLo65c5I7o2cs+yHNsnKJQBXQ5OVRx4OL2zCcV3Id GNq1QIISiV5c5fWy+9Tt5btjcAFuzoVmaVFXoWLf95Zoj92M1j4UaPexc w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAH6RhVKtJXG8/2dsb2JhbABPCoMHOFOCdrwsGIEJFnSCJQEBAQQBAQEXARkxAgcEBwwGAQgRAQMBAQEEERIFBCULFAMFAQgCBAEJBAUJh3gNkkSbVgaSVoEjjHMGBAEFBoEIEBsHAgICBIJbgUwDlC6DYpIMgyiBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208";a="285097208" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2013 03:15:51 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAF3Fp5X023294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 03:15:51 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 21:15:51 -0600 From: "Surendra Kumar (smkumar)" To: Andre Beliveau , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDwl0nN7MhlEaYEgafQy16wpojVngAgABdGwCAALQWgIAA0K0AgAAE9ACAAAKvAIAAAZMAgAADEACAAAGZgIAAFBSAgAAB7ICAAALaAIAAIasA Date: Fri, 15 Nov 2013 03:15:50 +0000 Message-ID: In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C2D8742@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.123.236] Content-Type: text/plain; charset="euc-kr" Content-ID: <6977F8ACF3B4194C93C0B66F80403D4D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 03:15:59 -0000 QUIsDQoNCk9uIDExLzE0LzEzIDk6MTUgQU0sICJBbmRyZSBCZWxpdmVhdSIgPGFuZHJlLmJlbGl2 ZWF1QGVyaWNzc29uLmNvbT4gd3JvdGU6DQoNCj5IaSwgDQo+DQo+SW4gZHJhZnQtYmVsaXZlYXUt c2ZjLWFyY2hpdGVjdHVyZSwgSSB3YXMgZXhwbGljaXQgdG8gZGVzY3JpYmUgMyBzZXBhcmF0ZQ0K PmxvZ2ljYWwgc2V0IG9mIGNvbXBvbmVudHM6ICB0aGUgc2VydmljZXMgKFNGKSwgdGhlIFNlcnZp Y2UgQ2hhaW5pbmcNCj5lbmZvcmNlbWVudCBmdW5jdGlvbnMgYW5kIHRoZSB0cmFuc3BvcnQgZnVu Y3Rpb25zIGJlY2F1c2Ugd2Ugd2FudCB0byBrZWVwDQo+dGhvc2Ugc2VwYXJhdGUgZnJvbSBlYWNo IG90aGVyIGFuZCBoYXZlIGNsZWFyIGludGVyZmFjZSBiZXR3ZWVuIHRoZW0uDQo+QW5kIGZvciBu b3csIHdlIHNob3VsZCBkaXNjdXNzIGFib3V0IHRoZW0gaW4gbG9naWNhbCB0ZXJtIGFuZCBub3QN Cj5waHlzaWNhbCBub2RlcyBhcyBvbmUgcGh5c2ljYWwgbm9kZSBtaWdodCB2ZXJ5IHdlbGwgaW5j bHVkZSBhbGwgMw0KPmZ1bmN0aW9ucy4NCj4NCi0tDQo+VGhlIFNDIGVuZm9yY2VtZW50IGZ1bmN0 aW9ucyBzaG91bGQgb3duIHNlcnZpY2UgY2hhaW5zIGFzIGRlZmluZWQgYnkgYW4NCj5vcGVyYXRv ciB3aGlsZSBhbiBTRiBtaWdodCBkZWNpZGUgdG8gd2hpY2ggY2hhaW4gKHRyYWNrKSB0aGUgcGFj a2V0DQo+c2hvdWxkIGNvbnRpbnVlIGl0cyByb3V0ZSBpdCBzaG91bGQgbm90IGJlIGFibGUgdG8g Y3JlYXRlIG5ldyBjaGFpbnMNCj4odHJhY2tzKS4NCi0tDQo8U0s+IFllcywgc2VydmljZSBjaGFp biBjcmVhdGlvbiBpcyBhIGNvbnRyb2wgcGxhbmUgYWN0aXZpdHkuIENQIGNyZWF0ZXMNCmNvcnJl c3BvbmRpbmcgc2VydmljZSBwYXRocyBhbmQgc29tZSBTRnMgbWF5IGNob29zZSBvbmUgYW1vbmcg dGhlDQphdmFpbGFibGUgc2VydmljZS1wYXRocyBmb3IgdGhlIG91dC1ib3VuZCBwYWNrZXRzLg0K DQpTdXJlbmRyYS4NCg0KPg0KPi9BQg0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIEppbQ0KPkd1aWNoYXJkIChqZ3VpY2hhcikNCj5TZW50OiBOb3ZlbWJlci0x NC0xMyAxMjowNSBQTQ0KPlRvOiBSb24gUGFya2VyDQo+Q2M6IG5zY0BpZXRmLm9yZzsgSG9uZ3l1 IExpIChKdWxpbyk7IERhdmlkIEFsbGFuIEkNCj5TdWJqZWN0OiBSZTogW25zY10gRlc6IHJlIGNs YXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQNCj5Qcm9wb3NlZCBTRkMgY2hh cnRlcg0KPg0KPkkgZG9uqfZ0IHRoaW5rIHdlIGFyZSBmb3JjaW5nIGFueXRoaW5nIGludG8gYSBs YXllciBidXQgc2ltcGx5IGNhbGwgb3V0DQo+ZGlmZmVyZW50IGNvbXBvbmVudHMgb2YgdGhlIG92 ZXJhbGwgc3lzdGVtIHRoYXQgd2lsbCB3b3JrIHRvZ2V0aGVyIGluDQo+Zm9ybWluZyB0aGUgU0ZD IGFyY2hpdGVjdHVyZS4gSWYgYW4gaW1wbGVtZW50b3Igd2lzaGVzIHRvIGNvbWJpbmUgdGhlDQo+ c2VydmljZSBmdW5jdGlvbiBhbmQgZm9yd2FyZGluZyBjb21wb25lbnRzIEkgc2VlIG5vIHJlYXNv biB3aHkgdGhpcyB3b3VsZA0KPm5vdCBiZSBjb21wbGlhbnQgd2l0aCB0aGUgYXJjaGl0ZWN0dXJl Lg0KPg0KPk9uIDExLzE0LzEzIDExOjU4IEFNLCAiUm9uIFBhcmtlciIgPFJvbl9QYXJrZXJAYWZm aXJtZWRuZXR3b3Jrcy5jb20+DQo+d3JvdGU6DQo+DQo+PkFncmVlLiAgIEJ1dCBpcyBpdCBuZWNl c3NhcnkgZm9yIHVzIHRvIGZvcmNlIHRoZSB0cmFuc3BvcnQgZW5jYXBzdWxhdGlvbg0KPj5pbnRv IG9uZSBvciB0aGUgb3RoZXIgbGF5ZXI/ICAgQ2FuIHdlIGp1c3Qgc2F5IHRoYXQgdGhlcmUgaXMs DQo+Pm5lY2Vzc2FyaWx5LCBhIHRyYW5zcG9ydCBkZS1lbmNhcHN1bGF0aW9uLCBzZmMgaGVhZGVy IGRlLWVuY2Fwc3VsYXRpb24sDQo+PnNlcnZpY2UgZnVuY3Rpb24gcHJvY2Vzc2luZywgc2ZjIGhl YWRlciBlbmNhcHN1bGF0aW9uLCB0cmFuc3BvcnQNCj4+ZW5jYXBzdWxhdGlvbiwgYW5kIGZpbmFs bHkgZm9yd2FyZGluZyBhbmQgdHJhbnNtaXNzaW9uIG9mIHRoZSBmdWxseQ0KPj5lbmNhcHN1bGF0 ZWQgcGFja2V0Pw0KPj4NCj4+ICAgUm9uDQo+Pg0KPj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+RnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBj aXNjby5jb21dDQo+PlNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxNCwgMjAxMyAxMDo0NiBBTQ0K Pj5UbzogUm9uIFBhcmtlcg0KPj5DYzogRGF2aWQgQWxsYW4gSTsgSG9uZ3l1IExpIChKdWxpbyk7 IG5zY0BpZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9u ICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQNCj4+UHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+DQo+ PlN1cmUgYnV0IGFyY2hpdGVjdHVyYWxseSB0aGUgc2VydmljZSBmdW5jdGlvbiBhbmQgZm9yd2Fy ZGluZyBjb21wb25lbnRzDQo+PmFyZSBzZXBhcmF0ZSBlbnRpdGllcy4gV2hldGhlciB5b3UgY2hv b3NlIHRvIGNvbWJpbmUgdGhlbSBpbg0KPj5pbXBsZW1lbnRhdGlvbiBpcyB5b3VyIG93biBjaG9p Y2UuDQo+Pg0KPj5TZW50IGZyb20gbXkgaVBob25lDQo+Pg0KPj4+IE9uIE5vdiAxNCwgMjAxMywg YXQgMTA6NDAgQU0sICJSb24gUGFya2VyIg0KPj4+PFJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jr cy5jb20+IHdyb3RlOg0KPj4+IA0KPj4+IEppbSwNCj4+PiANCj4+PiBJIHRoaW5rIHRoYXQgY291 bGQgYmUgYW4gaW1wbGVtZW50YXRpb24gZGVjaXNpb24uICAgT25lIGltcGxlbWVudGF0aW9uDQo+ Pj5hcHByb2FjaCBpcyB0aGF0IHRoZSBTRkMgSVAtbGF5ZXIgdHJhbnNwb3J0IHR1bm5lbHMgYXJl IGtub3duIGF0IHRoZQ0KPj4+Zm9yd2FyZGluZyBsYXllciAobGlrZSB0aGUgd2F5IElQLWluLUlQ IGFuZCBHUkUgdHVubmVscyBhcmUgZnJlcXVlbnRseQ0KPj4+c3VwcG9ydGVkIC0tIGFzIGFuIElQ IGludGVyZmFjZSkuICAgQW5vdGhlciBwb3NzaWJsZSBhcHByb2FjaCBpcyB0bw0KPj4+aGFuZGxl IHRoZSBTRkMgSVAtbGF5ZXIgdHJhbnNwb3J0IHR1bm5lbHMgYXQgYSBsZXZlbCBhYm92ZSB0aGUN Cj4+PmZvcndhcmRpbmcgbGF5ZXIgKGxpa2UgdGhlIHdheSBHVFAtVSB0dW5uZWxzIGFyZSBmcmVx dWVudGx5IHN1cHBvcnRlZA0KPj4+LS0gdGhleSBhcmUgbm90IHJlcHJlc2VudGVkIGFzIGRpc3Rp bmN0IElQIGludGVyZmFjZXMpLg0KPj4+IA0KPj4+ICAgIFJvbg0KPj4+IA0KPj4+IA0KPj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSmltIEd1aWNoYXJkIChqZ3VpY2hh cikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+Pj4gU2VudDogVGh1cnNkYXksIE5vdmVt YmVyIDE0LCAyMDEzIDEwOjMwIEFNDQo+Pj4gVG86IFJvbiBQYXJrZXI7IERhdmlkIEFsbGFuIEk7 IEhvbmd5dSBMaSAoSnVsaW8pOyBuc2NAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW25zY10g Rlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQNCj4+PiBQcm9w b3NlZCBTRkMgY2hhcnRlcg0KPj4+IA0KPj4+IEhpIFJvbiwNCj4+PiANCj4+PiBJIHdvdWxkIG5v dCBzYXkgdGhhdCBiIG1vZGlmaWVzIHRoZSB0cmFuc3BvcnQgaGVhZGVyIGJ1dCByYXRoZXIgYg0K Pj4+aW5mb3JtcyB0aGUgZm9yd2FyZGluZyBjb21wb25lbnQgb2YgaXQncyBpbnRlbnQgc28gdGhh dCBpdCBtYXkgaW5zZXJ0DQo+Pj50aGUgYXBwcm9wcmlhdGUgdHJhbnNwb3J0IGhlYWRlciB0byBt ZWV0IGIncyByZXF1aXJlbWVudC4NCj4+PiANCj4+Pj4gT24gMTEvMTQvMTMgMTA6MjQgQU0sICJS b24gUGFya2VyIiA8Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCj4+Pj53cm90ZToN Cj4+Pj4gDQo+Pj4+IEhpLCBKaW0uDQo+Pj4+IA0KPj4+PiBJIGFncmVlIHRoYXQgZm9yd2FyZGlu ZyBpcyBhZmZlY3RlZCBpbmRpcmVjdGx5LiAgIFdoZXRoZXIgZnVuY3Rpb24gYg0KPj4+PiBmb3J3 YXJkcyB0byBmdW5jdGlvbiBjIG9yIGZ1bmN0aW9uIGQgaXMgYWNjb21wbGlzaGVkIGJ5IGIgY29y cmVjdGx5DQo+Pj4+YWRkaW5nIChtb2RpZnlpbmcpIHRoZSB0cmFuc3BvcnQgaGVhZGVyIHNvIHRo YXQgZCBpcyBhZGRyZXNzZWQgb3IgYyBpcw0KPj4+PiBhZGRyZXNzZWQuICAgSW4gdGhlIG1vc3Qg Z2VuZXJhbCBjYXNlIG9mIHV0aWxpemluZyBhbiBJUC1iYXNlZA0KPj4+PnRyYW5zcG9ydA0KPj4+ PiBlbmNhcHN1bGF0aW9uIChlLmcuLCBJUC9VRFAsIElQL0dSRSwgZXRjLiksIHRoZSBzZWxlY3Rp b24gb2YgbmV4dA0KPj4+PmhvcCBpcw0KPj4+PiBub3QgbWFkZSBhdCB0aGlzIGxldmVsLiAgIFRo ZSB0cmFuc3BvcnQgbG9jYXRpb24gKElQIGFkZHJlc3MpIGZvciBjDQo+Pj4+YW5kIGQNCj4+Pj4g bWF5IG9yIG1heSBub3Qgc2hhcmUgdGhlIHNhbWUgbmV4dC1ob3AgYmFzZWQgb24gdGhlIG5ld3R3 b3JrDQo+Pj4+dG9wb2xvZ3kgIChpLmUuLCBjIGFuZC9vciBkIG1heSBvciBtYXkgbm90IGJlIG9u IHRoZSBzYW1lIHN1Ym5ldCBhcw0KPj4+PmIsIG1heSBvciAgbWF5IG5vdCBiZSByZWFjaGVkIHZp YSB0aGUgc2FtZSBuZXh0IGhvcCByb3V0ZXIpLg0KPj4+PiANCj4+Pj4gIFJvbg0KPj4+PiANCj4+ Pj4gDQo+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IG5zYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+ PiBPZiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KPj4+PiBTZW50OiBUaHVyc2RheSwgTm92ZW1i ZXIgMTQsIDIwMTMgMTA6MTQgQU0NCj4+Pj4gVG86IERhdmlkIEFsbGFuIEk7IEhvbmd5dSBMaSAo SnVsaW8pOyBuc2NAaWV0Zi5vcmcNCj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEZXOiByZSBjbGFz c2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50DQo+Pj4+IFByb3Bvc2VkIFNGQyBj aGFydGVyDQo+Pj4+IA0KPj4+PiBJIHRoaW5rIGl0IGlzIG1pc2xlYWRpbmcgdG8gc2F5IHRoYXQg YSBzZXJ2aWNlIGZ1bmN0aW9uIGRvZXMgbm90DQo+Pj4+aW1wYWN0IHBhY2tldCBmb3J3YXJkaW5n LiBJZiBicmFuY2hpbmcgb2NjdXJzIHRoZW4gdGhlIHNlcnZpY2UNCj4+Pj5mdW5jdGlvbiBkb2Vz IGltcGFjdCBwYWNrZXQgZm9yd2FyZGluZywgd2hldGhlciBkaXJlY3RseSBvcg0KPj4+PmluZGly ZWN0bHksIGFzIG90aGVyd2lzZSBwYWNrZXRzIHdvdWxkIG5vdCB0YWtlIHRoZSBuZXcgcGF0aCBh cyBhDQo+Pj4+cmVzdWx0IG9mIHRoZSBicmFuY2guIEZvciBleGFtcGxlLCBpZiB0aGUgY2hhaW4g aXMgYS1iLWMgYW5kIGINCj4+Pj5kZWNpZGVzIHRoYXQgZm9yIGNlcnRhaW4gZmxvd3MgdGhlIHRy YWZmaWMgc2hvdWxkIGdvIHRvIGQgcmF0aGVyIHRoYW4NCj4+Pj5jIHRoZW4gaXQgKm11c3QqIGZv cmNlIHRoZSBmb3J3YXJkaW5nIGNvbXBvbmVudCB0byBkaXJlY3QgdHJhZmZpYyB0bw0KPj4+PnRo ZSBuZXcgbmV4dC1ob3AuIFdoaWxlIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIG1heSBub3QgbW9kaWZ5 DQo+Pj4+Zm9yd2FyZGluZyBpbiB0ZXJtcyBvZiB1cGRhdGluZyBmb3J3YXJkaW5nIHRhYmxlcyBh bmQgc28gZm9ydGgsIGl0DQo+Pj4+aGFzIHRvIGluZm9ybSB0aGUgZm9yd2FyZGluZyBjb21wb25l bnQgb2YgaXRzIGludGVudCBzb21laG93LiBBbHNvLCBJDQo+Pj4+dGhpbmsgd2hhdCB5b3UgZGVz Y3JpYmUgRGF2ZSBpcyBhIGJ5cGFzcyBvcGVyYXRpb24gcmF0aGVyIHRoYW4gYQ0KPj4+PmJyYW5j aD8NCj4+Pj4gDQo+Pj4+PiBPbiAxMS8xNC8xMyA5OjU2IEFNLCAiRGF2aWQgQWxsYW4gSSIgPGRh dmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tPg0KPj4+Pj53cm90ZToNCj4+Pj4+IA0KPj4+Pj4gSSB0 aGluayBpdCBpcyBnb2luZyB0byBiZSBhIHJhcmUgZXZlbnQsIGFzIHdoYXQgaXMgbW9yZSBsaWtl bHkgaXMNCj4+Pj4+IHRoZSBmcm9udCBlbmQgb2YgdGhlIGNoYWluIGlzIGR5bmFtaWNhbGx5IG1v ZGlmaWVkIHNvIHN1YnNlcXVlbnQNCj4+Pj4+IHBhY2tldHMgaW4gYSBmbG93IHNraXAgY2VydGFp biBmdW5jdGlvbnMuIEhlbmNlIGEgZ3JhcGggbW9yZSBvZnRlbg0KPj4+Pj4gdGhhbiBub3QgaXMg bG9naWNhbGx5IFAyUC4gRmFjaWxpdGF0ZXMgdGVzdGluZyBhbW9uZ3N0IG90aGVyDQo+Pj4+PmJl bmVmaXRzLg0KPj4+Pj4gDQo+Pj4+PiBBcyBzdWNoIEknZCBub3Qgd2FudCB0byBiZSBwcmVzY3Jp cHRpdmUgYXMgdG8gaG93IGFuZCB3aGVyZSBpdCBpcw0KPj4+Pj4gZG9uZS4uLi4NCj4+Pj4+IA0K Pj4+Pj4gRGF2ZQ0KPj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+ Pj4gRnJvbTogSG9uZ3l1IExpIChKdWxpbykgW21haWx0bzpob25neXUubGlAaHVhd2VpLmNvbV0N Cj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTMsIDIwMTMgNjozMCBQTQ0KPj4+Pj4g VG86IERhdmlkIEFsbGFuIEk7IG5zY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVjdDogUkU6IFtuc2Nd IEZXOiByZSBjbGFzc2lmaWNhdGlvbiAmIGJyYW5jaGluZywgd2FzOiBDdXJyZW50DQo+Pj4+PiBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4gDQo+Pj4+PiBIaSBEYXZlLA0KPj4+Pj4gDQo+Pj4+ PiBZb3VyIGluZmVycmVkIHJlc3RyaWN0aW9uIG1heSBiZSBub3QgYWx3YXlzIHRydWUuIEluIGdl bmVyYWwsDQo+Pj4+PnNlcnZpY2UgZnVuY3Rpb25zIHNob3VsZCBiZSBhYmxlIHRvIGNvbXBvc2Ug YSBjaGFpbiBhcmJpdHJhcmlseS4NCj4+Pj4+IFBhcnRpY3VsYXJseSBmb3IgYnJhbmNoaW5nLCBh cyBJIHN1Z2dlc3RlZCBpbiBwcmV2aW91cyBlbWFpbCwNCj4+Pj4+c2VydmljZSBmdW5jdGlvbiBz aGFsbCBub3QgZGlyZWN0bHkgaW1wYWN0IHBhY2tldCBmb3J3YXJkaW5nLiBUaGlzDQo+Pj4+PnBy ZWNsdWRlcyB0aGUgcmVzdHJpY3Rpb24geW91IG1lbnRpb25lZC4gRm9yd2FyZGluZyBwbGFuZSBj YW4gZGVjaWRlDQo+Pj4+PndoZXRoZXIgYSBicmFuY2hpbmcgYWN0aW9uIHNob3VsZCBiZSB0YWtl biBieSByZWNsYXNzaWZpY2F0aW9uIG9yDQo+Pj4+Pm5vdCBwZXIgc2VydmljZSBjaGFpbi4NCj4+ Pj4+IA0KPj4+Pj4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQo+Pj4+PiANCj4+Pj4+IEhvbmd5dQ0K Pj4+Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogRGF2 aWQgQWxsYW4gSSBbbWFpbHRvOmRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tXQ0KPj4+Pj4gU2Vu dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMywgMjAxMyAxMTo0NSBQTQ0KPj4+Pj4gVG86IEhvbmd5 dSBMaSAoSnVsaW8pOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBGVzog cmUgY2xhc3NpZmljYXRpb24gJiBicmFuY2hpbmcsIHdhczogQ3VycmVudA0KPj4+Pj4gUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+IA0KPj4+Pj4gSEkgSG9uZ3l1Og0KPj4+Pj4gDQo+Pj4+PiBJ IHRoaW5rIHdlIHdpbGwgaGF2ZSBzY2VuYXJpb3Mgd2hlcmUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGFw cGVhcnMgaW4NCj4+Pj4+IG1vcmUgdGhhbiBvbmUgY2hhaW4sIGFzIHdvdWxkIGJlIHRoZSBjYXNl LCBmb3IgZXhhbXBsZSwgaWYgc29tZQ0KPj4+Pj4gZmxvd3MgY291bGQgZHluYW1pY2FsbHkgYnlw YXNzIERQSSBidXQgc3RpbGwgbmVlZGVkIHRvIHRyYW5zaXQgYQ0KPj4+Pj4gY29tbW9uIHNldCBv ZiBzdGF0ZWZ1bCBzZXJ2aWNlIGZ1bmN0aW9ucy4uLg0KPj4+Pj4gDQo+Pj4+PiBPbmNlIHlvdSBw b3N0dWxhdGUgYSBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIGFwcGVhcmluZyBpbiBtb3JlDQo+ Pj4+PiB0aGFuIG9uZSBjaGFpbiwgaXQgc2VlbXMgYXJ0aWZpY2lhbGx5IHJlc3RyaWN0aXZlIG5v dCB0byBwZXJtaXQNCj4+Pj4+IHN1Y2ggYSBmdW5jdGlvbiB0byBhbHNvIGltcGxlbWVudCBicmFu Y2hpbmcsIGFsbCB0aGUgY29udHJvbA0KPj4+Pj4gc3RydWN0dXJlcyB3b3VsZCBhbHJlYWR5IGJl IHRoZXJlLg0KPj4+Pj4gDQo+Pj4+PiBSZ2RzDQo+Pj4+PiBEYXZlDQo+Pj4+PiANCj4+Pj4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBIb25neXUgTGkgKEp1bGlvKSBb bWFpbHRvOmhvbmd5dS5saUBodWF3ZWkuY29tXQ0KPj4+Pj4gU2VudDogV2VkbmVzZGF5LCBOb3Zl bWJlciAxMywgMjAxMyAyOjEyIEFNDQo+Pj4+PiBUbzogRGF2aWQgQWxsYW4gSTsgbnNjQGlldGYu b3JnDQo+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJh bmNoaW5nLCB3YXM6IEN1cnJlbnQNCj4+Pj4+IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+PiAN Cj4+Pj4+IE1heSBJIHN1Z2dlc3Qgc3VtbWFyeSBvZiBteSB2aWV3cyBoZXJlOg0KPj4+Pj4gDQo+ Pj4+PiAxLiBCcmFuY2ggaXMgYSBzb3J0IG9mIHVzZSBjYXNlIG9yIHNjZW5hcmlvLCB3aGlsZSBy ZWNsYXNzaWZpY2F0aW9uDQo+Pj4+PmlzIGEgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLg0KPj4+ Pj4gMi4gU2VydmljZSBGdW5jdGlvbnMgc2hvdWxkIGJlIGRlY291cGxlZCB3aXRoIHRoZSBjaGFp biBpdHNlbGYuDQo+Pj4+PiAgICBNZWFuaW5nLCBhIFNGIHNoYWxsIG5vdCAqZGlyZWN0bHkqIGlt cGFjdCB0aGUgZm9yd2FyZGluZyBvZg0KPj4+Pj5wYWNrZXRzIGluIGEgY2hhaW4uIEJyYW5jaGlu ZyBzaG91bGQgYmUgcGVyZm9ybWVkIGJ5IGNoYWluDQo+Pj4+PmZvcndhcmRpbmcgbm9kZXMsIHBv c3NpYmx5IHVuZGVyIGNvbnRyb2wgb2YgYSBjb250cm9sIG5vZGUuIFRoZQ0KPj4+Pj5yZWFzb24g Zm9yIHRoaXMgaXMgaW4gTkZWIHdvcmxkLCBzZXJ2aWNlIGZ1bmN0aW9ucyBtYXkgY29tZSBmcm9t IGENCj4+Pj4+dGhpcmQgcGFydHksIHdoaWxlIGNoYWluIGlzIHByb3ZpZGVkIGJ5IHRoZSBpbmZy YXN0cnVjdHVyZSBvZiB0aGUNCj4+Pj4+bmV0d29yay4gVGhlcmUgbXVzdCBiZSBhIGN1c2hpb24g YXZvaWRpbmcgYSBzZXJ2aWNlIGZ1bmN0aW9uDQo+Pj4+Pm9wZXJhdGluZyBpbmZyYXN0cnVjdHVy ZSBkaXJlY3RseS4NCj4+Pj4+IDMuIChSZSljbGFzc2lmaWNhdGlvbiBpcyBiYXNlZCBvbiBpbmZv IGluIGEgcGFja2V0Lg0KPj4+Pj4gICAgVGhpcyBpcyB2ZXJ5IGdlbmVyYWwuIFN1Y2ggaW5mbyBj b3VsZCBiZSBMMn5MNyBkZXJpdmVkIGZyb20gYQ0KPj4+Pj51c2VyJ3MgcGFja2V0LCBhcyB3ZWxs IGFzIHNvbWUgaW5mbyBsaWtlIG1ldGFkYXRhIGluIGEgU0ZDIGhlYWRlci4NCj4+Pj4+IEFzIGNs YXNzaWZpY2F0aW9uIGlzIG91dCBvZiBzY29wZSBvZiBTRkMsIHdlIGRvbid0IGhhdmUgdG8gcHJv dmlkZQ0KPj4+Pj50b28gbXVjaCBkZXRhaWxzIG9mIGhvdyB0byBkbyBjbGFzc2lmaWNhdGlvbi4N Cj4+Pj4+IDQuIENoYWluIHNlZ21lbnRzIHN0aXRjaGluZyBpcyByZWxhdGl2ZWx5IGEgZWFzeSB3 YXkgZm9yIGJyYW5jaGluZy4NCj4+Pj4+IENvbXBhcmVkIHdpdGggY2hhaW5zIGFuZCBzdWJjaGFp bnMsIHdoaWNoIG1heSByZXF1aXJlIGEgbW9yZQ0KPj4+Pj5jb21wbGV4ICBoZWFkZXIgYW5kIGZv cndhcmRpbmcgY2FwYWJpbGl0aWVzLg0KPj4+Pj4gTXkgdHdvIGNlbnRzLg0KPj4+Pj4gSG9uZ3l1 DQo+Pj4+PiANCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYNCj4+Pj4+IE9mIERhdmlkIEFsbGFuIEkNCj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTMsIDIwMTMgMzowNCBBTQ0KPj4+Pj4gVG86IG5zY0BpZXRmLm9yZw0KPj4+Pj4gU3ViamVj dDogW25zY10gRlc6IHJlIGNsYXNzaWZpY2F0aW9uICYgYnJhbmNoaW5nLCB3YXM6IEN1cnJlbnQN Cj4+Pj4+IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+PiANCj4+Pj4+IEhpOg0KPj4+Pj4gKHJl c2VuZCB3aXRoIHJlY2lwaWVudCBsaXN0IGNsZWFuZWQgdXApDQo+Pj4+PiANCj4+Pj4+IEkgYWdy ZWUgd2UgYXJlIGRpc2N1c3NpbmcgbXVsdGlwbGUgY29uY2VwdHMsIGNsYXNzaWZpY2F0aW9uIGFu ZA0KPj4+Pj4gZmxvdy1zdWJzZXR0aW5nLiBQZXJoYXBzIG1vcmUgOy0pDQo+Pj4+PiANCj4+Pj4+ IERlZmluaW5nIGEgZmxvdyBzdWJzZXQgY2FuIGJlIGEgcmVzdWx0IG9mIGNsYXNzaWZpY2F0aW9u LCBidXQgaXQgaXMNCj4+Pj4+IG5vdCB0aGUgZXhjbHVzaXZlIG1lY2hhbmlzbS4gQnJhbmNoaW5n IGlzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGZsb3cNCj4+Pj4+IHN1YnNldHMgYXJlIGV4cG9zZWQg YW5kIG1hcHBlZCB0byBhIHNldCBvZiBzdWJjaGFpbnMgc3VjaCB0aGF0IGl0DQo+Pj4+PiBjYW4g YmUgaWRlbnRpZmllZCBpbiB0aGUgZGF0YXBsYW5lLi4uDQo+Pj4+PiANCj4+Pj4+IFRoYXQncyB0 aGUgdmlldyBmcm9tIGhlcmUNCj4+Pj4+IERhdmUNCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPj4+Pj4gT2YgRGF2aWQgTGFrZSAoZGxh a2UpDQo+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxMDo1MSBBTQ0KPj4+ Pj4gVG86IEppbSBHdWljaGFyZCAoamd1aWNoYXIpOyBLZXZpbiBKIE1hOyBTdXJlbmRyYSBLdW1h ciAoc21rdW1hcik7DQo+Pj4+PiBSb24gUGFya2VyOyBMaW5kYSBEdW5iYXI7IEhvbmd5dSBMaSAo SnVsaW8pDQo+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBN YWplZQ0KPj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0 ZXINCj4+Pj4+IA0KPj4+Pj4gVW5kZXJzdG9vZCAtIG1heWJlIGp1c3QgYSBsaXR0bGUgbG9jYWxp c2VkIHdhcm1pbmcgb2YgdGhlIHNlYSB0aGVuID8NCj4+Pj4+IEJ1dCBJIHN0aWxsIHRoaW5rIHdl IG5lZWQgdG8gY29uc2lkZXIgd2hlcmUgYW5kIGhvdyBwb2xpY3kgaXMNCj4+Pj4+IGRlZmluZWQv c2V0IGV2ZW4gZm9yIHRoZSBzaW5nbGUtZG9tYWluIGluc3RhbmNlLg0KPj4+Pj4gDQo+Pj4+PiBJ IGRvbid0IHRoaW5rIHdlIGNhbiBhc3N1bWUgdGhhdCBhbnkgTDEtMyBkZXZpY2Ugd2lsbCBiZSBh YmxlIHRvDQo+Pj4+PiBkZXRlcm1pbmUgbXVjaCB1c2VmdWwgaW5mb3JtYXRpb24gZnJvbSB0aGUg ZGF0YS1wbGFuZS4NCj4+Pj4+IA0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ Pj4+IEZyb206IEppbSBHdWljaGFyZCAoamd1aWNoYXIpDQo+Pj4+PiBTZW50OiAxMiBOb3ZlbWJl ciAyMDEzIDEwOjQ0DQo+Pj4+PiBUbzogRGF2aWQgTGFrZSAoZGxha2UpOyBLZXZpbiBKIE1hOyBT dXJlbmRyYSBLdW1hciAoc21rdW1hcik7IFJvbg0KPj4+Pj4gUGFya2VyOyBMaW5kYSBEdW5iYXI7 IEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3Jn OyBTdW1hbmRyYSBNYWplZQ0KPj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+IA0KPj4+Pj4gQXMgZGlzY3Vzc2VkIGR1cmluZyB0aGUgQk9G IG91ciBpbml0aWFsIHdvcmsgaXMgc2luZ2xlDQo+Pj4+PmFkbWluaXN0cmF0aXZlIGRvbWFpbiBm b3Igc29tZSBvZiB0aGUgdmVyeSByZWFzb25zIHlvdSBwb2ludCBvdXQuIFdlDQo+Pj4+Pm5lZWQg dG8ga2VlcCBmb2N1c2VkIHdpdGhvdXQgdHJ5aW5nIHRvIGJvaWwgdGhlIG9jZWFuIHJpZ2h0IG9m ZiB0aGUNCj4+Pj4+YmF0Lg0KPj4+Pj4gDQo+Pj4+Pj4gT24gMTEvMTIvMTMgMTozNiBQTSwgIkRh dmlkIExha2UgKGRsYWtlKSIgPGRsYWtlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+Pj4gDQo+Pj4+ Pj4gRXhhY3RseS4gIEJ1dCBob3cgY2FuIG5ldHdvcmstY29tcG9uZW50cyAidGVybWluYXRlIiBh bg0KPj4+Pj4+YXBwbGljYXRpb24gPz8/Pw0KPj4+Pj4+IA0KPj4+Pj4+IEkgdGhpbmsgd2UgbmVl ZCBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiBhIHJlY3Vyc2l2ZSBwb2xpY3kNCj4+Pj4+Pm1lY2hh bmlzbSAocmVjdXJzaXZlIGJlY2F1c2UgYSB1c2VyLWxhbmQgYXBwbGljYXRpb24gd2lsbCByaWRl IHdpdGgNCj4+Pj4+PmEgc3BlY2lmaWMgcG9saWN5IGFjcm9zcyBwb3RlbnRpYWxseSBkaWZmZXJl bnQgc2V0cyBvZiBjYXJyaWVyDQo+Pj4+Pj5wb2xpY2llcykuDQo+Pj4+Pj4gDQo+Pj4+Pj4gSSBo YXRlIHRvIGJyaW5nIHRoaXMgdXAgbm93LCBidXQgd2UgYWxzbyBuZWVkIHRvIHRoaW5rIGFib3V0 IHRoaXMNCj4+Pj4+PiBtdWx0aS1kb21haW4gaXNzdWUgLSBpZiBJIHNldCBhIHBvbGljeSBhcyBh IHVzZXIsIGNoYW5jZXMgYXJlIEkNCj4+Pj4+PiB3aWxsIGJlIGNyb3NzaW5nIHNldmVyYWwgZG9t YWluIGJvdW5kYXJpZXMuICBBcmUgd2UgZXhwZWN0aW5nIHRoZQ0KPj4+Pj4+IHNlcnZpY2UgaGVh ZGVycyB0byBkZWZpbmUgdGhlIHNlcnZpY2UgY2hhaW5pbmcgZm9yIHRoZSBkdXJhdGlvbiBvZg0K Pj4+Pj4+IHRoZSBlbnRpcmUgZmxvdyBhY3Jvc3MgYWxsIGRvbWFpbnMsIG9yIGp1c3QgYWNyb3Nz IGEgc2luZ2xlIG9uZSA/DQo+Pj4+Pj4gDQo+Pj4+Pj4gSW4gd2hpY2ggY2FzZSwgZG8gSSBoYXZl IHRvIHJlLXNldCBwb2xpY3kgYXMgSSB0cmF2ZXJzZSBkb21haW5zICBhbmQNCj4+Pj4+PiB3aGVy ZSBkb2VzIHRoYXQgcG9saWN5IGdldCBzZXQgPyAgIEl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIHRv IHNldA0KPj4+Pj4+cG9saWN5DQo+Pj4+Pj4gb25jZSBiYXNlZCBvbiBMNS03IG5lZWRzLCBhbmQg aGF2ZSB0aGF0IGluc3RhbnRpYXRlZCBhY3Jvc3MgdGhlDQo+Pj4+Pj5tdWx0aXBsZSBkb21haW5z Lg0KPj4+Pj4+IA0KPj4+Pj4+IEFnYWluLCB0aGlzIGFwcGVhcnMgdG8gYmUgb3V0c2lkZSB0aGUg c2NvcGUgb2YgU0ZDLCBidXQgcHJldHR5DQo+Pj4+Pj4gcmVsZXZhbnQgdG8gaG93IGl0IHdvdWxk IG9wZXJhdGUgaW4gdGhlIHJlYWwgd29ybGQuDQo+Pj4+Pj4gDQo+Pj4+Pj4gRGF2aWQNCj4+Pj4+ PiANCj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+IEZyb206IEtldmlu IEogTWEgW21haWx0bzprZXZpbi5tYUBhenVraXN5c3RlbXMuY29tXQ0KPj4+Pj4+IFNlbnQ6IDEy IE5vdmVtYmVyIDIwMTMgMTA6MjcNCj4+Pj4+PiBUbzogRGF2aWQgTGFrZSAoZGxha2UpOyBTdXJl bmRyYSBLdW1hciAoc21rdW1hcik7IFJvbiBQYXJrZXI7DQo+Pj4+Pj4gTGluZGEgRHVuYmFyOyBI b25neXUgTGkgKEp1bGlvKQ0KPj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7 IFN1bWFuZHJhIE1hamVlDQo+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+PiANCj4+Pj4+Pj4gSW4gdGhvc2UgY2lyY3Vtc3RhbmNlcywg b25seSB0aGUgZW5kIGFwcGxpY2F0aW9ucyB0aGVtc2VsdmVzIG9yIGENCj4+Pj4+Pj4gcmVhc29u YWJseSBicm9hZC1icnVzaGVkIGNsYXNzaWZpY2F0aW9uIChyZWFsbHkgdHJhZmZpYyBzdGVlcmlu Zw0KPj4+Pj4+PiBiYXNlZCBvbiB3aGF0IHdlIGNhbiBzZWUgYXQgaW5ncmVzcykgaXMgZ29pbmcg dG8gYmUgdXNlZnVsIC0gaXMNCj4+Pj4+Pj4gVEhBVCB3aGF0IHdlJ3JlIGFpbWluZyBmb3IgaGVy ZSA/DQo+Pj4+Pj4gDQo+Pj4+Pj4gSSB3b3VsZCBjZXJ0YWlubHkgaG9wZSBub3QsIGJ1dCB0aGF0 IGhhcyBiZWVuIG15IGNvbmNlcm4gYXMgd2VsbC4NCj4+Pj4+PiBBcHBsaWNhdGlvbiBsYXllciB0 ZXJtaW5hdGlvbiBhbmQgcmUtY2xhc3NpZmljYXRpb24gc2VlbXMgYSBtdXN0Pw0KPj4+Pj4+IA0K Pj4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0KPj4+Pj4+IA0KPj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBEYXZpZCBMYWtlIChkbGFrZSkgW21haWx0bzpkbGFr ZUBjaXNjby5jb21dDQo+Pj4+Pj4+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDE6 MDAgUE0NCj4+Pj4+Pj4gVG86IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKTsgUm9uIFBhcmtlcjsg S2V2aW4gSiBNYTsgTGluZGENCj4+Pj4+Pj4gRHVuYmFyOyBIb25neXUgTGkgKEp1bGlvKQ0KPj4+ Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZQ0KPj4+ Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+ Pj4+PiANCj4+Pj4+Pj4gUG9saWN5IG1heSBiZSBvdXRzaWRlIG9mIHRoZSBzY29wZSBvZiBTRkMs IGJ1dCB3aXRob3V0IHN0cm9uZw0KPj4+Pj4+PiBtYXBwaW5nIGJldHdlZW4gUG9saWN5IGFuZCB0 aGUgaW5zZXJ0ZWQgU2VydmljZSBIZWFkZXIocyksIHdlDQo+Pj4+Pj4+IHJ1bi10aGUtcmlzayBv ZiBsaW1pdGluZyB0aGUgZWZmaWNhY3kgb2YgdGhlIHByb3RvY29sIElNTy4NCj4+Pj4+Pj4gDQo+ Pj4+Pj4+IEZvciBleGFtcGxlLCBpbiBhIHdvcmxkIHdoZXJlIHRoZSBuZXR3b3JrIGhhcyAiZ29u ZSBkYXJrLCIgKGFzDQo+Pj4+Pj4+IHBlciB0aGUgSUVURiBUZWNobmljYWwgUGxlbmFyeSA/Oi0p ICkgd2hhdCBpcyBvdXIgYWJpbGl0eSB0bw0KPj4+Pj4+PiBkZXRlcm1pbmUgcG9saWN5IGJhc2Vk IG9uIERQSSBvZiBwYWNrZXRzLWluLWZsaWdodCA/DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBJbiB0aG9z ZSBjaXJjdW1zdGFuY2VzLCBvbmx5IHRoZSBlbmQgYXBwbGljYXRpb25zIHRoZW1zZWx2ZXMgb3Ig YQ0KPj4+Pj4+PiByZWFzb25hYmx5IGJyb2FkLWJydXNoZWQgY2xhc3NpZmljYXRpb24gKHJlYWxs eSB0cmFmZmljIHN0ZWVyaW5nDQo+Pj4+Pj4+IGJhc2VkIG9uIHdoYXQgd2UgY2FuIHNlZSBhdCBp bmdyZXNzKSBpcyBnb2luZyB0byBiZSB1c2VmdWwgLSBpcw0KPj4+Pj4+PiBUSEFUIHdoYXQgd2Un cmUgYWltaW5nIGZvciBoZXJlID8NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IERhdmlkDQo+Pj4+Pj4+IA0K Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBuc2MtYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+PiBC ZWhhbGYgT2YgU3VyZW5kcmEgS3VtYXIgKHNta3VtYXIpDQo+Pj4+Pj4+IFNlbnQ6IDEyIE5vdmVt YmVyIDIwMTMgMDk6MjYNCj4+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IEtldmluIEogTWE7IExpbmRh IER1bmJhcjsgSG9uZ3l1IExpIChKdWxpbykNCj4+Pj4+Pj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5z Y0BpZXRmLm9yZzsgU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1 cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFJvbiwNCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IENsYXNzaWZpY2F0aW9uIG9mIHRyYWZmaWMgaXMgd2VsbCB1bmRlcnN0b29k IGFuZCB3ZSBkbyBub3QgaGF2ZQ0KPj4+Pj4+PnRvICByZWRlZmluZSBpdCAtIGl0J3MgYmVlbiBh cm91bmQgZm9yIGFsbCB0aGUgdGltZSBtaWRkbGUgYm94ZXMNCj4+Pj4+Pj5oYXZlICBiZWVuIG9y IGZvciB0aGF0IG1hdHRlciB0aGUgTDIvTDMgZGV2aWNlcy4gQWxsIHdlIGFyZQ0KPj4+Pj4+PnRh bGtpbmcgIGFib3V0IGlzIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBjbGFzc2lmaWNhdGlvbiB0 bw0KPj4+Pj4+PmJyYW5jaGluZyBpbiBTRkMuDQo+Pj4+Pj4+IA0KPj4+Pj4+PiBZb3UgYXJlIHJp Z2h0LCBpdCBpcyBhbGwgYWJvdXQgcG9saWN5IHdoaWNoIGlzIG91dHNpZGUgdGhlIHNjb3BlDQo+ Pj4+Pj4+IG9mIFNGQy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IFN1cmVuZHJhLg0KPj4+Pj4+PiANCj4+ Pj4+Pj4gT24gMTEvMTIvMTMgNzo1MyBBTSwgIlJvbiBQYXJrZXIiDQo+Pj4+Pj4+IDxSb25fUGFy a2VyQGFmZmlybWVkbmV0d29ya3MuY29tPg0KPj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBJIHRoaW5rIHRoZSBsYWNrIG9mIGRlZmluaXRpb24gb2YgInJlY2xhc3NpZmljYXRpb24i IG1heSBiZQ0KPj4+Pj4+Pj4gY2F1c2luZw0KPj4+Pj4+PiBzb21lDQo+Pj4+Pj4+PiBtaXN1bmRl cnN0YW5kaW5ncyBoZXJlLiAgICBBIGJyYW5jaCB3b3VsZCBvY2N1ciBmb3Igc29tZQ0KPj4+Pj4+ PiBwb2xpY3ktZHJpdmVuDQo+Pj4+Pj4+PiByZWFzb24gYmFzZWQgb24gdGhlIGJlaGF2aW9yIGFu ZCBjb25jbHVzaW9ucyBvZiB0aGUgc2VydmljZQ0KPj4+Pj4+Pj5mdW5jdGlvbiwNCj4+Pj4+Pj4+ IGl0c2VsZi4gICBUaGUgZ3JhcGggd291bGQgcmVwcmVzZW50IHRoZSBmYWN0IHRoYXQgdGhlcmUg aXMgYQ0KPj4+Pj4+Pj5icmFuY2gNCj4+Pj4+Pj4+IHBvaW50LCBidXQgdGhlIHNlcnZpY2UgZnVu Y3Rpb24sIGl0c2VsZiwgYmVpbmcgYXdhcmUgdGhhdCBpdCBpcw0KPj4+Pj4+Pj5hICBicmFuY2hp bmcgcG9pbnQgd291bGQgY29udGFpbiB0aGUgcG9saWN5IGFuZCBsb2dpYyB0byBkZWNpZGUNCj4+ Pj4+Pj4+b24gd2hpY2gNCj4+Pj4+Pj4+IGJyYW5jaCB0byB0YWtlLiAgIFNwZWNpZnlpbmcgdGhh dCBwb2xpY3kgYW5kIGxvZ2ljIGlzIG91dCBvZg0KPj4+Pj4+Pj5zY29wZSwNCj4+Pj4+Pj4gSU1P Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAgUm9uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+IEZyb206IEtldmluIEogTWEg W21haWx0bzprZXZpbi5tYUBhenVraXN5c3RlbXMuY29tXQ0KPj4+Pj4+Pj4gU2VudDogVHVlc2Rh eSwgTm92ZW1iZXIgMTIsIDIwMTMgMTA6NDkgQU0NCj4+Pj4+Pj4+IFRvOiBMaW5kYSBEdW5iYXI7 IFJvbiBQYXJrZXI7IEhvbmd5dSBMaSAoSnVsaW8pDQo+Pj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRl bjsgbnNjQGlldGYub3JnOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7DQo+Pj4+Pj4+PiBTdW1h bmRyYSBNYWplZQ0KPj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQg U0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4gSGkgTGluZGEsDQo+Pj4+Pj4+PiANCj4+ Pj4+Pj4+IEFyZSB5b3Ugc2F5aW5nIHRoYXQgYSBicmFuY2hpbmcgcG9pbnQgaXMgIm5ldmVyIiBh DQo+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0aW9uIHBvaW50LCBvciBhcmUgeW91IHNheWluZyB0aGF0 IGEgYnJhbmNoaW5nIHBvaW50DQo+Pj4+Pj4+ICJkb2VzIG5vdCBoYXZlIHRvIGJlIg0KPj4+Pj4+ Pj4gYSByZWNsYXNzaWZpY2F0aW9uIHBvaW50Pw0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiBJIHRoaW5r IHRoaXMgaXMgYW4gaW1wb3J0YW50IGRpc3RpbmN0aW9uIHRoYXQgbmVlZHMgdG8gYmUNCj4+Pj4+ Pj4gY2xhcmlmaWVkLg0KPj4+Pj4+Pj4gSWYgYnJhbmNoaW5nIGlzIG5ldmVyIHJlY2xhc3NpZmlj YXRpb24sIHRoZW4gdGhlIG1lYW5pbmcgb2YgYQ0KPj4+Pj4+Pj4gY2hhaW4gaXMgZGlmZmVyZW50 IHRoYW4gSSBvcmlnaW5hbGx5IGluZmVycmVkLiAgSWYgdGhlIGNoYWluIGlzDQo+Pj4+Pj4+PiBh IHRyZWUgd2l0aCBvdGhlciAiYnJhbmNoaW5nIiBwb2ludHMgaW4gaXQsIHRoZW4gdGhhdCBsaW1p dHMgdGhlDQo+Pj4+Pj4+PiBzY29wZSBvZiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgZ29hbHMuDQo+ Pj4+Pj4+PiANCj4+Pj4+Pj4+IFdoaWxlIHRoaXMgY291bGQgYmUgYSBkZWdlbmVyYXRlIGNhc2Us IGFuZCBhbnkgaW1wbGVtZW50YXRpb24NCj4+Pj4+Pj4+IGNvdWxkIGRlZmluZSBiYWQgc2Vydmlj ZSBjaGFpbnMsIGlzIGl0IHRoZSBpbnRlbnQgb2YgU0ZDIHRvIG9ubHkNCj4+Pj4+Pj4+IGxvb2sg YXQgdGhlIHNpbXBsZXIgcGFja2V0LWxldmVsIGNsYXNzaWZpY2F0aW9uIGNhc2VzLCBvciBpcyBp dA0KPj4+Pj4+Pj4gdGhlIGludGVudCB0byBjb25zaWRlciB0aGUgY2FzZSB3aGVyZSBhIGJyYW5j aGluZyBwb2ludCBpcw0KPj4+Pj4+Pj4gdmlld2VkIGFzIGEgcmUtY2xhc3NpZmljYXRpb24gcG9p bnQ/DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IHRoYW54Lg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiAtLSAg S2V2aW4gSi4gTWENCj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+Pj4+Pj4+Pj4gRnJvbTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1 YXdlaS5jb21dDQo+Pj4+Pj4+Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTA6 MzQgQU0NCj4+Pj4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgSG9uZ3l1IExpIChKdWxpbyk7IEtldmlu IEogTWENCj4+Pj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdXJlbmRy YSBLdW1hciAoc21rdW1hcik7DQo+Pj4+Pj4+Pj4gU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+PiBT dWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+IFJvbiwNCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBGaXJzdCwgd2FudCB0byBt YWtlIGl0IGNsZWFyIHRoYXQgImJyYW5jaGluZyIgIT0NCj4+Pj4+Pj4+PiByZWNsYXNzaWZpY2F0 aW9uLCBhZ3JlZT8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBTZWNvbmQsIHRoZSByZXByZXNlbnRh dGlvbiBvZiBicmFuY2hpbmcgKG9yIHNlcnZpY2UgZ3JhcGgpIGNhbg0KPj4+Pj4+Pj4+IGJlIGlu IGEgZm9ybSBvZiBsb2dpYyBvbiBhIHNlcnZpY2UgZnVuY3Rpb24uIFNvbWUgc2VydmljZQ0KPj4+ Pj4+Pj4+IGZ1bmN0aW9ucywgZXNwZWNpYWxseSBMNyBiYXNlZCwgY2FuIHVzZSB2YWx1ZSBpbiBh IERhdGFiYXNlIHRvDQo+Pj4+Pj4+Pj4gZGV0ZXJtaW5lIHdoYXQgaXMgdGhlIG5leHQgc2Vydmlj ZSBmdW5jdGlvbi4NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBMaW5kYQ0KPj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9tOiBuc2Mt Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+Pj4+ Pj4+PiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3Zl bWJlciAxMiwgMjAxMyA4OjE2IEFNDQo+Pj4+Pj4+Pj4+IFRvOiBIb25neXUgTGkgKEp1bGlvKTsg S2V2aW4gSiBNYQ0KPj4+Pj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBT dXJlbmRyYSBLdW1hciAoc21rdW1hcik7DQo+Pj4+Pj4+Pj4+IFN1bWFuZHJhIE1hamVlDQo+Pj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBIb25neXUsDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBJ IGFncmVlIGNvbXBsZXRlbHkgdGhhdCByZS1jbGFzc2lmaWNhdGlvbiBpcyBub3QgbGltaXRlZCB0 byBEUEkuDQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBBbmQgYWxzbywgdGhhdCBhbiBhcmVhIGZv ciB1cyB0byBleHBsb3JlIGFzIGEgZ3JvdXAgaXMgaG93IHRvDQo+Pj4+Pj4+Pj4gcmVwcmVzZW50 DQo+Pj4+Pj4+Pj4+IHRoZSBzZXJ2aWNlIGdyYXBoLiAgIERvIHdlIHdhbnQgdG8gcmVwcmVzZW50 IGl0IGFzIGEgcHJvcGVyDQo+Pj4+Pj4+Pj4+Z3JhcGgNCj4+Pj4+Pj4gd2l0aA0KPj4+Pj4+Pj4+ PiBhbiBhZGphY2VuY3kgbGlzdCBvciBvdGhlciByZXByZXNlbnRhdGlvbmFsIG1vZGVsPyAgIE9y LCBkbyB3ZQ0KPj4+Pj4+PiB3YW50DQo+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+IHJlcHJlc2VudCBp dCBhcyBhIHNldCBvZiBsaW5lYXIgc2VnbWVudHMgYW5kIGlmIHNvLCBob3cgYXJlIHRoZQ0KPj4+ Pj4+Pj4+PiBzZWdtZW50cyBjb25uZWN0ZWQgaW50byBhIGdyYXBoPyAgIE90aGVyIGlkZWFzPw0K Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gICBSb24NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0KPj4+ Pj4+Pj4+PiBCZWhhbGYgT2YgSG9uZ3l1IExpIChKdWxpbykNCj4+Pj4+Pj4+Pj4gU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgNjo1NyBBTQ0KPj4+Pj4+Pj4+PiBUbzogUm9uIFBhcmtl cjsgS2V2aW4gSiBNYQ0KPj4+Pj4+Pj4+PiBDYzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3Jn OyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcik7DQo+Pj4+Pj4+Pj4+IFN1bWFuZHJhIE1hamVlDQo+ Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVy DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBCcmFuY2hpbmcvZm9ya2luZyBpcyBhIHZlcnkgaW50 ZXJlc3RpbmcgdG9waWMgb2YgU0ZDLiBBYm91dA0KPj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4g cmUtIGNsYXNzaWZpY2F0aW9uIHBvaW50LCBwcm9iYWJseSB3ZSBzaGFsbCBub3QgbGltaXQgaXQg dG8gRFBJLg0KPj4+Pj4+Pj4+PiBJdCBpcyBhbHNvIHBvc3NpYmxlIHRoYXQgcGFja2V0cyBnbyB0 byBkaWZmZXJlbnQgYnJhbmNoZXMNCj4+Pj4+Pj4+Pj4gYWZ0ZXIgYmVlbiBwcm9jZXNzZWQgYnkg YSBjZXJ0YWluIHNlcnZpY2UgZnVuY3Rpb24sIGRlY2lzaW9uDQo+Pj4+Pj4+Pj4+IG9mIHdoaWNo IGJyYW5jaGVzIHRvIGdvIGlzIG1hZGUgYmFzZWQgb24gdGhlIHJlc3VsdCBvZiBzZXJ2aWNlDQo+ Pj4+Pj4+Pj4+IGZ1bmN0aW9uJ3MgcHJvY2VzcywgaS5lLiBub3QganVzdCByZS0gY2xhc3NpZmlj YXRpb24gYnkgRFBJLg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gSG9uZ3l1DQo+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+PiBGcm9t OiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbg0K Pj4+Pj4+Pj4+PiBCZWhhbGYgT2YgUm9uIFBhcmtlcg0KPj4+Pj4+Pj4+PiBTZW50OiBUdWVzZGF5 LCBOb3ZlbWJlciAxMiwgMjAxMyA3OjQ1IFBNDQo+Pj4+Pj4+Pj4+IFRvOiBLZXZpbiBKIE1hDQo+ Pj4+Pj4+Pj4+IENjOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmc7IFN1cmVuZHJhIEt1bWFy IChzbWt1bWFyKTsNCj4+Pj4+Pj4+Pj4gU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+Pj4gU3ViamVj dDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+IEhpLCBLZXZpbg0KPj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4gWW91IGFzayBhIGdy ZWF0IHF1ZXN0aW9uIGFib3V0IGJyYW5jaGluZyB0aGUgZ3JhcGguICBUaGUNCj4+Pj4+Pj4+Pj4g ZGV0YWlscyBhcm91bmQgaG93IHRvIGNvbnZleSB0aGUgc2VsZWN0aW9uIG9mIHRoZQ0KPj4+Pj4+ Pj4+PiBzdWJ0cmVlL3N1YmdyYXBoIGFyZSBzdGlsbA0KPj4+Pj4+Pj4+IHRvIGJlDQo+Pj4+Pj4+ Pj4+IGRlZmluZWQuICAgSXMgaXQgb25lIGNoYWluIGlkIGZvciB0aGUgd2hvbGUgZ3JhcGg/ICAg RG9lcyBlYWNoDQo+Pj4+Pj4+IGJyYW5jaA0KPj4+Pj4+Pj4+PiBoYXZlIGl0cyBvd24gY2hhaW4g aWQ/ICAgU29tZSBjb21iaW5hdGlvbj8NCj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+ICAgUm9uDQo+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+PiBPbiBOb3YgMTIsIDIwMTMsIGF0IDE6NTIgQU0sICJLZXZp biBKIE1hIg0KPj4+Pj4+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4NCj4+Pj4+Pj4+ Pj4gd3JvdGU6DQo+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+IFllcywgcmVjbGFzc2lmaWNhdGlv biBjYW4gY2hhbmdlIHRoZSBzZXJ2aWNlIHBhdGggYW5kDQo+Pj4+Pj4+Pj4+Pj4gcmUtY2xhc3Np ZmljYXRpb24gbWF5IGhhcHBlbiBhdCBhbnkgbm9kZSBhbG9uZyBhIHNlcnZpY2UgcGF0aC4NCj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gSnVzdCB0byBleHBhbmQgb24gdGhhdCwgZ29pbmcgYmFj ayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24NCj4+Pj4+Pj4+Pj4+IGFib3V0IHNlcnZpY2UgaGVh ZGVyIGVuY2Fwc3VsYXRpb24sIGlzIGl0IGludGVuZGVkIHRoYXQgYQ0KPj4+Pj4+Pj4+Pj4gY2hh aW4gdGhhdCBpcyByZS1jbGFzc2lmaWVkIHdpbGwgZ2V0IGEgbmV3IGNoYWluIElEIHdoaWNoDQo+ Pj4+Pj4+Pj4+PiBmdWxseSBkZXNjcmliZXMgYSBjaGFpbiB0aGF0IGlzIGEgc3VwZXJzZXQgb2Yg dGhlIG9yaWdpbmFsDQo+Pj4+Pj4+Pj4+PiBjaGFpbiBJRCwgcHJpb3IgdG8gRFBJLWJhc2VkIHJl LWNsYXNzaWZpY2F0aW9uPyAgKGFzc3VtaW5nDQo+Pj4+Pj4+Pj4+PiB0aGUgZ29hbCBpcyAiYSBz aW5nbGUgY2hhaW4gSUQgdGhhdCBpcyBjb21tb25seSB1bmRlcnN0b29kDQo+Pj4+Pj4+Pj4+PiBh bG9uZyB0aGUgZW50aXJlIHNlcnZpY2UNCj4+Pj4+Pj4gY2hhaW4iDQo+Pj4+Pj4+Pj4+PiBodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbnNjL2N1cnJlbnQvbXNnMDA2MzguaHQN Cj4+Pj4+Pj4+Pj4+IG0NCj4+Pj4+Pj4+Pj4+IGwNCj4+Pj4+Pj4+Pj4+ICkNCj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4gQW5kIHRoZSBhcHBsaWNhYmxlIHN1YnNldCBvZiB0aGUgcGVybXV0YXRp dmUgbGlzdCBvZiBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+PiBwYXRocyB3b3VsZCBiZSBjb25maWd1cmVk IGF0IGVhY2ggYXBwcm9wcmlhdGUgc2VydmljZSBub2RlPw0KPj4+Pj4+Pj4+Pj4gZS5nLiwgSUQg MTogTkFUICsgZmlyZXdhbGwgKyBEUEkNCj4+Pj4+Pj4+Pj4+ICAgICBJRCAyOiBOQVQgKyBmaXJl d2FsbCArIERQSSArIEFWDQo+Pj4+Pj4+Pj4+PiAgICAgSUQgMzogTkFUICsgZmlyZXdhbGwgKyBE UEkgKyBBViArIE5BVA0KPj4+Pj4+Pj4+Pj4gICAgIElEIDQ6IE5BVCArIGZpcmV3YWxsICsgRFBJ ICsgTkFUDQo+Pj4+Pj4+Pj4+PiAgICAgSUQgNTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBViAr IExCDQo+Pj4+Pj4+Pj4+PiAgICAgSUQgNjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBMQg0KPj4+ Pj4+Pj4+Pj4gICAgIElEIDc6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgTEIgKyBDQUNIRQ0KPj4+ Pj4+Pj4+Pj4gICAgIElEIDg6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQ0FDSEUNCj4+Pj4+Pj4+ Pj4+ICAgICBJRCA5OiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGltaXplciArIExCDQo+Pj4+ Pj4+Pj4+PiAgICAgSUQgMTA6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgb3B0aW1pemVyICsgTEIg KyBDQUNIRQ0KPj4+Pj4+Pj4+Pj4gICAgIElEIDExOiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9w dGltaXplciArIENBQ0hFIFdvdWxkDQo+Pj4+Pj4+Pj4+PiBldmVyeSBmbG93IHRoZW4gYmUgaW5p dGlhbGx5IGNsYXNzaWZpZWQgYXMgSUQgMSwgYnV0DQo+Pj4+Pj4+Pj4+PiBldmVudHVhbGx5IGdl dCByZS0NCj4+Pj4+Pj4+Pj4gY2xhc3NpZmllZA0KPj4+Pj4+Pj4+Pj4gdG8gSUQgMi0xMSwgYWZ0 ZXIgdGhlIERQSSBwaGFzZT8NCj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4gdGhhbnguDQo+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0KPj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+PiBGcm9tOiBT dXJlbmRyYSBLdW1hciAoc21rdW1hcikgW21haWx0bzpzbWt1bWFyQGNpc2NvLmNvbV0NCj4+Pj4+ Pj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+Pj4+Pj4+ Pj4+Pj4gVG86IEtldmluIEogTWE7IFJvbiBQYXJrZXI7IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMg TmFydGVuOw0KPj4+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6 IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IE9uIDExLzExLzEzIDk6 NDYgUE0sICJLZXZpbiBKIE1hIg0KPj4+Pj4+Pj4+Pj4+PiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1z LmNvbT4NCj4+Pj4+Pj4+PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IEhp IFN1cmVuZHJhLA0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4gQ2xhc3NpZmljYXRpb24g bWF5IGJlIG91dCBvZiBzY29wZSwgYnV0IHRoZSBsZXZlbCBvZg0KPj4+Pj4+Pj4+Pj4+PiBzZXJ2 aWNlIHRoYXQNCj4+Pj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+Pj4+Pj4gYXBwbGljYWJsZSBpcyBkZXBl bmRlbnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24NCj4+Pj4+Pj4+Pj4+Pj4gdGhh dCBjYW4NCj4+Pj4+Pj4+Pj4gYmUNCj4+Pj4+Pj4+Pj4+Pj4gcGVyZm9ybWVkLiAgQW4gYXNzdW1w dGlvbiBvZiBwYWNrZXQgbGV2ZWwgZW5jYXBzdWxhdGlvbiBoYXMNCj4+Pj4+Pj4+Pj4+PiBpbXBs aWNhdGlvbnMNCj4+Pj4+Pj4+Pj4+Pj4gb24gdGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIGJl aW5nIHBlcmZvcm1lZD8gIElmIHRoZQ0KPj4+Pj4+Pj4+Pj4+PiBzdGF0ZWQNCj4+Pj4+Pj4+Pj4g Z29hbHMNCj4+Pj4+Pj4+Pj4+PiBhcmUNCj4+Pj4+Pj4+Pj4+Pj4gZm9yIGZpcmV3YWxsIGFuZCBs b2FkIGJhbGFuY2VyIGZ1bmN0aW9uYWxpdHksIHRoZW4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+IGFwcGxp Y2F0aW9uDQo+Pj4+Pj4+Pj4+Pj4gbGV2ZWwNCj4+Pj4+Pj4+Pj4+Pj4gbmF0dXJlIG9mIHRob3Nl IGZ1bmN0aW9ucyBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/DQo+Pj4+Pj4+Pj4+Pj4+ IElmLCBvbiB0aGUgb3RoZXIgaGFuZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gc2NvcGUgaXMNCj4+ Pj4+Pj4+Pj4+Pj4gbGltaXRlZCBkdWUgdG8gbGltaXRhdGlvbnMgaW4gY2xhc3NpZmljYXRpb24s IHRoYXQgd291bGQgYmUNCj4+Pj4+Pj4+Pj4+Pj4gYW5kIGltcG9ydGFudCBwaWVjZSBvZg0KPj4+ Pj4+Pj4+PiBpbmZvcm1hdGlvbj8NCj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IFdydCBz ZWN0aW9uIDQuNCBvZiBkcmFmdC1saXUtc2VydmljZS1jaGFpbmluZy11c2UtY2FzZXMNCj4+Pj4+ Pj4+Pj4+Pj4gdGhlIGZvcmsgcG9pbnRzIG9mIHRoZSBzZXJ2aWNlIHBhdGhzIHNlZW0gbGlrZQ0K Pj4+Pj4+Pj4+Pj4+PiByZS1jbGFzc2lmaWNhdGlvbg0KPj4+Pj4+PiBwb2ludHM/DQo+Pj4+Pj4+ Pj4+Pj4+IElzIHRoYXQgdGhlIGludGVycHJldGF0aW9uIGZyb20gdGhlIGFyY2hpdGVjdHVyZSBw ZXJzcGVjdGl2ZT8NCj4+Pj4+Pj4+Pj4+Pj4gT3IgaXMgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4gY2xhc3NpZmljYXRpb24gZXhjbHVzaXZlDQo+Pj4+Pj4+Pj4+Pj4+IG9mIERQSQ0KPj4+Pj4+ Pj4+PiBmdW5jdGlvbmFsaXR5Pw0KPj4+Pj4+Pj4+Pj4+IDxTSz4gSSBoYXZlIG5vdCBmdWxseSBy ZWFkIHRoYXQgZHJhZnQgeWV0LiBCdXQgaW4gZ2VuZXJhbCwNCj4+Pj4+Pj4+Pj4+PiBhcyBkZXNj cmliZWQgaW4gdGhlIGFyY2ggZHJhZnQsIHRoZSBjb2xsZWN0aW9uIG9mIHNlcnZpY2VzDQo+Pj4+ Pj4+Pj4+Pj4gZm9ybSBhIGdyYXBoLCBzZWdtZW50cyBvZiB3aGljaCBhcmUgc2VydmljZSBwYXRo cy4gWWVzLA0KPj4+Pj4+Pj4+Pj4+IHJlY2xhc3NpZmljYXRpb24gY2FuDQo+Pj4+Pj4+Pj4+IGNo YW5nZQ0KPj4+Pj4+Pj4+Pj4+IHRoZSBzZXJ2aWNlIHBhdGggYW5kIHJlLWNsYXNzaWZpY2F0aW9u IG1heSBoYXBwZW4gYXQgYW55DQo+Pj4+Pj4+Pj4+Pj4gbm9kZSBhbG9uZw0KPj4+Pj4+Pj4+PiBh IHNlcnZpY2UgcGF0aC4NCj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+PiBTdXJlbmRyYS4NCj4+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+IHRoYW54Lg0KPj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+IEZyb206IFN1cmVuZHJh IEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPj4+Pj4+Pj4+Pj4+ Pj4gU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTI6MDggQU0NCj4+Pj4+Pj4+Pj4+ Pj4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5h cnRlbjsNCj4+Pj4+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4gU3ViamVj dDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+Pj4gS2V2aW4sDQo+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+ IENsYXNzaWZpY2F0aW9uIG1lY2hhbmlzbSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiBTRkMuIEl0 DQo+Pj4+Pj4+Pj4+Pj4+PiBjYW4gYmUgYmFzZWQNCj4+Pj4+Pj4+Pj4+PiBvbg0KPj4+Pj4+Pj4+ Pj4+Pj4gdGhlIHBhY2tldCBvciBpbmZvcm1hdGlvbiBub3QgaW4gdGhlIHBhY2tldChlbnZpcm9u bWVudGFsDQo+Pj4+Pj4+Pj4+Pj4+PiBhdHRyaWJ1dGVzDQo+Pj4+Pj4+Pj4+Pj4gZm9yDQo+Pj4+ Pj4+Pj4+Pj4+PiBpbnN0YW5jZSkgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlzIGlt cG9ydGFudCBpcw0KPj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBzdWNoIGNsYXNzaWZpY2F0aW9uIGFpZHMg aW4gdHJhZmZpYyBzZWxlY3Rpb24gYW5kDQo+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIHBhdGggaWRl bnRpZmljYXRpb24uDQo+Pj4+Pj4+Pj4+Pj4+PiBJdCBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHBv bGljeSBpbiB0aGlzIHJlZ2FyZCBleGNlcHQNCj4+Pj4+Pj4+Pj4+Pj4+IHRoYXQgdGhlIHBvbGlj eSBub3cgc3BlY2lmaWVzIHRoZSBzZXJ2aWNlIHBhdGguDQo+Pj4+Pj4+Pj4+Pj4+PiBGdXJ0aGVy LCBjbGFzc2lmaWNhdGlvbiBpcyBub3QgbGltaXRlZCB0byB0aGUgbmV0d29yaw0KPj4+Pj4+Pj4+ Pj4+Pj4gZWxlbWVudHMgYnV0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBhcyB3ZWxsLiBTb21lIG9m IHRoaXMNCj4+Pj4+Pj4+Pj4+Pj4+IGlzIGRlc2NyaWJlZCBpbiB0aGUNCj4+Pj4+Pj4+Pj4+PiBh cmNoaXRlY3R1cmUNCj4+Pj4+Pj4+Pj4+Pj4+IGRyYWZ0cyBhcyB3ZWxsIC0NCj4+Pj4+Pj4+Pj4+ Pj4+ICJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1xdWlubi1zZmMtYXJj aC8iLg0KPj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+PiBTdXJlbmRyYS4NCj4+Pj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IE9uIDExLzExLzEzIDc6MzMgUE0sICJLZXZpbiBKIE1h Ig0KPj4+Pj4+Pj4+Pj4+Pj4+IDxrZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0KPj4+Pj4+Pj4+ PiB3cm90ZToNCj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+PiBIaSBSb24sDQo+Pj4+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4gSSB3YXMgdW5hYmxlIHRvIG1ha2UgdGhlIFNG QyBCb0YgZHVlIHRvIGEgY29uZmxpY3Qgd2l0aA0KPj4+Pj4+Pj4+Pj4+Pj4+IENETkksIGJ1dCBJ IGhhZCBhIHNpbWlsYXIgcXVlc3Rpb24gd3J0IGJ1bGxldCAxMSBpbg0KPj4+Pj4+Pj4+Pj4+Pj4+ IHNlY3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4+PiAyIG9mIHRoZQ0KPj4+Pj4+Pj4+PiBwcm9ibGVtDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gc3RhdGVtZW50Og0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4+ICAxMS4gIFBlci1TZXJ2aWNlIChyZSlDbGFzc2lmaWNhdGlvbjogQ2xhc3NpZmljYXRpb24N Cj4+Pj4+Pj4+Pj4+Pj4+PiBvY2N1cnMgYXQNCj4+Pj4+Pj4+Pj4gZWFjaA0KPj4+Pj4+Pj4+Pj4+ Pj4+ICAgICAgIHNlcnZpY2UsIGluZGVwZW5kZW50IGZyb20gcHJldmlvdXNseSBhcHBsaWVkDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmljZQ0KPj4+Pj4+Pj4+Pj4+Pj4gZnVuY3Rpb25zLg0KPj4+Pj4+ Pj4+Pj4+Pj4+ICAgICAgIFRoZXNlIHVucmVsYXRlZCBjbGFzc2lmaWNhdGlvbiBldmVudHMgY29u c3VtZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IHJlc291cmNlcw0KPj4+Pj4+Pj4+PiBwZXINCj4+Pj4+Pj4+ Pj4+Pj4+PiAgICAgICBzZXJ2aWNlLiAgTW9yZSBpbXBvcnRhbnRseSwgdGhlIGNsYXNzaWZpY2F0 aW9uDQo+Pj4+Pj4+Pj4+IGZ1bmN0aW9uYWxpdHkNCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBvZnRl biBkaWZmZXJzIHBlciBzZXJ2aWNlIGZ1bmN0aW9uIGFuZCBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4+ Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+Pj4+PiBjYW5ub3QNCj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICBs ZXZlcmFnZSB0aGUgcmVzdWx0cyBmcm9tIG90aGVyIGRlcGxveWVkIG5ldHdvcmsgb3INCj4+Pj4+ Pj4+Pj4gc2VydmljZS4NCj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+PiBhcyBpdCBy ZWxhdGVzIHRvIHNlY3Rpb24gNS4yIG9mIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQ6DQo+Pj4+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4gIFRoZSBTRkMgQ2xhc3NpZmllciBjbGFzc2lmaWVz IHBhY2tldHMgYmFzZWQgb24gKHNvbWUNCj4+Pj4+Pj4+Pj4+Pj4+PiBvZikgdGhlDQo+Pj4+Pj4+ Pj4+Pj4+PiBjb250ZW50cw0KPj4+Pj4+Pj4+Pj4+Pj4+ICBvZiB0aGUgcGFja2V0IGhlYWRlci4g IENvbmNyZXRlbHksIGl0IGNsYXNzaWZpZXMgcGFja2V0cw0KPj4+Pj4+Pj4+Pj4+Pj4+IGJhc2Vk IG9uDQo+Pj4+Pj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+PiAgcG9zc2libGUgY29tYmlu YXRpb24gb2Ygb25lIG9yIG1vcmUgaGVhZGVyIGZpZWxkcywgc3VjaA0KPj4+Pj4+Pj4+Pj4+Pj4+ IGFzDQo+Pj4+Pj4+Pj4+IHNvdXJjZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ICBhZGRyZXNzLCBkZXN0aW5h dGlvbiBhZGRyZXNzLCBEUyBmaWVsZCwgcHJvdG9jb2wgSUQsDQo+Pj4+Pj4+Pj4+Pj4+Pj4gc291 cmNlDQo+Pj4+Pj4+Pj4+IHBvcnQNCj4+Pj4+Pj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+ ICBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMsIGFuZCBhbnkgb3RoZXIgaW5mb3JtYXRpb24uDQo+ Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4gQSBwYWNrZXQtYmFzZWQgY2xhc3NpZmll ciBhcyBkZXNjcmliZWQgaW4gdGhlIGZyYW1ld29yaw0KPj4+Pj4+Pj4+Pj4+Pj4+IGRvY3VtZW50 DQo+Pj4+Pj4+Pj4+Pj4+PiB3b3VsZA0KPj4+Pj4+Pj4+Pj4+Pj4+IHNlZW0gdG8gYmUgbGltaXRl ZCBpbiB3aGF0IGl0IGNhbiBjbGFzc2lmeT8gIFRoZSBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4+Pj4g ZnVuY3Rpb24gaWRlbnRpZmllciBsb29rdXAgZG9lcyBub3Qgc2VlbSB0byBiZSBhDQo+Pj4+Pj4+ Pj4+Pj4+Pj4gc2lnbmlmaWNhbnQgb3B0aW1pemF0aW9uDQo+Pj4+Pj4+Pj4+Pj4gb3Zlcg0KPj4+ Pj4+Pj4+Pj4+Pj4+IGEgcGFja2V0LWJhc2VkIDUtdHVwbGUgbG9va3VwPyAgVGhlcmUgc2VlbXMg dG8gYmUgc29tZQ0KPj4+Pj4+Pj4+Pj4+Pj4+IG1pc3NpbmcNCj4+Pj4+Pj4+Pj4+PiBkZXRhaWwN Cj4+Pj4+Pj4+Pj4+Pj4+PiB3cnQgaG93IGNsYXNzaWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIGRl dGVybWluZWQgYW5kDQo+Pj4+Pj4+IHJldXNlZD8NCj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+ Pj4+Pj4+PiBXaGVuIHRoaW5raW5nIGFib3V0IGhpZ2hlciBsZXZlbCBzZXJ2aWNlcywgZS5nLiwg SFRUUCBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+PiBUTFMNCj4+Pj4+Pj4+Pj4+Pj4+IGVuY3J5cHRlZA0K Pj4+Pj4+Pj4+Pj4+Pj4+IGZsb3dzLCBhIHBhY2tldC1iYXNlZCBjbGFzc2lmaWVyIHNlZW1zIGlu YWRlcXVhdGU/ICBJIHdhcw0KPj4+Pj4+Pj4+Pj4+Pj4+IGFsc28NCj4+Pj4+Pj4+Pj4+Pj4+IHdv bmRlcmluZw0KPj4+Pj4+Pj4+Pj4+Pj4+IGhvdyBpbmRlcGVuZGVudCBITFMgc2VnbWVudCByZXF1 ZXN0cyBtaWdodCBiZSBjbGFzc2lmaWVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4+ Pj4+PiBhc3NvY2lhdGVkPw0KPj4+Pj4+Pj4+Pj4+Pj4+IFdlcmUgdGhlc2UgdHlwZXMgb2YgdXNl IGNhc2VzIGRpc2N1c3NlZCBpbiB0aGUgQm9GPw0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+Pj4+IHRoYW54Lg0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+IC0tICBLZXZp biBKLiBNYQ0KPj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBPbiBCZWhh bGYNCj4+Pj4+Pj4+Pj4+PiBPZg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBSb24NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gUGFya2VyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIw MTMgMTA6MTYgUE0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMg TmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2Nd IEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+IFN1bWFuZHJhLA0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4g QXMgd2FzIGRpc2N1c3NlZCBpbiBWYW5jb3V2ZXIsIHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZXhpc3Rpbmcgd2F5cw0KPj4+Pj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gYWNjb21wbGlzaCBzZXJ2aWNlIGNoYWluaW5nLiAgICAgQnV0IG5vbmUgb2YgdGhl bSBwcm92aWRlDQo+Pj4+Pj4+IGENCj4+Pj4+Pj4+Pj4+Pj4+IHN1ZmZpY2llbnQNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gY29tYmluYXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSwgZmxleGliaWxpdHksIGFu ZA0KPj4+Pj4+PiByZXNpbGllbmN5Lg0KPj4+Pj4+Pj4+PiBBDQo+Pj4+Pj4+Pj4+Pj4+PiBzaW5n bGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdpbGwgZ28g YSBsb25nIHdheSB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBlbnN1cmluZyB0aGVzZQ0KPj4+Pj4+Pj4+ Pj4+Pj4gZ29hbHMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEl0ICBtYXkgbm90IGJlIHRoZSBhYnNvbHV0 ZWx5IG1vc3QgZWZmaWNpZW50IGFwcHJvYWNoDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZvciBldmVyeQ0K Pj4+Pj4+Pj4+Pj4+Pj4gc2luZ2xlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG5ldHdvcmsgdG9wb2xvZ3kg YW5kIGV2ZXJ5IHNpbmdsZSB1c2UgY2FzZSwgYnV0IGl0cw0KPj4+Pj4+Pj4+Pj4+Pj4+PiB1Ymlx dWl0b3VzDQo+Pj4+Pj4+Pj4+Pj4gbmF0dXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHNob3VsZCBpbXBy b3ZlIGl0cyBhZG9wdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICBS b24NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBTdW1h bmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29tXQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50 OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjEwIFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFRv OiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFJvbiwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFuIGV4YW1wbGUgb2Ygb25lIHR5 cGUgb2YgZGVyaXZhdGlvbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSG93ZXZlcg0KPj4+Pj4+Pj4+Pj4+ Pj4gdGhpcw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQgd2l0aCBjbGFzc2lm aWNhdGlvbiByZXN1bHQsIGFnYWluIG9uZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+ Pj4+Pj4+PiBleGFtcGxlLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBB bGwgZmxvd3MgZnJvbSB0aGUgc2FtZSBzb3VyY2UgSVAgZG8gbm90IG5lY2Vzc2FyaWx5DQo+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZm9sbG93DQo+Pj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4+Pj4gc2Ft ZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBjaGFpbi4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gQ29ycmVjdC4gSXQg aXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQgYWxsIHRyYW5zYWN0aW9uDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+IG9mIHRoZSBzYW1lDQo+Pj4+Pj4+Pj4+Pj4+PiBmbG93DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZv bGxvdyB0aGUgc2FtZSBjaGFpbiBlaXRoZXIuIFNvIHdoeSBzdG9wIGF0IGZsb3cgaXRzZWxmLg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gQWdhaW4gdGhlIHBvaW50IGhlcmUg aXMgdGhhdCBkbyB3ZSBhbHdheXMgbmVlZCBTRkMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaGVhZGVyIG9y DQo+Pj4+Pj4+Pj4gTm90Lg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gU3Vt YW5kcmENCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+ Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBS b24gUGFya2VyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Um9uX1BhcmtlckBhZmZpcm1lZG5l dHdvcmtzLmNvbV0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwg MjAxMyA3OjAyIFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFz IE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNj XSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IFRoZSBpbnRlbnRpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBhbGxvdw0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBmb3Igb3BlcmF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+PiBhdA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiB0aGUgZnVsbHkgcXVhbGlmaWVkIGZsb3cgbGV2ZWwsIG9yIGV2ZW4gZmluZXIg Z3JhaW5lZCBhdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+IHRyYW5zYWN0 aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGxldmVsICh0aGlzIGlzIGFuIGltcGxlbWVudGF0aW9uIG1h dHRlciBmb3IgdGhlIFBEUCkuDQo+Pj4+Pj4+IEFsbA0KPj4+Pj4+Pj4+PiBmbG93cw0KPj4+Pj4+ Pj4+Pj4+Pj4gZnJvbQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgc2FtZSBzb3VyY2UgSVAgZG8gbm90 IG5lY2Vzc2FyaWx5IGZvbGxvdyB0aGUgc2FtZQ0KPj4+Pj4+PiBjaGFpbi4NCj4+Pj4+Pj4+Pj4+ PiBTb3VyY2UNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSVAsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZXJlZm9y ZSwgIGRvZXMgbm90IGlkZW50aWZ5IHRoZSBjaGFpbiBJRC4gICAgQW5vdGhlcg0KPj4+Pj4+Pj4+ IGludGVudGlvbg0KPj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29yaw0KPj4+Pj4+Pj4+PiB0 b3BvbG9neQ0KPj4+Pj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBub3QNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gYmUgbGltaXRlZCB0byBhIHNpbmdsZSBMQU4uICAgVGh1cywgd2hpbGUgVkxBTiBt YXkgYmUgcGFydA0KPj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4g dHJhbnNwb3J0LCBpdCBkb2VzIG5vdCBhZGVxdWF0ZWx5IGlkZW50aWZ5IHRoZSBzZXJ2aWNlDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IGNoYWluLA0KPj4+Pj4+Pj4+Pj4+IGVpdGhlci4NCj4+Pj4+Pj4+Pj4+ Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICBSb24NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUu Y29tXQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDk6 NTYgUE0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0ZW47IG5z Y0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQ cm9wb3NlZCBTRkMgY2hhcnRlcg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4g Um9uLA0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gVGhlIHNlcnZpY2UgaGVh ZGVyIGlzIG1lYW50IHRvIGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IGNhbg0KPj4+Pj4+Pj4+PiAqYWxzbyoNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYmUgZGVyaXZlZCAoZm9y IGV4YW1wbGUgdXNlIHNvdXJjZSBpcCBhbmQgdmxhbiB0bw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBpZGVu dGlmeSBjaGFpbklEIGFuZA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBwb3NpdGlvbikgb3IgZW5jYXBzdWxh dGVkIGFzIHBhcnQgb2YgYW5vdGhlciB0dW5uZWwNCj4+Pj4+Pj4gaGVhZGVyLg0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBTbyB0aGlzIGNvdWxkIGJlIG9wdGlvbmFsIElNSE8uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBGcm9tOiBSb24gUGFya2VyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86Um9uX1Bh cmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5 LCBOb3ZlbWJlciAxMSwgMjAxMyA0OjM2IFBNDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFRvOiBTdW1hbmRy YSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFN1 YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTdW1hbmRyYSwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IEFzIEkgdW5kZXJzdGFuZCBpdCwgYW4gU0ZDIHBhY2tldCB0cmF2ZXJz aW5nIGZyb20gUERQDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvIFNGIG9yIGZyb20NCj4+Pj4+Pj4+Pj4+ Pj4+IFNGDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFNGIHdpbGwgbG9v ayBsaWtlOg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gfCAgICAgICAgInRyYW5zcG9ydCIgICAg ICAgICB8DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IHwgICAgICBzZXJ2aWNlIGhlYWRlciAgICB8DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHwgICBvcmlnaW5h bCBJUCBoZWFkZXIgIHwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSsNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfCAgb3JpZ2luYWwgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHwgSVAgcGF5bG9hZA0KPj4+Pj4+ Pj4+PiB8DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFdoZXJlIHNlcnZpY2UgaGVhZGVy IGNvbnRhaW5zLCBhdCBhIG1pbmltdW0sIGVub3VnaCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaW5mb3Jt YXRpb24gdG8NCj4+Pj4+Pj4+Pj4+Pj4+IGFsbG93DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBwYWNr ZXQgdG8gYmUgcHJvcGFnYXRlZCBhbG9uZyB0aGUgZnVsbCBsZW5ndGggb2YgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IHRoZSBjaGFpbiwgYW5kIG9wdGlvbmFsbHksIG90aGVyIG1ldGFkYXRhIHRoYXQgZW5o YW5jZXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBvcGVyYXRpb24gb2YNCj4+Pj4+Pj4+Pj4gb25l DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG9yDQo+Pj4+Pj4+Pj4+Pj4gbW9yZQ0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBzZXJ2aWNlIGZ1bmN0aW9ucy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IEFuZCB3aGVyZSAidHJhbnNwb3J0IiBjb3VsZCBjb25jZWl2YWJseSBiZSBhbnkgb2YsIGJ1dCAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gbm90IGxpbWl0ZWQNCj4+Pj4+Pj4+Pj4+Pj4+IHRvOg0KPj4+Pj4+ Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gKiBFdGhlcm5ldA0KPj4+Pj4+Pj4+Pj4+Pj4+ PiAqIEV0aGVybmV0ICsgTExDMg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgTVBMUw0K Pj4+Pj4+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgKyBHUkUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4g KiBFdGhlcm5ldCArIElQICtVRFANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBBbHNvLCAib3JpZ2luYWwiIGluIHRoZSBkaWFncmFtIGFib3Zl IGlzIG5vdCBtZWFudCB0byANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaW1wbHkgaW1tdXRhYmlsaXR5LCBi dXQgcmF0aGVyIHRvIHNwZWNpZnkgdGhlIHBhY2tldCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhhdCBp cw0KPj4+Pj4+Pj4+PiBwcm9wYWdhdGVkDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZyb20gcHJlY2VkaW5n IGVudGl0eSB0byBzdWNjZWVkaW5nIGVudGl0eSwgcHJpb3IgdG8gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IGVuY2Fwc3VsYXRpb24uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgUm9u DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gRnJvbTogbnNjLWJv dW5jZXNAaWV0Zi5vcmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFttYWlsdG86bnNjLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZg0KPj4+Pj4+Pj4+Pj4+IE9mDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFN1bWFu ZHJhIE1hamVlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIw MTMgNjo0NiBQTQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBUbzogVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYu b3JnDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBHZW5lcmlj IFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSANCj4+Pj4+Pj4+Pj4+ Pj4+Pj4gZG9jdW1lbnQNCj4+Pj4+Pj4+PiB3aWxsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgZGVzY3Jp YmUgdGhlIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IGVuY2Fwc3VsYXRpb24NCj4+Pj4+Pj4+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZm9y DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgY29udmV5aW5nIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWlu IGFuZCB0aGUgc2VydmljZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+Pj4+ Pj4+IHBhdGgsDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgYW5kIGZvciBjb21tdW5pY2F0aW5nIGNvbnRl eHQgaW5mb3JtYXRpb24gYmV0d2VlbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbm9kZXMNCj4+Pj4+Pj4g dGhhdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGltcGxlbWVudCBzZXJ2aWNlIGZ1bmN0aW9ucy4gSXQg aXMgaW50ZW5kZWQgdGhhdCB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICBiZSBhZ25vc3RpYyB0byB0aGUgbGF5ZXIgYXQgd2hpY2ggaXQgaXMgYXBw bGllZCBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZSBzZXJ2aWNlDQo+Pj4+Pj4+Pj4+Pj4+PiB0 aGF0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGlzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgYmVpbmcgY29uc3Ry dWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IG1heSBiZQ0KPj4+Pj4+Pj4+PiB1c2VkDQo+Pj4+Pj4+Pj4+Pj4gb24NCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gICBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0d29yayANCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gbGF5ZXIgb3IgYXQgYW55IG90aGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAg bGF5ZXIsIGFuZCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4+ Pj4+Pj4+Pj4+IGNvbnN0cnVjdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbA0KPj4+ Pj4+PiBzZXJ2aWNlLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gW1NNXSBX aGF0IGRvZXMgaXQgbWVhbiBieSBhIHNpbmdsZSBzZXJ2aWNlLWxldmVsIA0KPj4+Pj4+Pj4+Pj4+ Pj4+PiBlbmNhcHN1bGF0aW9uLA0KPj4+Pj4+Pj4+PiBhDQo+Pj4+Pj4+Pj4+Pj4+PiBuZXcNCj4+ Pj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gICAg ICAgICAgIG9yIGFuIGFiaWxpdHkgdG8gc2VsZWN0IG9uZSBlbmNhcHN1bGF0aW9uIA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiBmb3JtYXQgdGhhdA0KPj4+Pj4+Pj4+Pj4+Pj4gZml0cw0KPj4+Pj4+Pj4+Pj4+ Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbmVlZCBmb3IgYSBnaXZlbiBzZXJ2aWNlIGNoYWlu Pw0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgICAgICAgICBUaGUgYWJpbGl0eSB0byBzZWxlY3QgYSBzcGVj aWZpYyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiB3b3VsZCBiZQ0KPj4+Pj4+Pj4+ Pj4+IGENCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWFuYWdlbWVudCBwbGFuZSBkZWNpc2lvbi4NCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgICBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgZXhpc3RpbmcgZW5jYXBz dWxhdGlvbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbWV0aG9kcyB0aGF0DQo+Pj4+Pj4+Pj4+Pj4+PiBj YW4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcG9zc2libHkgYmUgcmV1c2VkIHRvIHByb3ZpZGUNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgICBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gICBzZXJ2aWNl IG5vZGVzLiBJDQo+Pj4+Pj4+IGhhdmUNCj4+Pj4+Pj4+Pj4gc2Vlbg0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBtZW50aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG9mIEdSRSwgZm9yIEhUVFAgYmFzZWQNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICAgICAgICBhcHBsaWNhdGlvbnMgY29udGV4dHMgYXJlIHRyYW5zZmVycmVk IHZpYQ0KPj4+Pj4+PiBoZWFkZXJzLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBb bWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4+Pj4+Pj4+Pj4+PiBPZg0K Pj4+Pj4+Pj4+Pj4+Pj4+PiBUaG9tYXMgTmFydGVuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IFNlbnQ6IFdl ZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMTE6MDcgQU0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gVG86 IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBbbnNjXSBDdXJyZW50IFBy b3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBI aS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEN1cnJlbnQgY2hhcnRlciBj YW4gYmUgZm91bmQgYXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvY2hhcnRlci0NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaWV0Zi1zZmMvLg0KPj4+Pj4+Pj4+ Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gSXQgY29udGFpbnMgdGhlIHJldmlzZWQgbWFuYWdl bWVudCB0ZXh0IGFzIHdlbGwgYXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHVwZGF0ZWQNCj4+Pj4+Pj4+ Pj4+Pj4+IG1pbGVzdG9uZXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBB bGwga25vd24gaXNzdWVzIGhhdmUgYmVlbiBhZGRyZXNzZWQuIElmIHRoZXJlIGFyZSBhbnkgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IHJlbWFpbmluZw0KPj4+Pj4+Pj4+Pj4+Pj4gaXNzdWVzLA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiBwbGVhc2Ugc3BlYWsgdXAhDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBDaGFydGVyIGNoYXJ0ZXItaWV0Zi1zZmMtMDAtMDQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4g DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IE5ldHdvcmtzLCBzZXJ2ZXJzLCBzdG9yYWdlIHRlY2hub2xvZ2ll cywgYW5kIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBhcHBsaWNhdGlvbnMsIGhhdmUgYWxsIHVuZGVyZ29u ZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlY2VudCB5ZWFycyB3 aXRoIHRoZSBpbnRyb2R1Y3Rpb24NCj4+Pj4+Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4+Pj4+PiB2 aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9yY2hlc3RyYXRpb24uDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IFNlcnZpY2UNCj4+Pj4+Pj4+Pj4+PiBkZWxpdmVyeQ0KPj4+Pj4+Pj4+Pj4+ Pj4gaXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9y Z2FuaXphdGlvbmFsIGNoYWxsZW5nZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+Pj4+ Pj4+IGludm9sdmVzDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHNpZ25pZmljYW50IG1vZGlmaWNhdGlvbiB0 byB0aGUgbmV0d29yayBjb25maWd1cmF0aW9uLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBTZXJ2aWNlcyBh cmUgdHlwaWNhbGx5IGltcGxlbWVudGVkIGJ5IHRoZSBvcmRlcmVkIA0KPj4+Pj4+Pj4+Pj4+Pj4+ PiBjb21iaW5hdGlvbiBvZiBhIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGVwbG95ZWQgYXQgZGlmZmVyZW50IHBvaW50cyB3aXRoaW4NCj4+ Pj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEgY29tbW9u IGRlcGxveW1lbnQgbW9kZWwgaGFzIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9u cyBwaHlzaWNhbGx5IGluc2VydGVkIG9uIHRoZSBkYXRhIGZvcndhcmRpbmcgDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IHBhdGggYmV0d2VlbiBjb21tdW5pY2F0aW5nIHBlZXJzLg0KPj4+Pj4+Pj4+Pj4+Pj4g R29pbmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZm9yd2FyZCwgaG93ZXZlciwgdGhlcmUgaXMgYSBkZXNp cmUgdG8gbW92ZSB0byBhIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBkaWZmZXJlbnQgbW9kZWwsDQo+Pj4+ Pj4+Pj4+Pj4+PiB3aGVyZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUg bm90IHJlcXVpcmVkIHRvIHJlc2lkZSBvbiB0aGUgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGRlZmF1bHQg ZGF0YQ0KPj4+Pj4+Pj4+Pj4+IHBhdGgNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IHRyYWZmaWMgaXMgaW5zdGVhZCBzdGVlcmVkIHRocm91Z2ggc2VydmljZXMsIHdoZXJl dmVyIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0aGV5IGFyZQ0KPj4+Pj4+Pj4+Pj4+Pj4gZGVwbG95ZWQu DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBGb3IgYSBnaXZlbiBzZXJ2aWNl LCB0aGUgYWJzdHJhY3RlZCB2aWV3IG9mIHRoZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcmVxdWlyZWQg c2VydmljZSBmdW5jdGlvbnMgYW5kIHRoZSBvcmRlciBpbiB3aGljaCB0aGV5IA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBhcmUgdG8gYmUgYXBwbGllZCBpcw0KPj4+Pj4+Pj4+PiBjYWxsZWQNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gYSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluIChTRkMpLiBTaW5jZSBhIGdpdmVuIHNl cnZpY2UgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9uIG1heSBiZSBhdmFpbGFibGUgb24gbW9y ZSB0aGFuIG9uZSBub2RlIHdpdGhpbiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYSBuZXR3b3JrLCBhIFNl cnZpY2UgRnVuY3Rpb24gQ2hhaW4gaXMgaW5zdGFudGlhdGVkDQo+Pj4+Pj4+Pj4+Pj4+PiB2aWEN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0 aW9uIGluc3RhbmNlcyANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYW5kIHRoZSBuZXR3b3JrIG5vZGVzIG9u IHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVkLCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhlcmVieSBmb3Jt aW5nIGEgc2VydmljZSB0b3BvbG9neToNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gdGhpcyBpcyBjYWxsZWQg YSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBm dW5jdGlvbnMNCj4+Pj4+Pj4+Pj4gbWF5DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGJlIGFwcGxpZWQgYXQg YSBzcGVjaWZpYyBsYXllciB3aXRoaW4gdGhlIG5ldHdvcmsgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHBy b3RvY29sIHN0YWNrDQo+Pj4+Pj4+Pj4+Pj4+PiAobmV0d29yaw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBs YXllciwgYXBwbGljYXRpb24gbGF5ZXIsIGV0Yy4pLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gVGhlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgd29ya2luZyBn cm91cCB3aWxsIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBkZXZlbG9wIG5ldyBhcHByb2FjaGVzIHRvIHNl cnZpY2UgZGVsaXZlcnkgYW5kIGRlcGxveW1lbnQuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEl0IHdpbGwg cHJvZHVjZSBhIGZyYW1ld29yayBmb3Igc2VydmljZSBmdW5jdGlvbiANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gY2hhaW5pbmcgdGhhdCBpbmNsdWRlcyB0aGUgbmVjZXNzYXJ5IHByb3RvY29scw0KPj4+Pj4+ Pj4+Pj4+Pj4gb3INCj4+Pj4+Pj4+Pj4+Pj4+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBjb252 ZXkgdGhlIHNlcnZpY2UgcGF0aCBhbmQgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHNlcnZpY2UgcGF0aCBp bmZvcm1hdGlvbiB0byBub2RlcyB0aGF0IGltcGxlbWVudCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2Vy dmljZSBmdW5jdGlvbnMsIGFzIHdlbGwNCj4+Pj4+Pj4+Pj4gYXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4g bWVjaGFuaXNtcyBmb3Igc3RlZXJpbmcgdHJhZmZpYyB0aHJvdWdoIHNlcnZpY2UgZnVuY3Rpb25z Lg0KPj4+Pj4+Pj4+Pj4+Pj4+PiBUaGUNCj4+Pj4+Pj4+Pj4+Pj4+IHdvcmtpbmcNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZ3JvdXAgd2lsbCBhbHNvIGV4YW1pbmUgd2hhdCBpbmZvcm1hdGlvbiBuZWVkcyB0 byBiZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZ2F0aGVyZWQgZnJvbQ0KPj4+Pj4+Pj4+Pj4+Pj4gdGhl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG5ldHdvcmsgYW5kIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1cHBv cnQgb2Ygc2VydmljZSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+Pj4+PiBj aGFpbmluZw0KPj4+Pj4+Pj4+Pj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaG93IHRoYXQg aW5mb3JtYXRpb24gbWF5IGJlIG1hZGUgYXZhaWxhYmxlIHRvIG5vZGVzIA0KPj4+Pj4+Pj4+Pj4+ Pj4+PiB0aGF0IGltcGxlbWVudA0KPj4+Pj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4g U3BlY2lmaWNhbGx5LCB0aGUgU0ZDIFdHIGlzIGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZQ0KPj4+ Pj4+PiBmb2xsb3dpbmc6DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAxKSBQ cm9ibGVtIFN0YXRlbWVudDogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUgYSANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gc3VtbWFyeSBvZg0KPj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gICBw cm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJlc3NlZCBieSB0aGUgV0cgaW5jbHVkaW5nIA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiBleGFtcGxlDQo+Pj4+Pj4+Pj4+IGhpZ2gtDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAg bGV2ZWwgdXNlIGNhc2VzLiBBZGRpdGlvbmFsbHksIHRoZSBXRyB3aWxsIG5vcm1hbGl6ZQ0KPj4+ Pj4+Pj4+Pj4+IG5vbWVuY2xhdHVyZQ0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGFuZCBkZWZpbml0aW9u cyBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IDIpIEFyY2hpdGVjdHVyZTogVGhpcyBkb2N1bWVudCB3aWxsIHByb3ZpZGUg YSANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gZGVzY3JpcHRpb24gb2YNCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gICBhcmNoaXRlY3R1cmFsIGJ1aWxkaW5nIGJsb2NrcyBhbmQgdGhlaXIgDQo+ Pj4+Pj4+Pj4+Pj4+Pj4+IHJlbGF0aW9uc2hpcHMNCj4+Pj4+Pj4+Pj4gaW5jbHVkaW5nDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+ICAgaW50ZXJjb25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVz LCBtYW5hZ2VtZW50LA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGRpYWdub3N0aWNzLCBkZXNpZ24gYW5h bHlzaXMsIGFuZCBzZWN1cml0eSBtb2RlbHMsIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBhcyB3ZWxsDQo+ Pj4+Pj4+Pj4gYXMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gICByZXF1aXJlbWVudHMgb24gdGhlIHByb3Rv Y29sIG1lY2hhbmlzbXMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAzKSBH ZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSANCj4+Pj4+ Pj4+Pj4+Pj4+Pj4gZG9jdW1lbnQNCj4+Pj4+Pj4+Pj4gd2lsbA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAg IGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uDQo+Pj4+Pj4+Pj4+Pj4gZm9ybWF0DQo+Pj4+Pj4+Pj4+Pj4+ Pj4+IGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGNvbnZleWluZyB0aGUgc2VydmljZSBmdW5jdGlv biBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9uDQo+Pj4+ Pj4+Pj4+Pj4+PiBwYXRoLA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGFuZCBmb3IgY29tbXVuaWNhdGlu ZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IG5vZGVzDQo+ Pj4+Pj4+IHRoYXQNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlv bnMuIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlDQo+Pj4+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9u DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0 IGlzIGFwcGxpZWQgYW5kIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiB0aGUgc2VydmljZQ0KPj4+Pj4+Pj4+ Pj4+Pj4gdGhhdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBpcw0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGJlaW5n IGNvbnN0cnVjdGVkLiBUaGF0IGlzLCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9uIA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBtYXkgYmUNCj4+Pj4+Pj4+Pj4gdXNlZA0KPj4+Pj4+Pj4+Pj4+IG9uDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdv cmsgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGxheWVyIG9yIGF0IGFueSBvdGhlcg0KPj4+Pj4+Pj4+Pj4+ Pj4+PiAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0 aGUNCj4+Pj4+Pj4+Pj4+PiBjb25zdHJ1Y3Rpb24NCj4+Pj4+Pj4+Pj4+Pj4+IG9mDQo+Pj4+Pj4+ Pj4+Pj4+Pj4+ICAgc2VydmljZSBmdW5jdGlvbiBwYXRocyByZWdhcmRsZXNzIG9mIHRoZSBhY3R1 YWwNCj4+Pj4+Pj4gc2VydmljZS4NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ IDQpIENvbnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBzZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUN Cj4+Pj4+Pj4+Pj4gZGV2ZWxvcGVkIHRvDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgZGVzY3JpYmUgcmVx dWlyZW1lbnRzIGFuZCBwcm90b2NvbHMgbmVjZXNzYXJ5IHRvIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBj b252ZXkNCj4+Pj4+Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgdG8g c2VydmljZSBmdW5jdGlvbiBpbXBsZW1lbnRhdGlvbiBwb2ludHMuIFdoZXJlIA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBwb3NzaWJsZSwNCj4+Pj4+Pj4+Pj4+Pj4+IGV4aXN0aW5nDQo+Pj4+Pj4+Pj4+Pj4+ Pj4+ICAgSUVURiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIGFuZCBleHRlbmRlZC4gQWxsIA0KPj4+ Pj4+Pj4+Pj4+Pj4+PiBwcm90b2NvbA0KPj4+Pj4+Pj4+Pj4+IGV4dGVuc2lvbnMNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gICB3b3JrIHNob3VsZCBiZSBjYXJyaWVkIG91dCBpbiB0aGUgd29ya2luZyBncm91 cHMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHJlc3BvbnNpYmxlIGZvcg0KPj4+Pj4+Pj4+Pj4+Pj4gdGhl DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgcHJvdG9jb2xzIGJlaW5nIG1vZGlmaWVkIGluIGNvb3JkaW5h dGlvbiB3aXRoIHRoaXMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHdvcmtpbmcNCj4+Pj4+Pj4+Pj4+PiBn cm91cCwNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gYnV0DQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgbWF5IGJlIGRv bmUgaW4gdGhpcyB3b3JraW5nIGdyb3VwIGFmdGVyIGFncmVlbWVudCANCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gd2l0aCBhbGwNCj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+ICAgcmVsZXZhbnQg V0cgY2hhaXJzIGFuZCByZXNwb25zaWJsZSBBRHMuDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+ Pj4+Pj4+Pj4+PiA1KSBNYW5hZ2VhYmlsaXR5OiBXb3JrIG9uIHRoZSBtYW5hZ2VtZW50IGFuZCAN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gY29uZmlndXJhdGlvbiBvZg0KPj4+Pj4+Pj4+Pj4+IHNlcnZpY2UN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gICBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBTRkMgY29tcG9uZW50 cyB3aWxsIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBjZXJ0YWlubHkgYmUNCj4+Pj4+Pj4+Pj4gbmVlZGVk LA0KPj4+Pj4+Pj4+Pj4+Pj4+PiAgIGJ1dCBmaXJzdCBuZWVkcyB0byBiZSBiZXR0ZXIgdW5kZXJz dG9vZCBhbmQgc2NvcGVkLg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gUHJv cG9zZWQgTWlsZXN0b25lcw0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gQXBy IDIwMTQgU3VibWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudChzKSANCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gZGVmaW5pbmcgdGhlDQo+Pj4+Pj4+Pj4+Pj4+PiBwcm9ibGVtDQo+Pj4+Pj4+Pj4+ Pj4+Pj4+IHN0YXRlbWVudCBhbmQgY29yZSB1c2UgY2FzZXMgZm9yIFNlcnZpY2UgRnVuY3Rpb24g DQo+Pj4+Pj4+Pj4+Pj4+Pj4+IENoYWluaW5nDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBNYXkgMjAxNCBDb25zdWx0IHdpdGggT1BTIEFyZWEgb24gcG9zc2libGUgY2hhcnRl ciANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbW9kaWZpY2F0aW9ucyBmb3IgbWFuYWdlbWVudCBhbmQgY29u ZmlndXJhdGlvbiBvZiBTRkMgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGNvbXBvbmVudHMNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIEluZm9y bWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcgDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+ Pj4+Pj4+Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IGZvciBTRkMNCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gDQo+Pj4+Pj4+Pj4+Pj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIHJlcXVp cmVtZW50cyBmb3IgYSBnZW5lcmljIA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9u IGNoYWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IEF1ZyAyMDE1IFN1Ym1pdCB0byBJRVNHIFN0YW5kYXJkcyBUcmFjayBkb2N1 bWVudCANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gc3BlY2lmeWluZyB0aGUNCj4+Pj4+Pj4+Pj4+Pj4+IGdl bmVyaWMNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBoZWFkZXIg ZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IA0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4gDQo+Pj4+ Pj4+Pj4+Pj4+Pj4+IFRob21hcw0KPj4+Pj4+Pj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+Pj4+Pj4+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+ Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcN Cj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u c2MNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+ Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+Pj4+Pj4gbnNjIG1h aWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+Pj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+Pj4+Pj4+ Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+ Pj4+Pj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+Pj4+PiBuc2NAaWV0Zi5v cmcNCj4+Pj4+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25zYw0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IG5zY0BpZXRm Lm9yZw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KPj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9y Zw0KPj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+IG5zY0BpZXRmLm9yZw0K Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+ Pj4+PiANCj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+ Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4+IG5z YyBtYWlsaW5nIGxpc3QNCj4+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+Pj4gbnNjIG1haWxpbmcgbGlz dA0KPj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IG5zY0BpZXRmLm9yZw0K Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+PiBuc2Mg bWFpbGluZyBsaXN0DQo+Pj4+PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+ IG5zY0BpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25zYw0KPj4+IA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+bnNjIG1haWxpbmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5uc2MgbWFpbGluZyBsaXN0DQo+bnNjQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0K From smkumar@cisco.com Thu Nov 14 19:39:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D969B11E817F for ; Thu, 14 Nov 2013 19:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[AWL=1.398, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngd5zY2x+4eD for ; Thu, 14 Nov 2013 19:38:58 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BB33821F9D19 for ; Thu, 14 Nov 2013 19:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51053; q=dns/txt; s=iport; t=1384486737; x=1385696337; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+c6iR3edqsqUNQNU2w8J65zUpDcpDU73KIjOXRXxBN0=; b=Fi56tcvz37rs9/t1gpefK3O+raxoBQ50Lm6ILwVjIopp0KK2tUl5Rlv6 LRn9EXo/nbWsfmD8vvwT9gXjNurSl9rlOChvwq127fkS+ceBo2DWV31dP We+hihMZv4aFBySWjruwE7xNg7zqK9MtD/g3AJckQRGRZ/bGUx2eQN8S3 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOWWhVKtJV2Z/2dsb2JhbABPCoMHOFO/HYEhFnSCJQEBAQQBAQEXAR8rAgcEBwwGAQgOAwEDAQEBFQkJLgsUAwUBCAIEAQkEBQmHeA3BA44WBgQBBQaBCCsHAgQEhCcDlC6DYpIMgyiBaAEIFyI X-IronPort-AV: E=Sophos;i="4.93,704,1378857600"; d="scan'208";a="284887627" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 15 Nov 2013 03:38:56 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAF3ctu7029615 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Nov 2013 03:38:55 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 21:38:55 -0600 From: "Surendra Kumar (smkumar)" To: Ken Gray , "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: re classification & branching, was: Current Proposed SFC charter Thread-Index: AQHO39oDwl0nN7MhlEaYEgafQy16wpojVngAgABdGwCAALQWgIAA0K0AgAAE9ACAAAKvAIAAAZMAgAADEACAAAGZgP//lKkAgACOPACAAB4TgA== Date: Fri, 15 Nov 2013 03:38:54 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.123.236] Content-Type: text/plain; charset="us-ascii" Content-ID: <7F98395C062BCE40BEAEBE7EAA0BA9E1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" , David Allan I Subject: Re: [nsc] FW: re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 03:39:03 -0000 You hit it on the head, Ken! Surendra. On 11/14/13 9:51 AM, "Ken Gray" wrote: >+1=20 > >Fair-warning - I'm not a huge fan of a fan-out of interface definitions >(many of which only seem to disappear in implementation because nobody >really was going to build anything so super-atomic). > >That said, from a practical perspective, a service function can operate >on a packet ... it can transform the packet ...I don't see how you can >preclude this. In transforming the packet, it IS potentially altering >the forwarding on the egress side of the function - depending on the >logic it used to alter the packet. Unless we're proposing all of this >sort of transformation logic is going to suddenly be externalized for all >service functions, then branching is logically going to happen - >potentially driven by the service function. > >Depending on how you do "fix-up" or whatever your company calls this >handoff, you involve (or don't) some additional actions in the forwarding >component - implementation. So, we're arguing about implementation here >in this thread, IMO. Yeah, go ahead and create your interface if it >clarifies things for you, but it's going to be a logical division and not >a practical protocol or API. > >Finally, without the possibility of branching (which was the fundamental >question in the title, and we're straying away from it, IMO), you beg an >entirely centralized control system (every chain, for every circumstance >is pre-defined). That too, IMO, is an implementation choice but it's >enabled by creating roof for it int he architecture. If you remove >branching, you remove the choice. > >My .02. >________________________________________ >From: nsc-bounces@ietf.org on behalf of Surendra >Kumar (smkumar) >Sent: Thursday, November 14, 2013 12:22 PM >To: Jim Guichard (jguichar); Ron Parker >Cc: nsc@ietf.org; Hongyu Li (Julio); David Allan I >Subject: Re: [nsc] FW: re classification & branching, was: Current >Proposed SFC charter > >This separation is a very important architecture consideration IMO. Select >services can dictate the forwarding path at a higher level through the >service path. Actual forwarding may be left to the forwarding components. > >Surendra. > >On 11/14/13 7:46 AM, "Jim Guichard (jguichar)" wrote: > >>Sure but architecturally the service function and forwarding components >>are separate entities. Whether you choose to combine them in >>implementation is your own choice. >> >>Sent from my iPhone >> >>> On Nov 14, 2013, at 10:40 AM, "Ron Parker" >>> wrote: >>> >>> Jim, >>> >>> I think that could be an implementation decision. One implementation >>>approach is that the SFC IP-layer transport tunnels are known at the >>>forwarding layer (like the way IP-in-IP and GRE tunnels are frequently >>>supported -- as an IP interface). Another possible approach is to >>>handle the SFC IP-layer transport tunnels at a level above the >>>forwarding layer (like the way GTP-U tunnels are frequently supported -- >>>they are not represented as distinct IP interfaces). >>> >>> Ron >>> >>> >>> -----Original Message----- >>> From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] >>> Sent: Thursday, November 14, 2013 10:30 AM >>> To: Ron Parker; David Allan I; Hongyu Li (Julio); nsc@ietf.org >>> Subject: Re: [nsc] FW: re classification & branching, was: Current >>>Proposed SFC charter >>> >>> Hi Ron, >>> >>> I would not say that b modifies the transport header but rather b >>>informs the forwarding component of it's intent so that it may insert >>>the appropriate transport header to meet b's requirement. >>> >>>> On 11/14/13 10:24 AM, "Ron Parker" >>>>wrote: >>>> >>>> Hi, Jim. >>>> >>>> I agree that forwarding is affected indirectly. Whether function b >>>> forwards to function c or function d is accomplished by b correctly >>>> adding (modifying) the transport header so that d is addressed or c is >>>> addressed. In the most general case of utilizing an IP-based >>>>transport >>>> encapsulation (e.g., IP/UDP, IP/GRE, etc.), the selection of next hop >>>>is >>>> not made at this level. The transport location (IP address) for c >>>>and d >>>> may or may not share the same next-hop based on the newtwork topology >>>> (i.e., c and/or d may or may not be on the same subnet as b, may or >>>>may >>>> not be reached via the same next hop router). >>>> >>>> Ron >>>> >>>> >>>> -----Original Message----- >>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>> Jim Guichard (jguichar) >>>> Sent: Thursday, November 14, 2013 10:14 AM >>>> To: David Allan I; Hongyu Li (Julio); nsc@ietf.org >>>> Subject: Re: [nsc] FW: re classification & branching, was: Current >>>> Proposed SFC charter >>>> >>>> I think it is misleading to say that a service function does not >>>>impact >>>> packet forwarding. If branching occurs then the service function does >>>> impact packet forwarding, whether directly or indirectly, as otherwise >>>> packets would not take the new path as a result of the branch. For >>>> example, if the chain is a-b-c and b decides that for certain flows >>>>the >>>> traffic should go to d rather than c then it *must* force the >>>> forwarding component to direct traffic to the new next-hop. While the >>>> service function may not modify forwarding in terms of updating >>>> forwarding tables and so forth, it has to inform the forwarding >>>> component of its intent somehow. Also, I think what you describe Dave >>>> is a bypass operation rather than a branch? >>>> >>>>> On 11/14/13 9:56 AM, "David Allan I" >>>>>wrote: >>>>> >>>>> I think it is going to be a rare event, as what is more likely is the >>>>> front end of the chain is dynamically modified so subsequent packets >>>>> in a flow skip certain functions. Hence a graph more often than not >>>>>is >>>>> logically P2P. Facilitates testing amongst other benefits. >>>>> >>>>> As such I'd not want to be prescriptive as to how and where it is >>>>> done.... >>>>> >>>>> Dave >>>>> >>>>> -----Original Message----- >>>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>>> Sent: Wednesday, November 13, 2013 6:30 PM >>>>> To: David Allan I; nsc@ietf.org >>>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>>> Proposed SFC charter >>>>> >>>>> Hi Dave, >>>>> >>>>> Your inferred restriction may be not always true. In general, service >>>>> functions should be able to compose a chain arbitrarily. Particularly >>>>> for branching, as I suggested in previous email, service function >>>>> shall not directly impact packet forwarding. This precludes the >>>>> restriction you mentioned. Forwarding plane can decide whether a >>>>> branching action should be taken by reclassification or not per >>>>>service chain. >>>>> >>>>> Does this make sense? >>>>> >>>>> Hongyu >>>>> >>>>> -----Original Message----- >>>>> From: David Allan I [mailto:david.i.allan@ericsson.com] >>>>> Sent: Wednesday, November 13, 2013 11:45 PM >>>>> To: Hongyu Li (Julio); nsc@ietf.org >>>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>>> Proposed SFC charter >>>>> >>>>> HI Hongyu: >>>>> >>>>> I think we will have scenarios where a service function appears in >>>>> more than one chain, as would be the case, for example, if some flows >>>>> could dynamically bypass DPI but still needed to transit a common set >>>>> of stateful service functions... >>>>> >>>>> Once you postulate a service function instance appearing in more than >>>>> one chain, it seems artificially restrictive not to permit such a >>>>> function to also implement branching, all the control structures >>>>>would >>>>> already be there. >>>>> >>>>> Rgds >>>>> Dave >>>>> >>>>> -----Original Message----- >>>>> From: Hongyu Li (Julio) [mailto:hongyu.li@huawei.com] >>>>> Sent: Wednesday, November 13, 2013 2:12 AM >>>>> To: David Allan I; nsc@ietf.org >>>>> Subject: RE: [nsc] FW: re classification & branching, was: Current >>>>> Proposed SFC charter >>>>> >>>>> May I suggest summary of my views here: >>>>> >>>>> 1. Branch is a sort of use case or scenario, while reclassification >>>>>is >>>>> a way to solve the problem. >>>>> 2. Service Functions should be decoupled with the chain itself. >>>>> Meaning, a SF shall not *directly* impact the forwarding of >>>>>packets >>>>> in a chain. Branching should be performed by chain forwarding nodes, >>>>> possibly under control of a control node. The reason for this is in >>>>> NFV world, service functions may come from a third party, while chain >>>>> is provided by the infrastructure of the network. There must be a >>>>> cushion avoiding a service function operating infrastructure >>>>>directly. >>>>> 3. (Re)classification is based on info in a packet. >>>>> This is very general. Such info could be L2~L7 derived from a >>>>>user's >>>>> packet, as well as some info like metadata in a SFC header. As >>>>> classification is out of scope of SFC, we don't have to provide too >>>>> much details of how to do classification. >>>>> 4. Chain segments stitching is relatively a easy way for branching. >>>>> Compared with chains and subchains, which may require a more complex >>>>> header and forwarding capabilities. >>>>> My two cents. >>>>> Hongyu >>>>> >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>>> David Allan I >>>>> Sent: Wednesday, November 13, 2013 3:04 AM >>>>> To: nsc@ietf.org >>>>> Subject: [nsc] FW: re classification & branching, was: Current >>>>> Proposed SFC charter >>>>> >>>>> Hi: >>>>> (resend with recipient list cleaned up) >>>>> >>>>> I agree we are discussing multiple concepts, classification and >>>>> flow-subsetting. Perhaps more ;-) >>>>> >>>>> Defining a flow subset can be a result of classification, but it is >>>>> not the exclusive mechanism. Branching is a mechanism by which flow >>>>> subsets are exposed and mapped to a set of subchains such that it can >>>>> be identified in the dataplane... >>>>> >>>>> That's the view from here >>>>> Dave >>>>> >>>>> -----Original Message----- >>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>>> David Lake (dlake) >>>>> Sent: Tuesday, November 12, 2013 10:51 AM >>>>> To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); >>>>>Ron >>>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>> >>>>> Understood - maybe just a little localised warming of the sea then ? >>>>> But I still think we need to consider where and how policy is >>>>> defined/set even for the single-domain instance. >>>>> >>>>> I don't think we can assume that any L1-3 device will be able to >>>>> determine much useful information from the data-plane. >>>>> >>>>> -----Original Message----- >>>>> From: Jim Guichard (jguichar) >>>>> Sent: 12 November 2013 10:44 >>>>> To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron >>>>> Parker; Linda Dunbar; Hongyu Li (Julio) >>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>> >>>>> As discussed during the BOF our initial work is single administrative >>>>> domain for some of the very reasons you point out. We need to keep >>>>> focused without trying to boil the ocean right off the bat. >>>>> >>>>>> On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >>>>>> >>>>>> Exactly. But how can network-components "terminate" an application >>>>>>???? >>>>>> >>>>>> I think we need a good understanding of a recursive policy mechanism >>>>>> (recursive because a user-land application will ride with a specific >>>>>> policy across potentially different sets of carrier policies). >>>>>> >>>>>> I hate to bring this up now, but we also need to think about this >>>>>> multi-domain issue - if I set a policy as a user, chances are I will >>>>>> be crossing several domain boundaries. Are we expecting the service >>>>>> headers to define the service chaining for the duration of the >>>>>>entire >>>>>> flow across all domains, or just across a single one ? >>>>>> >>>>>> In which case, do I have to re-set policy as I traverse domains and >>>>>> where does that policy get set ? It would be much better to set >>>>>>policy >>>>>> once based on L5-7 needs, and have that instantiated across the >>>>>> multiple domains. >>>>>> >>>>>> Again, this appears to be outside the scope of SFC, but pretty >>>>>> relevant to how it would operate in the real world. >>>>>> >>>>>> David >>>>>> >>>>>> -----Original Message----- >>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>> Sent: 12 November 2013 10:27 >>>>>> To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>>>>> Dunbar; Hongyu Li (Julio) >>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>> >>>>>>> In those circumstances, only the end applications themselves or a >>>>>>> reasonably broad-brushed classification (really traffic steering >>>>>>> based on what we can see at ingress) is going to be useful - is >>>>>>> THAT what we're aiming for here ? >>>>>> >>>>>> I would certainly hope not, but that has been my concern as well. >>>>>> Application layer termination and re-classification seems a must? >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>>>>>> Sent: Tuesday, November 12, 2013 1:00 PM >>>>>>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>>>>>> Hongyu Li (Julio) >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Policy may be outside of the scope of SFC, but without strong >>>>>>> mapping between Policy and the inserted Service Header(s), we >>>>>>> run-the-risk of limiting the efficacy of the protocol IMO. >>>>>>> >>>>>>> For example, in a world where the network has "gone dark," (as per >>>>>>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>>>>>> policy based on DPI of packets-in-flight ? >>>>>>> >>>>>>> In those circumstances, only the end applications themselves or a >>>>>>> reasonably broad-brushed classification (really traffic steering >>>>>>> based on what we can see at ingress) is going to be useful - is >>>>>>> THAT what we're aiming for here ? >>>>>>> >>>>>>> David >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>> Of Surendra Kumar (smkumar) >>>>>>> Sent: 12 November 2013 09:26 >>>>>>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>>>>>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> Ron, >>>>>>> >>>>>>> Classification of traffic is well understood and we do not have to >>>>>>> redefine it - it's been around for all the time middle boxes have >>>>>>> been or for that matter the L2/L3 devices. All we are talking about >>>>>>> is the applicability of the classification to branching in SFC. >>>>>>> >>>>>>> You are right, it is all about policy which is outside the scope of >>>>>>> SFC. >>>>>>> >>>>>>> Surendra. >>>>>>> >>>>>>> On 11/12/13 7:53 AM, "Ron Parker" >>>>>>> wrote: >>>>>>> >>>>>>>> I think the lack of definition of "reclassification" may be >>>>>>>> causing >>>>>>> some >>>>>>>> misunderstandings here. A branch would occur for some >>>>>>> policy-driven >>>>>>>> reason based on the behavior and conclusions of the service >>>>>>>>function, >>>>>>>> itself. The graph would represent the fact that there is a >>>>>>>>branch >>>>>>>> point, but the service function, itself, being aware that it is a >>>>>>>> branching point would contain the policy and logic to decide on >>>>>>>>which >>>>>>>> branch to take. Specifying that policy and logic is out of >>>>>>>>scope, >>>>>>> IMO. >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>>>>>>> Sent: Tuesday, November 12, 2013 10:49 AM >>>>>>>> To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>> Sumandra Majee >>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>> >>>>>>>> Hi Linda, >>>>>>>> >>>>>>>> Are you saying that a branching point is "never" a >>>>>>>> reclassification point, or are you saying that a branching point >>>>>>> "does not have to be" >>>>>>>> a reclassification point? >>>>>>>> >>>>>>>> I think this is an important distinction that needs to be >>>>>>> clarified. >>>>>>>> If branching is never reclassification, then the meaning of a >>>>>>>> chain is different than I originally inferred. If the chain is a >>>>>>>> tree with other "branching" points in it, then that limits the >>>>>>>> scope of the problem statement goals. >>>>>>>> >>>>>>>> While this could be a degenerate case, and any implementation >>>>>>>> could define bad service chains, is it the intent of SFC to only >>>>>>>> look at the simpler packet-level classification cases, or is it >>>>>>>> the intent to consider the case where a branching point is viewed >>>>>>>> as a re-classification point? >>>>>>>> >>>>>>>> thanx. >>>>>>>> >>>>>>>> -- Kevin J. Ma >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>>>>>>>> Sent: Tuesday, November 12, 2013 10:34 AM >>>>>>>>> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>> Sumandra Majee >>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>> >>>>>>>>> Ron, >>>>>>>>> >>>>>>>>> First, want to make it clear that "branching" !=3D >>>>>>>>> reclassification, agree? >>>>>>>>> >>>>>>>>> Second, the representation of branching (or service graph) can >>>>>>>>> be in a form of logic on a service function. Some service >>>>>>>>> functions, especially L7 based, can use value in a Database to >>>>>>>>> determine what is the next service function. >>>>>>>>> >>>>>>>>> Linda >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>> Behalf Of Ron Parker >>>>>>>>>> Sent: Tuesday, November 12, 2013 8:16 AM >>>>>>>>>> To: Hongyu Li (Julio); Kevin J Ma >>>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>>> Sumandra Majee >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>> >>>>>>>>>> Hongyu, >>>>>>>>>> >>>>>>>>>> I agree completely that re-classification is not limited to DPI. >>>>>>>>>> >>>>>>>>>> And also, that an area for us to explore as a group is how to >>>>>>>>> represent >>>>>>>>>> the service graph. Do we want to represent it as a proper >>>>>>>>>>graph >>>>>>> with >>>>>>>>>> an adjacency list or other representational model? Or, do we >>>>>>> want >>>>>>> to >>>>>>>>>> represent it as a set of linear segments and if so, how are the >>>>>>>>>> segments connected into a graph? Other ideas? >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>> Behalf Of Hongyu Li (Julio) >>>>>>>>>> Sent: Tuesday, November 12, 2013 6:57 AM >>>>>>>>>> To: Ron Parker; Kevin J Ma >>>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>>> Sumandra Majee >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>> >>>>>>>>>> Branching/forking is a very interesting topic of SFC. About >>>>>>>>>> the >>>>>>>>>> re- classification point, probably we shall not limit it to DPI. >>>>>>>>>> It is also possible that packets go to different branches >>>>>>>>>> after been processed by a certain service function, decision >>>>>>>>>> of which branches to go is made based on the result of service >>>>>>>>>> function's process, i.e. not just re- classification by DPI. >>>>>>>>>> >>>>>>>>>> Hongyu >>>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>> Behalf Of Ron Parker >>>>>>>>>> Sent: Tuesday, November 12, 2013 7:45 PM >>>>>>>>>> To: Kevin J Ma >>>>>>>>>> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>>>>>>>>> Sumandra Majee >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>> >>>>>>>>>> Hi, Kevin >>>>>>>>>> >>>>>>>>>> You ask a great question about branching the graph. The >>>>>>>>>> details around how to convey the selection of the >>>>>>>>>> subtree/subgraph are still >>>>>>>>> to be >>>>>>>>>> defined. Is it one chain id for the whole graph? Does each >>>>>>> branch >>>>>>>>>> have its own chain id? Some combination? >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>>> >>>>>>>>>> On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>>> Yes, reclassification can change the service path and >>>>>>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>>>> >>>>>>>>>>> Just to expand on that, going back to the original question >>>>>>>>>>> about service header encapsulation, is it intended that a >>>>>>>>>>> chain that is re-classified will get a new chain ID which >>>>>>>>>>> fully describes a chain that is a superset of the original >>>>>>>>>>> chain ID, prior to DPI-based re-classification? (assuming >>>>>>>>>>> the goal is "a single chain ID that is commonly understood >>>>>>>>>>> along the entire service >>>>>>> chain" >>>>>>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.ht >>>>>>>>>>> m >>>>>>>>>>> l >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> And the applicable subset of the permutative list of service >>>>>>>>>>> paths would be configured at each appropriate service node? >>>>>>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>>>>>>>>>> every flow then be initially classified as ID 1, but >>>>>>>>>>> eventually get re- >>>>>>>>>> classified >>>>>>>>>>> to ID 2-11, after the DPI phase? >>>>>>>>>>> >>>>>>>>>>> thanx. >>>>>>>>>>> >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi Surendra, >>>>>>>>>>>>> >>>>>>>>>>>>> Classification may be out of scope, but the level of >>>>>>>>>>>>> service that >>>>>>>>>> is >>>>>>>>>>>>> applicable is dependent upon the level of classification >>>>>>>>>>>>> that can >>>>>>>>>> be >>>>>>>>>>>>> performed. An assumption of packet level encapsulation >>>>>>>>>>>>> has >>>>>>>>>>>> implications >>>>>>>>>>>>> on the level of classification being performed? If the >>>>>>>>>>>>> stated >>>>>>>>>> goals >>>>>>>>>>>> are >>>>>>>>>>>>> for firewall and load balancer functionality, then the >>>>>>>>>>>>> application >>>>>>>>>>>> level >>>>>>>>>>>>> nature of those functions needs to be taken into account? >>>>>>>>>>>>> If, on the other hand, the service function scope is >>>>>>>>>>>>> limited due to limitations in classification, that would >>>>>>>>>>>>> be and important piece of >>>>>>>>>> information? >>>>>>>>>>>>> >>>>>>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases >>>>>>>>>>>>> the fork points of the service paths seem like >>>>>>>>>>>>> re-classification >>>>>>> points? >>>>>>>>>>>>> Is that the interpretation from the architecture perspective? >>>>>>>>>>>>> Or is the service function chain classification exclusive >>>>>>>>>>>>> of DPI >>>>>>>>>> functionality? >>>>>>>>>>>> I have not fully read that draft yet. But in general, >>>>>>>>>>>> as described in the arch draft, the collection of services >>>>>>>>>>>> form a graph, segments of which are service paths. Yes, >>>>>>>>>>>> reclassification can >>>>>>>>>> change >>>>>>>>>>>> the service path and re-classification may happen at any >>>>>>>>>>>> node along >>>>>>>>>> a service path. >>>>>>>>>>>> >>>>>>>>>>>> Surendra. >>>>>>>>>>>>> >>>>>>>>>>>>> thanx. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas >>>>>>>>>>>>>> Narten; nsc@ietf.org >>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>> >>>>>>>>>>>>>> Kevin, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Classification mechanism is outside the scope of SFC. It >>>>>>>>>>>>>> can be based >>>>>>>>>>>> on >>>>>>>>>>>>>> the packet or information not in the packet(environmental >>>>>>>>>>>>>> attributes >>>>>>>>>>>> for >>>>>>>>>>>>>> instance) or a combination thereof. What is important is >>>>>>>>>>>>>> that such classification aids in traffic selection and >>>>>>>>>>>>>> service path identification. >>>>>>>>>>>>>> It is no different from a policy in this regard except >>>>>>>>>>>>>> that the policy now specifies the service path. >>>>>>>>>>>>>> Further, classification is not limited to the network >>>>>>>>>>>>>> elements but the service functions as well. Some of this >>>>>>>>>>>>>> is described in the >>>>>>>>>>>> architecture >>>>>>>>>>>>>> drafts as well - >>>>>>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>>>>> >>>>>>>>>>>>>> Surendra. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>>>>>>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Ron, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with >>>>>>>>>>>>>>> CDNI, but I had a similar question wrt bullet 11 in >>>>>>>>>>>>>>> section >>>>>>>>>>>>>>> 2 of the >>>>>>>>>> problem >>>>>>>>>>>>>>> statement: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 11. Per-Service (re)Classification: Classification >>>>>>>>>>>>>>> occurs at >>>>>>>>>> each >>>>>>>>>>>>>>> service, independent from previously applied >>>>>>>>>>>>>>> service >>>>>>>>>>>>>> functions. >>>>>>>>>>>>>>> These unrelated classification events consume >>>>>>>>>>>>>>> resources >>>>>>>>>> per >>>>>>>>>>>>>>> service. More importantly, the classification >>>>>>>>>> functionality >>>>>>>>>>>>>>> often differs per service function and service >>>>>>>>>>>>>>> function >>>>>>>>>>>> cannot >>>>>>>>>>>>>>> leverage the results from other deployed network >>>>>>>>>>>>>>> or >>>>>>>>>> service. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The SFC Classifier classifies packets based on (some >>>>>>>>>>>>>>> of) the >>>>>>>>>>>>>> contents >>>>>>>>>>>>>>> of the packet header. Concretely, it classifies >>>>>>>>>>>>>>> packets based on >>>>>>>>>>>>>> the >>>>>>>>>>>>>>> possible combination of one or more header fields, >>>>>>>>>>>>>>> such as >>>>>>>>>> source >>>>>>>>>>>>>>> address, destination address, DS field, protocol ID, >>>>>>>>>>>>>>> source >>>>>>>>>> port >>>>>>>>>>>>>> and >>>>>>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> A packet-based classifier as described in the framework >>>>>>>>>>>>>>> document >>>>>>>>>>>>>> would >>>>>>>>>>>>>>> seem to be limited in what it can classify? The service >>>>>>>>>>>>>>> function identifier lookup does not seem to be a >>>>>>>>>>>>>>> significant optimization >>>>>>>>>>>> over >>>>>>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some >>>>>>>>>>>>>>> missing >>>>>>>>>>>> detail >>>>>>>>>>>>>>> wrt how classification information is determined and >>>>>>> reused? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> When thinking about higher level services, e.g., HTTP >>>>>>>>>>>>>>> and TLS >>>>>>>>>>>>>> encrypted >>>>>>>>>>>>>>> flows, a packet-based classifier seems inadequate? I >>>>>>>>>>>>>>> was also >>>>>>>>>>>>>> wondering >>>>>>>>>>>>>>> how independent HLS segment requests might be classified >>>>>>>>>>>>>>> and >>>>>>>>>>>>>> associated? >>>>>>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanx. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: nsc-bounces@ietf.org >>>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>>> Of >>>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>> Parker >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As was discussed in Vancouver, there are already many >>>>>>>>>>>>>>>> existing ways >>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> accomplish service chaining. But none of them provide >>>>>>> a >>>>>>>>>>>>>> sufficient >>>>>>>>>>>>>>>> combination of interoperability, flexibility, and >>>>>>> resiliency. >>>>>>>>>> A >>>>>>>>>>>>>> single >>>>>>>>>>>>>>>> service chain encapsulation will go a long way to >>>>>>>>>>>>>>>> ensuring these >>>>>>>>>>>>>> goals. >>>>>>>>>>>>>>>> It may not be the absolutely most efficient approach >>>>>>>>>>>>>>>> for every >>>>>>>>>>>>>> single >>>>>>>>>>>>>>>> network topology and every single use case, but its >>>>>>>>>>>>>>>> ubiquitous >>>>>>>>>>>> nature >>>>>>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>>>>> However >>>>>>>>>>>>>> this >>>>>>>>>>>>>>>> could be augmented with classification result, again >>>>>>>>>>>>>>>> one more >>>>>>>>>>>>>> example. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> All flows from the same source IP do not necessarily >>>>>>>>>>>>>>>>>> follow >>>>>>>>>> the >>>>>>>>>>>>>> same >>>>>>>>>>>>>>>> chain. >>>>>>>>>>>>>>>> Correct. It is also not necessary that all transaction >>>>>>>>>>>>>>>> of the same >>>>>>>>>>>>>> flow >>>>>>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Again the point here is that do we always need SFC >>>>>>>>>>>>>>>> header or >>>>>>>>> Not. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sumandra >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The intention of service function chaining is to allow >>>>>>>>>>>>>>>> for operation >>>>>>>>>>>>>> at >>>>>>>>>>>>>>>> the fully qualified flow level, or even finer grained >>>>>>>>>>>>>>>> at the >>>>>>>>>>>>>> transaction >>>>>>>>>>>>>>>> level (this is an implementation matter for the PDP). >>>>>>> All >>>>>>>>>> flows >>>>>>>>>>>>>> from >>>>>>>>>>>>>>>> the same source IP do not necessarily follow the same >>>>>>> chain. >>>>>>>>>>>> Source >>>>>>>>>>>>>>>> IP, >>>>>>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>>>> intention >>>>>>>>>> of >>>>>>>>>>>>>>>> service function chaining is to operate over any >>>>>>>>>>>>>>>> network >>>>>>>>>> topology >>>>>>>>>>>> and >>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>>>>> of >>>>>>>>>> the >>>>>>>>>>>>>>>> transport, it does not adequately identify the service >>>>>>>>>>>>>>>> chain, >>>>>>>>>>>> either. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The service header is meant to carry the context which >>>>>>>>>>>>>>>> can >>>>>>>>>> *also* >>>>>>>>>>>>>>>> be derived (for example use source ip and vlan to >>>>>>>>>>>>>>>> identify chainID and >>>>>>>>>>>>>>>> position) or encapsulated as part of another tunnel >>>>>>> header. >>>>>>>>>>>>>>>> So this could be optional IMHO. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Ron Parker >>>>>>>>>>>>>>>> [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Sumandra, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP >>>>>>>>>>>>>>>> to SF or from >>>>>>>>>>>>>> SF >>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>> SF will look like: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>> | "transport" | >>>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>> | service header | >>>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>> | original IP header | >>>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>> | | original >>>>>>>>>>>>>>>> | IP payload >>>>>>>>>> | >>>>>>>>>>>>>>>> | | >>>>>>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Where service header contains, at a minimum, enough >>>>>>>>>>>>>>>> information to >>>>>>>>>>>>>> allow >>>>>>>>>>>>>>>> the packet to be propagated along the full length of >>>>>>>>>>>>>>>> the chain, and optionally, other metadata that enhances >>>>>>>>>>>>>>>> the operation of >>>>>>>>>> one >>>>>>>>>>>>>>>> or >>>>>>>>>>>> more >>>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And where "transport" could conceivably be any of, but >>>>>>>>>>>>>>>> not limited >>>>>>>>>>>>>> to: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * Ethernet >>>>>>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Also, "original" in the diagram above is not meant to >>>>>>>>>>>>>>>> imply immutability, but rather to specify the packet >>>>>>>>>>>>>>>> that is >>>>>>>>>> propagated >>>>>>>>>>>>>>>> from preceding entity to succeeding entity, prior to >>>>>>>>>>>>>>>> encapsulation. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Ron >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: nsc-bounces@ietf.org >>>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>>> Of >>>>>>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A >>>>>>>>>>>>>>>> document >>>>>>>>> will >>>>>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>>>>> encapsulation >>>>>>>>>>>> format >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> conveying the service function chain and the service >>>>>>>>>>>>>>>> function >>>>>>>>>>>>>> path, >>>>>>>>>>>>>>>> and for communicating context information between >>>>>>>>>>>>>>>> nodes >>>>>>> that >>>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and >>>>>>>>>>>>>>>> the service >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> being constructed. That is, the same encapsulation >>>>>>>>>>>>>>>> may be >>>>>>>>>> used >>>>>>>>>>>> on >>>>>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>>> construction >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>>> service. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> [SM] What does it mean by a single service-level >>>>>>>>>>>>>>>> encapsulation, >>>>>>>>>> a >>>>>>>>>>>>>> new >>>>>>>>>>>>>>>> encapsulation format >>>>>>>>>>>>>>>> or an ability to select one encapsulation >>>>>>>>>>>>>>>> format that >>>>>>>>>>>>>> fits >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>>>>>> The ability to select a specific >>>>>>>>>>>>>>>> encapsulation would be >>>>>>>>>>>> a >>>>>>>>>>>>>>>> management plane decision. >>>>>>>>>>>>>>>> There are quite a few existing encapsulation >>>>>>>>>>>>>>>> methods that >>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>>>>>> context information between service nodes. I >>>>>>> have >>>>>>>>>> seen >>>>>>>>>>>>>>>> mention >>>>>>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>>>>>> applications contexts are transferred via >>>>>>> headers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: nsc-bounces@ietf.org >>>>>>>>>>>>>>>> [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>>>>>>> Of >>>>>>>>>>>>>>>> Thomas Narten >>>>>>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It contains the revised management text as well as >>>>>>>>>>>>>>>> updated >>>>>>>>>>>>>> milestones. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> All known issues have been addressed. If there are any >>>>>>>>>>>>>>>> remaining >>>>>>>>>>>>>> issues, >>>>>>>>>>>>>>>> please speak up! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Networks, servers, storage technologies, and >>>>>>>>>>>>>>>> applications, have all undergone significant change in >>>>>>>>>>>>>>>> recent years with the introduction >>>>>>>>>>>> of >>>>>>>>>>>>>>>> virtualization, network overlays, and orchestration. >>>>>>>>>>>>>>>> Service >>>>>>>>>>>> delivery >>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> currently both a technical and organizational challenge >>>>>>>>>>>>>>>> that >>>>>>>>>>>> involves >>>>>>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>>>>>> Services are typically implemented by the ordered >>>>>>>>>>>>>>>> combination of a number of service functions that are >>>>>>>>>>>>>>>> deployed at different points within >>>>>>>>>>>> the >>>>>>>>>>>>>>>> network. Today, a common deployment model has service >>>>>>>>>>>>>>>> functions physically inserted on the data forwarding >>>>>>>>>>>>>>>> path between communicating peers. >>>>>>>>>>>>>> Going >>>>>>>>>>>>>>>> forward, however, there is a desire to move to a >>>>>>>>>>>>>>>> different model, >>>>>>>>>>>>>> where >>>>>>>>>>>>>>>> service functions are not required to reside on the >>>>>>>>>>>>>>>> default data >>>>>>>>>>>> path >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> traffic is instead steered through services, wherever >>>>>>>>>>>>>>>> they are >>>>>>>>>>>>>> deployed. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For a given service, the abstracted view of the >>>>>>>>>>>>>>>> required service functions and the order in which they >>>>>>>>>>>>>>>> are to be applied is >>>>>>>>>> called >>>>>>>>>>>>>>>> a Service Function Chain (SFC). Since a given service >>>>>>>>>>>>>>>> function may be available on more than one node within >>>>>>>>>>>>>>>> a network, a Service Function Chain is instantiated >>>>>>>>>>>>>> via >>>>>>>>>>>>>>>> the selection of specific service function instances >>>>>>>>>>>>>>>> and the network nodes on which they are provided, >>>>>>>>>>>>>>>> thereby forming a service topology: >>>>>>>>>>>>>>>> this is called a Service Function Path. The service >>>>>>>>>>>>>>>> functions >>>>>>>>>> may >>>>>>>>>>>>>>>> be applied at a specific layer within the network >>>>>>>>>>>>>>>> protocol stack >>>>>>>>>>>>>> (network >>>>>>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The Service Function Chaining (SFC) working group will >>>>>>>>>>>>>>>> develop new approaches to service delivery and deployment. >>>>>>>>>>>>>>>> It will produce a framework for service function >>>>>>>>>>>>>>>> chaining that includes the necessary protocols >>>>>>>>>>>>>> or >>>>>>>>>>>>>>>> protocol extensions to convey the service path and >>>>>>>>>>>>>>>> service path information to nodes that implement >>>>>>>>>>>>>>>> service functions, as well >>>>>>>>>> as >>>>>>>>>>>>>>>> mechanisms for steering traffic through service functions. >>>>>>>>>>>>>>>> The >>>>>>>>>>>>>> working >>>>>>>>>>>>>>>> group will also examine what information needs to be >>>>>>>>>>>>>>>> gathered from >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> network and service functions in support of service >>>>>>>>>>>>>>>> function >>>>>>>>>>>> chaining >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> how that information may be made available to nodes >>>>>>>>>>>>>>>> that implement >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> service functions. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>>>> following: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1) Problem Statement: This document will provide a >>>>>>>>>>>>>>>> summary of >>>>>>>>>> the >>>>>>>>>>>>>>>> problem space to be addressed by the WG including >>>>>>>>>>>>>>>> example >>>>>>>>>> high- >>>>>>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>>>>>> nomenclature >>>>>>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2) Architecture: This document will provide a >>>>>>>>>>>>>>>> description of >>>>>>>>> the >>>>>>>>>>>>>>>> architectural building blocks and their >>>>>>>>>>>>>>>> relationships >>>>>>>>>> including >>>>>>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>>>>>> diagnostics, design analysis, and security models, >>>>>>>>>>>>>>>> as well >>>>>>>>> as >>>>>>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A >>>>>>>>>>>>>>>> document >>>>>>>>>> will >>>>>>>>>>>>>>>> describe the single service-level data plane >>>>>>>>>>>>>>>> encapsulation >>>>>>>>>>>> format >>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>> conveying the service function chain and the service >>>>>>>>>>>>>>>> function >>>>>>>>>>>>>> path, >>>>>>>>>>>>>>>> and for communicating context information between >>>>>>>>>>>>>>>> nodes >>>>>>> that >>>>>>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>>>>>> encapsulation >>>>>>>>>>>>>>>> be agnostic to the layer at which it is applied and >>>>>>>>>>>>>>>> the service >>>>>>>>>>>>>> that >>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>> being constructed. That is, the same encapsulation >>>>>>>>>>>>>>>> may be >>>>>>>>>> used >>>>>>>>>>>> on >>>>>>>>>>>>>>>> a service function path realized at the network >>>>>>>>>>>>>>>> layer or at any other >>>>>>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>>>>>> construction >>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> service function paths regardless of the actual >>>>>>> service. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>>>> developed to >>>>>>>>>>>>>>>> describe requirements and protocols necessary to >>>>>>>>>>>>>>>> convey >>>>>>>>>>>>>> information >>>>>>>>>>>>>>>> to service function implementation points. Where >>>>>>>>>>>>>>>> possible, >>>>>>>>>>>>>> existing >>>>>>>>>>>>>>>> IETF protocols will be used and extended. All >>>>>>>>>>>>>>>> protocol >>>>>>>>>>>> extensions >>>>>>>>>>>>>>>> work should be carried out in the working groups >>>>>>>>>>>>>>>> responsible for >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>> protocols being modified in coordination with this >>>>>>>>>>>>>>>> working >>>>>>>>>>>> group, >>>>>>>>>>>>>>>> but >>>>>>>>>>>>>>>> may be done in this working group after agreement >>>>>>>>>>>>>>>> with all >>>>>>>>>> the >>>>>>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 5) Manageability: Work on the management and >>>>>>>>>>>>>>>> configuration of >>>>>>>>>>>> service >>>>>>>>>>>>>>>> functions in support of SFC components will >>>>>>>>>>>>>>>> certainly be >>>>>>>>>> needed, >>>>>>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s) >>>>>>>>>>>>>>>> defining the >>>>>>>>>>>>>> problem >>>>>>>>>>>>>>>> statement and core use cases for Service Function >>>>>>>>>>>>>>>> Chaining >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter >>>>>>>>>>>>>>>> modifications for management and configuration of SFC >>>>>>>>>>>>>>>> components >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining >>>>>>>>>>>>>>>> the >>>>>>>>>>>>>> architecture >>>>>>>>>>>>>>>> for SFC >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic >>>>>>>>>>>>>>>> service function chaining encapsulation protocol >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document >>>>>>>>>>>>>>>> specifying the >>>>>>>>>>>>>> generic >>>>>>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thomas >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>> nsc mailing list >>>>>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>> >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From mohamed.boucadair@orange.com Fri Nov 15 01:01:39 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E944811E8108 for ; Fri, 15 Nov 2013 01:01:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR8KxcYmOgVH for ; Fri, 15 Nov 2013 01:01:35 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) by ietfa.amsl.com (Postfix) with ESMTP id 49F6C11E8106 for ; Fri, 15 Nov 2013 01:01:32 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id DA3AD1B87FF; Fri, 15 Nov 2013 10:01:27 +0100 (CET) Received: from puexch31.nanterre.francetelecom.fr (unknown [10.101.44.29]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BD45C38404E; Fri, 15 Nov 2013 10:01:27 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by puexch31.nanterre.francetelecom.fr ([10.101.44.29]) with mapi; Fri, 15 Nov 2013 10:01:27 +0100 From: To: "sarikaya@ieee.org" , "Liushucheng (Will)" Date: Fri, 15 Nov 2013 10:01:25 +0100 Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: Ac7JvY2mPxAwECsZSYuzeCuh29v/GgYIpJLw Message-ID: <94C682931C08B048B7A8645303FDC9F36F3242634E@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_94C682931C08B048B7A8645303FDC9F36F3242634EPUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.14.23914 Cc: "nsc@ietf.org" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 09:01:40 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F3242634EPUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, We have added that sentence on purpose. Instantiating differentiated chains= on a per-subscriber basis is not justified given the current use cases we = have identified so far. The parental control filters are not designed for e= ach individual subscriber but are generic ones (few profiles can be enabled= in the service function providing such function). Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Behce= t Sarikaya Envoy=E9 : mardi 15 octobre 2013 17:45 =C0 : Liushucheng (Will) Cc : nsc@ietf.org Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-= 00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). 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 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_94C682931C08B048B7A8645303FDC9F36F3242634EPUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Behcet,

 

We have added that sentence on purpose. Instantiating differentiated c= hains on a per-subscriber basis is not justified given the current use case= s we have identified so far. The parental control filters are not designed = for each individual subscriber but are generic ones (few profiles can be en= abled in the service function providing such function).

 

Cheers,=

Med

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : ma= rdi 15 octobre 2013 17:45
=C0 : Liushucheng (Will)
Cc&= nbsp;: nsc@ietf.org
Objet : Re: [nsc] FW: New Version No= tification for draft-liu-sfc-use-cases-00.txt

 

Hi Shucheng,

=

In the use cases = draft, you say that

SFC are not per-subscriber.  In other word= s, this document assumes
      per-subscriber S= FCs are not instantiated in the network.
      = Deployments cases that would require per-subscriber SFCs are out
 &= nbsp;    of scope.

However you have at least three parental con= trol use cases. How would it be possible to have parental control not being= per-subscriber?

Regards,

Behcet=

 

On Fri, Oct 11, 2013 at 1:13 A= M, Liushucheng (Will) <liushucheng@huawei.com> wrote:

Folks,

We've uploaded the updated and renamed use case dra= ft. Looking forward to your comments.

Regards,
Shucheng LIU (Will= )


-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, Oc= tober 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio)= ; Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Will); Nicolai Leyman= n; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-case= s-00.txt


A new version of I-D, draft-liu-sfc-use-cases-00.txthas been successfully submitted by Will(Shucheng) Liu and posted to theIETF repository.

Filename:        draft-liu-sfc= -use-cases
Revision:        00
Title:   &nbs= p;       Service Function Chaining Use Cases
Creation dat= e:   2013-10-10
Group:           Individua= l Submission
Number of pages: 14
URL:         &nb= sp;   http://www.ietf.org/internet-drafts/draft-= liu-sfc-use-cases-00.txt
Status:          <= a href=3D"http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases" target= =3D"_blank">http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases
= Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The deliv= ery of value-added services relies on the invocation of
   adv= anced Service Functions in a sequential order.  This mechanism is
&= nbsp;  called Service Function Chaining (SFC).  The set of involv= ed Service
   Functions and their order depends on the service= context.

   This document presents a set of use cases of = Service Function
   Chaining (SFC).




Please = note that it may take a couple of minutes from the time of submission
un= til the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat=

_______________________________________________
nsc mailing list=
nsc@ietf.org
https://www.ietf.org/m= ailman/listinfo/nsc

 = ;

= --_000_94C682931C08B048B7A8645303FDC9F36F3242634EPUEXCB1Bnante_-- From mohamed.boucadair@orange.com Fri Nov 15 01:08:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD23511E8109 for ; Fri, 15 Nov 2013 01:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50sJwUGpZMqe for ; Fri, 15 Nov 2013 01:08:19 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 3795711E8108 for ; Fri, 15 Nov 2013 01:08:18 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id E5D2F2646DF; Fri, 15 Nov 2013 10:08:10 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C0EFA238056; Fri, 15 Nov 2013 10:08:10 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 15 Nov 2013 10:08:10 +0100 From: To: "sarikaya@ieee.org" , Ian Smith Date: Fri, 15 Nov 2013 10:08:09 +0100 Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: Ac7J83Z/S/j+mWpyRKKZ66QDnPgoXwX7mMag Message-ID: <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.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_94C682931C08B048B7A8645303FDC9F36F32426362PUEXCB1Bnante_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.14.54215 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Liushucheng \(Will\)" , Ron Parker Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 09:08:23 -0000 --_000_94C682931C08B048B7A8645303FDC9F36F32426362PUEXCB1Bnante_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Behcet, Which requirements document are you referring to? This one http://tools.iet= f.org/html/draft-boucadair-sfc-requirements-00? We should make a distinction between classification rules and the set of SF= Cs themselves. Classification rules may be subscriber-inferred while I'm st= ill not convinced the set of SFCs should be built on a per-subscriber basis= . Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Behce= t Sarikaya Envoy=E9 : mercredi 16 octobre 2013 00:11 =C0 : Ian Smith Cc : nsc@ietf.org; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-= 00.txt Folks, I checked and found out that in the requirements draft per-subscribe= r service issue is pretty clearly stated. My suggestion is to remove the paragraph that starts with SFC are not per-s= ubscriber. It is confusing. Regards, Behcet On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith > wrote: I'll see what I can do. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:14 PM To: Ian Smith Cc: Ron Parker; >; nsc@ietf.org= ; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Use cases from real operators would be a start. Sent from my iPhone On Oct 15, 2013, at 5:11 PM, "Ian Smith" > wrote: what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: >; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). 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 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_94C682931C08B048B7A8645303FDC9F36F32426362PUEXCB1Bnante_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Behcet,

 

Which requirements document are you referring to? This one http://tool= s.ietf.org/html/draft-boucadair-sfc-requirements-00? =

 

We sh= ould make a distinction between classification rules and the set of SFCs th= emselves. Classification rules may be subscriber-inferred while I’m s= till not convinced the set of SFCs should be built on a per-subscriber basi= s.

 

Cheers,

Med

 

De : nsc-bounces@ietf.o= rg [mailto:nsc-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : mercredi 16 octobre 2013 00:11
=C0 : Ia= n Smith
Cc : nsc@ietf.org; Jim Guichard (jguichar); Liushuch= eng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Not= ification for draft-liu-sfc-use-cases-00.txt

 

Folks, I checked and found out = that in the requirements draft per-subscriber service issue is pretty clear= ly stated.

My suggestion is to remove the paragraph that starts with SFC are n= ot per-subscriber. It is confusing.

Regards,

Behcet

 

On Tue, Oct= 15, 2013 at 4:14 PM, Ian Smith <I.Smith@f5.com> wrote:

I'll see what I can do.

Fro= m:= Jim Guichard (jguichar) [jguichar@cisco.com]

Sent:<= /span> Tu= esday, October 15, 2013 5:14 PM
To: Ian Smith
Cc: Ron P= arker; <sarikaya@= ieee.org>; nsc@iet= f.org; Liushucheng (Will)


Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-= cases-00.txt

&nb= sp;

Use cases from = real operators would be a start.

Sent from my iPhone

<= /div>


On Oct 15= , 2013, at 5:11 PM, "Ian Smith" <I.Smith@F5.com> wrote:

what do you need to make this reality driven?  =

=

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tues= day, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarikaya@ieee.org&= gt;; nsc@ietf.org; Li= ushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version No= tification for draft-liu-sfc-use-cases-00.txt

Sure but we should deal in reality driven by u= se cases and I have yet to see anyone suggest they will build an individual= service chain for every client. In fact the complete opposite seems true.<= br>
Sent from my iPhone


On Oct 15, 2013, at 4:52 PM, "Ron Par= ker" <Ron_Parker@affirmednetworks.com> wrote:

=

Agree that is the typical usage of policy.   And, the deg= enerate case is that the world is comprised of subscriber groups that have = exactly 1 subscriber.   Probably not practical, but why prevent i= t?

 

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

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf= Of Jim Guichard (jguichar)
Sent: Tuesday, October 15, 2013 4= :48 PM
To: <sarikaya@ieee.org>
Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith
S= ubject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-ca= ses-00.txt

 

No, to me this is most certainly a per-subscriber-group.

Se= nt from my iPhone


On Oct 15, 2013, at 4:45 PM= , "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

 I was talking about something like parental control.

Do you qualify such an SFC as each mobile client getting = its own SFC?

I think it is more like per-subscriber-gr= oup. It could be per subscriber as well but I can not think of an example a= t this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) <jguichar@cisco.com>= ; wrote:

Hi Ian,<= /p>

If by subscriber you mean per-tenant or per-subscriber= -group then I will agree that SFC's will be built for these but that's a fa= r cry from per-subscriber which implies to me an individual broadband or mo= bile client.

Sent from my iPhone

=


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you co= mbine what is being done in IaaS environments for muti-tenant dynamic datac= enters with what you can do with policy defined networking and IPv6, for an= access provider to provision per-subscriber VAS LANs and default gateways = takes away a lot of the big problems caused by aggregation that you're tryi= ng to solve with service chains.  More to the point, you don't need to= disaggregate anything when you know that all the traffic belongs to a sing= le customer, and that the default gateway of each node is the next hop in t= he service chain.  Solving the problem for 1 subscriber@1Gbps is trivi= al; what makes what we're talking about in this list hard is that you are t= rying to solve it for 10 million subscribers @100Gbps but in truth the only= technology-based reason you do that is because of administrative challenge= s that the cloud world is solving (and may have solved before anything is p= roduced in a WG) and that are squarely in the domain of things already prov= en to be better done by computers than people.

I tend to argue that = per-subscriber provisioning of the access path triggered by identity-based = authentication is the obvious and natural evolution of the technology being= fielded today.

 

From: nsc-bounces@ietf.org= [nsc-bounces= @ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: T= uesday, October 15, 2013 1:34 PM
To: sarikaya@ieee.org; Liushucheng (Will)
= Cc: nsc@ietf.org<= br>Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc= -use-cases-00.txt

It seems very= unlikely that one would opt for a solution whereby a separate SFC is requi= red per-subscriber; clearly millions of SFC's is not desirable no matter ho= w you cut it. IMHO, the support of services that require per-subscriber pol= icy are more likely to be realized using something like the solution descri= bed in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>=
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, Octob= er 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.c= om>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version N= otification for draft-liu-sfc-use-cases-00.txt

<= div>

 

H= i Shucheng,

In the use cases draft, you say that
<= br>SFC are not per-subscriber.  In other words, this document assumes<= br>      per-subscriber SFCs are not instantiated = in the network.
      Deployments cases that wo= uld require per-subscriber SFCs are out
      o= f scope.

However you have at least three parental cont= rol use cases. How would it be possible to have parental control not being = per-subscriber?

Regards,

B= ehcet

 

On Fri, Oc= t 11, 2013 at 1:13 AM, Liushucheng (Will) <liushucheng@huawei.com> wrote:

Folks,

We've uploaded the updated and r= enamed use case draft. Looking forward to your comments.

Regards,Shucheng LIU (Will)


-----Original Message-----
From: internet-drafts@ietf= .org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 = PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver)= ; Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subje= ct: New Version Notification for draft-liu-sfc-use-cases-00.txt


= A new version of I-D, draft-liu-sfc-use-cases-00.txt
has been successful= ly submitted by Will(Shucheng) Liu and posted to the
IETF repository.
Filename:        draft-liu-sfc-use-cases
Revisi= on:        00
Title:         &nb= sp; Service Function Chaining Use Cases
Creation date:   2013-10-10=
Group:           Individual Submission
Numb= er of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-= 00.txt
Status:          http://d= atatracker.ietf.org/doc/draft-liu-sfc-use-cases
Htmlized:   &nb= sp;    http://tools.ietf.org/html/draft-liu-sfc-use-case= s-00


Abstract:
   The delivery of value-added s= ervices relies on the invocation of
   advanced Service Functi= ons in a sequential order.  This mechanism is
   called S= ervice Function Chaining (SFC).  The set of involved Service
 =  Functions and their order depends on the service context.

&nb= sp;  This document presents a set of use cases of Service Function
=    Chaining (SFC).




Please note that it may tak= e a couple of minutes from the time of submission
until the htmlized ver= sion and diff are available at tools.ietf.org.

The IETF Secretariat

____________= ___________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mai= lman/listinfo/nsc

 

=

 

 

= --_000_94C682931C08B048B7A8645303FDC9F36F32426362PUEXCB1Bnante_-- From mohamed.boucadair@orange.com Fri Nov 15 01:22:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDAC11E810D for ; Fri, 15 Nov 2013 01:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTMJUlmkTJVA for ; Fri, 15 Nov 2013 01:22:33 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id AFF8311E810A for ; Fri, 15 Nov 2013 01:22:23 -0800 (PST) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 1F8A63B4140; Fri, 15 Nov 2013 10:22:13 +0100 (CET) Received: from PUEXCH71.nanterre.francetelecom.fr (unknown [10.101.44.33]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 05AC527C069; Fri, 15 Nov 2013 10:22:13 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.12]) by PUEXCH71.nanterre.francetelecom.fr ([10.101.44.33]) with mapi; Fri, 15 Nov 2013 10:22:12 +0100 From: To: "Joel M. Halpern" Date: Fri, 15 Nov 2013 10:22:10 +0100 Thread-Topic: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) Thread-Index: Ac7EQAfsHQLvkyaGTJCnVAu5hYF7PQdo08Lw Message-ID: <94C682931C08B048B7A8645303FDC9F36F32426383@PUEXCB1B.nanterre.francetelecom.fr> References: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> <52542CFB.1020301@joelhalpern.com> In-Reply-To: <52542CFB.1020301@joelhalpern.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.15.22114 Cc: "nsc@ietf.org" Subject: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 09:22:38 -0000 Hi Joel, Thanks for the feedback.=20 The point of that analysis text is to assess whether there are cases where = conveying a subscriber-id is needed to be carried as part of the SFC header= . The examples are there to illustrate particular cases and are not intende= d to be exhaustive.=20 Over-specifying the solution will make things more complex than the problem= we are trying to solve. Cheers, Med >-----Message d'origine----- >De=A0: Joel M. Halpern [mailto:jmh@joelhalpern.com] >Envoy=E9=A0: mardi 8 octobre 2013 18:04 >=C0=A0: BOUCADAIR Mohamed IMT/OLN >Cc=A0: nsc@ietf.org >Objet=A0: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter >bullet #3) > >I find that text extremely biased and centered on particular problems. > >Having said that, I agree that we should not have a mandatory field for >subscriber ID in the header. I never suggested that we have such a >mandatory field. Rather, I was pointing out that one of the uses of >metadata (and there are many) is to carry subscriber ID. > >I would not want the architecture or protocol to mandate exactly what >metadata is carried in the header, since different situations will need >different metadata. > >Yours, >Joel > >On 10/8/13 5:27 AM, mohamed.boucadair@orange.com wrote: >> Hi Joel, all, >> >> We updated the section that discuss subscriber-id consideration in the >sfc analysis draft. The text is available at: >https://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-00#section= - >4.1. >> >> Comments and additions to that text are welcome. >> >> Cheers, >> Med >> >>> -----Message d'origine----- >>> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de >Joel >>> M. Halpern >>> Envoy=E9 : mercredi 25 septembre 2013 09:24 >>> =C0 : Linda Dunbar >>> Cc : nsc@ietf.org; adrian@olddog.co.uk >>> Objet : Re: [nsc] New NSC WG Charter - charter bullet #3 >>> >>> For me, the canonical example of metadata applies to the use case of a >>> service chain providing residential gateway functionality with network >>> resident NAT. >>> If the operator is choosing, due to IPv4 exhaustion, to resuse IP >>> addresses across subscribers, then some field is needed to identify the >>> subscriber in the service chain. >>> In a classic BNG, the physical port, VLAN, or incoming MAC address >>> provides this function. But those will all be lost in the service >chain. >>> >>> I have also seen cases where DPI service engines are separate entities >>> in the chain from services which need the results of the DPI. That >>> seems a natural candidate for metadata. >>> >>> Yours, >>> Joel >>> >>> On 9/24/13 7:02 PM, Linda Dunbar wrote: >>>> Adrian, >>>> >>>> Very good analysis. Thank you. >>>> >>>> "Metadata" has been used extensively in the NSC context. But beyond th= e >>> "service chain ID", I can't find any other necessary information >required >>> to be exchanged among the "Service Functions" in all the use cases >>> presented at the Berlin informal BoF and use cases drafts. Can anyone >give >>> some examples of the information required to be exchanged among those >>> "Service Functions" given by the draft-quinn-nsc-arch-00? >>>> >>>> A non-exhaustive list of Service Functions includes: firewalls, >>>> WAN and application acceleration, Deep Packet Inspection (DPI), >>>> server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID >>>> injection, HTTP Header Enrichment functions, TCP optimizer, etc. >>>> >>>> >>>> Thanks, Linda >>>> >>>>> -----Original Message----- >>>>> >>>>> I think "metadata" is a particularly poor term to use here because it >>>>> actually >>>>> directly means "additional data attached to something specific". So, >it >>>>> is >>>>> metadata when you put it in the encapsulation header on a packet, but >>>>> if it is >>>>> out of band, it is what it is. >>>>> >>>>> So, let's look at what you might be talking about for "metadata": >>>>> - The details of the service chain itself (e.g. the service path) >>>>> - Information that one service node wants to communicate with >>>>> another service node (e.g. about how to perform given some >>>>> state information) >>>>> >>>>> We should also look at what you mean by out-of-band. I think here you >>>>> mean >>>>> "using some information exchange protocol." >>>> >>>> [Linda] Since each Service-Chain ID represents a list of service >>> functions, it is possible to use "out-of-band" control channel to pass >the >>> information on the sequence of Service Functions associated with the ID= . >>>> >>>> >>>>> >>>>> The charter says: >>>>> >>>>> | The Service Function Chaining (SFC) working group will develop >>>>> | new approaches to service delivery and deployment, by >>>>> | providing a framework for service function chaining and the >>>>> | necessary protocols or protocol extensions to convey the >>>>> | service path and for communication between nodes that >>>>> | implement service functions >>>>> >>>>> and: >>>>> >>>>> | 4) Control Plane Mechanisms: A set of documents will be >>>>> | developed to describe requirements and protocols necessary >>>>> | to convey information to service function implementation >>>>> | points. Where possible, existing IETF protocols will be used >>>>> | and extended. >>>>> >>>>> This feels like out-of-band exchange of information is expected. >>>>> >>>>> Adrian >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> From jmh@joelhalpern.com Fri Nov 15 01:27:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA83011E8108 for ; Fri, 15 Nov 2013 01:27:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC4q7NTGl-eU for ; Fri, 15 Nov 2013 01:27:09 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 4D09111E8102 for ; Fri, 15 Nov 2013 01:27:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 41BE31BC547E; Fri, 15 Nov 2013 01:27:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [192.165.183.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 6FD3C1BC546F; Fri, 15 Nov 2013 01:27:08 -0800 (PST) Message-ID: <5285E8EA.9040700@joelhalpern.com> Date: Fri, 15 Nov 2013 04:27:06 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> <52542CFB.1020301@joelhalpern.com> <94C682931C08B048B7A8645303FDC9F36F32426383@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F32426383@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" Subject: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 09:27:14 -0000 If the point of the text is to say that some service chains in some environments may need subscriber ID, but others will not, then just say that. The current text tries to argue about how common it is, when that is not as far as I can tell an important part of the question. You could then follow it with the observation that there are a range of requirements for different metadata in different circumstances, and that we need define how this is carried without mandating specific information in every packet, since the use cases are varied. None of that would be over-specifying the solution. And it would avoid getting into prejudicial text about different problems in different environments. Yours, Joel On 11/15/13 4:22 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, > > Thanks for the feedback. > > The point of that analysis text is to assess whether there are cases > where conveying a subscriber-id is needed to be carried as part of > the SFC header. The examples are there to illustrate particular cases > and are not intended to be exhaustive. > > Over-specifying the solution will make things more complex than the > problem we are trying to solve. > > Cheers, Med > >> -----Message d'origine----- De : Joel M. Halpern >> [mailto:jmh@joelhalpern.com] Envoyé : mardi 8 octobre 2013 18:04 À >> : BOUCADAIR Mohamed IMT/OLN Cc : nsc@ietf.org Objet : Re: [nsc] On >> subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) >> >> I find that text extremely biased and centered on particular >> problems. >> >> Having said that, I agree that we should not have a mandatory field >> for subscriber ID in the header. I never suggested that we have >> such a mandatory field. Rather, I was pointing out that one of the >> uses of metadata (and there are many) is to carry subscriber ID. >> >> I would not want the architecture or protocol to mandate exactly >> what metadata is carried in the header, since different situations >> will need different metadata. >> >> Yours, Joel >> >> On 10/8/13 5:27 AM, mohamed.boucadair@orange.com wrote: >>> Hi Joel, all, >>> >>> We updated the section that discuss subscriber-id consideration >>> in the >> sfc analysis draft. The text is available at: >> https://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-00#section- >> >> 4.1. >>> >>> Comments and additions to that text are welcome. >>> >>> Cheers, Med >>> >>>> -----Message d'origine----- De : nsc-bounces@ietf.org >>>> [mailto:nsc-bounces@ietf.org] De la part de >> Joel >>>> M. Halpern Envoyé : mercredi 25 septembre 2013 09:24 À : Linda >>>> Dunbar Cc : nsc@ietf.org; adrian@olddog.co.uk Objet : Re: [nsc] >>>> New NSC WG Charter - charter bullet #3 >>>> >>>> For me, the canonical example of metadata applies to the use >>>> case of a service chain providing residential gateway >>>> functionality with network resident NAT. If the operator is >>>> choosing, due to IPv4 exhaustion, to resuse IP addresses across >>>> subscribers, then some field is needed to identify the >>>> subscriber in the service chain. In a classic BNG, the physical >>>> port, VLAN, or incoming MAC address provides this function. >>>> But those will all be lost in the service >> chain. >>>> >>>> I have also seen cases where DPI service engines are separate >>>> entities in the chain from services which need the results of >>>> the DPI. That seems a natural candidate for metadata. >>>> >>>> Yours, Joel >>>> >>>> On 9/24/13 7:02 PM, Linda Dunbar wrote: >>>>> Adrian, >>>>> >>>>> Very good analysis. Thank you. >>>>> >>>>> "Metadata" has been used extensively in the NSC context. But >>>>> beyond the >>>> "service chain ID", I can't find any other necessary >>>> information >> required >>>> to be exchanged among the "Service Functions" in all the use >>>> cases presented at the Berlin informal BoF and use cases >>>> drafts. Can anyone >> give >>>> some examples of the information required to be exchanged among >>>> those "Service Functions" given by the >>>> draft-quinn-nsc-arch-00? >>>>> >>>>> A non-exhaustive list of Service Functions includes: >>>>> firewalls, WAN and application acceleration, Deep Packet >>>>> Inspection (DPI), server load balancers, NAT44 [RFC3022], >>>>> NAT64 [RFC6146], HOST_ID injection, HTTP Header Enrichment >>>>> functions, TCP optimizer, etc. >>>>> >>>>> >>>>> Thanks, Linda >>>>> >>>>>> -----Original Message----- >>>>>> >>>>>> I think "metadata" is a particularly poor term to use here >>>>>> because it actually directly means "additional data >>>>>> attached to something specific". So, >> it >>>>>> is metadata when you put it in the encapsulation header on >>>>>> a packet, but if it is out of band, it is what it is. >>>>>> >>>>>> So, let's look at what you might be talking about for >>>>>> "metadata": - The details of the service chain itself (e.g. >>>>>> the service path) - Information that one service node wants >>>>>> to communicate with another service node (e.g. about how to >>>>>> perform given some state information) >>>>>> >>>>>> We should also look at what you mean by out-of-band. I >>>>>> think here you mean "using some information exchange >>>>>> protocol." >>>>> >>>>> [Linda] Since each Service-Chain ID represents a list of >>>>> service >>>> functions, it is possible to use "out-of-band" control channel >>>> to pass >> the >>>> information on the sequence of Service Functions associated >>>> with the ID. >>>>> >>>>> >>>>>> >>>>>> The charter says: >>>>>> >>>>>> | The Service Function Chaining (SFC) working group will >>>>>> develop | new approaches to service delivery and >>>>>> deployment, by | providing a framework for service function >>>>>> chaining and the | necessary protocols or protocol >>>>>> extensions to convey the | service path and for >>>>>> communication between nodes that | implement service >>>>>> functions >>>>>> >>>>>> and: >>>>>> >>>>>> | 4) Control Plane Mechanisms: A set of documents will be | >>>>>> developed to describe requirements and protocols necessary >>>>>> | to convey information to service function implementation >>>>>> | points. Where possible, existing IETF protocols will be >>>>>> used | and extended. >>>>>> >>>>>> This feels like out-of-band exchange of information is >>>>>> expected. >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ nsc mailing >>>>> list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>>>> >>>> _______________________________________________ nsc mailing >>>> list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ nsc mailing list >>> nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc >>> > From Ron_Parker@affirmednetworks.com Fri Nov 15 05:06:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4882A11E80F9 for ; Fri, 15 Nov 2013 05:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJCnyQHta-c9 for ; Fri, 15 Nov 2013 05:05:56 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 26E9711E80F1 for ; Fri, 15 Nov 2013 05:05:56 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Fri, 15 Nov 2013 05:05:55 -0800 From: Ron Parker To: "mohamed.boucadair@orange.com" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: Ac7J83Z/S/j+mWpyRKKZ66QDnPgoXwX7mMagAAhkX8U= Date: Fri, 15 Nov 2013 13:05:55 +0000 Message-ID: <208B1585-D203-453B-BC61-46B9C32B8FB0@affirmednetworks.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> , <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_208B1585D203453BBC6146B9C32B8FB0affirmednetworkscom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 13:06:00 -0000 --_000_208B1585D203453BBC6146B9C32B8FB0affirmednetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In subscriber-based networks, the classification rules will generally be ap= plied to groups of subscribers. Of course, the degenerate case is each is = a group of one. Ron On Nov 15, 2013, at 4:08 AM, "mohamed.boucadair@orange.com" > wrote: Hi Behcet, Which requirements document are you referring to? This one http://tools.iet= f.org/html/draft-boucadair-sfc-requirements-00? We should make a distinction between classification rules and the set of SF= Cs themselves. Classification rules may be subscriber-inferred while I=92m = still not convinced the set of SFCs should be built on a per-subscriber bas= is. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Behcet Sarikaya Envoy=E9 : mercredi 16 octobre 2013 00:11 =C0 : Ian Smith Cc : nsc@ietf.org; Jim Guichard (jguichar); Liushuchen= g (Will); Ron Parker Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-= 00.txt Folks, I checked and found out that in the requirements draft per-subscribe= r service issue is pretty clearly stated. My suggestion is to remove the paragraph that starts with SFC are not per-s= ubscriber. It is confusing. Regards, Behcet On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith > wrote: I'll see what I can do. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:14 PM To: Ian Smith Cc: Ron Parker; >; nsc@ietf.org= ; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Use cases from real operators would be a start. Sent from my iPhone On Oct 15, 2013, at 5:11 PM, "Ian Smith" > wrote: what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: >; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). 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 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_208B1585D203453BBC6146B9C32B8FB0affirmednetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In subscriber-based networks, the classification rules will generally = be applied to groups of subscribers.  Of course, the degenerate case i= s each is a group of one. 

    Ron


On Nov 15, 2013, at 4:08 AM, "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com> wrote:

Hi Behcet,

 

Which requirements document are you referrin= g to? This one = http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00?

 

We should make a distinction between classif= ication rules and the set of SFCs themselves. Classification rules may be s= ubscriber-inferred while I=92m still not convinced the set of SFCs should be built on a per-subscriber basis.

 

Cheers,

Med

 

De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : mercredi 16 octobre 2013 00:11
=C0 : Ian Smith
Cc : nsc@ietf.org; Jim Guic= hard (jguichar); Liushucheng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sf= c-use-cases-00.txt

 

Folks, I checked and = found out that in the requirements draft per-subscriber service issue is pr= etty clearly stated.

My suggestion is to r= emove the paragraph that starts with SFC are not per-subscriber. It is conf= using.

Regards,

Behcet

 

On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith <I.Smith@f5.com> wrote= :

I'll see = what I can do.

From: Jim Guichard (jgui= char) [jguichar@cis= co.com]

Sent: Tuesday, October 1= 5, 2013 5:14 PM
To: Ian Smith
Cc: Ron Parker; <sarikaya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will)


Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Use cases from real operators would be a start.

Sent from my iPhone


On Oct 15, 2013, at 5:11 PM, "Ian Smith" <I.Smith@F5.com> wrote:

what do you need to make this reality dr= iven? 

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarik= aya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cas= es and I have yet to see anyone suggest they will build an individual servi= ce chain for every client. In fact the complete opposite seems true.

Sent from my iPhone


On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typical usage of poli= cy.   And, the degenerate case is that the world is comprised of subscriber groups that have exactly 1 subscriber.   Probably = not practical, but why prevent it?

 

   Ron

 

 

No, to me this is most certainly a per-subscriber-group.

Sent from my iPhone

 I was talking about something like parental control.

Do you qualify such an SFC as each mobile client getting its own SFC?

I think it is more like per-subscriber-group. It could be per subscriber= as well but I can not think of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) <jguichar@cisco.com&g= t; wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscriber-group then = I will agree that SFC's will be built for these but that's a far cry from p= er-subscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a= separate SFC is required per-subscriber; clearly millions of SFC's is not = desirable no matter how you cut it. IMHO, the support of services that require per-subscriber policy are more = likely to be realized using something like the solution described in draft-= quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at least three parental control use cases. How would it= be possible to have parental control not being per-subscriber?<= /p>

Regards,

Behcet

 

On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) <liushucheng@huawei.com> wrote:

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


A new version of I-D, draft-liu-sfc-use-cases-00.txt
has been successfully submitted by Will(Shucheng) Liu and posted to the
IETF repository.

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

   This document presents a set of use cases of Service Function<= br>    Chaining (SFC).




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

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

 

 

 

--_000_208B1585D203453BBC6146B9C32B8FB0affirmednetworkscom_-- From david.i.allan@ericsson.com Tue Nov 12 11:02:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E792711E810A for ; Tue, 12 Nov 2013 11:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[AWL=1.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsMvcYo2dENa for ; Tue, 12 Nov 2013 11:02:24 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2662521E8091 for ; Tue, 12 Nov 2013 11:02:18 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-64-52827b375400 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id E4.89.23183.73B72825; Tue, 12 Nov 2013 20:02:16 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 14:02:14 -0500 From: David Allan I To: "David Lake (dlake)" , "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] re classification & branching, was: Current Proposed SFC charter Thread-Index: Ac7f2KeWg1SLf0gOR960WR3lW1TU5w== Date: Tue, 12 Nov 2013 19:02:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPgq5FdVOQwa3znBYfv+RbbJiyhM1i 6Tx1izdTb7Nb3G2ZyGRxom8qi8XxffvZLC48ncpsMWlGP5vF0+/H2R24PF5cecbs8XDbbEaP Kb83snosmb+XyaPlyFsga8lPJo9z1/qYA9ijuGxSUnMyy1KL9O0SuDLufxQpmLicqeLgl9nM DYyHnzF2MXJySAiYSKz6doEFwhaTuHBvPVsXIxeHkMARRoml0y8zQTjLGSWer/jPClLFJmAg sef/F0aQhIjAHiaJqXeOg41iFsiU+Lf7AFiRsECoxIU/G5lBbBGBMImtB9ezQth6Eqfe/ANb xyKgKrF47QIwm1fAV+LC6W1gcxiBzvh+ag0TxExxiVtP5jNBnCcgsWTPeWYIW1Ti5eN/rBC2 ssSSJ/tZIOp1JBbs/sQGYWtLLFv4mhlivqDEyZlPWCYwisxCMnYWkpZZSFpmIWlZwMiyipGj tDi1LDfdyGATIzDyjkmw6e5g3PPS8hCjNAeLkjjvl7fOQUIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYs2oCooV2T7Xc9Pv/htjFBvefccz5LzbJnZMzZr9kfw6fyAPtN+HvzuRIZK+PkF3e tKQpS2nn0+bZRp6vXtYcK0ieNP/f+c0f1CeUHJt/JdfF9OWSp3InAjaH78gL41v7/+3UotAH K0yPncmdlrO/p/JghpbBjgRfzUbnJZcZ1dbNkZBfllZ1TomlOCPRUIu5qDgRABa9hT+KAgAA X-Mailman-Approved-At: Fri, 15 Nov 2013 08:21:07 -0800 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] re classification & branching, was: Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:02:32 -0000 Hi: I agree we are discussing multiple concepts, classification and flow-subset= ting. Perhaps more ;-) Defining a flow subset can be a result of classification, but it is not the= exclusive mechanism. Branching is a mechanism by which flow subsets are ex= posed and mapped to a set of subchains such that it can be identified in th= e dataplane... That's the view from here Dave -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Lake (dlake) Sent: Tuesday, November 12, 2013 10:51 AM To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Park= er; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Understood - maybe just a little localised warming of the sea then ? But = I still think we need to consider where and how policy is defined/set even = for the single-domain instance. I don't think we can assume that any L1-3 device will be able to determine = much useful information from the data-plane. -----Original Message----- From: Jim Guichard (jguichar) Sent: 12 November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter As discussed during the BOF our initial work is single administrative domai= n for some of the very reasons you point out. We need to keep focused witho= ut trying to boil the ocean right off the bat. On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >Exactly. But how can network-components "terminate" an application ???? > >I think we need a good understanding of a recursive policy mechanism=20 >(recursive because a user-land application will ride with a specific=20 >policy across potentially different sets of carrier policies). > >I hate to bring this up now, but we also need to think about this=20 >multi-domain issue - if I set a policy as a user, chances are I will be=20 >crossing several domain boundaries. Are we expecting the service=20 >headers to define the service chaining for the duration of the entire=20 >flow across all domains, or just across a single one ? > >In which case, do I have to re-set policy as I traverse domains and >where does that policy get set ? It would be much better to set policy >once based on L5-7 needs, and have that instantiated across the=20 >multiple domains. > >Again, this appears to be outside the scope of SFC, but pretty relevant=20 >to how it would operate in the real world. > >David > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: 12 November 2013 10:27 >To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? > >I would certainly hope not, but that has been my concern as well. >Application layer termination and re-classification seems a must? > >-- Kevin J. Ma > >> -----Original Message----- >> From: David Lake (dlake) [mailto:dlake@cisco.com] >> Sent: Tuesday, November 12, 2013 1:00 PM >> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >> Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Policy may be outside of the scope of SFC, but without strong mapping=20 >> between Policy and the inserted Service Header(s), we run-the-risk of=20 >> limiting the efficacy of the protocol IMO. >> >> For example, in a world where the network has "gone dark," (as per=20 >> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >> policy based on DPI of packets-in-flight ? >> >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? >> >> David >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Surendra Kumar (smkumar) >> Sent: 12 November 2013 09:26 >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to=20 >> redefine it - it's been around for all the time middle boxes have=20 >> been or for that matter the L2/L3 devices. All we are talking about=20 >> is the applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a=20 >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> >Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a=20 >> > reclassification point, or are you saying that a branching point "does= not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a=20 >> > chain is different than I originally inferred. If the chain is a=20 >> > tree with other "branching" points in it, then that limits the=20 >> > scope of the problem statement goals. >> > >> > While this could be a degenerate case, and any implementation=20 >> > could define bad service chains, is it the intent of SFC to only=20 >> > look at the simpler packet-level classification cases, or is it the=20 >> > intent to consider the case where a branching point is viewed as a=20 >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> Sumandra Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification,= =20 >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be=20 >> >> in a form of logic on a service function. Some service functions,=20 >> >> especially L7 based, can use value in a Database to determine what=20 >> >> is the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the >> >> > re- classification point, probably we shall not limit it to DPI. >> >> > It is also possible that packets go to different branches after=20 >> >> > been processed by a certain service function, decision of which=20 >> >> > branches to go is made based on the result of service function's=20 >> >> > process, i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details=20 >> >> > around how to convey the selection of the subtree/subgraph are=20 >> >> > still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and=20 >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question=20 >> >> > > about service header encapsulation, is it intended that a=20 >> >> > > chain that is re-classified will get a new chain ID which=20 >> >> > > fully describes a chain that is a superset of the original=20 >> >> > > chain ID, prior to DPI-based re-classification? (assuming the=20 >> >> > > goal is "a single chain ID that is commonly understood along=20 >> >> > > the entire service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >> >> > > ) >> >> > > >> >> > > And the applicable subset of the permutative list of service=20 >> >> > > paths would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >> >> > > every flow then be initially classified as ID 1, but=20 >> >> > > eventually get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma"=20 >> >> > >>> >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service=20 >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification=20 >> >> > >>> that can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the=20 >> >> > >>> stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the=20 >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? >> >> > >>> If, on the other hand, the service function scope is limited=20 >> >> > >>> due to limitations in classification, that would be and=20 >> >> > >>> important piece of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >> >> > >>> fork points of the service paths seem like re-classification >> points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of=20 >> >> > >>> DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as=20 >> >> > >> described in the arch draft, the collection of services form=20 >> >> > >> a graph, segments of which are service paths. Yes,=20 >> >> > >> reclassification can >> >> > change >> >> > >> the service path and re-classification may happen at any node=20 >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >> >> > >>>> can be based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental=20 >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is=20 >> >> > >>>> that such classification aids in traffic selection and=20 >> >> > >>>> service path identification. >> >> > >>>> It is no different from a policy in this regard except that=20 >> >> > >>>> the policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network=20 >> >> > >>>> elements but the service functions as well. Some of this is=20 >> >> > >>>> described in the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > >>>>> >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >> >> > >>>>> section >> >> > >>>>> 2 of the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >> >> > >>>>> occurs at >> >> > each >> >> > >>>>> service, independent from previously applied=20 >> >> > >>>>> service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume=20 >> >> > >>>>> resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service=20 >> >> > >>>>> function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 >> >> > >>>>> the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets=20 >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such=20 >> >> > >>>>> as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID,=20 >> >> > >>>>> source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework=20 >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service=20 >> >> > >>>>> function identifier lookup does not seem to be a=20 >> >> > >>>>> significant optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >> >> > >>>>> missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >> >> > >>>>> TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >> >> > >>>>> also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified=20 >> >> > >>>>> and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to=20 >> >> > >>>>>> ensuring these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for=20 >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its=20 >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one=20 >> >> > >>>>>> more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >> >> > >>>>>>>> follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of=20 >> >> > >>>>>> the same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header=20 >> >> > >>>>>> or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow=20 >> >> > >>>>>> for operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >> >> > >>>>>> the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service=20 >> >> > >>>>>> chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which=20 >> >> > >>>>>> can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to=20 >> >> > >>>>>> identify chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >> >> > >>>>>> SF or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP=20 >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough=20 >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the=20 >> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >> >> > >>>>>> not limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >> >> > >>>>>> imply immutability, but rather to specify the packet that=20 >> >> > >>>>>> is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >>will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level=20 >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation=20 >> >> > >>>>>> format that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation=20 >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation=20 >> >> > >>>>>> methods that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as=20 >> >> > >>>>>> updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any=20 >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and=20 >> >> > >>>>>> applications, have all undergone significant change in=20 >> >> > >>>>>> recent years with the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. >> >> > >>>>>> Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge=20 >> >> > >>>>>> that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered=20 >> >> > >>>>>> combination of a number of service functions that are=20 >> >> > >>>>>> deployed at different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service=20 >> >> > >>>>>> functions physically inserted on the data forwarding path=20 >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a=20 >> >> > >>>>>> different model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the=20 >> >> > >>>>>> default data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever=20 >> >> > >>>>>> they are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required=20 >> >> > >>>>>> service functions and the order in which they are to be=20 >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >> >> > >>>>>> function may be available on more than one node within a=20 >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and=20 >> >> > >>>>>> the network nodes on which they are provided, thereby=20 >> >> > >>>>>> forming a service topology: >> >> > >>>>>> this is called a Service Function Path. The service=20 >> >> > >>>>>> functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network=20 >> >> > >>>>>> protocol stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >> >> > >>>>>> develop new approaches to service delivery and deployment. >> >> > >>>>>> It will produce a framework for service function chaining=20 >> >> > >>>>>> that includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and=20 >> >> > >>>>>> service path information to nodes that implement service=20 >> >> > >>>>>> functions, as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be=20 >> >> > >>>>>> gathered from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service=20 >> >> > >>>>>> function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that=20 >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >> >> > >>>>>> summary of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including=20 >> >> > >>>>>> example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description=20 >> >> > >>>>>> of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >> >> > >>>>>> well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to=20 >> >> > >>>>>> convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where=20 >> >> > >>>>>> possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups=20 >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this=20 >> >> > >>>>>> working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with=20 >> >> > >>>>>> all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and=20 >> >> > >>>>>> configuration of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly=20 >> >> > >>>>>> be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >> >> > >>>>>> defining the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function=20 >> >> > >>>>>> Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >> >> > >>>>>> modifications for management and configuration of SFC=20 >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >> >> > >>>>>> the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >> >> > >>>>>> service function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >> >> > >>>>>> specifying the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From ddolson@sandvine.com Tue Nov 12 11:48:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58BC21F9F8E for ; Tue, 12 Nov 2013 11:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eReptqou-epM for ; Tue, 12 Nov 2013 11:48:14 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 99EB211E814D for ; Tue, 12 Nov 2013 11:48:11 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exch-2.sandvine.com ([::1]) with mapi id 14.01.0339.001; Tue, 12 Nov 2013 14:48:10 -0500 From: Dave Dolson To: "Jim Guichard (jguichar)" , "David Lake (dlake)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN70rnuyF38+0WKON28dGBA/5ohDc2AgAAOHICAACcIgIAAAa2AgAACJICAAAHCAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGiAIAAA3SAgAAm0YCAABXAAIAABCEAgAABcQCAABmvgIAACYeAgAAHuQCAAAKLAIAAAjuAgAAB1oCAAALAAP//ts3A Date: Tue, 12 Nov 2013 19:48:09 +0000 Message-ID: References: <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Nov 2013 08:21:07 -0800 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:48:18 -0000 I think there is great simplicity to be had by limiting the path selection = to the ingress node (i.e., the one who first puts the SFC header on). I believe this because of the requirement of many layer4-7 devices to see s= ymmetric paths. (e.g., {DPI2, NAT7, ContentControl11} on the way out and {C= ontentControll11, NAT7, DPI2} on the way back) I think it will be really hard to manage this if each device in the chain c= an select an arbitrary (policy-selected) next-hop. I think each packet's ne= xt hop and ID needs to determined by the received ID. Otherwise, I'm curious how others see the symmetric path problem being mana= ged? (Apologies if I'm mangling the terminology) David Dolson Software Architect, Sandvine Inc. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Tuesday, November 12, 2013 2:01 PM To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter The assumption is that classification may be performed at the network and/or application layer and that classification will be based on policy of some description. When we work through control plane aspects of the SFC charter presumably what policy needs to be generated and by what to where is part of the work item. Further, branching will occur because of a reclassification but reclassification may or may not force a branch from one chain to another. On 11/12/13 1:51 PM, "David Lake (dlake)" wrote: >Understood - maybe just a little localised warming of the sea then ? >But I still think we need to consider where and how policy is defined/set >even for the single-domain instance. > >I don't think we can assume that any L1-3 device will be able to >determine much useful information from the data-plane. > >-----Original Message----- >From: Jim Guichard (jguichar) >Sent: 12 November 2013 10:44 >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; >Linda Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: Re: [nsc] Current Proposed SFC charter > >As discussed during the BOF our initial work is single administrative >domain for some of the very reasons you point out. We need to keep >focused without trying to boil the ocean right off the bat. > >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: > >>Exactly. But how can network-components "terminate" an application ???? >> >>I think we need a good understanding of a recursive policy mechanism >>(recursive because a user-land application will ride with a specific >>policy across potentially different sets of carrier policies). >> >>I hate to bring this up now, but we also need to think about this >>multi-domain issue - if I set a policy as a user, chances are I will be >>crossing several domain boundaries. Are we expecting the service >>headers to define the service chaining for the duration of the entire >>flow across all domains, or just across a single one ? >> >>In which case, do I have to re-set policy as I traverse domains and >>where does that policy get set ? It would be much better to set policy >>once based on L5-7 needs, and have that instantiated across the >>multiple domains. >> >>Again, this appears to be outside the scope of SFC, but pretty relevant >>to how it would operate in the real world. >> >>David >> >>-----Original Message----- >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>Sent: 12 November 2013 10:27 >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda >>Dunbar; Hongyu Li (Julio) >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>Subject: RE: [nsc] Current Proposed SFC charter >> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >> >>I would certainly hope not, but that has been my concern as well. >>Application layer termination and re-classification seems a must? >> >>-- Kevin J. Ma >> >>> -----Original Message----- >>> From: David Lake (dlake) [mailto:dlake@cisco.com] >>> Sent: Tuesday, November 12, 2013 1:00 PM >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar; >>> Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: RE: [nsc] Current Proposed SFC charter >>> >>> Policy may be outside of the scope of SFC, but without strong mapping >>> between Policy and the inserted Service Header(s), we run-the-risk of >>> limiting the efficacy of the protocol IMO. >>> >>> For example, in a world where the network has "gone dark," (as per >>> the IETF Technical Plenary ?:-) ) what is our ability to determine >>> policy based on DPI of packets-in-flight ? >>> >>> In those circumstances, only the end applications themselves or a >>> reasonably broad-brushed classification (really traffic steering >>> based on what we can see at ingress) is going to be useful - is THAT >>> what we're aiming for here ? >>> >>> David >>> >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>> Surendra Kumar (smkumar) >>> Sent: 12 November 2013 09:26 >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >>> Subject: Re: [nsc] Current Proposed SFC charter >>> >>> Ron, >>> >>> Classification of traffic is well understood and we do not have to >>> redefine it - it's been around for all the time middle boxes have >>> been or for that matter the L2/L3 devices. All we are talking about >>> is the applicability of the classification to branching in SFC. >>> >>> You are right, it is all about policy which is outside the scope of >>>SFC. >>> >>> Surendra. >>> >>> On 11/12/13 7:53 AM, "Ron Parker" >>>wrote: >>> >>> >I think the lack of definition of "reclassification" may be causing >>>some >>> >misunderstandings here. A branch would occur for some policy-driven >>> >reason based on the behavior and conclusions of the service function, >>> >itself. The graph would represent the fact that there is a branch >>> >point, but the service function, itself, being aware that it is a >>> >branching point would contain the policy and logic to decide on which >>> >branch to take. Specifying that policy and logic is out of scope, >>>IMO. >>> > >>> > Ron >>> > >>> > >>> >-----Original Message----- >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >>> >Sent: Tuesday, November 12, 2013 10:49 AM >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra >>> >Majee >>> >Subject: RE: [nsc] Current Proposed SFC charter >>> > >>> >Hi Linda, >>> > >>> > Are you saying that a branching point is "never" a >>> > reclassification point, or are you saying that a branching point >>>"does not have to be" >>> > a reclassification point? >>> > >>> > I think this is an important distinction that needs to be clarified. >>> > If branching is never reclassification, then the meaning of a >>> > chain is different than I originally inferred. If the chain is a >>> > tree with other "branching" points in it, then that limits the >>> > scope of the problem statement goals. >>> > >>> > While this could be a degenerate case, and any implementation >>> > could define bad service chains, is it the intent of SFC to only >>> > look at the simpler packet-level classification cases, or is it the >>> > intent to consider the case where a branching point is viewed as a >>> > re-classification point? >>> > >>> >thanx. >>> > >>> >-- Kevin J. Ma >>> > >>> >> -----Original Message----- >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >>> >> Sent: Tuesday, November 12, 2013 10:34 AM >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> Sumandra Majee >>> >> Subject: RE: [nsc] Current Proposed SFC charter >>> >> >>> >> Ron, >>> >> >>> >> First, want to make it clear that "branching" !=3D reclassification, >>> >>agree? >>> >> >>> >> Second, the representation of branching (or service graph) can be >>> >> in a form of logic on a service function. Some service functions, >>> >> especially L7 based, can use value in a Database to determine what >>> >> is the next service function. >>> >> >>> >> Linda >>> >> >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM >>> >> > To: Hongyu Li (Julio); Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hongyu, >>> >> > >>> >> > I agree completely that re-classification is not limited to DPI. >>> >> > >>> >> > And also, that an area for us to explore as a group is how to >>> >>represent >>> >> > the service graph. Do we want to represent it as a proper graph >>> with >>> >> > an adjacency list or other representational model? Or, do we >>>want >>> to >>> >> > represent it as a set of linear segments and if so, how are the >>> >> > segments connected into a graph? Other ideas? >>> >> > >>> >> > Ron >>> >> > >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Hongyu Li (Julio) >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM >>> >> > To: Ron Parker; Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Branching/forking is a very interesting topic of SFC. About the >>> >> > re- classification point, probably we shall not limit it to DPI. >>> >> > It is also possible that packets go to different branches after >>> >> > been processed by a certain service function, decision of which >>> >> > branches to go is made based on the result of service function's >>> >> > process, i.e. not just re- classification by DPI. >>> >> > >>> >> > Hongyu >>> >> > >>> >> > -----Original Message----- >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>> >> > Behalf Of Ron Parker >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM >>> >> > To: Kevin J Ma >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); >>> >> > Sumandra Majee >>> >> > Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>> >> > Hi, Kevin >>> >> > >>> >> > You ask a great question about branching the graph. The details >>> >> > around how to convey the selection of the subtree/subgraph are >>> >> > still >>> >>to be >>> >> > defined. Is it one chain id for the whole graph? Does each >>>branch >>> >> > have its own chain id? Some combination? >>> >> > >>> >> > Ron >>> >> > >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >>> >> > >>> >> > wrote: >>> >> > >>> >> > >> Yes, reclassification can change the service path and >>> >> > >> re-classification may happen at any node along a service path. >>> >> > > >>> >> > > Just to expand on that, going back to the original question >>> >> > > about service header encapsulation, is it intended that a >>> >> > > chain that is re-classified will get a new chain ID which >>> >> > > fully describes a chain that is a superset of the original >>> >> > > chain ID, prior to DPI-based re-classification? (assuming the >>> >> > > goal is "a single chain ID that is commonly understood along >>> >> > > the entire service >>> chain" >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >>> >> > > ) >>> >> > > >>> >> > > And the applicable subset of the permutative list of service >>> >> > > paths would be configured at each appropriate service node? >>> >> > > e.g., ID 1: NAT + firewall + DPI >>> >> > > ID 2: NAT + firewall + DPI + AV >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT >>> >> > > ID 4: NAT + firewall + DPI + NAT >>> >> > > ID 5: NAT + firewall + DPI + AV + LB >>> >> > > ID 6: NAT + firewall + DPI + LB >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >>> >> > > ID 8: NAT + firewall + DPI + CACHE >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would >>> >> > > every flow then be initially classified as ID 1, but >>> >> > > eventually get re- >>> >> > classified >>> >> > > to ID 2-11, after the DPI phase? >>> >> > > >>> >> > > thanx. >>> >> > > >>> >> > > -- Kevin J. Ma >>> >> > > >>> >> > >> -----Original Message----- >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >> nsc@ietf.org >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma" >>> >> > >>> >>> >>wrote: >>> >> > >>> >>> >> > >>> Hi Surendra, >>> >> > >>> >>> >> > >>> Classification may be out of scope, but the level of service >>> >> > >>> that >>> >> > is >>> >> > >>> applicable is dependent upon the level of classification >>> >> > >>> that can >>> >> > be >>> >> > >>> performed. An assumption of packet level encapsulation has >>> >> > >> implications >>> >> > >>> on the level of classification being performed? If the >>> >> > >>> stated >>> >> > goals >>> >> > >> are >>> >> > >>> for firewall and load balancer functionality, then the >>> >> > >>> application >>> >> > >> level >>> >> > >>> nature of those functions needs to be taken into account? >>> >> > >>> If, on the other hand, the service function scope is limited >>> >> > >>> due to limitations in classification, that would be and >>> >> > >>> important piece of >>> >> > information? >>> >> > >>> >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the >>> >> > >>> fork points of the service paths seem like re-classification >>> points? >>> >> > >>> Is that the interpretation from the architecture perspective? >>> >> > >>> Or is the service function chain classification exclusive of >>> >> > >>> DPI >>> >> > functionality? >>> >> > >> I have not fully read that draft yet. But in general, as >>> >> > >> described in the arch draft, the collection of services form >>> >> > >> a graph, segments of which are service paths. Yes, >>> >> > >> reclassification can >>> >> > change >>> >> > >> the service path and re-classification may happen at any node >>> >> > >> along >>> >> > a service path. >>> >> > >> >>> >> > >> Surendra. >>> >> > >>> >>> >> > >>> thanx. >>> >> > >>> >>> >> > >>> -- Kevin J. Ma >>> >> > >>> >>> >> > >>>> -----Original Message----- >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>> >> > >>>> nsc@ietf.org >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>> >>> >> > >>>> Kevin, >>> >> > >>>> >>> >> > >>>> Classification mechanism is outside the scope of SFC. It >>> >> > >>>> can be based >>> >> > >> on >>> >> > >>>> the packet or information not in the packet(environmental >>> >> > >>>> attributes >>> >> > >> for >>> >> > >>>> instance) or a combination thereof. What is important is >>> >> > >>>> that such classification aids in traffic selection and >>> >> > >>>> service path identification. >>> >> > >>>> It is no different from a policy in this regard except that >>> >> > >>>> the policy now specifies the service path. >>> >> > >>>> Further, classification is not limited to the network >>> >> > >>>> elements but the service functions as well. Some of this is >>> >> > >>>> described in the >>> >> > >> architecture >>> >> > >>>> drafts as well - >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>> >> > >>>> >>> >> > >>>> Surendra. >>> >> > >>>> >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> >> > >>>>> >>> >> > wrote: >>> >> > >>>>> >>> >> > >>>>> Hi Ron, >>> >> > >>>>> >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in >>> >> > >>>>> section >>> >> > >>>>> 2 of the >>> >> > problem >>> >> > >>>>> statement: >>> >> > >>>>> >>> >> > >>>>> 11. Per-Service (re)Classification: Classification >>> >> > >>>>> occurs at >>> >> > each >>> >> > >>>>> service, independent from previously applied >>> >> > >>>>> service >>> >> > >>>> functions. >>> >> > >>>>> These unrelated classification events consume >>> >> > >>>>> resources >>> >> > per >>> >> > >>>>> service. More importantly, the classification >>> >> > functionality >>> >> > >>>>> often differs per service function and service >>> >> > >>>>> function >>> >> > >> cannot >>> >> > >>>>> leverage the results from other deployed network or >>> >> > service. >>> >> > >>>>> >>> >> > >>>>> as it relates to section 5.2 of the framework document: >>> >> > >>>>> >>> >> > >>>>> The SFC Classifier classifies packets based on (some of) >>> >> > >>>>> the >>> >> > >>>> contents >>> >> > >>>>> of the packet header. Concretely, it classifies packets >>> >> > >>>>> based on >>> >> > >>>> the >>> >> > >>>>> possible combination of one or more header fields, such >>> >> > >>>>> as >>> >> > source >>> >> > >>>>> address, destination address, DS field, protocol ID, >>> >> > >>>>> source >>> >> > port >>> >> > >>>> and >>> >> > >>>>> destination port numbers, and any other information. >>> >> > >>>>> >>> >> > >>>>> A packet-based classifier as described in the framework >>> >> > >>>>> document >>> >> > >>>> would >>> >> > >>>>> seem to be limited in what it can classify? The service >>> >> > >>>>> function identifier lookup does not seem to be a >>> >> > >>>>> significant optimization >>> >> > >> over >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some >>> >> > >>>>> missing >>> >> > >> detail >>> >> > >>>>> wrt how classification information is determined and reused? >>> >> > >>>>> >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and >>> >> > >>>>> TLS >>> >> > >>>> encrypted >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was >>> >> > >>>>> also >>> >> > >>>> wondering >>> >> > >>>>> how independent HLS segment requests might be classified >>> >> > >>>>> and >>> >> > >>>> associated? >>> >> > >>>>> Were these types of use cases discussed in the BoF? >>> >> > >>>>> >>> >> > >>>>> thanx. >>> >> > >>>>> >>> >> > >>>>> -- Kevin J. Ma >>> >> > >>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Ron >>> >> > >>>>>> Parker >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As was discussed in Vancouver, there are already many >>> >> > >>>>>> existing ways >>> >> > >>>> to >>> >> > >>>>>> accomplish service chaining. But none of them provide a >>> >> > >>>> sufficient >>> >> > >>>>>> combination of interoperability, flexibility, and >>>resiliency. >>> >> > A >>> >> > >>>> single >>> >> > >>>>>> service chain encapsulation will go a long way to >>> >> > >>>>>> ensuring these >>> >> > >>>> goals. >>> >> > >>>>>> It may not be the absolutely most efficient approach for >>> >> > >>>>>> every >>> >> > >>>> single >>> >> > >>>>>> network topology and every single use case, but its >>> >> > >>>>>> ubiquitous >>> >> > >> nature >>> >> > >>>>>> should improve its adoption. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> Absolutely, that was an example of one type of derivation. >>> >> > >>>>>> However >>> >> > >>>> this >>> >> > >>>>>> could be augmented with classification result, again one >>> >> > >>>>>> more >>> >> > >>>> example. >>> >> > >>>>>> >>> >> > >>>>>>>> All flows from the same source IP do not necessarily >>> >> > >>>>>>>> follow >>> >> > the >>> >> > >>>> same >>> >> > >>>>>> chain. >>> >> > >>>>>> Correct. It is also not necessary that all transaction of >>> >> > >>>>>> the same >>> >> > >>>> flow >>> >> > >>>>>> follow the same chain either. So why stop at flow itself. >>> >> > >>>>>> >>> >> > >>>>>> Again the point here is that do we always need SFC header >>> >> > >>>>>> or >>> >>Not. >>> >> > >>>>>> >>> >> > >>>>>> Sumandra >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> The intention of service function chaining is to allow >>> >> > >>>>>> for operation >>> >> > >>>> at >>> >> > >>>>>> the fully qualified flow level, or even finer grained at >>> >> > >>>>>> the >>> >> > >>>> transaction >>> >> > >>>>>> level (this is an implementation matter for the PDP). >>>All >>> >> > flows >>> >> > >>>> from >>> >> > >>>>>> the same source IP do not necessarily follow the same >>>chain. >>> >> > >> Source >>> >> > >>>>>> IP, >>> >> > >>>>>> therefore, does not identify the chain ID. Another >>> >>intention >>> >> > of >>> >> > >>>>>> service function chaining is to operate over any network >>> >> > topology >>> >> > >> and >>> >> > >>>>>> not >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>>of >>> >> > the >>> >> > >>>>>> transport, it does not adequately identify the service >>> >> > >>>>>> chain, >>> >> > >> either. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Ron, >>> >> > >>>>>> >>> >> > >>>>>> The service header is meant to carry the context which >>> >> > >>>>>> can >>> >> > *also* >>> >> > >>>>>> be derived (for example use source ip and vlan to >>> >> > >>>>>> identify chainID and >>> >> > >>>>>> position) or encapsulated as part of another tunnel header. >>> >> > >>>>>> So this could be optional IMHO. >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Sumandra, >>> >> > >>>>>> >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to >>> >> > >>>>>> SF or from >>> >> > >>>> SF >>> >> > >>>>>> to >>> >> > >>>>>> SF will look like: >>> >> > >>>>>> >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | "transport" | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | service header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | original IP header | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> | | original IP >>> >> > >>>>>> | payload >>> >> > | >>> >> > >>>>>> | | >>> >> > >>>>>> +------------------------+ >>> >> > >>>>>> >>> >> > >>>>>> Where service header contains, at a minimum, enough >>> >> > >>>>>> information to >>> >> > >>>> allow >>> >> > >>>>>> the packet to be propagated along the full length of the >>> >> > >>>>>> chain, and optionally, other metadata that enhances the >>> >> > >>>>>> operation of >>> >> > one >>> >> > >>>>>> or >>> >> > >> more >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> And where "transport" could conceivably be any of, but >>> >> > >>>>>> not limited >>> >> > >>>> to: >>> >> > >>>>>> >>> >> > >>>>>> * Ethernet >>> >> > >>>>>> * Ethernet + LLC2 >>> >> > >>>>>> * Ethernet + MPLS >>> >> > >>>>>> * Ethernet + IP + GRE >>> >> > >>>>>> * Ethernet + IP +UDP >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Also, "original" in the diagram above is not meant to >>> >> > >>>>>> imply immutability, but rather to specify the packet that >>> >> > >>>>>> is >>> >> > propagated >>> >> > >>>>>> from preceding entity to succeeding entity, prior to >>> >> > >>>>>> encapsulation. >>> >> > >>>>>> >>> >> > >>>>>> Ron >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Sumandra Majee >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >>will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> [SM] What does it mean by a single service-level >>> >> > >>>>>> encapsulation, >>> >> > a >>> >> > >>>> new >>> >> > >>>>>> encapsulation format >>> >> > >>>>>> or an ability to select one encapsulation >>> >> > >>>>>> format that >>> >> > >>>> fits >>> >> > >>>>>> the >>> >> > >>>>>> need for a given service chain? >>> >> > >>>>>> The ability to select a specific encapsulation >>> >> > >>>>>> would be >>> >> > >> a >>> >> > >>>>>> management plane decision. >>> >> > >>>>>> There are quite a few existing encapsulation >>> >> > >>>>>> methods that >>> >> > >>>> can >>> >> > >>>>>> possibly be reused to provide >>> >> > >>>>>> context information between service nodes. I >>>have >>> >> > seen >>> >> > >>>>>> mention >>> >> > >>>>>> of GRE, for HTTP based >>> >> > >>>>>> applications contexts are transferred via headers. >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> -----Original Message----- >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] >>> >> > >>>>>> On Behalf >>> >> > >> Of >>> >> > >>>>>> Thomas Narten >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>> >> > >>>>>> To: nsc@ietf.org >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >>> >> > >>>>>> >>> >> > >>>>>> Hi. >>> >> > >>>>>> >>> >> > >>>>>> Current charter can be found at >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >>> >> > >>>>>> ietf-sfc/. >>> >> > >>>>>> >>> >> > >>>>>> It contains the revised management text as well as >>> >> > >>>>>> updated >>> >> > >>>> milestones. >>> >> > >>>>>> >>> >> > >>>>>> All known issues have been addressed. If there are any >>> >> > >>>>>> remaining >>> >> > >>>> issues, >>> >> > >>>>>> please speak up! >>> >> > >>>>>> >>> >> > >>>>>> Charter charter-ietf-sfc-00-04 >>> >> > >>>>>> >>> >> > >>>>>> Networks, servers, storage technologies, and >>> >> > >>>>>> applications, have all undergone significant change in >>> >> > >>>>>> recent years with the introduction >>> >> > >> of >>> >> > >>>>>> virtualization, network overlays, and orchestration. >>> >> > >>>>>> Service >>> >> > >> delivery >>> >> > >>>> is >>> >> > >>>>>> currently both a technical and organizational challenge >>> >> > >>>>>> that >>> >> > >> involves >>> >> > >>>>>> significant modification to the network configuration. >>> >> > >>>>>> Services are typically implemented by the ordered >>> >> > >>>>>> combination of a number of service functions that are >>> >> > >>>>>> deployed at different points within >>> >> > >> the >>> >> > >>>>>> network. Today, a common deployment model has service >>> >> > >>>>>> functions physically inserted on the data forwarding path >>> >> > >>>>>> between communicating peers. >>> >> > >>>> Going >>> >> > >>>>>> forward, however, there is a desire to move to a >>> >> > >>>>>> different model, >>> >> > >>>> where >>> >> > >>>>>> service functions are not required to reside on the >>> >> > >>>>>> default data >>> >> > >> path >>> >> > >>>>>> and >>> >> > >>>>>> traffic is instead steered through services, wherever >>> >> > >>>>>> they are >>> >> > >>>> deployed. >>> >> > >>>>>> >>> >> > >>>>>> For a given service, the abstracted view of the required >>> >> > >>>>>> service functions and the order in which they are to be >>> >> > >>>>>> applied is >>> >> > called >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service >>> >> > >>>>>> function may be available on more than one node within a >>> >> > >>>>>> network, a Service Function Chain is instantiated >>> >> > >>>> via >>> >> > >>>>>> the selection of specific service function instances and >>> >> > >>>>>> the network nodes on which they are provided, thereby >>> >> > >>>>>> forming a service topology: >>> >> > >>>>>> this is called a Service Function Path. The service >>> >> > >>>>>> functions >>> >> > may >>> >> > >>>>>> be applied at a specific layer within the network >>> >> > >>>>>> protocol stack >>> >> > >>>> (network >>> >> > >>>>>> layer, application layer, etc.). >>> >> > >>>>>> >>> >> > >>>>>> The Service Function Chaining (SFC) working group will >>> >> > >>>>>> develop new approaches to service delivery and deployment. >>> >> > >>>>>> It will produce a framework for service function chaining >>> >> > >>>>>> that includes the necessary protocols >>> >> > >>>> or >>> >> > >>>>>> protocol extensions to convey the service path and >>> >> > >>>>>> service path information to nodes that implement service >>> >> > >>>>>> functions, as well >>> >> > as >>> >> > >>>>>> mechanisms for steering traffic through service functions. >>> >> > >>>>>> The >>> >> > >>>> working >>> >> > >>>>>> group will also examine what information needs to be >>> >> > >>>>>> gathered from >>> >> > >>>> the >>> >> > >>>>>> network and service functions in support of service >>> >> > >>>>>> function >>> >> > >> chaining >>> >> > >>>>>> and >>> >> > >>>>>> how that information may be made available to nodes that >>> >> > >>>>>> implement >>> >> > >>>> the >>> >> > >>>>>> service functions. >>> >> > >>>>>> >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >>> following: >>> >> > >>>>>> >>> >> > >>>>>> 1) Problem Statement: This document will provide a >>> >> > >>>>>> summary of >>> >> > the >>> >> > >>>>>> problem space to be addressed by the WG including >>> >> > >>>>>> example >>> >> > high- >>> >> > >>>>>> level use cases. Additionally, the WG will normalize >>> >> > >> nomenclature >>> >> > >>>>>> and definitions for service function chaining. >>> >> > >>>>>> >>> >> > >>>>>> 2) Architecture: This document will provide a description >>> >> > >>>>>> of >>> >>the >>> >> > >>>>>> architectural building blocks and their relationships >>> >> > including >>> >> > >>>>>> interconnection, placement of capabilities, management, >>> >> > >>>>>> diagnostics, design analysis, and security models, as >>> >> > >>>>>> well >>> >>as >>> >> > >>>>>> requirements on the protocol mechanisms. >>> >> > >>>>>> >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A >>> >> > >>>>>> document >>> >> > will >>> >> > >>>>>> describe the single service-level data plane >>> >> > >>>>>> encapsulation >>> >> > >> format >>> >> > >>>>>> for >>> >> > >>>>>> conveying the service function chain and the service >>> >> > >>>>>> function >>> >> > >>>> path, >>> >> > >>>>>> and for communicating context information between >>> >> > >>>>>> nodes >>> that >>> >> > >>>>>> implement service functions. It is intended that the >>> >> > >>>> encapsulation >>> >> > >>>>>> be agnostic to the layer at which it is applied and >>> >> > >>>>>> the service >>> >> > >>>> that >>> >> > >>>>>> is >>> >> > >>>>>> being constructed. That is, the same encapsulation may >>> >> > >>>>>> be >>> >> > used >>> >> > >> on >>> >> > >>>>>> a service function path realized at the network layer=20 >>> >> > >>>>>> or at any other >>> >> > >>>>>> layer, and the same encapsulation will apply for the >>> >> > >> construction >>> >> > >>>> of >>> >> > >>>>>> service function paths regardless of the actual service. >>> >> > >>>>>> >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >>> >> > developed to >>> >> > >>>>>> describe requirements and protocols necessary to=20 >>> >> > >>>>>> convey >>> >> > >>>> information >>> >> > >>>>>> to service function implementation points. Where=20 >>> >> > >>>>>> possible, >>> >> > >>>> existing >>> >> > >>>>>> IETF protocols will be used and extended. All protocol >>> >> > >> extensions >>> >> > >>>>>> work should be carried out in the working groups=20 >>> >> > >>>>>> responsible for >>> >> > >>>> the >>> >> > >>>>>> protocols being modified in coordination with this=20 >>> >> > >>>>>> working >>> >> > >> group, >>> >> > >>>>>> but >>> >> > >>>>>> may be done in this working group after agreement with=20 >>> >> > >>>>>> all >>> >> > the >>> >> > >>>>>> relevant WG chairs and responsible ADs. >>> >> > >>>>>> >>> >> > >>>>>> 5) Manageability: Work on the management and=20 >>> >> > >>>>>> configuration of >>> >> > >> service >>> >> > >>>>>> functions in support of SFC components will certainly=20 >>> >> > >>>>>> be >>> >> > needed, >>> >> > >>>>>> but first needs to be better understood and scoped. >>> >> > >>>>>> >>> >> > >>>>>> Proposed Milestones >>> >> > >>>>>> >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >>> >> > >>>>>> defining the >>> >> > >>>> problem >>> >> > >>>>>> statement and core use cases for Service Function=20 >>> >> > >>>>>> Chaining >>> >> > >>>>>> >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >>> >> > >>>>>> modifications for management and configuration of SFC=20 >>> >> > >>>>>> components >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >>> >> > >>>>>> the >>> >> > >>>> architecture >>> >> > >>>>>> for SFC >>> >> > >>>>>> >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >>> >> > >>>>>> service function chaining encapsulation protocol >>> >> > >>>>>> >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >>> >> > >>>>>> specifying the >>> >> > >>>> generic >>> >> > >>>>>> service function chaining header encapsulation >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> >>> >> > >>>>>> Thomas >>> >> > >>>>>> >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>>> _______________________________________________ >>> >> > >>>>>> nsc mailing list >>> >> > >>>>>> nsc@ietf.org >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > >>>>> _______________________________________________ >>> >> > >>>>> nsc mailing list >>> >> > >>>>> nsc@ietf.org >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >>> >> > > >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >> > _______________________________________________ >>> >> > nsc mailing list >>> >> > nsc@ietf.org >>> >> > https://www.ietf.org/mailman/listinfo/nsc >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From ddolson@sandvine.com Tue Nov 12 11:53:33 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C6321E80A7 for ; Tue, 12 Nov 2013 11:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui5iYrENSyRA for ; Tue, 12 Nov 2013 11:53:29 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 561C621F9CC5 for ; Tue, 12 Nov 2013 11:53:26 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exch-2.sandvine.com ([fe80::c1c8:c02e:acd1:5a6a%14]) with mapi id 14.01.0289.001; Tue, 12 Nov 2013 14:53:25 -0500 From: Dave Dolson To: "David Lake (dlake)" , "Jim Guichard (jguichar)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN70rnuyF38+0WKON28dGBA/5ohDc2AgAAOHICAACcIgIAAAa2AgAACJICAAAHCAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGiAIAAA3SAgAAm0YCAABXAAIAABCEAgAABcQCAABmvgIAACYeAgAAHuQCAAAKLAIAAAjuAgAAB1oD//7xrIA== Date: Tue, 12 Nov 2013 19:53:25 +0000 Message-ID: References: <3512BB31280C39448A9880F61DD54CEB0C8EA7B7@xmb-aln-x09.cisco.com> <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> In-Reply-To: <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Nov 2013 08:21:07 -0800 Cc: Thomas Narten , "nsc@ietf.org" , Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 19:53:33 -0000 It might be helpful to associate each chain ID at a particular node with a = "realm" of some sort. Then the receiving node can map the ID to a realm and provide appropriate b= ehaviour. This could at least assist with different domains of overlapping private IP= v4, which can occur within the same operator. If you don't have need of different realms, just use the default for all of= your IDs. -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of David= Lake (dlake) Sent: Tuesday, November 12, 2013 1:51 PM To: Jim Guichard (jguichar); Kevin J Ma; Surendra Kumar (smkumar); Ron Park= er; Linda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter Understood - maybe just a little localised warming of the sea then ? But = I still think we need to consider where and how policy is defined/set even = for the single-domain instance. I don't think we can assume that any L1-3 device will be able to determine = much useful information from the data-plane. -----Original Message----- From: Jim Guichard (jguichar)=20 Sent: 12 November 2013 10:44 To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio) Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee Subject: Re: [nsc] Current Proposed SFC charter As discussed during the BOF our initial work is single administrative domai= n for some of the very reasons you point out. We need to keep focused witho= ut trying to boil the ocean right off the bat. On 11/12/13 1:36 PM, "David Lake (dlake)" wrote: >Exactly. But how can network-components "terminate" an application ???? > >I think we need a good understanding of a recursive policy mechanism=20 >(recursive because a user-land application will ride with a specific=20 >policy across potentially different sets of carrier policies). > >I hate to bring this up now, but we also need to think about this=20 >multi-domain issue - if I set a policy as a user, chances are I will be=20 >crossing several domain boundaries. Are we expecting the service=20 >headers to define the service chaining for the duration of the entire=20 >flow across all domains, or just across a single one ? > >In which case, do I have to re-set policy as I traverse domains and >where does that policy get set ? It would be much better to set policy >once based on L5-7 needs, and have that instantiated across the=20 >multiple domains. > >Again, this appears to be outside the scope of SFC, but pretty relevant=20 >to how it would operate in the real world. > >David > >-----Original Message----- >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >Sent: 12 November 2013 10:27 >To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=20 >Dunbar; Hongyu Li (Julio) >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >Subject: RE: [nsc] Current Proposed SFC charter > >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? > >I would certainly hope not, but that has been my concern as well. >Application layer termination and re-classification seems a must? > >-- Kevin J. Ma > >> -----Original Message----- >> From: David Lake (dlake) [mailto:dlake@cisco.com] >> Sent: Tuesday, November 12, 2013 1:00 PM >> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=20 >> Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: RE: [nsc] Current Proposed SFC charter >> >> Policy may be outside of the scope of SFC, but without strong mapping=20 >> between Policy and the inserted Service Header(s), we run-the-risk of=20 >> limiting the efficacy of the protocol IMO. >> >> For example, in a world where the network has "gone dark," (as per=20 >> the IETF Technical Plenary ?:-) ) what is our ability to determine=20 >> policy based on DPI of packets-in-flight ? >> >> In those circumstances, only the end applications themselves or a=20 >> reasonably broad-brushed classification (really traffic steering=20 >> based on what we can see at ingress) is going to be useful - is THAT=20 >> what we're aiming for here ? >> >> David >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 >> Surendra Kumar (smkumar) >> Sent: 12 November 2013 09:26 >> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Ron, >> >> Classification of traffic is well understood and we do not have to=20 >> redefine it - it's been around for all the time middle boxes have=20 >> been or for that matter the L2/L3 devices. All we are talking about=20 >> is the applicability of the classification to branching in SFC. >> >> You are right, it is all about policy which is outside the scope of SFC. >> >> Surendra. >> >> On 11/12/13 7:53 AM, "Ron Parker" >>wrote: >> >> >I think the lack of definition of "reclassification" may be causing >>some >> >misunderstandings here. A branch would occur for some policy-driven >> >reason based on the behavior and conclusions of the service function, >> >itself. The graph would represent the fact that there is a branch >> >point, but the service function, itself, being aware that it is a=20 >> >branching point would contain the policy and logic to decide on which >> >branch to take. Specifying that policy and logic is out of scope, >>IMO. >> > >> > Ron >> > >> > >> >-----Original Message----- >> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] >> >Sent: Tuesday, November 12, 2013 10:49 AM >> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio) >> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=20 >> >Majee >> >Subject: RE: [nsc] Current Proposed SFC charter >> > >> >Hi Linda, >> > >> > Are you saying that a branching point is "never" a=20 >> > reclassification point, or are you saying that a branching point "does= not have to be" >> > a reclassification point? >> > >> > I think this is an important distinction that needs to be clarified. >> > If branching is never reclassification, then the meaning of a=20 >> > chain is different than I originally inferred. If the chain is a=20 >> > tree with other "branching" points in it, then that limits the=20 >> > scope of the problem statement goals. >> > >> > While this could be a degenerate case, and any implementation=20 >> > could define bad service chains, is it the intent of SFC to only=20 >> > look at the simpler packet-level classification cases, or is it the=20 >> > intent to consider the case where a branching point is viewed as a=20 >> > re-classification point? >> > >> >thanx. >> > >> >-- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >> >> Sent: Tuesday, November 12, 2013 10:34 AM >> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma >> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> Sumandra Majee >> >> Subject: RE: [nsc] Current Proposed SFC charter >> >> >> >> Ron, >> >> >> >> First, want to make it clear that "branching" !=3D reclassification,= =20 >> >>agree? >> >> >> >> Second, the representation of branching (or service graph) can be=20 >> >> in a form of logic on a service function. Some service functions,=20 >> >> especially L7 based, can use value in a Database to determine what=20 >> >> is the next service function. >> >> >> >> Linda >> >> >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 8:16 AM >> >> > To: Hongyu Li (Julio); Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hongyu, >> >> > >> >> > I agree completely that re-classification is not limited to DPI. >> >> > >> >> > And also, that an area for us to explore as a group is how to >> >>represent >> >> > the service graph. Do we want to represent it as a proper graph >> with >> >> > an adjacency list or other representational model? Or, do we want >> to >> >> > represent it as a set of linear segments and if so, how are the >> >> > segments connected into a graph? Other ideas? >> >> > >> >> > Ron >> >> > >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Hongyu Li (Julio) >> >> > Sent: Tuesday, November 12, 2013 6:57 AM >> >> > To: Ron Parker; Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Branching/forking is a very interesting topic of SFC. About the >> >> > re- classification point, probably we shall not limit it to DPI. >> >> > It is also possible that packets go to different branches after=20 >> >> > been processed by a certain service function, decision of which=20 >> >> > branches to go is made based on the result of service function's=20 >> >> > process, i.e. not just re- classification by DPI. >> >> > >> >> > Hongyu >> >> > >> >> > -----Original Message----- >> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=20 >> >> > Behalf Of Ron Parker >> >> > Sent: Tuesday, November 12, 2013 7:45 PM >> >> > To: Kevin J Ma >> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=20 >> >> > Sumandra Majee >> >> > Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> > Hi, Kevin >> >> > >> >> > You ask a great question about branching the graph. The details=20 >> >> > around how to convey the selection of the subtree/subgraph are=20 >> >> > still >> >>to be >> >> > defined. Is it one chain id for the whole graph? Does each >>branch >> >> > have its own chain id? Some combination? >> >> > >> >> > Ron >> >> > >> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma" >> >> > >> >> > wrote: >> >> > >> >> > >> Yes, reclassification can change the service path and=20 >> >> > >> re-classification may happen at any node along a service path. >> >> > > >> >> > > Just to expand on that, going back to the original question=20 >> >> > > about service header encapsulation, is it intended that a=20 >> >> > > chain that is re-classified will get a new chain ID which=20 >> >> > > fully describes a chain that is a superset of the original=20 >> >> > > chain ID, prior to DPI-based re-classification? (assuming the=20 >> >> > > goal is "a single chain ID that is commonly understood along=20 >> >> > > the entire service >> chain" >> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html >> >> > > ) >> >> > > >> >> > > And the applicable subset of the permutative list of service=20 >> >> > > paths would be configured at each appropriate service node? >> >> > > e.g., ID 1: NAT + firewall + DPI >> >> > > ID 2: NAT + firewall + DPI + AV >> >> > > ID 3: NAT + firewall + DPI + AV + NAT >> >> > > ID 4: NAT + firewall + DPI + NAT >> >> > > ID 5: NAT + firewall + DPI + AV + LB >> >> > > ID 6: NAT + firewall + DPI + LB >> >> > > ID 7: NAT + firewall + DPI + LB + CACHE >> >> > > ID 8: NAT + firewall + DPI + CACHE >> >> > > ID 9: NAT + firewall + DPI + optimizer + LB >> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=20 >> >> > > every flow then be initially classified as ID 1, but=20 >> >> > > eventually get re- >> >> > classified >> >> > > to ID 2-11, after the DPI phase? >> >> > > >> >> > > thanx. >> >> > > >> >> > > -- Kevin J. Ma >> >> > > >> >> > >> -----Original Message----- >> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM >> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >> nsc@ietf.org >> >> > >> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >> >> >> > >> >> >> > >> >> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma"=20 >> >> > >>> >> >>wrote: >> >> > >>> >> >> > >>> Hi Surendra, >> >> > >>> >> >> > >>> Classification may be out of scope, but the level of service=20 >> >> > >>> that >> >> > is >> >> > >>> applicable is dependent upon the level of classification=20 >> >> > >>> that can >> >> > be >> >> > >>> performed. An assumption of packet level encapsulation has >> >> > >> implications >> >> > >>> on the level of classification being performed? If the=20 >> >> > >>> stated >> >> > goals >> >> > >> are >> >> > >>> for firewall and load balancer functionality, then the=20 >> >> > >>> application >> >> > >> level >> >> > >>> nature of those functions needs to be taken into account? >> >> > >>> If, on the other hand, the service function scope is limited=20 >> >> > >>> due to limitations in classification, that would be and=20 >> >> > >>> important piece of >> >> > information? >> >> > >>> >> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=20 >> >> > >>> fork points of the service paths seem like re-classification >> points? >> >> > >>> Is that the interpretation from the architecture perspective? >> >> > >>> Or is the service function chain classification exclusive of=20 >> >> > >>> DPI >> >> > functionality? >> >> > >> I have not fully read that draft yet. But in general, as=20 >> >> > >> described in the arch draft, the collection of services form=20 >> >> > >> a graph, segments of which are service paths. Yes,=20 >> >> > >> reclassification can >> >> > change >> >> > >> the service path and re-classification may happen at any node=20 >> >> > >> along >> >> > a service path. >> >> > >> >> >> > >> Surendra. >> >> > >>> >> >> > >>> thanx. >> >> > >>> >> >> > >>> -- Kevin J. Ma >> >> > >>> >> >> > >>>> -----Original Message----- >> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM >> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=20 >> >> > >>>> nsc@ietf.org >> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>> >> >> > >>>> Kevin, >> >> > >>>> >> >> > >>>> Classification mechanism is outside the scope of SFC. It=20 >> >> > >>>> can be based >> >> > >> on >> >> > >>>> the packet or information not in the packet(environmental=20 >> >> > >>>> attributes >> >> > >> for >> >> > >>>> instance) or a combination thereof. What is important is=20 >> >> > >>>> that such classification aids in traffic selection and=20 >> >> > >>>> service path identification. >> >> > >>>> It is no different from a policy in this regard except that=20 >> >> > >>>> the policy now specifies the service path. >> >> > >>>> Further, classification is not limited to the network=20 >> >> > >>>> elements but the service functions as well. Some of this is=20 >> >> > >>>> described in the >> >> > >> architecture >> >> > >>>> drafts as well - >> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >> >> > >>>> >> >> > >>>> Surendra. >> >> > >>>> >> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> >> > >>>>> >> >> > wrote: >> >> > >>>>> >> >> > >>>>> Hi Ron, >> >> > >>>>> >> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=20 >> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=20 >> >> > >>>>> section >> >> > >>>>> 2 of the >> >> > problem >> >> > >>>>> statement: >> >> > >>>>> >> >> > >>>>> 11. Per-Service (re)Classification: Classification=20 >> >> > >>>>> occurs at >> >> > each >> >> > >>>>> service, independent from previously applied=20 >> >> > >>>>> service >> >> > >>>> functions. >> >> > >>>>> These unrelated classification events consume=20 >> >> > >>>>> resources >> >> > per >> >> > >>>>> service. More importantly, the classification >> >> > functionality >> >> > >>>>> often differs per service function and service=20 >> >> > >>>>> function >> >> > >> cannot >> >> > >>>>> leverage the results from other deployed network or >> >> > service. >> >> > >>>>> >> >> > >>>>> as it relates to section 5.2 of the framework document: >> >> > >>>>> >> >> > >>>>> The SFC Classifier classifies packets based on (some of)=20 >> >> > >>>>> the >> >> > >>>> contents >> >> > >>>>> of the packet header. Concretely, it classifies packets=20 >> >> > >>>>> based on >> >> > >>>> the >> >> > >>>>> possible combination of one or more header fields, such=20 >> >> > >>>>> as >> >> > source >> >> > >>>>> address, destination address, DS field, protocol ID,=20 >> >> > >>>>> source >> >> > port >> >> > >>>> and >> >> > >>>>> destination port numbers, and any other information. >> >> > >>>>> >> >> > >>>>> A packet-based classifier as described in the framework=20 >> >> > >>>>> document >> >> > >>>> would >> >> > >>>>> seem to be limited in what it can classify? The service=20 >> >> > >>>>> function identifier lookup does not seem to be a=20 >> >> > >>>>> significant optimization >> >> > >> over >> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=20 >> >> > >>>>> missing >> >> > >> detail >> >> > >>>>> wrt how classification information is determined and reused? >> >> > >>>>> >> >> > >>>>> When thinking about higher level services, e.g., HTTP and=20 >> >> > >>>>> TLS >> >> > >>>> encrypted >> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=20 >> >> > >>>>> also >> >> > >>>> wondering >> >> > >>>>> how independent HLS segment requests might be classified=20 >> >> > >>>>> and >> >> > >>>> associated? >> >> > >>>>> Were these types of use cases discussed in the BoF? >> >> > >>>>> >> >> > >>>>> thanx. >> >> > >>>>> >> >> > >>>>> -- Kevin J. Ma >> >> > >>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Ron >> >> > >>>>>> Parker >> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As was discussed in Vancouver, there are already many=20 >> >> > >>>>>> existing ways >> >> > >>>> to >> >> > >>>>>> accomplish service chaining. But none of them provide a >> >> > >>>> sufficient >> >> > >>>>>> combination of interoperability, flexibility, and >>resiliency. >> >> > A >> >> > >>>> single >> >> > >>>>>> service chain encapsulation will go a long way to=20 >> >> > >>>>>> ensuring these >> >> > >>>> goals. >> >> > >>>>>> It may not be the absolutely most efficient approach for=20 >> >> > >>>>>> every >> >> > >>>> single >> >> > >>>>>> network topology and every single use case, but its=20 >> >> > >>>>>> ubiquitous >> >> > >> nature >> >> > >>>>>> should improve its adoption. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> Absolutely, that was an example of one type of derivation. >> >> > >>>>>> However >> >> > >>>> this >> >> > >>>>>> could be augmented with classification result, again one=20 >> >> > >>>>>> more >> >> > >>>> example. >> >> > >>>>>> >> >> > >>>>>>>> All flows from the same source IP do not necessarily=20 >> >> > >>>>>>>> follow >> >> > the >> >> > >>>> same >> >> > >>>>>> chain. >> >> > >>>>>> Correct. It is also not necessary that all transaction of=20 >> >> > >>>>>> the same >> >> > >>>> flow >> >> > >>>>>> follow the same chain either. So why stop at flow itself. >> >> > >>>>>> >> >> > >>>>>> Again the point here is that do we always need SFC header=20 >> >> > >>>>>> or >> >>Not. >> >> > >>>>>> >> >> > >>>>>> Sumandra >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> The intention of service function chaining is to allow=20 >> >> > >>>>>> for operation >> >> > >>>> at >> >> > >>>>>> the fully qualified flow level, or even finer grained at=20 >> >> > >>>>>> the >> >> > >>>> transaction >> >> > >>>>>> level (this is an implementation matter for the PDP). >>All >> >> > flows >> >> > >>>> from >> >> > >>>>>> the same source IP do not necessarily follow the same chain. >> >> > >> Source >> >> > >>>>>> IP, >> >> > >>>>>> therefore, does not identify the chain ID. Another >> >>intention >> >> > of >> >> > >>>>>> service function chaining is to operate over any network >> >> > topology >> >> > >> and >> >> > >>>>>> not >> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part >>of >> >> > the >> >> > >>>>>> transport, it does not adequately identify the service=20 >> >> > >>>>>> chain, >> >> > >> either. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM >> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Ron, >> >> > >>>>>> >> >> > >>>>>> The service header is meant to carry the context which=20 >> >> > >>>>>> can >> >> > *also* >> >> > >>>>>> be derived (for example use source ip and vlan to=20 >> >> > >>>>>> identify chainID and >> >> > >>>>>> position) or encapsulated as part of another tunnel header. >> >> > >>>>>> So this could be optional IMHO. >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM >> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Sumandra, >> >> > >>>>>> >> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=20 >> >> > >>>>>> SF or from >> >> > >>>> SF >> >> > >>>>>> to >> >> > >>>>>> SF will look like: >> >> > >>>>>> >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | "transport" | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | service header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | original IP header | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> | | original IP=20 >> >> > >>>>>> | payload >> >> > | >> >> > >>>>>> | | >> >> > >>>>>> +------------------------+ >> >> > >>>>>> >> >> > >>>>>> Where service header contains, at a minimum, enough=20 >> >> > >>>>>> information to >> >> > >>>> allow >> >> > >>>>>> the packet to be propagated along the full length of the=20 >> >> > >>>>>> chain, and optionally, other metadata that enhances the=20 >> >> > >>>>>> operation of >> >> > one >> >> > >>>>>> or >> >> > >> more >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> And where "transport" could conceivably be any of, but=20 >> >> > >>>>>> not limited >> >> > >>>> to: >> >> > >>>>>> >> >> > >>>>>> * Ethernet >> >> > >>>>>> * Ethernet + LLC2 >> >> > >>>>>> * Ethernet + MPLS >> >> > >>>>>> * Ethernet + IP + GRE >> >> > >>>>>> * Ethernet + IP +UDP >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Also, "original" in the diagram above is not meant to=20 >> >> > >>>>>> imply immutability, but rather to specify the packet that=20 >> >> > >>>>>> is >> >> > propagated >> >> > >>>>>> from preceding entity to succeeding entity, prior to=20 >> >> > >>>>>> encapsulation. >> >> > >>>>>> >> >> > >>>>>> Ron >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Sumandra Majee >> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM >> >> > >>>>>> To: Thomas Narten; nsc@ietf.org >> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >>will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> [SM] What does it mean by a single service-level=20 >> >> > >>>>>> encapsulation, >> >> > a >> >> > >>>> new >> >> > >>>>>> encapsulation format >> >> > >>>>>> or an ability to select one encapsulation=20 >> >> > >>>>>> format that >> >> > >>>> fits >> >> > >>>>>> the >> >> > >>>>>> need for a given service chain? >> >> > >>>>>> The ability to select a specific encapsulation=20 >> >> > >>>>>> would be >> >> > >> a >> >> > >>>>>> management plane decision. >> >> > >>>>>> There are quite a few existing encapsulation=20 >> >> > >>>>>> methods that >> >> > >>>> can >> >> > >>>>>> possibly be reused to provide >> >> > >>>>>> context information between service nodes. I have >> >> > seen >> >> > >>>>>> mention >> >> > >>>>>> of GRE, for HTTP based >> >> > >>>>>> applications contexts are transferred via headers. >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> -----Original Message----- >> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=20 >> >> > >>>>>> On Behalf >> >> > >> Of >> >> > >>>>>> Thomas Narten >> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >> >> > >>>>>> To: nsc@ietf.org >> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter >> >> > >>>>>> >> >> > >>>>>> Hi. >> >> > >>>>>> >> >> > >>>>>> Current charter can be found at >> >> > >>>>>> https://datatracker.ietf.org/doc/charter- >> >> > >>>>>> ietf-sfc/. >> >> > >>>>>> >> >> > >>>>>> It contains the revised management text as well as=20 >> >> > >>>>>> updated >> >> > >>>> milestones. >> >> > >>>>>> >> >> > >>>>>> All known issues have been addressed. If there are any=20 >> >> > >>>>>> remaining >> >> > >>>> issues, >> >> > >>>>>> please speak up! >> >> > >>>>>> >> >> > >>>>>> Charter charter-ietf-sfc-00-04 >> >> > >>>>>> >> >> > >>>>>> Networks, servers, storage technologies, and=20 >> >> > >>>>>> applications, have all undergone significant change in=20 >> >> > >>>>>> recent years with the introduction >> >> > >> of >> >> > >>>>>> virtualization, network overlays, and orchestration. >> >> > >>>>>> Service >> >> > >> delivery >> >> > >>>> is >> >> > >>>>>> currently both a technical and organizational challenge=20 >> >> > >>>>>> that >> >> > >> involves >> >> > >>>>>> significant modification to the network configuration. >> >> > >>>>>> Services are typically implemented by the ordered=20 >> >> > >>>>>> combination of a number of service functions that are=20 >> >> > >>>>>> deployed at different points within >> >> > >> the >> >> > >>>>>> network. Today, a common deployment model has service=20 >> >> > >>>>>> functions physically inserted on the data forwarding path=20 >> >> > >>>>>> between communicating peers. >> >> > >>>> Going >> >> > >>>>>> forward, however, there is a desire to move to a=20 >> >> > >>>>>> different model, >> >> > >>>> where >> >> > >>>>>> service functions are not required to reside on the=20 >> >> > >>>>>> default data >> >> > >> path >> >> > >>>>>> and >> >> > >>>>>> traffic is instead steered through services, wherever=20 >> >> > >>>>>> they are >> >> > >>>> deployed. >> >> > >>>>>> >> >> > >>>>>> For a given service, the abstracted view of the required=20 >> >> > >>>>>> service functions and the order in which they are to be=20 >> >> > >>>>>> applied is >> >> > called >> >> > >>>>>> a Service Function Chain (SFC). Since a given service=20 >> >> > >>>>>> function may be available on more than one node within a=20 >> >> > >>>>>> network, a Service Function Chain is instantiated >> >> > >>>> via >> >> > >>>>>> the selection of specific service function instances and=20 >> >> > >>>>>> the network nodes on which they are provided, thereby=20 >> >> > >>>>>> forming a service topology: >> >> > >>>>>> this is called a Service Function Path. The service=20 >> >> > >>>>>> functions >> >> > may >> >> > >>>>>> be applied at a specific layer within the network=20 >> >> > >>>>>> protocol stack >> >> > >>>> (network >> >> > >>>>>> layer, application layer, etc.). >> >> > >>>>>> >> >> > >>>>>> The Service Function Chaining (SFC) working group will=20 >> >> > >>>>>> develop new approaches to service delivery and deployment. >> >> > >>>>>> It will produce a framework for service function chaining=20 >> >> > >>>>>> that includes the necessary protocols >> >> > >>>> or >> >> > >>>>>> protocol extensions to convey the service path and=20 >> >> > >>>>>> service path information to nodes that implement service=20 >> >> > >>>>>> functions, as well >> >> > as >> >> > >>>>>> mechanisms for steering traffic through service functions. >> >> > >>>>>> The >> >> > >>>> working >> >> > >>>>>> group will also examine what information needs to be=20 >> >> > >>>>>> gathered from >> >> > >>>> the >> >> > >>>>>> network and service functions in support of service=20 >> >> > >>>>>> function >> >> > >> chaining >> >> > >>>>>> and >> >> > >>>>>> how that information may be made available to nodes that=20 >> >> > >>>>>> implement >> >> > >>>> the >> >> > >>>>>> service functions. >> >> > >>>>>> >> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the >> following: >> >> > >>>>>> >> >> > >>>>>> 1) Problem Statement: This document will provide a=20 >> >> > >>>>>> summary of >> >> > the >> >> > >>>>>> problem space to be addressed by the WG including=20 >> >> > >>>>>> example >> >> > high- >> >> > >>>>>> level use cases. Additionally, the WG will normalize >> >> > >> nomenclature >> >> > >>>>>> and definitions for service function chaining. >> >> > >>>>>> >> >> > >>>>>> 2) Architecture: This document will provide a description=20 >> >> > >>>>>> of >> >>the >> >> > >>>>>> architectural building blocks and their relationships >> >> > including >> >> > >>>>>> interconnection, placement of capabilities, management, >> >> > >>>>>> diagnostics, design analysis, and security models, as=20 >> >> > >>>>>> well >> >>as >> >> > >>>>>> requirements on the protocol mechanisms. >> >> > >>>>>> >> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=20 >> >> > >>>>>> document >> >> > will >> >> > >>>>>> describe the single service-level data plane=20 >> >> > >>>>>> encapsulation >> >> > >> format >> >> > >>>>>> for >> >> > >>>>>> conveying the service function chain and the service=20 >> >> > >>>>>> function >> >> > >>>> path, >> >> > >>>>>> and for communicating context information between=20 >> >> > >>>>>> nodes >> that >> >> > >>>>>> implement service functions. It is intended that the >> >> > >>>> encapsulation >> >> > >>>>>> be agnostic to the layer at which it is applied and=20 >> >> > >>>>>> the service >> >> > >>>> that >> >> > >>>>>> is >> >> > >>>>>> being constructed. That is, the same encapsulation may=20 >> >> > >>>>>> be >> >> > used >> >> > >> on >> >> > >>>>>> a service function path realized at the network layer=20 >> >> > >>>>>> or at any other >> >> > >>>>>> layer, and the same encapsulation will apply for the >> >> > >> construction >> >> > >>>> of >> >> > >>>>>> service function paths regardless of the actual service. >> >> > >>>>>> >> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be >> >> > developed to >> >> > >>>>>> describe requirements and protocols necessary to=20 >> >> > >>>>>> convey >> >> > >>>> information >> >> > >>>>>> to service function implementation points. Where=20 >> >> > >>>>>> possible, >> >> > >>>> existing >> >> > >>>>>> IETF protocols will be used and extended. All protocol >> >> > >> extensions >> >> > >>>>>> work should be carried out in the working groups=20 >> >> > >>>>>> responsible for >> >> > >>>> the >> >> > >>>>>> protocols being modified in coordination with this=20 >> >> > >>>>>> working >> >> > >> group, >> >> > >>>>>> but >> >> > >>>>>> may be done in this working group after agreement with=20 >> >> > >>>>>> all >> >> > the >> >> > >>>>>> relevant WG chairs and responsible ADs. >> >> > >>>>>> >> >> > >>>>>> 5) Manageability: Work on the management and=20 >> >> > >>>>>> configuration of >> >> > >> service >> >> > >>>>>> functions in support of SFC components will certainly=20 >> >> > >>>>>> be >> >> > needed, >> >> > >>>>>> but first needs to be better understood and scoped. >> >> > >>>>>> >> >> > >>>>>> Proposed Milestones >> >> > >>>>>> >> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=20 >> >> > >>>>>> defining the >> >> > >>>> problem >> >> > >>>>>> statement and core use cases for Service Function=20 >> >> > >>>>>> Chaining >> >> > >>>>>> >> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=20 >> >> > >>>>>> modifications for management and configuration of SFC=20 >> >> > >>>>>> components >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=20 >> >> > >>>>>> the >> >> > >>>> architecture >> >> > >>>>>> for SFC >> >> > >>>>>> >> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=20 >> >> > >>>>>> service function chaining encapsulation protocol >> >> > >>>>>> >> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=20 >> >> > >>>>>> specifying the >> >> > >>>> generic >> >> > >>>>>> service function chaining header encapsulation >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> >> >> > >>>>>> Thomas >> >> > >>>>>> >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>>> _______________________________________________ >> >> > >>>>>> nsc mailing list >> >> > >>>>>> nsc@ietf.org >> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > >>>>> _______________________________________________ >> >> > >>>>> nsc mailing list >> >> > >>>>> nsc@ietf.org >> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc >> >> > > >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> > _______________________________________________ >> >> > nsc mailing list >> >> > nsc@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/nsc >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From S.Majee@f5.com Tue Nov 12 21:36:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F18F11E817A for ; Tue, 12 Nov 2013 21:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.573 X-Spam-Level: X-Spam-Status: No, score=-10.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU0NQ5IGMIsR for ; Tue, 12 Nov 2013 21:36:16 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id B574311E8170 for ; Tue, 12 Nov 2013 21:36:14 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.93,690,1378857600"; d="scan'208";a="87466384" X-IPAS-Result: AqQEAN0Og1LAqArr/2dsb2JhbABQCoM/U78ogS90giUBAQEBAgEBAQEXAR8rAgcEBwwEAgEIDQEDAQMBAQEKCwkJBycLFAMGCAIEAQkEBQgBh3ITvnUXjhwEAQUGgQIGKwcCBASDFoERA5QuikaOT4FoAQg5 Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 13 Nov 2013 05:36:08 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 21:36:08 -0800 From: Sumandra Majee To: Dave Dolson , "Jim Guichard (jguichar)" , "David Lake (dlake)" , Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , Linda Dunbar , "Hongyu Li (Julio)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN9qQulgPomIkmfBvbrqRpzcZogt1rQgACW2YD//5/0sIAAiMKA//96YzCAAImCAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAAFGjAIAAA3OAgAAm0oCAABXAAIAABCAAgAABcgCAABmugIAACYeAgAAHugCAAAKLAIAAAjuAgAAB1YCAAALBAIAADTOAgAAXJBc= Date: Wed, 13 Nov 2013 05:36:07 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098849186D5@SEAEMBX01.olympus.F5Net.com> References: <3512BB31280C39448A9880F61DD54CEB0C8EAAE3@xmb-aln-x09.cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 15 Nov 2013 08:21:07 -0800 Cc: Thomas Narten , "nsc@ietf.org" Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 05:36:25 -0000 I think there is great simplicity to be had by limiting the path selection = to the ingress node (i.e., the one who first puts the SFC header on).=0A= =0A= [SM] I would tend to agree that initial path selection should begin at ingr= ess. However an application classification is a continuous process. It coul= d take a few packets on the response side to classify if this is a video, t= he type, coded rate and tie this with device screen size which could then s= elect a proper video optimizer. Such device would also hold on to the respo= nse as opposed streaming, to make this content available to the optimizer. = It could use the HTTP redirect method but that does waste RAN bandwidth. Mi= nor implementation detail not really important for WG=0A= =0A= I think there is a general confusion or may be it is mine only,=0A= a) What are the classification point and by classification I don't mean D= PI and signatures. It could be dst port or dst_ip address. Say a service is= aware of IP pools used by a popular music streaming service and it could t= hen add this extra classification result. This could be encap modification = or could trigger a new tunnel to some other service endpoint. =0A= =0A= b) Is SFC inline network element? The question around Sd interface to PCRF= suggests that it is. However there would be less control over data when it= is out of band, that is simply the unfortunate truth about network real es= tate.=0A= =0A= c) Chain. How do we create these chain, graphs that are pre created. I can= argue that with increasing number of nodes that will be messy. Another opt= ion is to create a few useful chains and allow nodes to branch off to a dif= ferent node forward or JMP to a new chainID. This could limit the number of= configs object. This also implies that policy is distributed around ... wh= at?=0A= =0A= Regards.=0A= =0A= Sumandra=0A= =0A= =0A= ________________________________________=0A= From: Dave Dolson [ddolson@sandvine.com]=0A= Sent: Tuesday, November 12, 2013 11:48 AM=0A= To: Jim Guichard (jguichar); David Lake (dlake); Kevin J Ma; Surendra Kumar= (smkumar); Ron Parker; Linda Dunbar; Hongyu Li (Julio)=0A= Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= Subject: RE: [nsc] Current Proposed SFC charter=0A= =0A= I think there is great simplicity to be had by limiting the path selection = to the ingress node (i.e., the one who first puts the SFC header on).=0A= =0A= I believe this because of the requirement of many layer4-7 devices to see s= ymmetric paths. (e.g., {DPI2, NAT7, ContentControl11} on the way out and {C= ontentControll11, NAT7, DPI2} on the way back)=0A= =0A= I think it will be really hard to manage this if each device in the chain c= an select an arbitrary (policy-selected) next-hop. I think each packet's ne= xt hop and ID needs to determined by the received ID.=0A= =0A= Otherwise, I'm curious how others see the symmetric path problem being mana= ged?=0A= =0A= =0A= (Apologies if I'm mangling the terminology)=0A= =0A= David Dolson=0A= Software Architect, Sandvine Inc.=0A= =0A= =0A= =0A= =0A= =0A= -----Original Message-----=0A= From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar)=0A= Sent: Tuesday, November 12, 2013 2:01 PM=0A= To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; L= inda Dunbar; Hongyu Li (Julio)=0A= Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= Subject: Re: [nsc] Current Proposed SFC charter=0A= =0A= The assumption is that classification may be performed at the network=0A= and/or application layer and that classification will be based on policy=0A= of some description. When we work through control plane aspects of the SFC= =0A= charter presumably what policy needs to be generated and by what to where= =0A= is part of the work item. Further, branching will occur because of a=0A= reclassification but reclassification may or may not force a branch from=0A= one chain to another.=0A= =0A= On 11/12/13 1:51 PM, "David Lake (dlake)" wrote:=0A= =0A= >Understood - maybe just a little localised warming of the sea then ?=0A= >But I still think we need to consider where and how policy is defined/set= =0A= >even for the single-domain instance.=0A= >=0A= >I don't think we can assume that any L1-3 device will be able to=0A= >determine much useful information from the data-plane.=0A= >=0A= >-----Original Message-----=0A= >From: Jim Guichard (jguichar)=0A= >Sent: 12 November 2013 10:44=0A= >To: David Lake (dlake); Kevin J Ma; Surendra Kumar (smkumar); Ron Parker;= =0A= >Linda Dunbar; Hongyu Li (Julio)=0A= >Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >Subject: Re: [nsc] Current Proposed SFC charter=0A= >=0A= >As discussed during the BOF our initial work is single administrative=0A= >domain for some of the very reasons you point out. We need to keep=0A= >focused without trying to boil the ocean right off the bat.=0A= >=0A= >On 11/12/13 1:36 PM, "David Lake (dlake)" wrote:=0A= >=0A= >>Exactly. But how can network-components "terminate" an application ????= =0A= >>=0A= >>I think we need a good understanding of a recursive policy mechanism=0A= >>(recursive because a user-land application will ride with a specific=0A= >>policy across potentially different sets of carrier policies).=0A= >>=0A= >>I hate to bring this up now, but we also need to think about this=0A= >>multi-domain issue - if I set a policy as a user, chances are I will be= =0A= >>crossing several domain boundaries. Are we expecting the service=0A= >>headers to define the service chaining for the duration of the entire=0A= >>flow across all domains, or just across a single one ?=0A= >>=0A= >>In which case, do I have to re-set policy as I traverse domains and=0A= >>where does that policy get set ? It would be much better to set policy= =0A= >>once based on L5-7 needs, and have that instantiated across the=0A= >>multiple domains.=0A= >>=0A= >>Again, this appears to be outside the scope of SFC, but pretty relevant= =0A= >>to how it would operate in the real world.=0A= >>=0A= >>David=0A= >>=0A= >>-----Original Message-----=0A= >>From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=0A= >>Sent: 12 November 2013 10:27=0A= >>To: David Lake (dlake); Surendra Kumar (smkumar); Ron Parker; Linda=0A= >>Dunbar; Hongyu Li (Julio)=0A= >>Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>Subject: RE: [nsc] Current Proposed SFC charter=0A= >>=0A= >>> In those circumstances, only the end applications themselves or a=0A= >>> reasonably broad-brushed classification (really traffic steering=0A= >>> based on what we can see at ingress) is going to be useful - is THAT=0A= >>> what we're aiming for here ?=0A= >>=0A= >>I would certainly hope not, but that has been my concern as well.=0A= >>Application layer termination and re-classification seems a must?=0A= >>=0A= >>-- Kevin J. Ma=0A= >>=0A= >>> -----Original Message-----=0A= >>> From: David Lake (dlake) [mailto:dlake@cisco.com]=0A= >>> Sent: Tuesday, November 12, 2013 1:00 PM=0A= >>> To: Surendra Kumar (smkumar); Ron Parker; Kevin J Ma; Linda Dunbar;=0A= >>> Hongyu Li (Julio)=0A= >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>>=0A= >>> Policy may be outside of the scope of SFC, but without strong mapping= =0A= >>> between Policy and the inserted Service Header(s), we run-the-risk of= =0A= >>> limiting the efficacy of the protocol IMO.=0A= >>>=0A= >>> For example, in a world where the network has "gone dark," (as per=0A= >>> the IETF Technical Plenary ?:-) ) what is our ability to determine=0A= >>> policy based on DPI of packets-in-flight ?=0A= >>>=0A= >>> In those circumstances, only the end applications themselves or a=0A= >>> reasonably broad-brushed classification (really traffic steering=0A= >>> based on what we can see at ingress) is going to be useful - is THAT=0A= >>> what we're aiming for here ?=0A= >>>=0A= >>> David=0A= >>>=0A= >>> -----Original Message-----=0A= >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of= =0A= >>> Surendra Kumar (smkumar)=0A= >>> Sent: 12 November 2013 09:26=0A= >>> To: Ron Parker; Kevin J Ma; Linda Dunbar; Hongyu Li (Julio)=0A= >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee=0A= >>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>>=0A= >>> Ron,=0A= >>>=0A= >>> Classification of traffic is well understood and we do not have to=0A= >>> redefine it - it's been around for all the time middle boxes have=0A= >>> been or for that matter the L2/L3 devices. All we are talking about=0A= >>> is the applicability of the classification to branching in SFC.=0A= >>>=0A= >>> You are right, it is all about policy which is outside the scope of=0A= >>>SFC.=0A= >>>=0A= >>> Surendra.=0A= >>>=0A= >>> On 11/12/13 7:53 AM, "Ron Parker" =0A= >>>wrote:=0A= >>>=0A= >>> >I think the lack of definition of "reclassification" may be causing=0A= >>>some=0A= >>> >misunderstandings here. A branch would occur for some policy-driven= =0A= >>> >reason based on the behavior and conclusions of the service function,= =0A= >>> >itself. The graph would represent the fact that there is a branch=0A= >>> >point, but the service function, itself, being aware that it is a=0A= >>> >branching point would contain the policy and logic to decide on which= =0A= >>> >branch to take. Specifying that policy and logic is out of scope,=0A= >>>IMO.=0A= >>> >=0A= >>> > Ron=0A= >>> >=0A= >>> >=0A= >>> >-----Original Message-----=0A= >>> >From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=0A= >>> >Sent: Tuesday, November 12, 2013 10:49 AM=0A= >>> >To: Linda Dunbar; Ron Parker; Hongyu Li (Julio)=0A= >>> >Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar); Sumandra=0A= >>> >Majee=0A= >>> >Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >=0A= >>> >Hi Linda,=0A= >>> >=0A= >>> > Are you saying that a branching point is "never" a=0A= >>> > reclassification point, or are you saying that a branching point=0A= >>>"does not have to be"=0A= >>> > a reclassification point?=0A= >>> >=0A= >>> > I think this is an important distinction that needs to be clarified.= =0A= >>> > If branching is never reclassification, then the meaning of a=0A= >>> > chain is different than I originally inferred. If the chain is a=0A= >>> > tree with other "branching" points in it, then that limits the=0A= >>> > scope of the problem statement goals.=0A= >>> >=0A= >>> > While this could be a degenerate case, and any implementation=0A= >>> > could define bad service chains, is it the intent of SFC to only=0A= >>> > look at the simpler packet-level classification cases, or is it the= =0A= >>> > intent to consider the case where a branching point is viewed as a=0A= >>> > re-classification point?=0A= >>> >=0A= >>> >thanx.=0A= >>> >=0A= >>> >-- Kevin J. Ma=0A= >>> >=0A= >>> >> -----Original Message-----=0A= >>> >> From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= >>> >> Sent: Tuesday, November 12, 2013 10:34 AM=0A= >>> >> To: Ron Parker; Hongyu Li (Julio); Kevin J Ma=0A= >>> >> Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>> >> Sumandra Majee=0A= >>> >> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >>=0A= >>> >> Ron,=0A= >>> >>=0A= >>> >> First, want to make it clear that "branching" !=3D reclassification,= =0A= >>> >>agree?=0A= >>> >>=0A= >>> >> Second, the representation of branching (or service graph) can be=0A= >>> >> in a form of logic on a service function. Some service functions,=0A= >>> >> especially L7 based, can use value in a Database to determine what= =0A= >>> >> is the next service function.=0A= >>> >>=0A= >>> >> Linda=0A= >>> >>=0A= >>> >> > -----Original Message-----=0A= >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>> >> > Behalf Of Ron Parker=0A= >>> >> > Sent: Tuesday, November 12, 2013 8:16 AM=0A= >>> >> > To: Hongyu Li (Julio); Kevin J Ma=0A= >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>> >> > Sumandra Majee=0A= >>> >> > Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> >=0A= >>> >> > Hongyu,=0A= >>> >> >=0A= >>> >> > I agree completely that re-classification is not limited to DPI.= =0A= >>> >> >=0A= >>> >> > And also, that an area for us to explore as a group is how to=0A= >>> >>represent=0A= >>> >> > the service graph. Do we want to represent it as a proper graph= =0A= >>> with=0A= >>> >> > an adjacency list or other representational model? Or, do we=0A= >>>want=0A= >>> to=0A= >>> >> > represent it as a set of linear segments and if so, how are the=0A= >>> >> > segments connected into a graph? Other ideas?=0A= >>> >> >=0A= >>> >> > Ron=0A= >>> >> >=0A= >>> >> >=0A= >>> >> > -----Original Message-----=0A= >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>> >> > Behalf Of Hongyu Li (Julio)=0A= >>> >> > Sent: Tuesday, November 12, 2013 6:57 AM=0A= >>> >> > To: Ron Parker; Kevin J Ma=0A= >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>> >> > Sumandra Majee=0A= >>> >> > Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> >=0A= >>> >> > Branching/forking is a very interesting topic of SFC. About the=0A= >>> >> > re- classification point, probably we shall not limit it to DPI.= =0A= >>> >> > It is also possible that packets go to different branches after=0A= >>> >> > been processed by a certain service function, decision of which=0A= >>> >> > branches to go is made based on the result of service function's= =0A= >>> >> > process, i.e. not just re- classification by DPI.=0A= >>> >> >=0A= >>> >> > Hongyu=0A= >>> >> >=0A= >>> >> > -----Original Message-----=0A= >>> >> > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On=0A= >>> >> > Behalf Of Ron Parker=0A= >>> >> > Sent: Tuesday, November 12, 2013 7:45 PM=0A= >>> >> > To: Kevin J Ma=0A= >>> >> > Cc: Thomas Narten; nsc@ietf.org; Surendra Kumar (smkumar);=0A= >>> >> > Sumandra Majee=0A= >>> >> > Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> >=0A= >>> >> > Hi, Kevin=0A= >>> >> >=0A= >>> >> > You ask a great question about branching the graph. The details= =0A= >>> >> > around how to convey the selection of the subtree/subgraph are=0A= >>> >> > still=0A= >>> >>to be=0A= >>> >> > defined. Is it one chain id for the whole graph? Does each=0A= >>>branch=0A= >>> >> > have its own chain id? Some combination?=0A= >>> >> >=0A= >>> >> > Ron=0A= >>> >> >=0A= >>> >> > On Nov 12, 2013, at 1:52 AM, "Kevin J Ma"=0A= >>> >> > =0A= >>> >> > wrote:=0A= >>> >> >=0A= >>> >> > >> Yes, reclassification can change the service path and=0A= >>> >> > >> re-classification may happen at any node along a service path.= =0A= >>> >> > >=0A= >>> >> > > Just to expand on that, going back to the original question=0A= >>> >> > > about service header encapsulation, is it intended that a=0A= >>> >> > > chain that is re-classified will get a new chain ID which=0A= >>> >> > > fully describes a chain that is a superset of the original=0A= >>> >> > > chain ID, prior to DPI-based re-classification? (assuming the= =0A= >>> >> > > goal is "a single chain ID that is commonly understood along=0A= >>> >> > > the entire service=0A= >>> chain"=0A= >>> >> > > http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html= =0A= >>> >> > > )=0A= >>> >> > >=0A= >>> >> > > And the applicable subset of the permutative list of service=0A= >>> >> > > paths would be configured at each appropriate service node?=0A= >>> >> > > e.g., ID 1: NAT + firewall + DPI=0A= >>> >> > > ID 2: NAT + firewall + DPI + AV=0A= >>> >> > > ID 3: NAT + firewall + DPI + AV + NAT=0A= >>> >> > > ID 4: NAT + firewall + DPI + NAT=0A= >>> >> > > ID 5: NAT + firewall + DPI + AV + LB=0A= >>> >> > > ID 6: NAT + firewall + DPI + LB=0A= >>> >> > > ID 7: NAT + firewall + DPI + LB + CACHE=0A= >>> >> > > ID 8: NAT + firewall + DPI + CACHE=0A= >>> >> > > ID 9: NAT + firewall + DPI + optimizer + LB=0A= >>> >> > > ID 10: NAT + firewall + DPI + optimizer + LB + CACHE=0A= >>> >> > > ID 11: NAT + firewall + DPI + optimizer + CACHE Would=0A= >>> >> > > every flow then be initially classified as ID 1, but=0A= >>> >> > > eventually get re-=0A= >>> >> > classified=0A= >>> >> > > to ID 2-11, after the DPI phase?=0A= >>> >> > >=0A= >>> >> > > thanx.=0A= >>> >> > >=0A= >>> >> > > -- Kevin J. Ma=0A= >>> >> > >=0A= >>> >> > >> -----Original Message-----=0A= >>> >> > >> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=0A= >>> >> > >> Sent: Tuesday, November 12, 2013 1:01 AM=0A= >>> >> > >> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=0A= >>> >> > >> nsc@ietf.org=0A= >>> >> > >> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> > >>=0A= >>> >> > >>=0A= >>> >> > >>=0A= >>> >> > >>> On 11/11/13 9:46 PM, "Kevin J Ma"=0A= >>> >> > >>> =0A= >>> >>wrote:=0A= >>> >> > >>>=0A= >>> >> > >>> Hi Surendra,=0A= >>> >> > >>>=0A= >>> >> > >>> Classification may be out of scope, but the level of service= =0A= >>> >> > >>> that=0A= >>> >> > is=0A= >>> >> > >>> applicable is dependent upon the level of classification=0A= >>> >> > >>> that can=0A= >>> >> > be=0A= >>> >> > >>> performed. An assumption of packet level encapsulation has=0A= >>> >> > >> implications=0A= >>> >> > >>> on the level of classification being performed? If the=0A= >>> >> > >>> stated=0A= >>> >> > goals=0A= >>> >> > >> are=0A= >>> >> > >>> for firewall and load balancer functionality, then the=0A= >>> >> > >>> application=0A= >>> >> > >> level=0A= >>> >> > >>> nature of those functions needs to be taken into account?=0A= >>> >> > >>> If, on the other hand, the service function scope is limited= =0A= >>> >> > >>> due to limitations in classification, that would be and=0A= >>> >> > >>> important piece of=0A= >>> >> > information?=0A= >>> >> > >>>=0A= >>> >> > >>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the=0A= >>> >> > >>> fork points of the service paths seem like re-classification= =0A= >>> points?=0A= >>> >> > >>> Is that the interpretation from the architecture perspective?= =0A= >>> >> > >>> Or is the service function chain classification exclusive of= =0A= >>> >> > >>> DPI=0A= >>> >> > functionality?=0A= >>> >> > >> I have not fully read that draft yet. But in general, as= =0A= >>> >> > >> described in the arch draft, the collection of services form=0A= >>> >> > >> a graph, segments of which are service paths. Yes,=0A= >>> >> > >> reclassification can=0A= >>> >> > change=0A= >>> >> > >> the service path and re-classification may happen at any node= =0A= >>> >> > >> along=0A= >>> >> > a service path.=0A= >>> >> > >>=0A= >>> >> > >> Surendra.=0A= >>> >> > >>>=0A= >>> >> > >>> thanx.=0A= >>> >> > >>>=0A= >>> >> > >>> -- Kevin J. Ma=0A= >>> >> > >>>=0A= >>> >> > >>>> -----Original Message-----=0A= >>> >> > >>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]=0A= >>> >> > >>>> Sent: Tuesday, November 12, 2013 12:08 AM=0A= >>> >> > >>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten;=0A= >>> >> > >>>> nsc@ietf.org=0A= >>> >> > >>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>=0A= >>> >> > >>>> Kevin,=0A= >>> >> > >>>>=0A= >>> >> > >>>> Classification mechanism is outside the scope of SFC. It=0A= >>> >> > >>>> can be based=0A= >>> >> > >> on=0A= >>> >> > >>>> the packet or information not in the packet(environmental=0A= >>> >> > >>>> attributes=0A= >>> >> > >> for=0A= >>> >> > >>>> instance) or a combination thereof. What is important is=0A= >>> >> > >>>> that such classification aids in traffic selection and=0A= >>> >> > >>>> service path identification.=0A= >>> >> > >>>> It is no different from a policy in this regard except that= =0A= >>> >> > >>>> the policy now specifies the service path.=0A= >>> >> > >>>> Further, classification is not limited to the network=0A= >>> >> > >>>> elements but the service functions as well. Some of this is= =0A= >>> >> > >>>> described in the=0A= >>> >> > >> architecture=0A= >>> >> > >>>> drafts as well -=0A= >>> >> > >>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/".=0A= >>> >> > >>>>=0A= >>> >> > >>>> Surendra.=0A= >>> >> > >>>>=0A= >>> >> > >>>>> On 11/11/13 7:33 PM, "Kevin J Ma"=0A= >>> >> > >>>>> =0A= >>> >> > wrote:=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> Hi Ron,=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> I was unable to make the SFC BoF due to a conflict with=0A= >>> >> > >>>>> CDNI, but I had a similar question wrt bullet 11 in=0A= >>> >> > >>>>> section=0A= >>> >> > >>>>> 2 of the=0A= >>> >> > problem=0A= >>> >> > >>>>> statement:=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> 11. Per-Service (re)Classification: Classification=0A= >>> >> > >>>>> occurs at=0A= >>> >> > each=0A= >>> >> > >>>>> service, independent from previously applied=0A= >>> >> > >>>>> service=0A= >>> >> > >>>> functions.=0A= >>> >> > >>>>> These unrelated classification events consume=0A= >>> >> > >>>>> resources=0A= >>> >> > per=0A= >>> >> > >>>>> service. More importantly, the classification=0A= >>> >> > functionality=0A= >>> >> > >>>>> often differs per service function and service=0A= >>> >> > >>>>> function=0A= >>> >> > >> cannot=0A= >>> >> > >>>>> leverage the results from other deployed network or= =0A= >>> >> > service.=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> as it relates to section 5.2 of the framework document:=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> The SFC Classifier classifies packets based on (some of)= =0A= >>> >> > >>>>> the=0A= >>> >> > >>>> contents=0A= >>> >> > >>>>> of the packet header. Concretely, it classifies packets= =0A= >>> >> > >>>>> based on=0A= >>> >> > >>>> the=0A= >>> >> > >>>>> possible combination of one or more header fields, such=0A= >>> >> > >>>>> as=0A= >>> >> > source=0A= >>> >> > >>>>> address, destination address, DS field, protocol ID,=0A= >>> >> > >>>>> source=0A= >>> >> > port=0A= >>> >> > >>>> and=0A= >>> >> > >>>>> destination port numbers, and any other information.=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> A packet-based classifier as described in the framework=0A= >>> >> > >>>>> document=0A= >>> >> > >>>> would=0A= >>> >> > >>>>> seem to be limited in what it can classify? The service=0A= >>> >> > >>>>> function identifier lookup does not seem to be a=0A= >>> >> > >>>>> significant optimization=0A= >>> >> > >> over=0A= >>> >> > >>>>> a packet-based 5-tuple lookup? There seems to be some=0A= >>> >> > >>>>> missing=0A= >>> >> > >> detail=0A= >>> >> > >>>>> wrt how classification information is determined and reused?= =0A= >>> >> > >>>>>=0A= >>> >> > >>>>> When thinking about higher level services, e.g., HTTP and=0A= >>> >> > >>>>> TLS=0A= >>> >> > >>>> encrypted=0A= >>> >> > >>>>> flows, a packet-based classifier seems inadequate? I was=0A= >>> >> > >>>>> also=0A= >>> >> > >>>> wondering=0A= >>> >> > >>>>> how independent HLS segment requests might be classified=0A= >>> >> > >>>>> and=0A= >>> >> > >>>> associated?=0A= >>> >> > >>>>> Were these types of use cases discussed in the BoF?=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> thanx.=0A= >>> >> > >>>>>=0A= >>> >> > >>>>> -- Kevin J. Ma=0A= >>> >> > >>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=0A= >>> >> > >>>>>> On Behalf=0A= >>> >> > >> Of=0A= >>> >> > >>>>>> Ron=0A= >>> >> > >>>>>> Parker=0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:16 PM=0A= >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Sumandra,=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> As was discussed in Vancouver, there are already many=0A= >>> >> > >>>>>> existing ways=0A= >>> >> > >>>> to=0A= >>> >> > >>>>>> accomplish service chaining. But none of them provide a= =0A= >>> >> > >>>> sufficient=0A= >>> >> > >>>>>> combination of interoperability, flexibility, and=0A= >>>resiliency.=0A= >>> >> > A=0A= >>> >> > >>>> single=0A= >>> >> > >>>>>> service chain encapsulation will go a long way to=0A= >>> >> > >>>>>> ensuring these=0A= >>> >> > >>>> goals.=0A= >>> >> > >>>>>> It may not be the absolutely most efficient approach for= =0A= >>> >> > >>>>>> every=0A= >>> >> > >>>> single=0A= >>> >> > >>>>>> network topology and every single use case, but its=0A= >>> >> > >>>>>> ubiquitous=0A= >>> >> > >> nature=0A= >>> >> > >>>>>> should improve its adoption.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Ron=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 10:10 PM=0A= >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Ron,=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Absolutely, that was an example of one type of derivation.= =0A= >>> >> > >>>>>> However=0A= >>> >> > >>>> this=0A= >>> >> > >>>>>> could be augmented with classification result, again one=0A= >>> >> > >>>>>> more=0A= >>> >> > >>>> example.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>>> All flows from the same source IP do not necessarily=0A= >>> >> > >>>>>>>> follow=0A= >>> >> > the=0A= >>> >> > >>>> same=0A= >>> >> > >>>>>> chain.=0A= >>> >> > >>>>>> Correct. It is also not necessary that all transaction of= =0A= >>> >> > >>>>>> the same=0A= >>> >> > >>>> flow=0A= >>> >> > >>>>>> follow the same chain either. So why stop at flow itself.= =0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Again the point here is that do we always need SFC header= =0A= >>> >> > >>>>>> or=0A= >>> >>Not.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Sumandra=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]= =0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 7:02 PM=0A= >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Sumandra,=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> The intention of service function chaining is to allow=0A= >>> >> > >>>>>> for operation=0A= >>> >> > >>>> at=0A= >>> >> > >>>>>> the fully qualified flow level, or even finer grained at=0A= >>> >> > >>>>>> the=0A= >>> >> > >>>> transaction=0A= >>> >> > >>>>>> level (this is an implementation matter for the PDP).=0A= >>>All=0A= >>> >> > flows=0A= >>> >> > >>>> from=0A= >>> >> > >>>>>> the same source IP do not necessarily follow the same=0A= >>>chain.=0A= >>> >> > >> Source=0A= >>> >> > >>>>>> IP,=0A= >>> >> > >>>>>> therefore, does not identify the chain ID. Another=0A= >>> >>intention=0A= >>> >> > of=0A= >>> >> > >>>>>> service function chaining is to operate over any network=0A= >>> >> > topology=0A= >>> >> > >> and=0A= >>> >> > >>>>>> not=0A= >>> >> > >>>>>> be limited to a single LAN. Thus, while VLAN may be part= =0A= >>>of=0A= >>> >> > the=0A= >>> >> > >>>>>> transport, it does not adequately identify the service=0A= >>> >> > >>>>>> chain,=0A= >>> >> > >> either.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Ron=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com]=0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 9:56 PM=0A= >>> >> > >>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Ron,=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> The service header is meant to carry the context which=0A= >>> >> > >>>>>> can=0A= >>> >> > *also*=0A= >>> >> > >>>>>> be derived (for example use source ip and vlan to=0A= >>> >> > >>>>>> identify chainID and=0A= >>> >> > >>>>>> position) or encapsulated as part of another tunnel header.= =0A= >>> >> > >>>>>> So this could be optional IMHO.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]= =0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 4:36 PM=0A= >>> >> > >>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: RE: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Sumandra,=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> As I understand it, an SFC packet traversing from PDP to=0A= >>> >> > >>>>>> SF or from=0A= >>> >> > >>>> SF=0A= >>> >> > >>>>>> to=0A= >>> >> > >>>>>> SF will look like:=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> +------------------------+=0A= >>> >> > >>>>>> | "transport" |=0A= >>> >> > >>>>>> +------------------------+=0A= >>> >> > >>>>>> | service header |=0A= >>> >> > >>>>>> +------------------------+=0A= >>> >> > >>>>>> | original IP header |=0A= >>> >> > >>>>>> +------------------------+=0A= >>> >> > >>>>>> | | original IP=0A= >>> >> > >>>>>> | payload=0A= >>> >> > |=0A= >>> >> > >>>>>> | |=0A= >>> >> > >>>>>> +------------------------+=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Where service header contains, at a minimum, enough=0A= >>> >> > >>>>>> information to=0A= >>> >> > >>>> allow=0A= >>> >> > >>>>>> the packet to be propagated along the full length of the=0A= >>> >> > >>>>>> chain, and optionally, other metadata that enhances the=0A= >>> >> > >>>>>> operation of=0A= >>> >> > one=0A= >>> >> > >>>>>> or=0A= >>> >> > >> more=0A= >>> >> > >>>>>> service functions.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> And where "transport" could conceivably be any of, but=0A= >>> >> > >>>>>> not limited=0A= >>> >> > >>>> to:=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> * Ethernet=0A= >>> >> > >>>>>> * Ethernet + LLC2=0A= >>> >> > >>>>>> * Ethernet + MPLS=0A= >>> >> > >>>>>> * Ethernet + IP + GRE=0A= >>> >> > >>>>>> * Ethernet + IP +UDP=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Also, "original" in the diagram above is not meant to=0A= >>> >> > >>>>>> imply immutability, but rather to specify the packet that= =0A= >>> >> > >>>>>> is=0A= >>> >> > propagated=0A= >>> >> > >>>>>> from preceding entity to succeeding entity, prior to=0A= >>> >> > >>>>>> encapsulation.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Ron=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=0A= >>> >> > >>>>>> On Behalf=0A= >>> >> > >> Of=0A= >>> >> > >>>>>> Sumandra Majee=0A= >>> >> > >>>>>> Sent: Monday, November 11, 2013 6:46 PM=0A= >>> >> > >>>>>> To: Thomas Narten; nsc@ietf.org=0A= >>> >> > >>>>>> Subject: Re: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Generic Service Function Chaining Encapsulation: A=0A= >>> >> > >>>>>> document=0A= >>> >>will=0A= >>> >> > >>>>>> describe the single service-level data plane=0A= >>> >> > >>>>>> encapsulation=0A= >>> >> > >> format=0A= >>> >> > >>>>>> for=0A= >>> >> > >>>>>> conveying the service function chain and the service=0A= >>> >> > >>>>>> function=0A= >>> >> > >>>> path,=0A= >>> >> > >>>>>> and for communicating context information between=0A= >>> >> > >>>>>> nodes=0A= >>> that=0A= >>> >> > >>>>>> implement service functions. It is intended that the=0A= >>> >> > >>>> encapsulation=0A= >>> >> > >>>>>> be agnostic to the layer at which it is applied and=0A= >>> >> > >>>>>> the service=0A= >>> >> > >>>> that=0A= >>> >> > >>>>>> is=0A= >>> >> > >>>>>> being constructed. That is, the same encapsulation may= =0A= >>> >> > >>>>>> be=0A= >>> >> > used=0A= >>> >> > >> on=0A= >>> >> > >>>>>> a service function path realized at the network layer=0A= >>> >> > >>>>>> or at any other=0A= >>> >> > >>>>>> layer, and the same encapsulation will apply for the=0A= >>> >> > >> construction=0A= >>> >> > >>>> of=0A= >>> >> > >>>>>> service function paths regardless of the actual service.= =0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> [SM] What does it mean by a single service-level=0A= >>> >> > >>>>>> encapsulation,=0A= >>> >> > a=0A= >>> >> > >>>> new=0A= >>> >> > >>>>>> encapsulation format=0A= >>> >> > >>>>>> or an ability to select one encapsulation=0A= >>> >> > >>>>>> format that=0A= >>> >> > >>>> fits=0A= >>> >> > >>>>>> the=0A= >>> >> > >>>>>> need for a given service chain?=0A= >>> >> > >>>>>> The ability to select a specific encapsulation=0A= >>> >> > >>>>>> would be=0A= >>> >> > >> a=0A= >>> >> > >>>>>> management plane decision.=0A= >>> >> > >>>>>> There are quite a few existing encapsulation=0A= >>> >> > >>>>>> methods that=0A= >>> >> > >>>> can=0A= >>> >> > >>>>>> possibly be reused to provide=0A= >>> >> > >>>>>> context information between service nodes. I=0A= >>>have=0A= >>> >> > seen=0A= >>> >> > >>>>>> mention=0A= >>> >> > >>>>>> of GRE, for HTTP based=0A= >>> >> > >>>>>> applications contexts are transferred via headers.= =0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> -----Original Message-----=0A= >>> >> > >>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org]=0A= >>> >> > >>>>>> On Behalf=0A= >>> >> > >> Of=0A= >>> >> > >>>>>> Thomas Narten=0A= >>> >> > >>>>>> Sent: Wednesday, November 06, 2013 11:07 AM=0A= >>> >> > >>>>>> To: nsc@ietf.org=0A= >>> >> > >>>>>> Subject: [nsc] Current Proposed SFC charter=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Hi.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Current charter can be found at=0A= >>> >> > >>>>>> https://datatracker.ietf.org/doc/charter-=0A= >>> >> > >>>>>> ietf-sfc/.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> It contains the revised management text as well as=0A= >>> >> > >>>>>> updated=0A= >>> >> > >>>> milestones.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> All known issues have been addressed. If there are any=0A= >>> >> > >>>>>> remaining=0A= >>> >> > >>>> issues,=0A= >>> >> > >>>>>> please speak up!=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Charter charter-ietf-sfc-00-04=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Networks, servers, storage technologies, and=0A= >>> >> > >>>>>> applications, have all undergone significant change in=0A= >>> >> > >>>>>> recent years with the introduction=0A= >>> >> > >> of=0A= >>> >> > >>>>>> virtualization, network overlays, and orchestration.=0A= >>> >> > >>>>>> Service=0A= >>> >> > >> delivery=0A= >>> >> > >>>> is=0A= >>> >> > >>>>>> currently both a technical and organizational challenge=0A= >>> >> > >>>>>> that=0A= >>> >> > >> involves=0A= >>> >> > >>>>>> significant modification to the network configuration.=0A= >>> >> > >>>>>> Services are typically implemented by the ordered=0A= >>> >> > >>>>>> combination of a number of service functions that are=0A= >>> >> > >>>>>> deployed at different points within=0A= >>> >> > >> the=0A= >>> >> > >>>>>> network. Today, a common deployment model has service=0A= >>> >> > >>>>>> functions physically inserted on the data forwarding path= =0A= >>> >> > >>>>>> between communicating peers.=0A= >>> >> > >>>> Going=0A= >>> >> > >>>>>> forward, however, there is a desire to move to a=0A= >>> >> > >>>>>> different model,=0A= >>> >> > >>>> where=0A= >>> >> > >>>>>> service functions are not required to reside on the=0A= >>> >> > >>>>>> default data=0A= >>> >> > >> path=0A= >>> >> > >>>>>> and=0A= >>> >> > >>>>>> traffic is instead steered through services, wherever=0A= >>> >> > >>>>>> they are=0A= >>> >> > >>>> deployed.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> For a given service, the abstracted view of the required=0A= >>> >> > >>>>>> service functions and the order in which they are to be=0A= >>> >> > >>>>>> applied is=0A= >>> >> > called=0A= >>> >> > >>>>>> a Service Function Chain (SFC). Since a given service=0A= >>> >> > >>>>>> function may be available on more than one node within a=0A= >>> >> > >>>>>> network, a Service Function Chain is instantiated=0A= >>> >> > >>>> via=0A= >>> >> > >>>>>> the selection of specific service function instances and=0A= >>> >> > >>>>>> the network nodes on which they are provided, thereby=0A= >>> >> > >>>>>> forming a service topology:=0A= >>> >> > >>>>>> this is called a Service Function Path. The service=0A= >>> >> > >>>>>> functions=0A= >>> >> > may=0A= >>> >> > >>>>>> be applied at a specific layer within the network=0A= >>> >> > >>>>>> protocol stack=0A= >>> >> > >>>> (network=0A= >>> >> > >>>>>> layer, application layer, etc.).=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> The Service Function Chaining (SFC) working group will=0A= >>> >> > >>>>>> develop new approaches to service delivery and deployment.= =0A= >>> >> > >>>>>> It will produce a framework for service function chaining= =0A= >>> >> > >>>>>> that includes the necessary protocols=0A= >>> >> > >>>> or=0A= >>> >> > >>>>>> protocol extensions to convey the service path and=0A= >>> >> > >>>>>> service path information to nodes that implement service=0A= >>> >> > >>>>>> functions, as well=0A= >>> >> > as=0A= >>> >> > >>>>>> mechanisms for steering traffic through service functions.= =0A= >>> >> > >>>>>> The=0A= >>> >> > >>>> working=0A= >>> >> > >>>>>> group will also examine what information needs to be=0A= >>> >> > >>>>>> gathered from=0A= >>> >> > >>>> the=0A= >>> >> > >>>>>> network and service functions in support of service=0A= >>> >> > >>>>>> function=0A= >>> >> > >> chaining=0A= >>> >> > >>>>>> and=0A= >>> >> > >>>>>> how that information may be made available to nodes that=0A= >>> >> > >>>>>> implement=0A= >>> >> > >>>> the=0A= >>> >> > >>>>>> service functions.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Specifically, the SFC WG is chartered to deliver the=0A= >>> following:=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> 1) Problem Statement: This document will provide a=0A= >>> >> > >>>>>> summary of=0A= >>> >> > the=0A= >>> >> > >>>>>> problem space to be addressed by the WG including=0A= >>> >> > >>>>>> example=0A= >>> >> > high-=0A= >>> >> > >>>>>> level use cases. Additionally, the WG will normalize=0A= >>> >> > >> nomenclature=0A= >>> >> > >>>>>> and definitions for service function chaining.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> 2) Architecture: This document will provide a description= =0A= >>> >> > >>>>>> of=0A= >>> >>the=0A= >>> >> > >>>>>> architectural building blocks and their relationships=0A= >>> >> > including=0A= >>> >> > >>>>>> interconnection, placement of capabilities, management,= =0A= >>> >> > >>>>>> diagnostics, design analysis, and security models, as=0A= >>> >> > >>>>>> well=0A= >>> >>as=0A= >>> >> > >>>>>> requirements on the protocol mechanisms.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> 3) Generic Service Function Chaining Encapsulation: A=0A= >>> >> > >>>>>> document=0A= >>> >> > will=0A= >>> >> > >>>>>> describe the single service-level data plane=0A= >>> >> > >>>>>> encapsulation=0A= >>> >> > >> format=0A= >>> >> > >>>>>> for=0A= >>> >> > >>>>>> conveying the service function chain and the service=0A= >>> >> > >>>>>> function=0A= >>> >> > >>>> path,=0A= >>> >> > >>>>>> and for communicating context information between=0A= >>> >> > >>>>>> nodes=0A= >>> that=0A= >>> >> > >>>>>> implement service functions. It is intended that the=0A= >>> >> > >>>> encapsulation=0A= >>> >> > >>>>>> be agnostic to the layer at which it is applied and=0A= >>> >> > >>>>>> the service=0A= >>> >> > >>>> that=0A= >>> >> > >>>>>> is=0A= >>> >> > >>>>>> being constructed. That is, the same encapsulation may= =0A= >>> >> > >>>>>> be=0A= >>> >> > used=0A= >>> >> > >> on=0A= >>> >> > >>>>>> a service function path realized at the network layer=0A= >>> >> > >>>>>> or at any other=0A= >>> >> > >>>>>> layer, and the same encapsulation will apply for the=0A= >>> >> > >> construction=0A= >>> >> > >>>> of=0A= >>> >> > >>>>>> service function paths regardless of the actual service.= =0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> 4) Control Plane Mechanisms: A set of documents will be=0A= >>> >> > developed to=0A= >>> >> > >>>>>> describe requirements and protocols necessary to=0A= >>> >> > >>>>>> convey=0A= >>> >> > >>>> information=0A= >>> >> > >>>>>> to service function implementation points. Where=0A= >>> >> > >>>>>> possible,=0A= >>> >> > >>>> existing=0A= >>> >> > >>>>>> IETF protocols will be used and extended. All protocol= =0A= >>> >> > >> extensions=0A= >>> >> > >>>>>> work should be carried out in the working groups=0A= >>> >> > >>>>>> responsible for=0A= >>> >> > >>>> the=0A= >>> >> > >>>>>> protocols being modified in coordination with this=0A= >>> >> > >>>>>> working=0A= >>> >> > >> group,=0A= >>> >> > >>>>>> but=0A= >>> >> > >>>>>> may be done in this working group after agreement with= =0A= >>> >> > >>>>>> all=0A= >>> >> > the=0A= >>> >> > >>>>>> relevant WG chairs and responsible ADs.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> 5) Manageability: Work on the management and=0A= >>> >> > >>>>>> configuration of=0A= >>> >> > >> service=0A= >>> >> > >>>>>> functions in support of SFC components will certainly=0A= >>> >> > >>>>>> be=0A= >>> >> > needed,=0A= >>> >> > >>>>>> but first needs to be better understood and scoped.=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Proposed Milestones=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Apr 2014 Submit to IESG Informational document(s)=0A= >>> >> > >>>>>> defining the=0A= >>> >> > >>>> problem=0A= >>> >> > >>>>>> statement and core use cases for Service Function=0A= >>> >> > >>>>>> Chaining=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> May 2014 Consult with OPS Area on possible charter=0A= >>> >> > >>>>>> modifications for management and configuration of SFC=0A= >>> >> > >>>>>> components=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Jan 2015 Submit to IESG Informational document defining=0A= >>> >> > >>>>>> the=0A= >>> >> > >>>> architecture=0A= >>> >> > >>>>>> for SFC=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Jan 2015 Submit to IESG requirements for a generic=0A= >>> >> > >>>>>> service function chaining encapsulation protocol=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Aug 2015 Submit to IESG Standards Track document=0A= >>> >> > >>>>>> specifying the=0A= >>> >> > >>>> generic=0A= >>> >> > >>>>>> service function chaining header encapsulation=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> Thomas=0A= >>> >> > >>>>>>=0A= >>> >> > >>>>>> _______________________________________________=0A= >>> >> > >>>>>> nsc mailing list=0A= >>> >> > >>>>>> nsc@ietf.org=0A= >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > >>>>>> _______________________________________________=0A= >>> >> > >>>>>> nsc mailing list=0A= >>> >> > >>>>>> nsc@ietf.org=0A= >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > >>>>>> _______________________________________________=0A= >>> >> > >>>>>> nsc mailing list=0A= >>> >> > >>>>>> nsc@ietf.org=0A= >>> >> > >>>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > >>>>> _______________________________________________=0A= >>> >> > >>>>> nsc mailing list=0A= >>> >> > >>>>> nsc@ietf.org=0A= >>> >> > >>>>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > >=0A= >>> >> > _______________________________________________=0A= >>> >> > nsc mailing list=0A= >>> >> > nsc@ietf.org=0A= >>> >> > https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > _______________________________________________=0A= >>> >> > nsc mailing list=0A= >>> >> > nsc@ietf.org=0A= >>> >> > https://www.ietf.org/mailman/listinfo/nsc=0A= >>> >> > _______________________________________________=0A= >>> >> > nsc mailing list=0A= >>> >> > nsc@ietf.org=0A= >>> >> > https://www.ietf.org/mailman/listinfo/nsc=0A= >>>=0A= >>> _______________________________________________=0A= >>> nsc mailing list=0A= >>> nsc@ietf.org=0A= >>> https://www.ietf.org/mailman/listinfo/nsc=0A= >>_______________________________________________=0A= >>nsc mailing list=0A= >>nsc@ietf.org=0A= >>https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From mehmet.ersue@nsn.com Sun Nov 17 06:07:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4011E8115 for ; Sun, 17 Nov 2013 06:07:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kw8kcITcOp+0 for ; Sun, 17 Nov 2013 06:07:40 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEBD11E8D2A for ; Sun, 17 Nov 2013 06:07:39 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAHE7LI9002291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 17 Nov 2013 15:07:21 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAHE7Lj3004518 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Nov 2013 15:07:21 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.220]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 15:07:20 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAP//5+wAgAADV4CAAA7jAIAHzLoA Date: Sun, 17 Nov 2013 14:07:20 +0000 Message-ID: References: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> In-Reply-To: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.101] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 38508 X-purgate-ID: 151667::1384697241-00005753-955365E2/0-0/0-0 Cc: "nsc@ietf.org" , ext Benoit Claise , "ext Diego R. Lopez" , "adrian.farrel@huawei.com" , ext Melinda Shore Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 14:07:44 -0000 RGVhciBTRkMgQ2hhaXJzLCBBbGwsDQoNCkFGQUlLIHRoZSBtYW5hZ2VtZW50IG9mIFNGQyBvciBz ZXJ2aWNlIGdyYXBocyBpbiBnZW5lcmFsIG5lZWRzIHRvIGFkZHJlc3M6DQoNCi0gdGhlIG9yY2hl c3RyYXRpb24gb2YgYSBzZXJ2aWNlIGdyYXBoIGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiBpbiBh IG1vZGVsIHVzZWQgYXMgaW5wdXQsDQotIGxpZmVjeWNsZSBtYW5hZ2VtZW50IG9mIG5ldHdvcmsg c2VydmljZXMgYW5kIHBvc3NpYmx5IG9mIHNpbmdsZSBWTkZzLA0KLSBGQ0FQUyBhcyB3ZWxsIGFz IG1hbmFnZW1lbnQgb2YgdmlydHVhbGl6YXRpb24gcmVsYXRlZCBldmVudHMgKGUuZy4gbW9uaXRv cmluZyBhbmQgY29ycmVsYXRpb24gb2YgdmlydHVhbGl6YXRpb24gZXZlbnRzKQ0KLSBzcGVjaWZp Y2F0aW9uIG9mIHJlbGV2YW50IGluZm9ybWF0aW9uIG1vZGVscyBhbmQgdGhlIHN0YW5kYXJkaXph dGlvbiBvZiBuZWNlc3NhcnkgZGF0YSBtb2RlbHMuDQoNCkFGQUlVIGl0IGlzIG5vdCBlYXN5IHRv IGFkZHJlc3MgYWxsIG9mIHRoZXNlIG1hbmFnZW1lbnQgYXNwZWN0cyBpbiB0aGUgZnV0dXJlIFNG QyBXRyBhbmQgYSBwYXJhbGxlbCB3b3JrIGluIE9QUyBhcmVhIG1pZ2h0IGJlIHVzZWZ1bCBpZiBz dGFydGVkIGVhcmx5Lg0KDQpQbGVhc2UgZWxhYm9yYXRlIGFuZCBhcmd1ZSBvdGhlcndpc2UuDQoN CkNoZWVycywgDQpNZWhtZXQgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIGV4dCBEaWVnbyBSLg0KPiBMb3Bleg0KPiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJl ciAxMiwgMjAxMyA0OjQ2IFBNDQo+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0KPiBDYzog VGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnOyBTdW1hbmRyYSBNYWplZTsgS2V2aW4gSiBNYTsg Um9uIFBhcmtlcjsgSm9lbCBNLg0KPiBIYWxwZXJuOyBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikN Cj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4gDQo+ IExldCBtZSBhZGQgZm9yIHRoZSByZWNvcmQgdGhhdCB0aGlzIGlzIHRoZSBraW5kIG9mIG1hbmFn ZW1lbnQgYXNwZWN0cyBJIGhhZCBpbiBtaW5kDQo+IHdoZW4gd2Ugd2VyZSB0YWxraW5nIGFib3V0 IHNlcnZpY2UgbWV0YWRhdGEgYW5kIGhvdyB0byBleGNoYW5nZSB0aGVtLi4uDQo+IA0KPiBCZSBn b29kZSwNCj4gDQo+IE9uIDEyIE5vdiAyMDEzLCBhdCAxNTo1MiAsIEppbSBHdWljaGFyZCAoamd1 aWNoYXIpIHdyb3RlOg0KPiANCj4gPiBZZXMgb3B0aW1pemF0aW9uIGNhbiBjZXJ0YWlubHkgYmUg YnVpbHQgaW50byB0aGlzIGJ1dCBJIHdhbnRlZCB0byBzaG93IGFuDQo+ID4gZXhhbXBsZSBvZiB0 aGUgdHlwZXMgb2YgdGhpbmdzIHdlIG1lYW4gd2hlbiB3ZSB0YWxrIGFib3V0IGJyYW5jaGluZy4g T25jZQ0KPiA+IHRoZSBjb25jZXB0IGlzIGJldHRlciB1bmRlcnN0b29kIEkgdGhpbmsgd2Ugd2ls bCBzZWUgc29tZSBtb3JlIGV4Y2l0aW5nDQo+ID4gZXhhbXBsZXMuIE5vdGUgYWxzbyB0aGF0IHRo ZSBjb250cm9sIGxvZ2ljIGNvdWxkIGFsc28gdXRpbGl6ZSB0aGUgc2VydmljZQ0KPiA+IGVuY2Fw c3VsYXRpb24gYXMgYSBtZWNoYW5pc20gdG8gcHVzaCBub3RpZmljYXRpb25zIGJhY2sgdXAgdGhl IG9yaWdpbmFsDQo+ID4gY2hhaW4gdG8gaW5mb3JtIHRoZSBpbmdyZXNzIHRvIGJ5cGFzcyB0aGUg b3JpZ2luYWwgY2hhaW4gZm9yIGFsbA0KPiA+IHN1YnNlcXVlbnQgcGFja2V0cyBmb3IgdGhpcyBm bG93Lg0KPiA+DQo+ID4gT24gMTEvMTIvMTMgOTo0MCBBTSwgIkpvZWwgTS4gSGFscGVybiIgPGpt aEBqb2VsaGFscGVybi5jb20+IHdyb3RlOg0KPiA+DQo+ID4+IEppbSwgdGhhbmsgeW91IGZvciBh IGNvbmNyZXRlIGV4YW1wbGUuDQo+ID4+IEkgd291bGQgc3VnZ2VzdCB0aGF0IGluIHRoZSB1c3Vh bCBjYXNlcywgdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRvIGhhbmRsZQ0KPiA+PiB0aGlzIHRoYW4g YnJhbmNoaW5nIGFuZCByZXdyaXRpbmcgYXQgdGhlIFBDUkYuDQo+ID4+DQo+ID4+IElmIHRoZSBE UEkgZW5naW5lIG9yIFBDUkYgbG9naWMgKHdoaWNoZXZlciBtYWtlcyB0aGUgZGVjaXNpb24pIG5v dGlmaWVzDQo+ID4+IHRoZSBjb250cm9sIGxvZ2ljIGFib3V0IHRoZSBkZWNpc2lvbiBmb3IgdGhl IGZsb3csIHRoZW4gdGhlIGluZ3Jlc3MgY2FuDQo+ID4+IGRpcmVjdCBzdWJzZXF1ZW50IHBhY2tl dHMgdG8gdGhlIGNvcnJlY3QgcGxhY2UsIGF2b2lkaW5nIG5lZWRsZXNzDQo+ID4+IHByb2Nlc3Np bmcgb2YgZnVydGhlciBwYWNrZXRzIGluIHRoZSBEUEkgYW5kIFBDUkYgbG9naWMuDQo+ID4+IEZ1 cnRoZXIsIHRoZSBuZWVkZWQgY29udHJvbCBpbmZvcm1hdGlvbiBjYW4gYmUgcGFzc2VkIHRvIHRo ZQ0KPiA+PiBvcHRpbWl6YXRpb24gb3IgcGFyZW50YWwgY29udHJvbCBzbyB0aGF0IGl0IGRvZXMg bm90IG1hdHRlciB3aGVyZSB0aGUNCj4gPj4gZmlyc3QgcGFja2V0IGlzIHNlbnQsIGF2b2lkaW5n IHRoZSBuZWVkIGZvciB0aGUgUENSRiB0byB1bmRlcnN0YW5kIGhvdw0KPiA+PiB0byBkaXJlY3Qg cGFja2V0cyB0byBzZXJ2aWNlIHBhdGhzLg0KPiA+Pg0KPiA+PiBZb3VycywNCj4gPj4gSm9lbA0K PiA+Pg0KPiA+PiBPbiAxMS8xMi8xMyA5OjA3IEFNLCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSB3 cm90ZToNCj4gPj4+IEhpIEtldmluLA0KPiA+Pj4NCj4gPj4+IExldCBtZSB0cnkgYW5kIHByb3Zp ZGUgYSBjb25jcmV0ZSBleGFtcGxlIHRvIHNlZSBpZiB0aGlzIGFuc3dlcnMgeW91cg0KPiA+Pj4g c3BlY2lmaWMgcXVlc3Rpb246DQo+ID4+Pg0KPiA+Pj4gVXNlIGNhc2U6IFAtR1cgLT4gUENSRiAt PiBzZXJ2aWNlcyBhcHBsaWVkIHRvIHRyYWZmaWMgYmFzZWQgb24NCj4gPj4+IGFwcGxpY2F0aW9u SUQgYW5kIHN1YnNjcmliZXJJRC4NCj4gPj4+DQo+ID4+PiBJbnN0YW50aWF0ZWQgYXM6DQo+ID4+ Pg0KPiA+Pj4gU0ZDMTogUC1HVyAtPiBEUEkgLT4gUENSRg0KPiA+Pj4gU0ZDMjogUENSRiAtPiB2 aWRlby1vcHRpbWl6YXRpb24gLT4gbWV0ZXJpbmcgLT4gRlcNCj4gPj4+IFNGQzM6IFBDUkYgLT4g cGFyZW50YWwtY29udHJvbCAtPiBtZXRlcmluZyAtPiBGVw0KPiA+Pj4NCj4gPj4+IEluIHRoaXMg Y2FzZSBEUEkgaXMgcGVyZm9ybWVkIG9uIFNGQzEgYW5kIGlkZW50aWZpZXMgYXBwbGljYXRpb25J RC4gVGhlDQo+ID4+PiBhcHBsaWNhdGlvbklEIGlzIGNhcnJpZWQgaW4gdGhlIHNlcnZpY2UgZW5j YXBzdWxhdGlvbiB0byBQQ1JGLiBQQ1JGIHVzZXMNCj4gPj4+IHNvbHV0aW9uIHNwZWNpZmljIGxv Z2ljIChpZGVudGlmaWVzIHN1YnNjcmliZXIsIGFwcGxpZXMgcG9saWNpZXMsIGV0YykNCj4gPj4+ IGFuZA0KPiA+Pj4gdXNlcyB0aGUgcmVzdWx0IGFsb25nIHdpdGggdGhlIGFwcGxpY2F0aW9uSUQg cmVjZWl2ZWQgZnJvbSBEUEkgdG8gc2VsZWN0DQo+ID4+PiBhbiBvdXRib3VuZCBzZXJ2aWNlIGNo YWluLCBTRkMyIG9yIFNGQzMuIE5vdGUgdGhhdCBpbiB0aGlzIGNhc2UNCj4gPj4+IGJyYW5jaGlu Zw0KPiA+Pj4gb2NjdXJzIGZyb20gU0ZDMSB0byBlaXRoZXIgU0ZDMiBvciBTRkMzLg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IE9uIDExLzEyLzEzIDE6NTIgQU0sICJLZXZpbiBK IE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4+PiBZ ZXMsIHJlY2xhc3NpZmljYXRpb24gY2FuIGNoYW5nZSB0aGUgc2VydmljZSBwYXRoIGFuZA0KPiA+ Pj4+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBub2RlIGFsb25nIGEgc2Vy dmljZSBwYXRoLg0KPiA+Pj4+DQo+ID4+Pj4gSnVzdCB0byBleHBhbmQgb24gdGhhdCwgZ29pbmcg YmFjayB0byB0aGUgb3JpZ2luYWwgcXVlc3Rpb24gYWJvdXQNCj4gPj4+PiBzZXJ2aWNlIGhlYWRl ciBlbmNhcHN1bGF0aW9uLCBpcyBpdCBpbnRlbmRlZCB0aGF0IGEgY2hhaW4gdGhhdA0KPiA+Pj4+ IGlzIHJlLWNsYXNzaWZpZWQgd2lsbCBnZXQgYSBuZXcgY2hhaW4gSUQgd2hpY2ggZnVsbHkgZGVz Y3JpYmVzDQo+ID4+Pj4gYSBjaGFpbiB0aGF0IGlzIGEgc3VwZXJzZXQgb2YgdGhlIG9yaWdpbmFs IGNoYWluIElELCBwcmlvciB0bw0KPiA+Pj4+IERQSS1iYXNlZCByZS1jbGFzc2lmaWNhdGlvbj8g IChhc3N1bWluZyB0aGUgZ29hbCBpcyAiYSBzaW5nbGUNCj4gPj4+PiBjaGFpbiBJRCB0aGF0IGlz IGNvbW1vbmx5IHVuZGVyc3Rvb2QgYWxvbmcgdGhlIGVudGlyZSBzZXJ2aWNlIGNoYWluIg0KPiA+ Pj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uc2MvY3VycmVudC9tc2cw MDYzOC5odG1sKQ0KPiA+Pj4+DQo+ID4+Pj4gQW5kIHRoZSBhcHBsaWNhYmxlIHN1YnNldCBvZiB0 aGUgcGVybXV0YXRpdmUgbGlzdCBvZiBzZXJ2aWNlDQo+ID4+Pj4gcGF0aHMgd291bGQgYmUgY29u ZmlndXJlZCBhdCBlYWNoIGFwcHJvcHJpYXRlIHNlcnZpY2Ugbm9kZT8NCj4gPj4+PiBlLmcuLCBJ RCAxOiBOQVQgKyBmaXJld2FsbCArIERQSQ0KPiA+Pj4+ICAgICAgSUQgMjogTkFUICsgZmlyZXdh bGwgKyBEUEkgKyBBVg0KPiA+Pj4+ICAgICAgSUQgMzogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBB ViArIE5BVA0KPiA+Pj4+ICAgICAgSUQgNDogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBOQVQNCj4g Pj4+PiAgICAgIElEIDU6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBMQg0KPiA+Pj4+ICAg ICAgSUQgNjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBMQg0KPiA+Pj4+ICAgICAgSUQgNzogTkFU ICsgZmlyZXdhbGwgKyBEUEkgKyBMQiArIENBQ0hFDQo+ID4+Pj4gICAgICBJRCA4OiBOQVQgKyBm aXJld2FsbCArIERQSSArIENBQ0hFDQo+ID4+Pj4gICAgICBJRCA5OiBOQVQgKyBmaXJld2FsbCAr IERQSSArIG9wdGltaXplciArIExCDQo+ID4+Pj4gICAgICBJRCAxMDogTkFUICsgZmlyZXdhbGwg KyBEUEkgKyBvcHRpbWl6ZXIgKyBMQiArIENBQ0hFDQo+ID4+Pj4gICAgICBJRCAxMTogTkFUICsg ZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6ZXIgKyBDQUNIRQ0KPiA+Pj4+IFdvdWxkIGV2ZXJ5IGZs b3cgdGhlbiBiZSBpbml0aWFsbHkgY2xhc3NpZmllZCBhcyBJRCAxLCBidXQNCj4gPj4+PiBldmVu dHVhbGx5IGdldCByZS1jbGFzc2lmaWVkIHRvIElEIDItMTEsIGFmdGVyIHRoZSBEUEkgcGhhc2U/ DQo+ID4+Pj4NCj4gPj4+PiB0aGFueC4NCj4gPj4+Pg0KPiA+Pj4+IC0tICBLZXZpbiBKLiBNYQ0K PiA+Pj4+DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+IEZyb206 IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBbbWFpbHRvOnNta3VtYXJAY2lzY28uY29tXQ0KPiA+ Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxOjAxIEFNDQo+ID4+Pj4+IFRv OiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsN Cj4gPj4+Pj4gbnNjQGlldGYub3JnDQo+ID4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50 IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+ IE9uIDExLzExLzEzIDk6NDYgUE0sICJLZXZpbiBKIE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1z LmNvbT4gd3JvdGU6DQo+ID4+Pj4+DQo+ID4+Pj4+PiBIaSBTdXJlbmRyYSwNCj4gPj4+Pj4+DQo+ ID4+Pj4+PiAgQ2xhc3NpZmljYXRpb24gbWF5IGJlIG91dCBvZiBzY29wZSwgYnV0IHRoZSBsZXZl bCBvZiBzZXJ2aWNlIHRoYXQNCj4gPj4+Pj4+IGlzDQo+ID4+Pj4+PiAgYXBwbGljYWJsZSBpcyBk ZXBlbmRlbnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gdGhhdCBjYW4NCj4gPj4+ Pj4+IGJlDQo+ID4+Pj4+PiAgcGVyZm9ybWVkLiAgQW4gYXNzdW1wdGlvbiBvZiBwYWNrZXQgbGV2 ZWwgZW5jYXBzdWxhdGlvbiBoYXMNCj4gPj4+Pj4gaW1wbGljYXRpb25zDQo+ID4+Pj4+PiAgb24g dGhlIGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIGJlaW5nIHBlcmZvcm1lZD8gIElmIHRoZSBzdGF0 ZWQNCj4gPj4+Pj4+IGdvYWxzDQo+ID4+Pj4+IGFyZQ0KPiA+Pj4+Pj4gIGZvciBmaXJld2FsbCBh bmQgbG9hZCBiYWxhbmNlciBmdW5jdGlvbmFsaXR5LCB0aGVuIHRoZSBhcHBsaWNhdGlvbg0KPiA+ Pj4+PiBsZXZlbA0KPiA+Pj4+Pj4gIG5hdHVyZSBvZiB0aG9zZSBmdW5jdGlvbnMgbmVlZHMgdG8g YmUgdGFrZW4gaW50byBhY2NvdW50PyAgSWYsIG9uDQo+ID4+Pj4+PiB0aGUNCj4gPj4+Pj4+ICBv dGhlciBoYW5kLCB0aGUgc2VydmljZSBmdW5jdGlvbiBzY29wZSBpcyBsaW1pdGVkIGR1ZSB0bw0K PiA+Pj4+Pj4gbGltaXRhdGlvbnMNCj4gPj4+Pj4gaW4NCj4gPj4+Pj4+ICBjbGFzc2lmaWNhdGlv biwgdGhhdCB3b3VsZCBiZSBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIGluZm9ybWF0aW9uPw0KPiA+ Pj4+Pj4NCj4gPj4+Pj4+ICBXcnQgc2VjdGlvbiA0LjQgb2YgZHJhZnQtbGl1LXNlcnZpY2UtY2hh aW5pbmctdXNlLWNhc2VzIHRoZSBmb3JrDQo+ID4+Pj4+IHBvaW50cw0KPiA+Pj4+Pj4gIG9mIHRo ZSBzZXJ2aWNlIHBhdGhzIHNlZW0gbGlrZSByZS1jbGFzc2lmaWNhdGlvbiBwb2ludHM/ICBJcyB0 aGF0DQo+ID4+Pj4+PiB0aGUNCj4gPj4+Pj4+ICBpbnRlcnByZXRhdGlvbiBmcm9tIHRoZSBhcmNo aXRlY3R1cmUgcGVyc3BlY3RpdmU/ICBPciBpcyB0aGUNCj4gPj4+Pj4+IHNlcnZpY2UNCj4gPj4+ Pj4+ICBmdW5jdGlvbiBjaGFpbiBjbGFzc2lmaWNhdGlvbiBleGNsdXNpdmUgb2YgRFBJIGZ1bmN0 aW9uYWxpdHk/DQo+ID4+Pj4+IDxTSz4gSSBoYXZlIG5vdCBmdWxseSByZWFkIHRoYXQgZHJhZnQg eWV0LiBCdXQgaW4gZ2VuZXJhbCwgYXMNCj4gPj4+Pj4gZGVzY3JpYmVkDQo+ID4+Pj4+IGluDQo+ ID4+Pj4+IHRoZSBhcmNoIGRyYWZ0LCB0aGUgY29sbGVjdGlvbiBvZiBzZXJ2aWNlcyBmb3JtIGEg Z3JhcGgsIHNlZ21lbnRzIG9mDQo+ID4+Pj4+IHdoaWNoDQo+ID4+Pj4+IGFyZSBzZXJ2aWNlIHBh dGhzLiBZZXMsIHJlY2xhc3NpZmljYXRpb24gY2FuIGNoYW5nZSB0aGUgc2VydmljZSBwYXRoDQo+ ID4+Pj4+IGFuZA0KPiA+Pj4+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVuIGF0IGFueSBu b2RlIGFsb25nIGEgc2VydmljZSBwYXRoLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBTdXJlbmRyYS4NCj4g Pj4+Pj4+DQo+ID4+Pj4+PiB0aGFueC4NCj4gPj4+Pj4+DQo+ID4+Pj4+PiAtLSAgS2V2aW4gSi4g TWENCj4gPj4+Pj4+DQo+ID4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ Pj4+PiBGcm9tOiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgW21haWx0bzpzbWt1bWFyQGNpc2Nv LmNvbV0NCj4gPj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxMjowOCBB TQ0KPiA+Pj4+Pj4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRyYSBNYWplZTsg VGhvbWFzIE5hcnRlbjsNCj4gPj4+Pj4gbnNjQGlldGYub3JnDQo+ID4+Pj4+Pj4gU3ViamVjdDog UmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4gPj4+Pj4+Pg0KPiA+Pj4+ Pj4+IEtldmluLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gQ2xhc3NpZmljYXRpb24gbWVjaGFuaXNt IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNGQy4gSXQgY2FuIGJlDQo+ID4+Pj4+Pj4gYmFzZWQN Cj4gPj4+Pj4gb24NCj4gPj4+Pj4+PiB0aGUgcGFja2V0IG9yIGluZm9ybWF0aW9uIG5vdCBpbiB0 aGUgcGFja2V0KGVudmlyb25tZW50YWwgYXR0cmlidXRlcw0KPiA+Pj4+PiBmb3INCj4gPj4+Pj4+ PiBpbnN0YW5jZSkgb3IgYSBjb21iaW5hdGlvbiB0aGVyZW9mLiBXaGF0IGlzIGltcG9ydGFudCBp cyB0aGF0IHN1Y2gNCj4gPj4+Pj4+PiBjbGFzc2lmaWNhdGlvbiBhaWRzIGluIHRyYWZmaWMgc2Vs ZWN0aW9uIGFuZCBzZXJ2aWNlIHBhdGgNCj4gPj4+Pj4+PiBpZGVudGlmaWNhdGlvbi4NCj4gPj4+ Pj4+PiBJdCBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHBvbGljeSBpbiB0aGlzIHJlZ2FyZCBleGNl cHQgdGhhdCB0aGUNCj4gPj4+Pj4gcG9saWN5DQo+ID4+Pj4+Pj4gbm93DQo+ID4+Pj4+Pj4gc3Bl Y2lmaWVzIHRoZSBzZXJ2aWNlIHBhdGguDQo+ID4+Pj4+Pj4gRnVydGhlciwgY2xhc3NpZmljYXRp b24gaXMgbm90IGxpbWl0ZWQgdG8gdGhlIG5ldHdvcmsgZWxlbWVudHMgYnV0DQo+ID4+Pj4+IHRo ZQ0KPiA+Pj4+Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwuIFNvbWUgb2YgdGhpcyBpcyBk ZXNjcmliZWQgaW4gdGhlDQo+ID4+Pj4+IGFyY2hpdGVjdHVyZQ0KPiA+Pj4+Pj4+IGRyYWZ0cyBh cyB3ZWxsIC0NCj4gPj4+Pj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtcXVpbm4tc2ZjLWFyY2gvIi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IFN1cmVuZHJhLg0KPiA+ Pj4+Pj4+DQo+ID4+Pj4+Pj4gT24gMTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiIDxrZXZp bi5tYUBhenVraXN5c3RlbXMuY29tPg0KPiB3cm90ZToNCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBI aSBSb24sDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICBJIHdhcyB1bmFibGUgdG8gbWFrZSB0aGUg U0ZDIEJvRiBkdWUgdG8gYSBjb25mbGljdCB3aXRoIENETkksIGJ1dA0KPiA+Pj4+PiBJDQo+ID4+ Pj4+Pj4+ICBoYWQgYSBzaW1pbGFyIHF1ZXN0aW9uIHdydCBidWxsZXQgMTEgaW4gc2VjdGlvbiAy IG9mIHRoZSBwcm9ibGVtDQo+ID4+Pj4+Pj4+IHN0YXRlbWVudDoNCj4gPj4+Pj4+Pj4NCj4gPj4+ Pj4+Pj4gICAgMTEuICBQZXItU2VydmljZSAocmUpQ2xhc3NpZmljYXRpb246IENsYXNzaWZpY2F0 aW9uIG9jY3VycyBhdA0KPiA+Pj4+PiBlYWNoDQo+ID4+Pj4+Pj4+ICAgICAgICAgc2VydmljZSwg aW5kZXBlbmRlbnQgZnJvbSBwcmV2aW91c2x5IGFwcGxpZWQgc2VydmljZQ0KPiA+Pj4+Pj4+IGZ1 bmN0aW9ucy4NCj4gPj4+Pj4+Pj4gICAgICAgICBUaGVzZSB1bnJlbGF0ZWQgY2xhc3NpZmljYXRp b24gZXZlbnRzIGNvbnN1bWUgcmVzb3VyY2VzDQo+ID4+Pj4+Pj4+IHBlcg0KPiA+Pj4+Pj4+PiAg ICAgICAgIHNlcnZpY2UuICBNb3JlIGltcG9ydGFudGx5LCB0aGUgY2xhc3NpZmljYXRpb24NCj4g Pj4+Pj4gZnVuY3Rpb25hbGl0eQ0KPiA+Pj4+Pj4+PiAgICAgICAgIG9mdGVuIGRpZmZlcnMgcGVy IHNlcnZpY2UgZnVuY3Rpb24gYW5kIHNlcnZpY2UgZnVuY3Rpb24NCj4gPj4+Pj4gY2Fubm90DQo+ ID4+Pj4+Pj4+ICAgICAgICAgbGV2ZXJhZ2UgdGhlIHJlc3VsdHMgZnJvbSBvdGhlciBkZXBsb3ll ZCBuZXR3b3JrIG9yDQo+ID4+Pj4+IHNlcnZpY2UuDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICBh cyBpdCByZWxhdGVzIHRvIHNlY3Rpb24gNS4yIG9mIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQ6DQo+ ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ICAgIFRoZSBTRkMgQ2xhc3NpZmllciBjbGFzc2lmaWVzIHBh Y2tldHMgYmFzZWQgb24gKHNvbWUgb2YpIHRoZQ0KPiA+Pj4+Pj4+IGNvbnRlbnRzDQo+ID4+Pj4+ Pj4+ICAgIG9mIHRoZSBwYWNrZXQgaGVhZGVyLiAgQ29uY3JldGVseSwgaXQgY2xhc3NpZmllcyBw YWNrZXRzIGJhc2VkDQo+ID4+Pj4+IG9uDQo+ID4+Pj4+Pj4gdGhlDQo+ID4+Pj4+Pj4+ICAgIHBv c3NpYmxlIGNvbWJpbmF0aW9uIG9mIG9uZSBvciBtb3JlIGhlYWRlciBmaWVsZHMsIHN1Y2ggYXMN Cj4gPj4+Pj4gc291cmNlDQo+ID4+Pj4+Pj4+ICAgIGFkZHJlc3MsIGRlc3RpbmF0aW9uIGFkZHJl c3MsIERTIGZpZWxkLCBwcm90b2NvbCBJRCwgc291cmNlDQo+ID4+Pj4+Pj4+IHBvcnQNCj4gPj4+ Pj4+PiBhbmQNCj4gPj4+Pj4+Pj4gICAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBhbmQgYW55 IG90aGVyIGluZm9ybWF0aW9uLg0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAgQSBwYWNrZXQtYmFz ZWQgY2xhc3NpZmllciBhcyBkZXNjcmliZWQgaW4gdGhlIGZyYW1ld29yayBkb2N1bWVudA0KPiA+ Pj4+Pj4+IHdvdWxkDQo+ID4+Pj4+Pj4+ICBzZWVtIHRvIGJlIGxpbWl0ZWQgaW4gd2hhdCBpdCBj YW4gY2xhc3NpZnk/ICBUaGUgc2VydmljZSBmdW5jdGlvbg0KPiA+Pj4+Pj4+PiAgaWRlbnRpZmll ciBsb29rdXAgZG9lcyBub3Qgc2VlbSB0byBiZSBhIHNpZ25pZmljYW50IG9wdGltaXphdGlvbg0K PiA+Pj4+PiBvdmVyDQo+ID4+Pj4+Pj4+ICBhIHBhY2tldC1iYXNlZCA1LXR1cGxlIGxvb2t1cD8g IFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgbWlzc2luZw0KPiA+Pj4+PiBkZXRhaWwNCj4gPj4+Pj4+ Pj4gIHdydCBob3cgY2xhc3NpZmljYXRpb24gaW5mb3JtYXRpb24gaXMgZGV0ZXJtaW5lZCBhbmQg cmV1c2VkPw0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiAgV2hlbiB0aGlua2luZyBhYm91dCBoaWdo ZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhUVFAgYW5kIFRMUw0KPiA+Pj4+Pj4+IGVuY3J5cHRl ZA0KPiA+Pj4+Pj4+PiAgZmxvd3MsIGEgcGFja2V0LWJhc2VkIGNsYXNzaWZpZXIgc2VlbXMgaW5h ZGVxdWF0ZT8gIEkgd2FzIGFsc28NCj4gPj4+Pj4+PiB3b25kZXJpbmcNCj4gPj4+Pj4+Pj4gIGhv dyBpbmRlcGVuZGVudCBITFMgc2VnbWVudCByZXF1ZXN0cyBtaWdodCBiZSBjbGFzc2lmaWVkIGFu ZA0KPiA+Pj4+Pj4+IGFzc29jaWF0ZWQ/DQo+ID4+Pj4+Pj4+ICBXZXJlIHRoZXNlIHR5cGVzIG9m IHVzZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJvRj8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4g dGhhbnguDQo+ID4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IC0tICBLZXZpbiBKLiBNYQ0KPiA+Pj4+Pj4+ Pg0KPiA+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4+IEZy b206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPiA+Pj4+PiBPZg0KPiA+Pj4+Pj4+Pj4gUm9uDQo+ID4+Pj4+Pj4+PiBQYXJrZXIN Cj4gPj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTYgUE0NCj4g Pj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3Jn DQo+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hh cnRlcg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFN1bWFuZHJhLA0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+IEFzIHdhcyBkaXNjdXNzZWQgaW4gVmFuY291dmVyLCB0aGVyZSBhcmUgYWxyZWFk eSBtYW55IGV4aXN0aW5nDQo+ID4+Pj4+IHdheXMNCj4gPj4+Pj4+PiB0bw0KPiA+Pj4+Pj4+Pj4g YWNjb21wbGlzaCBzZXJ2aWNlIGNoYWluaW5nLiAgICAgQnV0IG5vbmUgb2YgdGhlbSBwcm92aWRl IGENCj4gPj4+Pj4+PiBzdWZmaWNpZW50DQo+ID4+Pj4+Pj4+PiBjb21iaW5hdGlvbiBvZiBpbnRl cm9wZXJhYmlsaXR5LCBmbGV4aWJpbGl0eSwgYW5kIHJlc2lsaWVuY3kuICAgQQ0KPiA+Pj4+Pj4+ IHNpbmdsZQ0KPiA+Pj4+Pj4+Pj4gc2VydmljZSBjaGFpbiBlbmNhcHN1bGF0aW9uIHdpbGwgZ28g YSBsb25nIHdheSB0byBlbnN1cmluZyB0aGVzZQ0KPiA+Pj4+Pj4+IGdvYWxzLg0KPiA+Pj4+Pj4+ Pj4gSXQgIG1heSBub3QgYmUgdGhlIGFic29sdXRlbHkgbW9zdCBlZmZpY2llbnQgYXBwcm9hY2gg Zm9yIGV2ZXJ5DQo+ID4+Pj4+Pj4gc2luZ2xlDQo+ID4+Pj4+Pj4+PiBuZXR3b3JrIHRvcG9sb2d5 IGFuZCBldmVyeSBzaW5nbGUgdXNlIGNhc2UsIGJ1dCBpdHMgdWJpcXVpdG91cw0KPiA+Pj4+PiBu YXR1cmUNCj4gPj4+Pj4+Pj4+IHNob3VsZCBpbXByb3ZlIGl0cyBhZG9wdGlvbi4NCj4gPj4+Pj4+ Pj4+DQo+ID4+Pj4+Pj4+PiAgICBSb24NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+Pj4+Pj4+IEZyb206IFN1bWFu ZHJhIE1hamVlIFttYWlsdG86Uy5NYWplZUBGNS5jb21dDQo+ID4+Pj4+Pj4+PiBTZW50OiBNb25k YXksIE5vdmVtYmVyIDExLCAyMDEzIDEwOjEwIFBNDQo+ID4+Pj4+Pj4+PiBUbzogUm9uIFBhcmtl cjsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IFJvbiwNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBBYnNvbHV0ZWx5LCB0aGF0IHdhcyBh biBleGFtcGxlIG9mIG9uZSB0eXBlIG9mIGRlcml2YXRpb24uIEhvd2V2ZXINCj4gPj4+Pj4+PiB0 aGlzDQo+ID4+Pj4+Pj4+PiBjb3VsZCBiZSBhdWdtZW50ZWQgd2l0aCBjbGFzc2lmaWNhdGlvbiBy ZXN1bHQsIGFnYWluIG9uZSBtb3JlDQo+ID4+Pj4+Pj4gZXhhbXBsZS4NCj4gPj4+Pj4+Pj4+DQo+ ID4+Pj4+Pj4+Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVj ZXNzYXJpbHkgZm9sbG93IHRoZQ0KPiA+Pj4+Pj4+IHNhbWUNCj4gPj4+Pj4+Pj4+IGNoYWluLg0K PiA+Pj4+Pj4+Pj4gQ29ycmVjdC4gSXQgaXMgYWxzbyBub3QgbmVjZXNzYXJ5IHRoYXQgYWxsIHRy YW5zYWN0aW9uIG9mIHRoZSBzYW1lDQo+ID4+Pj4+Pj4gZmxvdw0KPiA+Pj4+Pj4+Pj4gZm9sbG93 IHRoZSBzYW1lIGNoYWluIGVpdGhlci4gU28gd2h5IHN0b3AgYXQgZmxvdyBpdHNlbGYuDQo+ID4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQWdhaW4gdGhlIHBvaW50IGhlcmUgaXMgdGhhdCBkbyB3ZSBh bHdheXMgbmVlZCBTRkMgaGVhZGVyIG9yIE5vdC4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBT dW1hbmRyYQ0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+Pj4+Pj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJv bl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5jb21dDQo+ID4+Pj4+Pj4+PiBTZW50OiBNb25kYXks IE5vdmVtYmVyIDExLCAyMDEzIDc6MDIgUE0NCj4gPj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWpl ZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+ID4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTog W25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRlcg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+ Pj4+IFN1bWFuZHJhLA0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRoZSBpbnRlbnRpb24gb2Yg c2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBpcyB0byBhbGxvdyBmb3INCj4gPj4+Pj4gb3BlcmF0 aW9uDQo+ID4+Pj4+Pj4gYXQNCj4gPj4+Pj4+Pj4+IHRoZSBmdWxseSBxdWFsaWZpZWQgZmxvdyBs ZXZlbCwgb3IgZXZlbiBmaW5lciBncmFpbmVkIGF0IHRoZQ0KPiA+Pj4+Pj4+IHRyYW5zYWN0aW9u DQo+ID4+Pj4+Pj4+PiBsZXZlbCAodGhpcyBpcyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIgZm9y IHRoZSBQRFApLiAgICAgQWxsDQo+ID4+Pj4+IGZsb3dzDQo+ID4+Pj4+Pj4gZnJvbQ0KPiA+Pj4+ Pj4+Pj4gdGhlIHNhbWUgc291cmNlIElQIGRvIG5vdCBuZWNlc3NhcmlseSBmb2xsb3cgdGhlIHNh bWUgY2hhaW4uDQo+ID4+Pj4+IFNvdXJjZQ0KPiA+Pj4+Pj4+Pj4gSVAsDQo+ID4+Pj4+Pj4+PiB0 aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlmeSB0aGUgY2hhaW4gSUQuICAgIEFub3RoZXIgaW50 ZW50aW9uDQo+ID4+Pj4+IG9mDQo+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5n IGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0d29yayB0b3BvbG9neQ0KPiA+Pj4+PiBhbmQNCj4g Pj4+Pj4+Pj4+IG5vdA0KPiA+Pj4+Pj4+Pj4gYmUgbGltaXRlZCB0byBhIHNpbmdsZSBMQU4uICAg VGh1cywgd2hpbGUgVkxBTiBtYXkgYmUgcGFydCBvZiB0aGUNCj4gPj4+Pj4+Pj4+IHRyYW5zcG9y dCwgaXQgZG9lcyBub3QgYWRlcXVhdGVseSBpZGVudGlmeSB0aGUgc2VydmljZSBjaGFpbiwNCj4g Pj4+Pj4gZWl0aGVyLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ICAgIFJvbg0KPiA+Pj4+Pj4+ Pj4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+Pj4+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1LmNvbV0N Cj4gPj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgOTo1NiBQTQ0KPiA+ Pj4+Pj4+Pj4gVG86IFJvbiBQYXJrZXI7IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZw0KPiA+ Pj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXIN Cj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBSb24sDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g VGhlIHNlcnZpY2UgaGVhZGVyIGlzIG1lYW50IHRvIGNhcnJ5IHRoZSBjb250ZXh0IHdoaWNoIGNh biAqYWxzbyoNCj4gPj4+Pj4gYmUNCj4gPj4+Pj4+Pj4+IGRlcml2ZWQgKGZvciBleGFtcGxlIHVz ZSBzb3VyY2UgaXAgYW5kIHZsYW4gdG8gaWRlbnRpZnkgY2hhaW5JRA0KPiA+Pj4+PiBhbmQNCj4g Pj4+Pj4+Pj4+IHBvc2l0aW9uKSBvciBlbmNhcHN1bGF0ZWQgYXMgcGFydCBvZiBhbm90aGVyIHR1 bm5lbCBoZWFkZXIuIFNvDQo+ID4+Pj4+IHRoaXMNCj4gPj4+Pj4+Pj4+IGNvdWxkDQo+ID4+Pj4+ Pj4+PiBiZSBvcHRpb25hbCBJTUhPLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+PiBGcm9tOiBSb24gUGFya2VyIFttYWlsdG86 Um9uX1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0NCj4gPj4+Pj4+Pj4+IFNlbnQ6IE1vbmRh eSwgTm92ZW1iZXIgMTEsIDIwMTMgNDozNiBQTQ0KPiA+Pj4+Pj4+Pj4gVG86IFN1bWFuZHJhIE1h amVlOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IFN1YmplY3Q6IFJF OiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gU3VtYW5kcmEsDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gQXMgSSB1bmRlcnN0YW5k IGl0LCBhbiBTRkMgcGFja2V0IHRyYXZlcnNpbmcgZnJvbSBQRFAgdG8gU0Ygb3INCj4gPj4+Pj4g ZnJvbQ0KPiA+Pj4+Pj4+IFNGDQo+ID4+Pj4+Pj4+PiB0bw0KPiA+Pj4+Pj4+Pj4gU0Ygd2lsbCBs b29rIGxpa2U6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCj4gPj4+Pj4+Pj4+IHwgICAgICAgICJ0cmFuc3BvcnQiICAgICAgICAgfA0KPiA+Pj4+ Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4+Pj4+Pj4+IHwgICAgICBzZXJ2 aWNlIGhlYWRlciAgICB8DQo+ID4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K PiA+Pj4+Pj4+Pj4gfCAgIG9yaWdpbmFsIElQIGhlYWRlciAgfA0KPiA+Pj4+Pj4+Pj4gKy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4+Pj4+Pj4+IHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgIG9yaWdpbmFsIElQIHBheWxvYWQNCj4gPj4+Pj4gfA0KPiA+ Pj4+Pj4+Pj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBXaGVyZSBzZXJ2aWNlIGhlYWRlciBjb250YWlucywgYXQgYSBtaW5pbXVtLCBlbm91Z2gg aW5mb3JtYXRpb24gdG8NCj4gPj4+Pj4+PiBhbGxvdw0KPiA+Pj4+Pj4+Pj4gdGhlIHBhY2tldCB0 byBiZSBwcm9wYWdhdGVkIGFsb25nIHRoZSBmdWxsIGxlbmd0aCBvZiB0aGUgY2hhaW4sDQo+ID4+ Pj4+IGFuZA0KPiA+Pj4+Pj4+Pj4gb3B0aW9uYWxseSwgb3RoZXIgbWV0YWRhdGEgdGhhdCBlbmhh bmNlcyB0aGUgb3BlcmF0aW9uIG9mIG9uZSBvcg0KPiA+Pj4+PiBtb3JlDQo+ID4+Pj4+Pj4+PiBz ZXJ2aWNlIGZ1bmN0aW9ucy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiAgQW5kIHdoZXJlICJ0 cmFuc3BvcnQiIGNvdWxkIGNvbmNlaXZhYmx5IGJlIGFueSBvZiwgYnV0IG5vdA0KPiA+Pj4+PiBs aW1pdGVkDQo+ID4+Pj4+Pj4gdG86DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gKiBFdGhlcm5l dA0KPiA+Pj4+Pj4+Pj4gKiBFdGhlcm5ldCArIExMQzINCj4gPj4+Pj4+Pj4+ICogRXRoZXJuZXQg KyBNUExTDQo+ID4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgKyBHUkUNCj4gPj4+Pj4+Pj4+ICog RXRoZXJuZXQgKyBJUCArVURQDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+ IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRpYWdyYW0gYWJvdmUgaXMgbm90IG1lYW50IHRvIGlt cGx5DQo+ID4+Pj4+Pj4+PiBpbW11dGFiaWxpdHksDQo+ID4+Pj4+Pj4+PiBidXQgcmF0aGVyIHRv IHNwZWNpZnkgdGhlIHBhY2tldCB0aGF0IGlzIHByb3BhZ2F0ZWQgZnJvbSBwcmVjZWRpbmcNCj4g Pj4+Pj4+Pj4+IGVudGl0eQ0KPiA+Pj4+Pj4+Pj4gdG8gc3VjY2VlZGluZyBlbnRpdHksIHByaW9y IHRvIGVuY2Fwc3VsYXRpb24uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gICAgUm9uDQo+ID4+ Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+ID4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gPj4+Pj4gT2YNCj4gPj4+Pj4+Pj4+IFN1bWFu ZHJhIE1hamVlDQo+ID4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDY6 NDYgUE0NCj4gPj4+Pj4+Pj4+IFRvOiBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4gPj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+ ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5n IEVuY2Fwc3VsYXRpb246IEEgZG9jdW1lbnQgd2lsbA0KPiA+Pj4+Pj4+Pj4gICAgIGRlc2NyaWJl IHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24NCj4gPj4+ Pj4gZm9ybWF0DQo+ID4+Pj4+Pj4+PiBmb3INCj4gPj4+Pj4+Pj4+ICAgICBjb252ZXlpbmcgdGhl IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uDQo+ID4+Pj4+ Pj4gcGF0aCwNCj4gPj4+Pj4+Pj4+ICAgICBhbmQgZm9yIGNvbW11bmljYXRpbmcgY29udGV4dCBp bmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQNCj4gPj4+Pj4+Pj4+ICAgICBpbXBsZW1lbnQg c2VydmljZSBmdW5jdGlvbnMuIEl0IGlzIGludGVuZGVkIHRoYXQgdGhlDQo+ID4+Pj4+Pj4gZW5j YXBzdWxhdGlvbg0KPiA+Pj4+Pj4+Pj4gICAgIGJlIGFnbm9zdGljIHRvIHRoZSBsYXllciBhdCB3 aGljaCBpdCBpcyBhcHBsaWVkIGFuZCB0aGUNCj4gPj4+Pj4gc2VydmljZQ0KPiA+Pj4+Pj4+IHRo YXQNCj4gPj4+Pj4+Pj4+IGlzDQo+ID4+Pj4+Pj4+PiAgICAgYmVpbmcgY29uc3RydWN0ZWQuIFRo YXQgaXMsIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gbWF5IGJlDQo+ID4+Pj4+Pj4+PiB1c2VkDQo+ ID4+Pj4+IG9uDQo+ID4+Pj4+Pj4+PiAgICAgYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6 ZWQgYXQgdGhlIG5ldHdvcmsgbGF5ZXIgb3IgYXQNCj4gPj4+Pj4gYW55DQo+ID4+Pj4+Pj4+PiBv dGhlcg0KPiA+Pj4+Pj4+Pj4gICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3 aWxsIGFwcGx5IGZvciB0aGUNCj4gPj4+Pj4gY29uc3RydWN0aW9uDQo+ID4+Pj4+Pj4gb2YNCj4g Pj4+Pj4+Pj4+ICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFj dHVhbCBzZXJ2aWNlLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFtTTV0gV2hhdCBkb2VzIGl0 IG1lYW4gYnkgYSBzaW5nbGUgc2VydmljZS1sZXZlbCBlbmNhcHN1bGF0aW9uLCAgYQ0KPiA+Pj4+ Pj4+IG5ldw0KPiA+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBmb3JtYXQNCj4gPj4+Pj4+Pj4+ICAg ICAgICAgICAgIG9yIGFuIGFiaWxpdHkgdG8gc2VsZWN0IG9uZSBlbmNhcHN1bGF0aW9uIGZvcm1h dCB0aGF0DQo+ID4+Pj4+Pj4gZml0cw0KPiA+Pj4+Pj4+Pj4gdGhlDQo+ID4+Pj4+Pj4+PiBuZWVk IGZvciBhIGdpdmVuIHNlcnZpY2UgY2hhaW4/DQo+ID4+Pj4+Pj4+PiAgICAgICAgICAgIFRoZSBh YmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNpZmljIGVuY2Fwc3VsYXRpb24gIHdvdWxkDQo+ID4+Pj4+ IGJlDQo+ID4+Pj4+IGENCj4gPj4+Pj4+Pj4+IG1hbmFnZW1lbnQgcGxhbmUgZGVjaXNpb24uDQo+ ID4+Pj4+Pj4+PiAgICAgICAgICAgVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGV4aXN0aW5nIGVuY2Fw c3VsYXRpb24gbWV0aG9kcw0KPiA+Pj4+PiB0aGF0DQo+ID4+Pj4+Pj4gY2FuDQo+ID4+Pj4+Pj4+ PiBwb3NzaWJseSBiZSByZXVzZWQgdG8gcHJvdmlkZQ0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgIGNv bnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMuIEkgaGF2ZQ0KPiA+Pj4+ Pj4+Pj4gc2Vlbg0KPiA+Pj4+Pj4+Pj4gbWVudGlvbg0KPiA+Pj4+Pj4+Pj4gb2YgR1JFLCBmb3Ig SFRUUCBiYXNlZA0KPiA+Pj4+Pj4+Pj4gICAgICAgICAgIGFwcGxpY2F0aW9ucyBjb250ZXh0cyBh cmUgdHJhbnNmZXJyZWQgdmlhIGhlYWRlcnMuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+Pj4+Pj4+PiBGcm9tOiBu c2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYNCj4gPj4+Pj4gT2YNCj4gPj4+Pj4+Pj4+IFRob21hcyBOYXJ0ZW4NCj4gPj4+Pj4+Pj4+IFNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMTE6MDcgQU0NCj4gPj4+Pj4+Pj4+IFRv OiBuc2NAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IFN1YmplY3Q6IFtuc2NdIEN1cnJlbnQgUHJvcG9z ZWQgU0ZDIGNoYXJ0ZXINCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBIaS4NCj4gPj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PiBDdXJyZW50IGNoYXJ0ZXIgY2FuIGJlIGZvdW5kIGF0DQo+ID4+Pj4+Pj4+ PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVyLQ0KPiA+Pj4+Pj4+Pj4g aWV0Zi1zZmMvLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEl0IGNvbnRhaW5zIHRoZSByZXZp c2VkIG1hbmFnZW1lbnQgdGV4dCBhcyB3ZWxsIGFzIHVwZGF0ZWQNCj4gPj4+Pj4+PiBtaWxlc3Rv bmVzLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEFsbCBrbm93biBpc3N1ZXMgaGF2ZSBiZWVu IGFkZHJlc3NlZC4gSWYgdGhlcmUgYXJlIGFueSByZW1haW5pbmcNCj4gPj4+Pj4+PiBpc3N1ZXMs DQo+ID4+Pj4+Pj4+PiBwbGVhc2Ugc3BlYWsgdXAhDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g Q2hhcnRlciBjaGFydGVyLWlldGYtc2ZjLTAwLTA0DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4g TmV0d29ya3MsIHNlcnZlcnMsIHN0b3JhZ2UgdGVjaG5vbG9naWVzLCBhbmQgYXBwbGljYXRpb25z LCBoYXZlDQo+ID4+Pj4+IGFsbA0KPiA+Pj4+Pj4+Pj4gdW5kZXJnb25lIHNpZ25pZmljYW50IGNo YW5nZSBpbiByZWNlbnQgeWVhcnMgd2l0aCB0aGUgaW50cm9kdWN0aW9uDQo+ID4+Pj4+IG9mDQo+ ID4+Pj4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9yY2hlc3Ry YXRpb24uIFNlcnZpY2UNCj4gPj4+Pj4gZGVsaXZlcnkNCj4gPj4+Pj4+PiBpcw0KPiA+Pj4+Pj4+ Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFsIGNoYWxsZW5n ZSB0aGF0DQo+ID4+Pj4+IGludm9sdmVzDQo+ID4+Pj4+Pj4+PiBzaWduaWZpY2FudCBtb2RpZmlj YXRpb24gdG8gdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbi4NCj4gPj4+Pj4+Pj4+IFNlcnZpY2Vz IGFyZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQgY29tYmluYXRpb24gb2Yg YQ0KPiA+Pj4+Pj4+Pj4gbnVtYmVyDQo+ID4+Pj4+Pj4+PiBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0 aGF0IGFyZSBkZXBsb3llZCBhdCBkaWZmZXJlbnQgcG9pbnRzIHdpdGhpbg0KPiA+Pj4+PiB0aGUN Cj4gPj4+Pj4+Pj4+IG5ldHdvcmsuIFRvZGF5LCBhIGNvbW1vbiBkZXBsb3ltZW50IG1vZGVsIGhh cyBzZXJ2aWNlIGZ1bmN0aW9ucw0KPiA+Pj4+Pj4+Pj4gcGh5c2ljYWxseQ0KPiA+Pj4+Pj4+Pj4g aW5zZXJ0ZWQgb24gdGhlIGRhdGEgZm9yd2FyZGluZyBwYXRoIGJldHdlZW4gY29tbXVuaWNhdGlu ZyBwZWVycy4NCj4gPj4+Pj4+PiBHb2luZw0KPiA+Pj4+Pj4+Pj4gZm9yd2FyZCwgaG93ZXZlciwg dGhlcmUgaXMgYSBkZXNpcmUgdG8gbW92ZSB0byBhIGRpZmZlcmVudCBtb2RlbCwNCj4gPj4+Pj4+ PiB3aGVyZQ0KPiA+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0 byByZXNpZGUgb24gdGhlIGRlZmF1bHQgZGF0YQ0KPiA+Pj4+PiBwYXRoDQo+ID4+Pj4+Pj4+PiBh bmQNCj4gPj4+Pj4+Pj4+IHRyYWZmaWMgaXMgaW5zdGVhZCBzdGVlcmVkIHRocm91Z2ggc2Vydmlj ZXMsIHdoZXJldmVyIHRoZXkgYXJlDQo+ID4+Pj4+Pj4gZGVwbG95ZWQuDQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4gRm9yIGEgZ2l2ZW4gc2VydmljZSwgdGhlIGFic3RyYWN0ZWQgdmlldyBvZiB0 aGUgcmVxdWlyZWQgc2VydmljZQ0KPiA+Pj4+Pj4+Pj4gZnVuY3Rpb25zDQo+ID4+Pj4+Pj4+PiBh bmQgdGhlIG9yZGVyIGluIHdoaWNoIHRoZXkgYXJlIHRvIGJlIGFwcGxpZWQgaXMgY2FsbGVkIGEg U2VydmljZQ0KPiA+Pj4+Pj4+Pj4gRnVuY3Rpb24NCj4gPj4+Pj4+Pj4+IENoYWluIChTRkMpLiBT aW5jZSBhIGdpdmVuIHNlcnZpY2UgZnVuY3Rpb24gbWF5IGJlIGF2YWlsYWJsZSBvbg0KPiA+Pj4+ PiBtb3JlDQo+ID4+Pj4+Pj4+PiB0aGFuDQo+ID4+Pj4+Pj4+PiBvbmUgbm9kZSB3aXRoaW4gYSBu ZXR3b3JrLCBhIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW4gaXMNCj4gPj4+Pj4gaW5zdGFudGlhdGVk DQo+ID4+Pj4+Pj4gdmlhDQo+ID4+Pj4+Pj4+PiB0aGUgc2VsZWN0aW9uIG9mIHNwZWNpZmljIHNl cnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzIGFuZCB0aGUNCj4gPj4+Pj4gbmV0d29yaw0KPiA+Pj4+ Pj4+Pj4gbm9kZXMNCj4gPj4+Pj4+Pj4+IG9uIHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVkLCB0aGVy ZWJ5IGZvcm1pbmcgYSBzZXJ2aWNlIHRvcG9sb2d5Og0KPiA+Pj4+Pj4+Pj4gdGhpcyBpcyBjYWxs ZWQgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNlIGZ1bmN0aW9ucyBtYXkNCj4g Pj4+Pj4gYmUNCj4gPj4+Pj4+Pj4+IGFwcGxpZWQgYXQgYSBzcGVjaWZpYyBsYXllciB3aXRoaW4g dGhlIG5ldHdvcmsgcHJvdG9jb2wgc3RhY2sNCj4gPj4+Pj4+PiAobmV0d29yaw0KPiA+Pj4+Pj4+ Pj4gbGF5ZXIsIGFwcGxpY2F0aW9uIGxheWVyLCBldGMuKS4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBUaGUgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoU0ZDKSB3b3JraW5nIGdyb3VwIHdp bGwgZGV2ZWxvcCBuZXcNCj4gPj4+Pj4+Pj4+IGFwcHJvYWNoZXMgdG8gc2VydmljZSBkZWxpdmVy eSBhbmQgZGVwbG95bWVudC4gSXQgd2lsbCBwcm9kdWNlIGENCj4gPj4+Pj4+Pj4+IGZyYW1ld29y aw0KPiA+Pj4+Pj4+Pj4gZm9yIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcgdGhhdCBpbmNsdWRl cyB0aGUgbmVjZXNzYXJ5DQo+ID4+Pj4+IHByb3RvY29scw0KPiA+Pj4+Pj4+IG9yDQo+ID4+Pj4+ Pj4+PiBwcm90b2NvbCBleHRlbnNpb25zIHRvIGNvbnZleSB0aGUgc2VydmljZSBwYXRoIGFuZCBz ZXJ2aWNlIHBhdGgNCj4gPj4+Pj4+Pj4+IGluZm9ybWF0aW9uIHRvIG5vZGVzIHRoYXQgaW1wbGVt ZW50IHNlcnZpY2UgZnVuY3Rpb25zLCBhcyB3ZWxsIGFzDQo+ID4+Pj4+Pj4+PiBtZWNoYW5pc21z IGZvciBzdGVlcmluZyB0cmFmZmljIHRocm91Z2ggc2VydmljZSBmdW5jdGlvbnMuIFRoZQ0KPiA+ Pj4+Pj4+IHdvcmtpbmcNCj4gPj4+Pj4+Pj4+IGdyb3VwIHdpbGwgYWxzbyBleGFtaW5lIHdoYXQg aW5mb3JtYXRpb24gbmVlZHMgdG8gYmUgZ2F0aGVyZWQgZnJvbQ0KPiA+Pj4+Pj4+IHRoZQ0KPiA+ Pj4+Pj4+Pj4gbmV0d29yayBhbmQgc2VydmljZSBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBzZXJ2 aWNlIGZ1bmN0aW9uDQo+ID4+Pj4+IGNoYWluaW5nDQo+ID4+Pj4+Pj4+PiBhbmQNCj4gPj4+Pj4+ Pj4+IGhvdyB0aGF0IGluZm9ybWF0aW9uIG1heSBiZSBtYWRlIGF2YWlsYWJsZSB0byBub2RlcyB0 aGF0IGltcGxlbWVudA0KPiA+Pj4+Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlv bnMuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gU3BlY2lmaWNhbGx5LCB0aGUgU0ZDIFdHIGlz IGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZSBmb2xsb3dpbmc6DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+ Pj4+Pj4gMSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGEg c3VtbWFyeSBvZiB0aGUNCj4gPj4+Pj4+Pj4+ICAgICBwcm9ibGVtIHNwYWNlIHRvIGJlIGFkZHJl c3NlZCBieSB0aGUgV0cgaW5jbHVkaW5nIGV4YW1wbGUNCj4gPj4+Pj4gaGlnaC0NCj4gPj4+Pj4+ Pj4+ICAgICBsZXZlbCB1c2UgY2FzZXMuIEFkZGl0aW9uYWxseSwgdGhlIFdHIHdpbGwgbm9ybWFs aXplDQo+ID4+Pj4+IG5vbWVuY2xhdHVyZQ0KPiA+Pj4+Pj4+Pj4gICAgIGFuZCBkZWZpbml0aW9u cyBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZy4NCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+ PiAyKSBBcmNoaXRlY3R1cmU6IFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRlIGEgZGVzY3JpcHRp b24gb2YgdGhlDQo+ID4+Pj4+Pj4+PiAgICAgYXJjaGl0ZWN0dXJhbCBidWlsZGluZyBibG9ja3Mg YW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMNCj4gPj4+Pj4gaW5jbHVkaW5nDQo+ID4+Pj4+Pj4+PiAg ICAgaW50ZXJjb25uZWN0aW9uLCBwbGFjZW1lbnQgb2YgY2FwYWJpbGl0aWVzLCBtYW5hZ2VtZW50 LA0KPiA+Pj4+Pj4+Pj4gICAgIGRpYWdub3N0aWNzLCBkZXNpZ24gYW5hbHlzaXMsIGFuZCBzZWN1 cml0eSBtb2RlbHMsIGFzIHdlbGwgYXMNCj4gPj4+Pj4+Pj4+ICAgICByZXF1aXJlbWVudHMgb24g dGhlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4gMykgR2Vu ZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIEVuY2Fwc3VsYXRpb246IEEgZG9jdW1lbnQN Cj4gPj4+Pj4gd2lsbA0KPiA+Pj4+Pj4+Pj4gICAgIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2Vydmlj ZS1sZXZlbCBkYXRhIHBsYW5lIGVuY2Fwc3VsYXRpb24NCj4gPj4+Pj4gZm9ybWF0DQo+ID4+Pj4+ Pj4+PiBmb3INCj4gPj4+Pj4+Pj4+ICAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24g Y2hhaW4gYW5kIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uDQo+ID4+Pj4+Pj4gcGF0aCwNCj4gPj4+Pj4+ Pj4+ICAgICBhbmQgZm9yIGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVu IG5vZGVzIHRoYXQNCj4gPj4+Pj4+Pj4+ICAgICBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMu IEl0IGlzIGludGVuZGVkIHRoYXQgdGhlDQo+ID4+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPiA+Pj4+ Pj4+Pj4gICAgIGJlIGFnbm9zdGljIHRvIHRoZSBsYXllciBhdCB3aGljaCBpdCBpcyBhcHBsaWVk IGFuZCB0aGUNCj4gPj4+Pj4gc2VydmljZQ0KPiA+Pj4+Pj4+IHRoYXQNCj4gPj4+Pj4+Pj4+IGlz DQo+ID4+Pj4+Pj4+PiAgICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1lIGVu Y2Fwc3VsYXRpb24gbWF5IGJlDQo+ID4+Pj4+Pj4+PiB1c2VkDQo+ID4+Pj4+IG9uDQo+ID4+Pj4+ Pj4+PiAgICAgYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIG5ldHdvcmsg bGF5ZXIgb3IgYXQNCj4gPj4+Pj4gYW55DQo+ID4+Pj4+Pj4+PiBvdGhlcg0KPiA+Pj4+Pj4+Pj4g ICAgIGxheWVyLCBhbmQgdGhlIHNhbWUgZW5jYXBzdWxhdGlvbiB3aWxsIGFwcGx5IGZvciB0aGUN Cj4gPj4+Pj4gY29uc3RydWN0aW9uDQo+ID4+Pj4+Pj4gb2YNCj4gPj4+Pj4+Pj4+ICAgICBzZXJ2 aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhlIGFjdHVhbCBzZXJ2aWNlLg0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDQpIENvbnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBzZXQg b2YgZG9jdW1lbnRzIHdpbGwgYmUgZGV2ZWxvcGVkDQo+ID4+Pj4+IHRvDQo+ID4+Pj4+Pj4+PiAg ICAgZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbHMgbmVjZXNzYXJ5IHRvIGNvbnZl eQ0KPiA+Pj4+Pj4+IGluZm9ybWF0aW9uDQo+ID4+Pj4+Pj4+PiAgICAgdG8gc2VydmljZSBmdW5j dGlvbiBpbXBsZW1lbnRhdGlvbiBwb2ludHMuIFdoZXJlIHBvc3NpYmxlLA0KPiA+Pj4+Pj4+IGV4 aXN0aW5nDQo+ID4+Pj4+Pj4+PiAgICAgSUVURiBwcm90b2NvbHMgd2lsbCBiZSB1c2VkIGFuZCBl eHRlbmRlZC4gQWxsIHByb3RvY29sDQo+ID4+Pj4+IGV4dGVuc2lvbnMNCj4gPj4+Pj4+Pj4+ICAg ICB3b3JrIHNob3VsZCBiZSBjYXJyaWVkIG91dCBpbiB0aGUgd29ya2luZyBncm91cHMgcmVzcG9u c2libGUNCj4gPj4+Pj4gZm9yDQo+ID4+Pj4+Pj4gdGhlDQo+ID4+Pj4+Pj4+PiAgICAgcHJvdG9j b2xzIGJlaW5nIG1vZGlmaWVkIGluIGNvb3JkaW5hdGlvbiB3aXRoIHRoaXMgd29ya2luZw0KPiA+ Pj4+PiBncm91cCwNCj4gPj4+Pj4+Pj4+IGJ1dA0KPiA+Pj4+Pj4+Pj4gICAgIG1heSBiZSBkb25l IGluIHRoaXMgd29ya2luZyBncm91cCBhZnRlciBhZ3JlZW1lbnQgd2l0aCBhbGwNCj4gPj4+Pj4+ Pj4+IHRoZQ0KPiA+Pj4+Pj4+Pj4gICAgIHJlbGV2YW50IFdHIGNoYWlycyBhbmQgcmVzcG9uc2li bGUgQURzLg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IDUpIE1hbmFnZWFiaWxpdHk6IFdvcmsg b24gdGhlIG1hbmFnZW1lbnQgYW5kIGNvbmZpZ3VyYXRpb24gb2YNCj4gPj4+Pj4gc2VydmljZQ0K PiA+Pj4+Pj4+Pj4gICAgIGZ1bmN0aW9ucyBpbiBzdXBwb3J0IG9mIFNGQyBjb21wb25lbnRzIHdp bGwgY2VydGFpbmx5IGJlDQo+ID4+Pj4+IG5lZWRlZCwNCj4gPj4+Pj4+Pj4+ICAgICBidXQgZmly c3QgbmVlZHMgdG8gYmUgYmV0dGVyIHVuZGVyc3Rvb2QgYW5kIHNjb3BlZC4NCj4gPj4+Pj4+Pj4+ DQo+ID4+Pj4+Pj4+PiBQcm9wb3NlZCBNaWxlc3RvbmVzDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+ Pj4gQXByIDIwMTQgU3VibWl0IHRvIElFU0cgSW5mb3JtYXRpb25hbCBkb2N1bWVudChzKSBkZWZp bmluZyB0aGUNCj4gPj4+Pj4+PiBwcm9ibGVtDQo+ID4+Pj4+Pj4+PiBzdGF0ZW1lbnQgYW5kIGNv cmUgdXNlIGNhc2VzIGZvciBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nDQo+ID4+Pj4+Pj4+Pg0K PiA+Pj4+Pj4+Pj4gTWF5IDIwMTQgQ29uc3VsdCB3aXRoIE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNo YXJ0ZXIgbW9kaWZpY2F0aW9ucw0KPiA+Pj4+PiBmb3INCj4gPj4+Pj4+Pj4+IG1hbmFnZW1lbnQg YW5kIGNvbmZpZ3VyYXRpb24gb2YgU0ZDIGNvbXBvbmVudHMNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+ Pj4+PiBKYW4gMjAxNSBTdWJtaXQgdG8gSUVTRyBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IGRlZmlu aW5nIHRoZQ0KPiA+Pj4+Pj4+IGFyY2hpdGVjdHVyZQ0KPiA+Pj4+Pj4+Pj4gZm9yIFNGQw0KPiA+ Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IEphbiAyMDE1IFN1Ym1pdCB0byBJRVNHIHJlcXVpcmVtZW50 cyBmb3IgYSBnZW5lcmljIHNlcnZpY2UNCj4gPj4+Pj4gZnVuY3Rpb24NCj4gPj4+Pj4+Pj4+IGNo YWluaW5nIGVuY2Fwc3VsYXRpb24gcHJvdG9jb2wNCj4gPj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+PiBB dWcgMjAxNSBTdWJtaXQgdG8gSUVTRyBTdGFuZGFyZHMgVHJhY2sgZG9jdW1lbnQgc3BlY2lmeWlu ZyB0aGUNCj4gPj4+Pj4+PiBnZW5lcmljDQo+ID4+Pj4+Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNo YWluaW5nIGhlYWRlciBlbmNhcHN1bGF0aW9uDQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4g Pj4+Pj4+Pj4+DQo+ID4+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IFRob21hcw0K PiA+Pj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+ID4+Pj4+Pj4+ PiBuc2NAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnNjDQo+ID4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+ Pj4gbnNjQGlldGYub3JnDQo+ID4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25zYw0KPiA+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4gPj4+Pj4+ Pj4+IG5zY0BpZXRmLm9yZw0KPiA+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uc2MNCj4gPj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPiA+Pj4+Pj4+ PiBuc2NAaWV0Zi5vcmcNCj4gPj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uc2MNCj4gPj4+Pj4+DQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4g Pj4+PiBuc2NAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4+PiBuc2MgbWFpbGluZyBsaXN0DQo+ID4+PiBuc2NAaWV0Zi5v cmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ID4+ Pg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPiBuc2MgbWFpbGluZyBsaXN0DQo+ID4gbnNjQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj4gDQo+IA0KPiAtLQ0KPiAiRXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KPiANCj4gRHIgRGllZ28gUi4gTG9w ZXoNCj4gVGVsZWZvbmljYSBJK0QNCj4gaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXov DQo+IA0KPiBlLW1haWw6IGRpZWdvQHRpZC5lcw0KPiBUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0K PiBNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IA0KPiBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGlu YXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVlc3RyYQ0KPiBwb2zDrXRpY2EgZGUgZW52w61vIHkg cmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3D oXMgYWJham8uDQo+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRz IGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsDQo+IG9uIHRoZSBiYXNp cyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCj4gaHR0cDovL3d3dy50aWQuZXMvRVMvUEFHSU5B Uy9kaXNjbGFpbWVyLmFzcHgNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gbnNjIG1haWxpbmcgbGlzdA0KPiBuc2NAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From jmh@joelhalpern.com Sun Nov 17 06:27:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA6A11E8183 for ; Sun, 17 Nov 2013 06:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy7bwKTb6p6S for ; Sun, 17 Nov 2013 06:27:45 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id ADFB811E8D57 for ; Sun, 17 Nov 2013 06:27:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 730231BCB7A4; Sun, 17 Nov 2013 06:27:39 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 0E53B1BCB79D; Sun, 17 Nov 2013 06:27:36 -0800 (PST) Message-ID: <5288D256.1060302@joelhalpern.com> Date: Sun, 17 Nov 2013 09:27:34 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "Ersue, Mehmet (NSN - DE/Munich)" , "Jim Guichard (jguichar)" , Thomas Narten References: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , ext Benoit Claise , "ext Diego R. Lopez" , "adrian.farrel@huawei.com" , ext Melinda Shore Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 14:27:50 -0000 You list a number of very useful items that are needed for the full utilization of service chaining in a network. That does not mean that all those items should be in scope for this working group. As far as I can tell, our goal is to make a useful contribution to solving the problem, rather than to attempt to simultaneously address all known or expected issues. The remaining topics may be dealt with in other working groups, in other fora, or by vendors and operators individually. Yours, Joel On 11/17/13 9:07 AM, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear SFC Chairs, All, > > AFAIK the management of SFC or service graphs in general needs to address: > > - the orchestration of a service graph based on the information in a model used as input, > - lifecycle management of network services and possibly of single VNFs, > - FCAPS as well as management of virtualization related events (e.g. monitoring and correlation of virtualization events) > - specification of relevant information models and the standardization of necessary data models. > > AFAIU it is not easy to address all of these management aspects in the future SFC WG and a parallel work in OPS area might be useful if started early. > > Please elaborate and argue otherwise. > > Cheers, > Mehmet > >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of ext Diego R. >> Lopez >> Sent: Tuesday, November 12, 2013 4:46 PM >> To: Jim Guichard (jguichar) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee; Kevin J Ma; Ron Parker; Joel M. >> Halpern; Surendra Kumar (smkumar) >> Subject: Re: [nsc] Current Proposed SFC charter >> >> Let me add for the record that this is the kind of management aspects I had in mind >> when we were talking about service metadata and how to exchange them... >> >> Be goode, >> >> On 12 Nov 2013, at 15:52 , Jim Guichard (jguichar) wrote: >> >>> Yes optimization can certainly be built into this but I wanted to show an >>> example of the types of things we mean when we talk about branching. Once >>> the concept is better understood I think we will see some more exciting >>> examples. Note also that the control logic could also utilize the service >>> encapsulation as a mechanism to push notifications back up the original >>> chain to inform the ingress to bypass the original chain for all >>> subsequent packets for this flow. >>> >>> On 11/12/13 9:40 AM, "Joel M. Halpern" wrote: >>> >>>> Jim, thank you for a concrete example. >>>> I would suggest that in the usual cases, there is a better way to handle >>>> this than branching and rewriting at the PCRF. >>>> >>>> If the DPI engine or PCRF logic (whichever makes the decision) notifies >>>> the control logic about the decision for the flow, then the ingress can >>>> direct subsequent packets to the correct place, avoiding needless >>>> processing of further packets in the DPI and PCRF logic. >>>> Further, the needed control information can be passed to the >>>> optimization or parental control so that it does not matter where the >>>> first packet is sent, avoiding the need for the PCRF to understand how >>>> to direct packets to service paths. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >>>>> Hi Kevin, >>>>> >>>>> Let me try and provide a concrete example to see if this answers your >>>>> specific question: >>>>> >>>>> Use case: P-GW -> PCRF -> services applied to traffic based on >>>>> applicationID and subscriberID. >>>>> >>>>> Instantiated as: >>>>> >>>>> SFC1: P-GW -> DPI -> PCRF >>>>> SFC2: PCRF -> video-optimization -> metering -> FW >>>>> SFC3: PCRF -> parental-control -> metering -> FW >>>>> >>>>> In this case DPI is performed on SFC1 and identifies applicationID. The >>>>> applicationID is carried in the service encapsulation to PCRF. PCRF uses >>>>> solution specific logic (identifies subscriber, applies policies, etc) >>>>> and >>>>> uses the result along with the applicationID received from DPI to select >>>>> an outbound service chain, SFC2 or SFC3. Note that in this case >>>>> branching >>>>> occurs from SFC1 to either SFC2 or SFC3. >>>>> >>>>> >>>>> >>>>> >>>>> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >>>>> >>>>>>> Yes, reclassification can change the service path and >>>>>>> re-classification may happen at any node along a service path. >>>>>> >>>>>> Just to expand on that, going back to the original question about >>>>>> service header encapsulation, is it intended that a chain that >>>>>> is re-classified will get a new chain ID which fully describes >>>>>> a chain that is a superset of the original chain ID, prior to >>>>>> DPI-based re-classification? (assuming the goal is "a single >>>>>> chain ID that is commonly understood along the entire service chain" >>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>>>>> >>>>>> And the applicable subset of the permutative list of service >>>>>> paths would be configured at each appropriate service node? >>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>> ID 2: NAT + firewall + DPI + AV >>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>> ID 6: NAT + firewall + DPI + LB >>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE >>>>>> Would every flow then be initially classified as ID 1, but >>>>>> eventually get re-classified to ID 2-11, after the DPI phase? >>>>>> >>>>>> thanx. >>>>>> >>>>>> -- Kevin J. Ma >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>> nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" wrote: >>>>>>> >>>>>>>> Hi Surendra, >>>>>>>> >>>>>>>> Classification may be out of scope, but the level of service that >>>>>>>> is >>>>>>>> applicable is dependent upon the level of classification that can >>>>>>>> be >>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>> implications >>>>>>>> on the level of classification being performed? If the stated >>>>>>>> goals >>>>>>> are >>>>>>>> for firewall and load balancer functionality, then the application >>>>>>> level >>>>>>>> nature of those functions needs to be taken into account? If, on >>>>>>>> the >>>>>>>> other hand, the service function scope is limited due to >>>>>>>> limitations >>>>>>> in >>>>>>>> classification, that would be and important piece of information? >>>>>>>> >>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>>>>> points >>>>>>>> of the service paths seem like re-classification points? Is that >>>>>>>> the >>>>>>>> interpretation from the architecture perspective? Or is the >>>>>>>> service >>>>>>>> function chain classification exclusive of DPI functionality? >>>>>>> I have not fully read that draft yet. But in general, as >>>>>>> described >>>>>>> in >>>>>>> the arch draft, the collection of services form a graph, segments of >>>>>>> which >>>>>>> are service paths. Yes, reclassification can change the service path >>>>>>> and >>>>>>> re-classification may happen at any node along a service path. >>>>>>> >>>>>>> Surendra. >>>>>>>> >>>>>>>> thanx. >>>>>>>> >>>>>>>> -- Kevin J. Ma >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>> nsc@ietf.org >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>> >>>>>>>>> Kevin, >>>>>>>>> >>>>>>>>> Classification mechanism is outside the scope of SFC. It can be >>>>>>>>> based >>>>>>> on >>>>>>>>> the packet or information not in the packet(environmental attributes >>>>>>> for >>>>>>>>> instance) or a combination thereof. What is important is that such >>>>>>>>> classification aids in traffic selection and service path >>>>>>>>> identification. >>>>>>>>> It is no different from a policy in this regard except that the >>>>>>> policy >>>>>>>>> now >>>>>>>>> specifies the service path. >>>>>>>>> Further, classification is not limited to the network elements but >>>>>>> the >>>>>>>>> service functions as well. Some of this is described in the >>>>>>> architecture >>>>>>>>> drafts as well - >>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>> >>>>>>>>> Surendra. >>>>>>>>> >>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> wrote: >>>>>>>>> >>>>>>>>>> Hi Ron, >>>>>>>>>> >>>>>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, but >>>>>>> I >>>>>>>>>> had a similar question wrt bullet 11 in section 2 of the problem >>>>>>>>>> statement: >>>>>>>>>> >>>>>>>>>> 11. Per-Service (re)Classification: Classification occurs at >>>>>>> each >>>>>>>>>> service, independent from previously applied service >>>>>>>>> functions. >>>>>>>>>> These unrelated classification events consume resources >>>>>>>>>> per >>>>>>>>>> service. More importantly, the classification >>>>>>> functionality >>>>>>>>>> often differs per service function and service function >>>>>>> cannot >>>>>>>>>> leverage the results from other deployed network or >>>>>>> service. >>>>>>>>>> >>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>> >>>>>>>>>> The SFC Classifier classifies packets based on (some of) the >>>>>>>>> contents >>>>>>>>>> of the packet header. Concretely, it classifies packets based >>>>>>> on >>>>>>>>> the >>>>>>>>>> possible combination of one or more header fields, such as >>>>>>> source >>>>>>>>>> address, destination address, DS field, protocol ID, source >>>>>>>>>> port >>>>>>>>> and >>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>> >>>>>>>>>> A packet-based classifier as described in the framework document >>>>>>>>> would >>>>>>>>>> seem to be limited in what it can classify? The service function >>>>>>>>>> identifier lookup does not seem to be a significant optimization >>>>>>> over >>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>>>>>> detail >>>>>>>>>> wrt how classification information is determined and reused? >>>>>>>>>> >>>>>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>>>>> encrypted >>>>>>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>>>>>> wondering >>>>>>>>>> how independent HLS segment requests might be classified and >>>>>>>>> associated? >>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>> >>>>>>>>>> thanx. >>>>>>>>>> >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>>>>>> Ron >>>>>>>>>>> Parker >>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Sumandra, >>>>>>>>>>> >>>>>>>>>>> As was discussed in Vancouver, there are already many existing >>>>>>> ways >>>>>>>>> to >>>>>>>>>>> accomplish service chaining. But none of them provide a >>>>>>>>> sufficient >>>>>>>>>>> combination of interoperability, flexibility, and resiliency. A >>>>>>>>> single >>>>>>>>>>> service chain encapsulation will go a long way to ensuring these >>>>>>>>> goals. >>>>>>>>>>> It may not be the absolutely most efficient approach for every >>>>>>>>> single >>>>>>>>>>> network topology and every single use case, but its ubiquitous >>>>>>> nature >>>>>>>>>>> should improve its adoption. >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Ron, >>>>>>>>>>> >>>>>>>>>>> Absolutely, that was an example of one type of derivation. However >>>>>>>>> this >>>>>>>>>>> could be augmented with classification result, again one more >>>>>>>>> example. >>>>>>>>>>> >>>>>>>>>>>>> All flows from the same source IP do not necessarily follow the >>>>>>>>> same >>>>>>>>>>> chain. >>>>>>>>>>> Correct. It is also not necessary that all transaction of the same >>>>>>>>> flow >>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>> >>>>>>>>>>> Again the point here is that do we always need SFC header or Not. >>>>>>>>>>> >>>>>>>>>>> Sumandra >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Sumandra, >>>>>>>>>>> >>>>>>>>>>> The intention of service function chaining is to allow for >>>>>>> operation >>>>>>>>> at >>>>>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>>>>> transaction >>>>>>>>>>> level (this is an implementation matter for the PDP). All >>>>>>> flows >>>>>>>>> from >>>>>>>>>>> the same source IP do not necessarily follow the same chain. >>>>>>> Source >>>>>>>>>>> IP, >>>>>>>>>>> therefore, does not identify the chain ID. Another intention >>>>>>> of >>>>>>>>>>> service function chaining is to operate over any network topology >>>>>>> and >>>>>>>>>>> not >>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of the >>>>>>>>>>> transport, it does not adequately identify the service chain, >>>>>>> either. >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Ron, >>>>>>>>>>> >>>>>>>>>>> The service header is meant to carry the context which can *also* >>>>>>> be >>>>>>>>>>> derived (for example use source ip and vlan to identify chainID >>>>>>> and >>>>>>>>>>> position) or encapsulated as part of another tunnel header. So >>>>>>> this >>>>>>>>>>> could >>>>>>>>>>> be optional IMHO. >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Sumandra, >>>>>>>>>>> >>>>>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>>>>> from >>>>>>>>> SF >>>>>>>>>>> to >>>>>>>>>>> SF will look like: >>>>>>>>>>> >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | "transport" | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | service header | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | original IP header | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | | original IP payload >>>>>>> | >>>>>>>>>>> | | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> >>>>>>>>>>> Where service header contains, at a minimum, enough information to >>>>>>>>> allow >>>>>>>>>>> the packet to be propagated along the full length of the chain, >>>>>>> and >>>>>>>>>>> optionally, other metadata that enhances the operation of one or >>>>>>> more >>>>>>>>>>> service functions. >>>>>>>>>>> >>>>>>>>>>> And where "transport" could conceivably be any of, but not >>>>>>> limited >>>>>>>>> to: >>>>>>>>>>> >>>>>>>>>>> * Ethernet >>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>>>>> immutability, >>>>>>>>>>> but rather to specify the packet that is propagated from preceding >>>>>>>>>>> entity >>>>>>>>>>> to succeeding entity, prior to encapsulation. >>>>>>>>>>> >>>>>>>>>>> Ron >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>>>>>> Sumandra Majee >>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Generic Service Function Chaining Encapsulation: A document will >>>>>>>>>>> describe the single service-level data plane encapsulation >>>>>>> format >>>>>>>>>>> for >>>>>>>>>>> conveying the service function chain and the service function >>>>>>>>> path, >>>>>>>>>>> and for communicating context information between nodes that >>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>> encapsulation >>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>>>>>> that >>>>>>>>>>> is >>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>> used >>>>>>> on >>>>>>>>>>> a service function path realized at the network layer or at >>>>>>> any >>>>>>>>>>> other >>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>> construction >>>>>>>>> of >>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>> >>>>>>>>>>> [SM] What does it mean by a single service-level encapsulation, a >>>>>>>>> new >>>>>>>>>>> encapsulation format >>>>>>>>>>> or an ability to select one encapsulation format that >>>>>>>>> fits >>>>>>>>>>> the >>>>>>>>>>> need for a given service chain? >>>>>>>>>>> The ability to select a specific encapsulation would >>>>>>> be >>>>>>> a >>>>>>>>>>> management plane decision. >>>>>>>>>>> There are quite a few existing encapsulation methods >>>>>>> that >>>>>>>>> can >>>>>>>>>>> possibly be reused to provide >>>>>>>>>>> context information between service nodes. I have >>>>>>>>>>> seen >>>>>>>>>>> mention >>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>> applications contexts are transferred via headers. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>>>>>> Thomas Narten >>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>> >>>>>>>>>>> Hi. >>>>>>>>>>> >>>>>>>>>>> Current charter can be found at >>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>> ietf-sfc/. >>>>>>>>>>> >>>>>>>>>>> It contains the revised management text as well as updated >>>>>>>>> milestones. >>>>>>>>>>> >>>>>>>>>>> All known issues have been addressed. If there are any remaining >>>>>>>>> issues, >>>>>>>>>>> please speak up! >>>>>>>>>>> >>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>> >>>>>>>>>>> Networks, servers, storage technologies, and applications, have >>>>>>> all >>>>>>>>>>> undergone significant change in recent years with the introduction >>>>>>> of >>>>>>>>>>> virtualization, network overlays, and orchestration. Service >>>>>>> delivery >>>>>>>>> is >>>>>>>>>>> currently both a technical and organizational challenge that >>>>>>> involves >>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>> Services are typically implemented by the ordered combination of a >>>>>>>>>>> number >>>>>>>>>>> of service functions that are deployed at different points within >>>>>>> the >>>>>>>>>>> network. Today, a common deployment model has service functions >>>>>>>>>>> physically >>>>>>>>>>> inserted on the data forwarding path between communicating peers. >>>>>>>>> Going >>>>>>>>>>> forward, however, there is a desire to move to a different model, >>>>>>>>> where >>>>>>>>>>> service functions are not required to reside on the default data >>>>>>> path >>>>>>>>>>> and >>>>>>>>>>> traffic is instead steered through services, wherever they are >>>>>>>>> deployed. >>>>>>>>>>> >>>>>>>>>>> For a given service, the abstracted view of the required service >>>>>>>>>>> functions >>>>>>>>>>> and the order in which they are to be applied is called a Service >>>>>>>>>>> Function >>>>>>>>>>> Chain (SFC). Since a given service function may be available on >>>>>>> more >>>>>>>>>>> than >>>>>>>>>>> one node within a network, a Service Function Chain is >>>>>>> instantiated >>>>>>>>> via >>>>>>>>>>> the selection of specific service function instances and the >>>>>>> network >>>>>>>>>>> nodes >>>>>>>>>>> on which they are provided, thereby forming a service topology: >>>>>>>>>>> this is called a Service Function Path. The service functions may >>>>>>> be >>>>>>>>>>> applied at a specific layer within the network protocol stack >>>>>>>>> (network >>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>> >>>>>>>>>>> The Service Function Chaining (SFC) working group will develop new >>>>>>>>>>> approaches to service delivery and deployment. It will produce a >>>>>>>>>>> framework >>>>>>>>>>> for service function chaining that includes the necessary >>>>>>> protocols >>>>>>>>> or >>>>>>>>>>> protocol extensions to convey the service path and service path >>>>>>>>>>> information to nodes that implement service functions, as well as >>>>>>>>>>> mechanisms for steering traffic through service functions. The >>>>>>>>> working >>>>>>>>>>> group will also examine what information needs to be gathered from >>>>>>>>> the >>>>>>>>>>> network and service functions in support of service function >>>>>>> chaining >>>>>>>>>>> and >>>>>>>>>>> how that information may be made available to nodes that implement >>>>>>>>> the >>>>>>>>>>> service functions. >>>>>>>>>>> >>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the following: >>>>>>>>>>> >>>>>>>>>>> 1) Problem Statement: This document will provide a summary of the >>>>>>>>>>> problem space to be addressed by the WG including example >>>>>>> high- >>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>> nomenclature >>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>> >>>>>>>>>>> 2) Architecture: This document will provide a description of the >>>>>>>>>>> architectural building blocks and their relationships >>>>>>> including >>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>> diagnostics, design analysis, and security models, as well as >>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>> >>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>>>>>> will >>>>>>>>>>> describe the single service-level data plane encapsulation >>>>>>> format >>>>>>>>>>> for >>>>>>>>>>> conveying the service function chain and the service function >>>>>>>>> path, >>>>>>>>>>> and for communicating context information between nodes that >>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>> encapsulation >>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>>>>>> that >>>>>>>>>>> is >>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>> used >>>>>>> on >>>>>>>>>>> a service function path realized at the network layer or at >>>>>>> any >>>>>>>>>>> other >>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>> construction >>>>>>>>> of >>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>> >>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be developed >>>>>>> to >>>>>>>>>>> describe requirements and protocols necessary to convey >>>>>>>>> information >>>>>>>>>>> to service function implementation points. Where possible, >>>>>>>>> existing >>>>>>>>>>> IETF protocols will be used and extended. All protocol >>>>>>> extensions >>>>>>>>>>> work should be carried out in the working groups responsible >>>>>>> for >>>>>>>>> the >>>>>>>>>>> protocols being modified in coordination with this working >>>>>>> group, >>>>>>>>>>> but >>>>>>>>>>> may be done in this working group after agreement with all >>>>>>>>>>> the >>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>> >>>>>>>>>>> 5) Manageability: Work on the management and configuration of >>>>>>> service >>>>>>>>>>> functions in support of SFC components will certainly be >>>>>>> needed, >>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>> >>>>>>>>>>> Proposed Milestones >>>>>>>>>>> >>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>>>>>> problem >>>>>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>>>>> >>>>>>>>>>> May 2014 Consult with OPS Area on possible charter modifications >>>>>>> for >>>>>>>>>>> management and configuration of SFC components >>>>>>>>>>> >>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>>>>> architecture >>>>>>>>>>> for SFC >>>>>>>>>>> >>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>>>>> function >>>>>>>>>>> chaining encapsulation protocol >>>>>>>>>>> >>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying the >>>>>>>>> generic >>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thomas >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra >> política de envío y recepción de correo electrónico en el enlace situado más abajo. >> This message is intended exclusively for its addressee. We only send and receive email >> on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From Ron_Parker@affirmednetworks.com Sun Nov 17 07:28:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3319D11E8D72 for ; Sun, 17 Nov 2013 07:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJflP+NmeIto for ; Sun, 17 Nov 2013 07:27:54 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id 681BB11E8E06 for ; Sun, 17 Nov 2013 07:27:20 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Sun, 17 Nov 2013 07:27:19 -0800 From: Ron Parker To: "Joel M. Halpern" , "Ersue, Mehmet (NSN - DE/Munich)" , "Jim Guichard (jguichar)" , Thomas Narten Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN7SGSB4wwIQ0GPbQPsksKTepohQBeA//+FbhCAAK+3gP//ehgwgACJuYD//3oZQAAAOrNwABSpS4AAAVLbgAAAf0GAAAHQBoAADy4TAAABLeUAAABq2IAAAdzWgAD4ATsAAAC05gAADuQIEA== Date: Sun, 17 Nov 2013 15:27:19 +0000 Message-ID: References: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> <5288D256.1060302@joelhalpern.com> In-Reply-To: <5288D256.1060302@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.76.112.207] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , ext Benoit Claise , "ext Diego R. Lopez" , "adrian.farrel@huawei.com" , ext Melinda Shore Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 15:28:00 -0000 Um9uPj4gT2YgdGhlIGZvdXIgbGlzdGVkIGl0ZW1zLCB0aGUgZm9sbG93aW5nIHR3byBzZWVtIGlu LXNjb3BlIGZvciB0aGUgU0ZDIFdHLCBJTU86DQoNCj4gLSB0aGUgb3JjaGVzdHJhdGlvbiBvZiBh IHNlcnZpY2UgZ3JhcGggYmFzZWQgb24gdGhlIGluZm9ybWF0aW9uIGluIGEgDQo+IG1vZGVsIHVz ZWQgYXMgaW5wdXQsDQpSb24+PiB3aXRoIHRoZSBjYXZlYXQgdGhhdCAib3JjaGVzdHJhdGlvbiIg aXMgYSBicm9hZGx5IHVzZWQgdGVybSBhbmQgd2lsbCB1bHRpbWF0ZWx5IHJlcXVpcmUgbW9yZSBz cGVjaWZpY2l0eS4gDQoNCj4gLSBzcGVjaWZpY2F0aW9uIG9mIHJlbGV2YW50IGluZm9ybWF0aW9u IG1vZGVscyBhbmQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBuZWNlc3NhcnkgZGF0YSBtb2RlbHMu DQo+DQpSb24+PiBUaGVyZSBpcyBhbiBleHBlY3RhdGlvbiB0aGF0IFlBTkcgb3Igb3RoZXIgZGF0 YSBtb2RlbHMgd2lsbCBiZSBwdWJsaXNoZWQuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBKb2VsIE0uIEhhbHBlcm4NClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIg MTcsIDIwMTMgOToyOCBBTQ0KVG86IEVyc3VlLCBNZWhtZXQgKE5TTiAtIERFL011bmljaCk7IEpp bSBHdWljaGFyZCAoamd1aWNoYXIpOyBUaG9tYXMgTmFydGVuDQpDYzogbnNjQGlldGYub3JnOyBl eHQgQmVub2l0IENsYWlzZTsgZXh0IERpZWdvIFIuIExvcGV6OyBhZHJpYW4uZmFycmVsQGh1YXdl aS5jb207IGV4dCBNZWxpbmRhIFNob3JlDQpTdWJqZWN0OiBSZTogW25zY10gQ3VycmVudCBQcm9w b3NlZCBTRkMgY2hhcnRlcg0KDQpZb3UgbGlzdCBhIG51bWJlciBvZiB2ZXJ5IHVzZWZ1bCBpdGVt cyB0aGF0IGFyZSBuZWVkZWQgZm9yIHRoZSBmdWxsIHV0aWxpemF0aW9uIG9mIHNlcnZpY2UgY2hh aW5pbmcgaW4gYSBuZXR3b3JrLg0KDQpUaGF0IGRvZXMgbm90IG1lYW4gdGhhdCBhbGwgdGhvc2Ug aXRlbXMgc2hvdWxkIGJlIGluIHNjb3BlIGZvciB0aGlzIHdvcmtpbmcgZ3JvdXAuICBBcyBmYXIg YXMgSSBjYW4gdGVsbCwgb3VyIGdvYWwgaXMgdG8gbWFrZSBhIHVzZWZ1bCBjb250cmlidXRpb24g dG8gc29sdmluZyB0aGUgcHJvYmxlbSwgcmF0aGVyIHRoYW4gdG8gYXR0ZW1wdCB0byBzaW11bHRh bmVvdXNseSBhZGRyZXNzIGFsbCBrbm93biBvciBleHBlY3RlZCBpc3N1ZXMuDQoNClRoZSByZW1h aW5pbmcgdG9waWNzIG1heSBiZSBkZWFsdCB3aXRoIGluIG90aGVyIHdvcmtpbmcgZ3JvdXBzLCBp biBvdGhlciBmb3JhLCBvciBieSB2ZW5kb3JzIGFuZCBvcGVyYXRvcnMgaW5kaXZpZHVhbGx5Lg0K DQpZb3VycywNCkpvZWwNCg0KT24gMTEvMTcvMTMgOTowNyBBTSwgRXJzdWUsIE1laG1ldCAoTlNO IC0gREUvTXVuaWNoKSB3cm90ZToNCj4gRGVhciBTRkMgQ2hhaXJzLCBBbGwsDQo+DQo+IEFGQUlL IHRoZSBtYW5hZ2VtZW50IG9mIFNGQyBvciBzZXJ2aWNlIGdyYXBocyBpbiBnZW5lcmFsIG5lZWRz IHRvIGFkZHJlc3M6DQo+DQo+IC0gdGhlIG9yY2hlc3RyYXRpb24gb2YgYSBzZXJ2aWNlIGdyYXBo IGJhc2VkIG9uIHRoZSBpbmZvcm1hdGlvbiBpbiBhIA0KPiBtb2RlbCB1c2VkIGFzIGlucHV0LA0K PiAtIGxpZmVjeWNsZSBtYW5hZ2VtZW50IG9mIG5ldHdvcmsgc2VydmljZXMgYW5kIHBvc3NpYmx5 IG9mIHNpbmdsZSANCj4gVk5GcywNCj4gLSBGQ0FQUyBhcyB3ZWxsIGFzIG1hbmFnZW1lbnQgb2Yg dmlydHVhbGl6YXRpb24gcmVsYXRlZCBldmVudHMgKGUuZy4gDQo+IG1vbml0b3JpbmcgYW5kIGNv cnJlbGF0aW9uIG9mIHZpcnR1YWxpemF0aW9uIGV2ZW50cykNCj4gLSBzcGVjaWZpY2F0aW9uIG9m IHJlbGV2YW50IGluZm9ybWF0aW9uIG1vZGVscyBhbmQgdGhlIHN0YW5kYXJkaXphdGlvbiBvZiBu ZWNlc3NhcnkgZGF0YSBtb2RlbHMuDQo+DQo+IEFGQUlVIGl0IGlzIG5vdCBlYXN5IHRvIGFkZHJl c3MgYWxsIG9mIHRoZXNlIG1hbmFnZW1lbnQgYXNwZWN0cyBpbiB0aGUgZnV0dXJlIFNGQyBXRyBh bmQgYSBwYXJhbGxlbCB3b3JrIGluIE9QUyBhcmVhIG1pZ2h0IGJlIHVzZWZ1bCBpZiBzdGFydGVk IGVhcmx5Lg0KPg0KPiBQbGVhc2UgZWxhYm9yYXRlIGFuZCBhcmd1ZSBvdGhlcndpc2UuDQo+DQo+ IENoZWVycywNCj4gTWVobWV0DQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4g RnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIGV4dCBEaWVnbyBSLg0KPj4gTG9wZXoNCj4+IFNlbnQ6IFR1ZXNkYXksIE5v dmVtYmVyIDEyLCAyMDEzIDQ6NDYgUE0NCj4+IFRvOiBKaW0gR3VpY2hhcmQgKGpndWljaGFyKQ0K Pj4gQ2M6IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9yZzsgU3VtYW5kcmEgTWFqZWU7IEtldmlu IEogTWE7IFJvbiBQYXJrZXI7IEpvZWwgTS4NCj4+IEhhbHBlcm47IFN1cmVuZHJhIEt1bWFyIChz bWt1bWFyKQ0KPj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0 ZXINCj4+DQo+PiBMZXQgbWUgYWRkIGZvciB0aGUgcmVjb3JkIHRoYXQgdGhpcyBpcyB0aGUga2lu ZCBvZiBtYW5hZ2VtZW50IGFzcGVjdHMgDQo+PiBJIGhhZCBpbiBtaW5kIHdoZW4gd2Ugd2VyZSB0 YWxraW5nIGFib3V0IHNlcnZpY2UgbWV0YWRhdGEgYW5kIGhvdyB0byBleGNoYW5nZSB0aGVtLi4u DQo+Pg0KPj4gQmUgZ29vZGUsDQo+Pg0KPj4gT24gMTIgTm92IDIwMTMsIGF0IDE1OjUyICwgSmlt IEd1aWNoYXJkIChqZ3VpY2hhcikgd3JvdGU6DQo+Pg0KPj4+IFllcyBvcHRpbWl6YXRpb24gY2Fu IGNlcnRhaW5seSBiZSBidWlsdCBpbnRvIHRoaXMgYnV0IEkgd2FudGVkIHRvIA0KPj4+IHNob3cg YW4gZXhhbXBsZSBvZiB0aGUgdHlwZXMgb2YgdGhpbmdzIHdlIG1lYW4gd2hlbiB3ZSB0YWxrIGFi b3V0IA0KPj4+IGJyYW5jaGluZy4gT25jZSB0aGUgY29uY2VwdCBpcyBiZXR0ZXIgdW5kZXJzdG9v ZCBJIHRoaW5rIHdlIHdpbGwgc2VlIA0KPj4+IHNvbWUgbW9yZSBleGNpdGluZyBleGFtcGxlcy4g Tm90ZSBhbHNvIHRoYXQgdGhlIGNvbnRyb2wgbG9naWMgY291bGQgDQo+Pj4gYWxzbyB1dGlsaXpl IHRoZSBzZXJ2aWNlIGVuY2Fwc3VsYXRpb24gYXMgYSBtZWNoYW5pc20gdG8gcHVzaCANCj4+PiBu b3RpZmljYXRpb25zIGJhY2sgdXAgdGhlIG9yaWdpbmFsIGNoYWluIHRvIGluZm9ybSB0aGUgaW5n cmVzcyB0byANCj4+PiBieXBhc3MgdGhlIG9yaWdpbmFsIGNoYWluIGZvciBhbGwgc3Vic2VxdWVu dCBwYWNrZXRzIGZvciB0aGlzIGZsb3cuDQo+Pj4NCj4+PiBPbiAxMS8xMi8xMyA5OjQwIEFNLCAi Sm9lbCBNLiBIYWxwZXJuIiA8am1oQGpvZWxoYWxwZXJuLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj4g SmltLCB0aGFuayB5b3UgZm9yIGEgY29uY3JldGUgZXhhbXBsZS4NCj4+Pj4gSSB3b3VsZCBzdWdn ZXN0IHRoYXQgaW4gdGhlIHVzdWFsIGNhc2VzLCB0aGVyZSBpcyBhIGJldHRlciB3YXkgdG8gDQo+ Pj4+IGhhbmRsZSB0aGlzIHRoYW4gYnJhbmNoaW5nIGFuZCByZXdyaXRpbmcgYXQgdGhlIFBDUkYu DQo+Pj4+DQo+Pj4+IElmIHRoZSBEUEkgZW5naW5lIG9yIFBDUkYgbG9naWMgKHdoaWNoZXZlciBt YWtlcyB0aGUgZGVjaXNpb24pIA0KPj4+PiBub3RpZmllcyB0aGUgY29udHJvbCBsb2dpYyBhYm91 dCB0aGUgZGVjaXNpb24gZm9yIHRoZSBmbG93LCB0aGVuIA0KPj4+PiB0aGUgaW5ncmVzcyBjYW4g ZGlyZWN0IHN1YnNlcXVlbnQgcGFja2V0cyB0byB0aGUgY29ycmVjdCBwbGFjZSwgDQo+Pj4+IGF2 b2lkaW5nIG5lZWRsZXNzIHByb2Nlc3Npbmcgb2YgZnVydGhlciBwYWNrZXRzIGluIHRoZSBEUEkg YW5kIFBDUkYgbG9naWMuDQo+Pj4+IEZ1cnRoZXIsIHRoZSBuZWVkZWQgY29udHJvbCBpbmZvcm1h dGlvbiBjYW4gYmUgcGFzc2VkIHRvIHRoZSANCj4+Pj4gb3B0aW1pemF0aW9uIG9yIHBhcmVudGFs IGNvbnRyb2wgc28gdGhhdCBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUgDQo+Pj4+IHRoZSBmaXJz dCBwYWNrZXQgaXMgc2VudCwgYXZvaWRpbmcgdGhlIG5lZWQgZm9yIHRoZSBQQ1JGIHRvIA0KPj4+ PiB1bmRlcnN0YW5kIGhvdyB0byBkaXJlY3QgcGFja2V0cyB0byBzZXJ2aWNlIHBhdGhzLg0KPj4+ Pg0KPj4+PiBZb3VycywNCj4+Pj4gSm9lbA0KPj4+Pg0KPj4+PiBPbiAxMS8xMi8xMyA5OjA3IEFN LCBKaW0gR3VpY2hhcmQgKGpndWljaGFyKSB3cm90ZToNCj4+Pj4+IEhpIEtldmluLA0KPj4+Pj4N Cj4+Pj4+IExldCBtZSB0cnkgYW5kIHByb3ZpZGUgYSBjb25jcmV0ZSBleGFtcGxlIHRvIHNlZSBp ZiB0aGlzIGFuc3dlcnMgDQo+Pj4+PiB5b3VyIHNwZWNpZmljIHF1ZXN0aW9uOg0KPj4+Pj4NCj4+ Pj4+IFVzZSBjYXNlOiBQLUdXIC0+IFBDUkYgLT4gc2VydmljZXMgYXBwbGllZCB0byB0cmFmZmlj IGJhc2VkIG9uIA0KPj4+Pj4gYXBwbGljYXRpb25JRCBhbmQgc3Vic2NyaWJlcklELg0KPj4+Pj4N Cj4+Pj4+IEluc3RhbnRpYXRlZCBhczoNCj4+Pj4+DQo+Pj4+PiBTRkMxOiBQLUdXIC0+IERQSSAt PiBQQ1JGDQo+Pj4+PiBTRkMyOiBQQ1JGIC0+IHZpZGVvLW9wdGltaXphdGlvbiAtPiBtZXRlcmlu ZyAtPiBGVw0KPj4+Pj4gU0ZDMzogUENSRiAtPiBwYXJlbnRhbC1jb250cm9sIC0+IG1ldGVyaW5n IC0+IEZXDQo+Pj4+Pg0KPj4+Pj4gSW4gdGhpcyBjYXNlIERQSSBpcyBwZXJmb3JtZWQgb24gU0ZD MSBhbmQgaWRlbnRpZmllcyANCj4+Pj4+IGFwcGxpY2F0aW9uSUQuIFRoZSBhcHBsaWNhdGlvbklE IGlzIGNhcnJpZWQgaW4gdGhlIHNlcnZpY2UgDQo+Pj4+PiBlbmNhcHN1bGF0aW9uIHRvIFBDUkYu IFBDUkYgdXNlcyBzb2x1dGlvbiBzcGVjaWZpYyBsb2dpYyANCj4+Pj4+IChpZGVudGlmaWVzIHN1 YnNjcmliZXIsIGFwcGxpZXMgcG9saWNpZXMsIGV0YykgYW5kIHVzZXMgdGhlIHJlc3VsdCANCj4+ Pj4+IGFsb25nIHdpdGggdGhlIGFwcGxpY2F0aW9uSUQgcmVjZWl2ZWQgZnJvbSBEUEkgdG8gc2Vs ZWN0IGFuIA0KPj4+Pj4gb3V0Ym91bmQgc2VydmljZSBjaGFpbiwgU0ZDMiBvciBTRkMzLiBOb3Rl IHRoYXQgaW4gdGhpcyBjYXNlIA0KPj4+Pj4gYnJhbmNoaW5nIG9jY3VycyBmcm9tIFNGQzEgdG8g ZWl0aGVyIFNGQzIgb3IgU0ZDMy4NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBP biAxMS8xMi8xMyAxOjUyIEFNLCAiS2V2aW4gSiBNYSIgPGtldmluLm1hQGF6dWtpc3lzdGVtcy5j b20+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+Pj4gWWVzLCByZWNsYXNzaWZpY2F0aW9uIGNhbiBjaGFu Z2UgdGhlIHNlcnZpY2UgcGF0aCBhbmQgDQo+Pj4+Pj4+IHJlLWNsYXNzaWZpY2F0aW9uIG1heSBo YXBwZW4gYXQgYW55IG5vZGUgYWxvbmcgYSBzZXJ2aWNlIHBhdGguDQo+Pj4+Pj4NCj4+Pj4+PiBK dXN0IHRvIGV4cGFuZCBvbiB0aGF0LCBnb2luZyBiYWNrIHRvIHRoZSBvcmlnaW5hbCBxdWVzdGlv biBhYm91dCANCj4+Pj4+PiBzZXJ2aWNlIGhlYWRlciBlbmNhcHN1bGF0aW9uLCBpcyBpdCBpbnRl bmRlZCB0aGF0IGEgY2hhaW4gdGhhdCBpcyANCj4+Pj4+PiByZS1jbGFzc2lmaWVkIHdpbGwgZ2V0 IGEgbmV3IGNoYWluIElEIHdoaWNoIGZ1bGx5IGRlc2NyaWJlcyBhIA0KPj4+Pj4+IGNoYWluIHRo YXQgaXMgYSBzdXBlcnNldCBvZiB0aGUgb3JpZ2luYWwgY2hhaW4gSUQsIHByaW9yIHRvIA0KPj4+ Pj4+IERQSS1iYXNlZCByZS1jbGFzc2lmaWNhdGlvbj8gIChhc3N1bWluZyB0aGUgZ29hbCBpcyAi YSBzaW5nbGUgDQo+Pj4+Pj4gY2hhaW4gSUQgdGhhdCBpcyBjb21tb25seSB1bmRlcnN0b29kIGFs b25nIHRoZSBlbnRpcmUgc2VydmljZSBjaGFpbiINCj4+Pj4+PiBodHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvbnNjL2N1cnJlbnQvbXNnMDA2MzguaHRtbCkNCj4+Pj4+Pg0KPj4+ Pj4+IEFuZCB0aGUgYXBwbGljYWJsZSBzdWJzZXQgb2YgdGhlIHBlcm11dGF0aXZlIGxpc3Qgb2Yg c2VydmljZSANCj4+Pj4+PiBwYXRocyB3b3VsZCBiZSBjb25maWd1cmVkIGF0IGVhY2ggYXBwcm9w cmlhdGUgc2VydmljZSBub2RlPw0KPj4+Pj4+IGUuZy4sIElEIDE6IE5BVCArIGZpcmV3YWxsICsg RFBJDQo+Pj4+Pj4gICAgICAgSUQgMjogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBBVg0KPj4+Pj4+ ICAgICAgIElEIDM6IE5BVCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBOQVQNCj4+Pj4+PiAgICAg ICBJRCA0OiBOQVQgKyBmaXJld2FsbCArIERQSSArIE5BVA0KPj4+Pj4+ICAgICAgIElEIDU6IE5B VCArIGZpcmV3YWxsICsgRFBJICsgQVYgKyBMQg0KPj4+Pj4+ICAgICAgIElEIDY6IE5BVCArIGZp cmV3YWxsICsgRFBJICsgTEINCj4+Pj4+PiAgICAgICBJRCA3OiBOQVQgKyBmaXJld2FsbCArIERQ SSArIExCICsgQ0FDSEUNCj4+Pj4+PiAgICAgICBJRCA4OiBOQVQgKyBmaXJld2FsbCArIERQSSAr IENBQ0hFDQo+Pj4+Pj4gICAgICAgSUQgOTogTkFUICsgZmlyZXdhbGwgKyBEUEkgKyBvcHRpbWl6 ZXIgKyBMQg0KPj4+Pj4+ICAgICAgIElEIDEwOiBOQVQgKyBmaXJld2FsbCArIERQSSArIG9wdGlt aXplciArIExCICsgQ0FDSEUNCj4+Pj4+PiAgICAgICBJRCAxMTogTkFUICsgZmlyZXdhbGwgKyBE UEkgKyBvcHRpbWl6ZXIgKyBDQUNIRSBXb3VsZCBldmVyeSANCj4+Pj4+PiBmbG93IHRoZW4gYmUg aW5pdGlhbGx5IGNsYXNzaWZpZWQgYXMgSUQgMSwgYnV0IGV2ZW50dWFsbHkgZ2V0IA0KPj4+Pj4+ IHJlLWNsYXNzaWZpZWQgdG8gSUQgMi0xMSwgYWZ0ZXIgdGhlIERQSSBwaGFzZT8NCj4+Pj4+Pg0K Pj4+Pj4+IHRoYW54Lg0KPj4+Pj4+DQo+Pj4+Pj4gLS0gIEtldmluIEouIE1hDQo+Pj4+Pj4NCj4+ Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogU3VyZW5kcmEg S3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dDQo+Pj4+Pj4+IFNlbnQ6 IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDE6MDEgQU0NCj4+Pj4+Pj4gVG86IEtldmluIEog TWE7IFJvbiBQYXJrZXI7IFN1bWFuZHJhIE1hamVlOyBUaG9tYXMgTmFydGVuOyANCj4+Pj4+Pj4g bnNjQGlldGYub3JnDQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbbnNjXSBDdXJyZW50IFByb3Bvc2Vk IFNGQyBjaGFydGVyDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IE9uIDExLzEx LzEzIDk6NDYgUE0sICJLZXZpbiBKIE1hIiA8a2V2aW4ubWFAYXp1a2lzeXN0ZW1zLmNvbT4gd3Jv dGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiBIaSBTdXJlbmRyYSwNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAg IENsYXNzaWZpY2F0aW9uIG1heSBiZSBvdXQgb2Ygc2NvcGUsIGJ1dCB0aGUgbGV2ZWwgb2Ygc2Vy dmljZSANCj4+Pj4+Pj4+IHRoYXQgaXMNCj4+Pj4+Pj4+ICAgYXBwbGljYWJsZSBpcyBkZXBlbmRl bnQgdXBvbiB0aGUgbGV2ZWwgb2YgY2xhc3NpZmljYXRpb24gdGhhdCANCj4+Pj4+Pj4+IGNhbiBi ZQ0KPj4+Pj4+Pj4gICBwZXJmb3JtZWQuICBBbiBhc3N1bXB0aW9uIG9mIHBhY2tldCBsZXZlbCBl bmNhcHN1bGF0aW9uIGhhcw0KPj4+Pj4+PiBpbXBsaWNhdGlvbnMNCj4+Pj4+Pj4+ICAgb24gdGhl IGxldmVsIG9mIGNsYXNzaWZpY2F0aW9uIGJlaW5nIHBlcmZvcm1lZD8gIElmIHRoZSANCj4+Pj4+ Pj4+IHN0YXRlZCBnb2Fscw0KPj4+Pj4+PiBhcmUNCj4+Pj4+Pj4+ICAgZm9yIGZpcmV3YWxsIGFu ZCBsb2FkIGJhbGFuY2VyIGZ1bmN0aW9uYWxpdHksIHRoZW4gdGhlIA0KPj4+Pj4+Pj4gYXBwbGlj YXRpb24NCj4+Pj4+Pj4gbGV2ZWwNCj4+Pj4+Pj4+ICAgbmF0dXJlIG9mIHRob3NlIGZ1bmN0aW9u cyBuZWVkcyB0byBiZSB0YWtlbiBpbnRvIGFjY291bnQ/ICANCj4+Pj4+Pj4+IElmLCBvbiB0aGUN Cj4+Pj4+Pj4+ICAgb3RoZXIgaGFuZCwgdGhlIHNlcnZpY2UgZnVuY3Rpb24gc2NvcGUgaXMgbGlt aXRlZCBkdWUgdG8gDQo+Pj4+Pj4+PiBsaW1pdGF0aW9ucw0KPj4+Pj4+PiBpbg0KPj4+Pj4+Pj4g ICBjbGFzc2lmaWNhdGlvbiwgdGhhdCB3b3VsZCBiZSBhbmQgaW1wb3J0YW50IHBpZWNlIG9mIGlu Zm9ybWF0aW9uPw0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgV3J0IHNlY3Rpb24gNC40IG9mIGRyYWZ0 LWxpdS1zZXJ2aWNlLWNoYWluaW5nLXVzZS1jYXNlcyB0aGUgDQo+Pj4+Pj4+PiBmb3JrDQo+Pj4+ Pj4+IHBvaW50cw0KPj4+Pj4+Pj4gICBvZiB0aGUgc2VydmljZSBwYXRocyBzZWVtIGxpa2UgcmUt Y2xhc3NpZmljYXRpb24gcG9pbnRzPyAgSXMgDQo+Pj4+Pj4+PiB0aGF0IHRoZQ0KPj4+Pj4+Pj4g ICBpbnRlcnByZXRhdGlvbiBmcm9tIHRoZSBhcmNoaXRlY3R1cmUgcGVyc3BlY3RpdmU/ICBPciBp cyB0aGUgDQo+Pj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4+PiAgIGZ1bmN0aW9uIGNoYWluIGNsYXNz aWZpY2F0aW9uIGV4Y2x1c2l2ZSBvZiBEUEkgZnVuY3Rpb25hbGl0eT8NCj4+Pj4+Pj4gPFNLPiBJ IGhhdmUgbm90IGZ1bGx5IHJlYWQgdGhhdCBkcmFmdCB5ZXQuIEJ1dCBpbiBnZW5lcmFsLCBhcyAN Cj4+Pj4+Pj4gZGVzY3JpYmVkIGluIHRoZSBhcmNoIGRyYWZ0LCB0aGUgY29sbGVjdGlvbiBvZiBz ZXJ2aWNlcyBmb3JtIGEgDQo+Pj4+Pj4+IGdyYXBoLCBzZWdtZW50cyBvZiB3aGljaCBhcmUgc2Vy dmljZSBwYXRocy4gWWVzLCANCj4+Pj4+Pj4gcmVjbGFzc2lmaWNhdGlvbiBjYW4gY2hhbmdlIHRo ZSBzZXJ2aWNlIHBhdGggYW5kIA0KPj4+Pj4+PiByZS1jbGFzc2lmaWNhdGlvbiBtYXkgaGFwcGVu IGF0IGFueSBub2RlIGFsb25nIGEgc2VydmljZSBwYXRoLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBTdXJl bmRyYS4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiB0aGFueC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAtLSAg S2V2aW4gSi4gTWENCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+Pj4+Pj4+PiBGcm9tOiBTdXJlbmRyYSBLdW1hciAoc21rdW1hcikgW21haWx0bzpzbWt1 bWFyQGNpc2NvLmNvbV0NCj4+Pj4+Pj4+PiBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAx MyAxMjowOCBBTQ0KPj4+Pj4+Pj4+IFRvOiBLZXZpbiBKIE1hOyBSb24gUGFya2VyOyBTdW1hbmRy YSBNYWplZTsgVGhvbWFzIE5hcnRlbjsNCj4+Pj4+Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4g U3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IEtldmluLA0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2xhc3NpZmljYXRpb24g bWVjaGFuaXNtIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFNGQy4gSXQgY2FuIA0KPj4+Pj4+Pj4+ IGJlIGJhc2VkDQo+Pj4+Pj4+IG9uDQo+Pj4+Pj4+Pj4gdGhlIHBhY2tldCBvciBpbmZvcm1hdGlv biBub3QgaW4gdGhlIHBhY2tldChlbnZpcm9ubWVudGFsIA0KPj4+Pj4+Pj4+IGF0dHJpYnV0ZXMN Cj4+Pj4+Pj4gZm9yDQo+Pj4+Pj4+Pj4gaW5zdGFuY2UpIG9yIGEgY29tYmluYXRpb24gdGhlcmVv Zi4gV2hhdCBpcyBpbXBvcnRhbnQgaXMgdGhhdCANCj4+Pj4+Pj4+PiBzdWNoIGNsYXNzaWZpY2F0 aW9uIGFpZHMgaW4gdHJhZmZpYyBzZWxlY3Rpb24gYW5kIHNlcnZpY2UgcGF0aCANCj4+Pj4+Pj4+ PiBpZGVudGlmaWNhdGlvbi4NCj4+Pj4+Pj4+PiBJdCBpcyBubyBkaWZmZXJlbnQgZnJvbSBhIHBv bGljeSBpbiB0aGlzIHJlZ2FyZCBleGNlcHQgdGhhdCANCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4g cG9saWN5DQo+Pj4+Pj4+Pj4gbm93DQo+Pj4+Pj4+Pj4gc3BlY2lmaWVzIHRoZSBzZXJ2aWNlIHBh dGguDQo+Pj4+Pj4+Pj4gRnVydGhlciwgY2xhc3NpZmljYXRpb24gaXMgbm90IGxpbWl0ZWQgdG8g dGhlIG5ldHdvcmsgZWxlbWVudHMgDQo+Pj4+Pj4+Pj4gYnV0DQo+Pj4+Pj4+IHRoZQ0KPj4+Pj4+ Pj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFzIHdlbGwuIFNvbWUgb2YgdGhpcyBpcyBkZXNjcmliZWQg aW4gdGhlDQo+Pj4+Pj4+IGFyY2hpdGVjdHVyZQ0KPj4+Pj4+Pj4+IGRyYWZ0cyBhcyB3ZWxsIC0N Cj4+Pj4+Pj4+PiAiaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcXVpbm4t c2ZjLWFyY2gvIi4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFN1cmVuZHJhLg0KPj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4gT24gMTEvMTEvMTMgNzozMyBQTSwgIktldmluIEogTWEiIDxrZXZpbi5tYUBhenVr aXN5c3RlbXMuY29tPg0KPj4gd3JvdGU6DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSGkgUm9uLA0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgIEkgd2FzIHVuYWJsZSB0byBtYWtlIHRoZSBTRkMgQm9G IGR1ZSB0byBhIGNvbmZsaWN0IHdpdGggDQo+Pj4+Pj4+Pj4+IENETkksIGJ1dA0KPj4+Pj4+PiBJ DQo+Pj4+Pj4+Pj4+ICAgaGFkIGEgc2ltaWxhciBxdWVzdGlvbiB3cnQgYnVsbGV0IDExIGluIHNl Y3Rpb24gMiBvZiB0aGUgDQo+Pj4+Pj4+Pj4+IHByb2JsZW0NCj4+Pj4+Pj4+Pj4gc3RhdGVtZW50 Og0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgICAgMTEuICBQZXItU2VydmljZSAocmUpQ2xhc3Np ZmljYXRpb246IENsYXNzaWZpY2F0aW9uIA0KPj4+Pj4+Pj4+PiBvY2N1cnMgYXQNCj4+Pj4+Pj4g ZWFjaA0KPj4+Pj4+Pj4+PiAgICAgICAgICBzZXJ2aWNlLCBpbmRlcGVuZGVudCBmcm9tIHByZXZp b3VzbHkgYXBwbGllZCBzZXJ2aWNlDQo+Pj4+Pj4+Pj4gZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+PiAg ICAgICAgICBUaGVzZSB1bnJlbGF0ZWQgY2xhc3NpZmljYXRpb24gZXZlbnRzIGNvbnN1bWUgDQo+ Pj4+Pj4+Pj4+IHJlc291cmNlcyBwZXINCj4+Pj4+Pj4+Pj4gICAgICAgICAgc2VydmljZS4gIE1v cmUgaW1wb3J0YW50bHksIHRoZSBjbGFzc2lmaWNhdGlvbg0KPj4+Pj4+PiBmdW5jdGlvbmFsaXR5 DQo+Pj4+Pj4+Pj4+ICAgICAgICAgIG9mdGVuIGRpZmZlcnMgcGVyIHNlcnZpY2UgZnVuY3Rpb24g YW5kIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+IGZ1bmN0aW9uDQo+Pj4+Pj4+IGNhbm5vdA0KPj4+Pj4+ Pj4+PiAgICAgICAgICBsZXZlcmFnZSB0aGUgcmVzdWx0cyBmcm9tIG90aGVyIGRlcGxveWVkIG5l dHdvcmsgb3INCj4+Pj4+Pj4gc2VydmljZS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICBhcyBp dCByZWxhdGVzIHRvIHNlY3Rpb24gNS4yIG9mIHRoZSBmcmFtZXdvcmsgZG9jdW1lbnQ6DQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgICBUaGUgU0ZDIENsYXNzaWZpZXIgY2xhc3NpZmllcyBwYWNr ZXRzIGJhc2VkIG9uIChzb21lIG9mKSANCj4+Pj4+Pj4+Pj4gdGhlDQo+Pj4+Pj4+Pj4gY29udGVu dHMNCj4+Pj4+Pj4+Pj4gICAgIG9mIHRoZSBwYWNrZXQgaGVhZGVyLiAgQ29uY3JldGVseSwgaXQg Y2xhc3NpZmllcyBwYWNrZXRzIA0KPj4+Pj4+Pj4+PiBiYXNlZA0KPj4+Pj4+PiBvbg0KPj4+Pj4+ Pj4+IHRoZQ0KPj4+Pj4+Pj4+PiAgICAgcG9zc2libGUgY29tYmluYXRpb24gb2Ygb25lIG9yIG1v cmUgaGVhZGVyIGZpZWxkcywgc3VjaCANCj4+Pj4+Pj4+Pj4gYXMNCj4+Pj4+Pj4gc291cmNlDQo+ Pj4+Pj4+Pj4+ICAgICBhZGRyZXNzLCBkZXN0aW5hdGlvbiBhZGRyZXNzLCBEUyBmaWVsZCwgcHJv dG9jb2wgSUQsIA0KPj4+Pj4+Pj4+PiBzb3VyY2UgcG9ydA0KPj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+ Pj4+PiAgICAgZGVzdGluYXRpb24gcG9ydCBudW1iZXJzLCBhbmQgYW55IG90aGVyIGluZm9ybWF0 aW9uLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgIEEgcGFja2V0LWJhc2VkIGNsYXNzaWZpZXIg YXMgZGVzY3JpYmVkIGluIHRoZSBmcmFtZXdvcmsgDQo+Pj4+Pj4+Pj4+IGRvY3VtZW50DQo+Pj4+ Pj4+Pj4gd291bGQNCj4+Pj4+Pj4+Pj4gICBzZWVtIHRvIGJlIGxpbWl0ZWQgaW4gd2hhdCBpdCBj YW4gY2xhc3NpZnk/ICBUaGUgc2VydmljZSBmdW5jdGlvbg0KPj4+Pj4+Pj4+PiAgIGlkZW50aWZp ZXIgbG9va3VwIGRvZXMgbm90IHNlZW0gdG8gYmUgYSBzaWduaWZpY2FudCANCj4+Pj4+Pj4+Pj4g b3B0aW1pemF0aW9uDQo+Pj4+Pj4+IG92ZXINCj4+Pj4+Pj4+Pj4gICBhIHBhY2tldC1iYXNlZCA1 LXR1cGxlIGxvb2t1cD8gIFRoZXJlIHNlZW1zIHRvIGJlIHNvbWUgDQo+Pj4+Pj4+Pj4+IG1pc3Np bmcNCj4+Pj4+Pj4gZGV0YWlsDQo+Pj4+Pj4+Pj4+ICAgd3J0IGhvdyBjbGFzc2lmaWNhdGlvbiBp bmZvcm1hdGlvbiBpcyBkZXRlcm1pbmVkIGFuZCByZXVzZWQ/DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+ICAgV2hlbiB0aGlua2luZyBhYm91dCBoaWdoZXIgbGV2ZWwgc2VydmljZXMsIGUuZy4sIEhU VFAgYW5kIA0KPj4+Pj4+Pj4+PiBUTFMNCj4+Pj4+Pj4+PiBlbmNyeXB0ZWQNCj4+Pj4+Pj4+Pj4g ICBmbG93cywgYSBwYWNrZXQtYmFzZWQgY2xhc3NpZmllciBzZWVtcyBpbmFkZXF1YXRlPyAgSSB3 YXMgDQo+Pj4+Pj4+Pj4+IGFsc28NCj4+Pj4+Pj4+PiB3b25kZXJpbmcNCj4+Pj4+Pj4+Pj4gICBo b3cgaW5kZXBlbmRlbnQgSExTIHNlZ21lbnQgcmVxdWVzdHMgbWlnaHQgYmUgY2xhc3NpZmllZCAN Cj4+Pj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4gYXNzb2NpYXRlZD8NCj4+Pj4+Pj4+Pj4gICBXZXJl IHRoZXNlIHR5cGVzIG9mIHVzZSBjYXNlcyBkaXNjdXNzZWQgaW4gdGhlIEJvRj8NCj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4gdGhhbnguDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IC0tICBLZXZpbiBK LiBNYQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4+Pj4+Pj4+Pj4+IEZyb206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIA0KPj4+Pj4+Pj4+Pj4gQmVoYWxmDQo+Pj4+Pj4+IE9mDQo+Pj4+Pj4+ Pj4+PiBSb24NCj4+Pj4+Pj4+Pj4+IFBhcmtlcg0KPj4+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBO b3ZlbWJlciAxMSwgMjAxMyAxMDoxNiBQTQ0KPj4+Pj4+Pj4+Pj4gVG86IFN1bWFuZHJhIE1hamVl OyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBb bnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBjaGFydGVyDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4gU3VtYW5kcmEsDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQXMgd2FzIGRpc2N1c3NlZCBp biBWYW5jb3V2ZXIsIHRoZXJlIGFyZSBhbHJlYWR5IG1hbnkgDQo+Pj4+Pj4+Pj4+PiBleGlzdGlu Zw0KPj4+Pj4+PiB3YXlzDQo+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+Pj4+IGFjY29tcGxpc2ggc2Vy dmljZSBjaGFpbmluZy4gICAgIEJ1dCBub25lIG9mIHRoZW0gcHJvdmlkZSBhDQo+Pj4+Pj4+Pj4g c3VmZmljaWVudA0KPj4+Pj4+Pj4+Pj4gY29tYmluYXRpb24gb2YgaW50ZXJvcGVyYWJpbGl0eSwg ZmxleGliaWxpdHksIGFuZCByZXNpbGllbmN5LiAgIEENCj4+Pj4+Pj4+PiBzaW5nbGUNCj4+Pj4+ Pj4+Pj4+IHNlcnZpY2UgY2hhaW4gZW5jYXBzdWxhdGlvbiB3aWxsIGdvIGEgbG9uZyB3YXkgdG8g ZW5zdXJpbmcgDQo+Pj4+Pj4+Pj4+PiB0aGVzZQ0KPj4+Pj4+Pj4+IGdvYWxzLg0KPj4+Pj4+Pj4+ Pj4gSXQgIG1heSBub3QgYmUgdGhlIGFic29sdXRlbHkgbW9zdCBlZmZpY2llbnQgYXBwcm9hY2gg Zm9yIA0KPj4+Pj4+Pj4+Pj4gZXZlcnkNCj4+Pj4+Pj4+PiBzaW5nbGUNCj4+Pj4+Pj4+Pj4+IG5l dHdvcmsgdG9wb2xvZ3kgYW5kIGV2ZXJ5IHNpbmdsZSB1c2UgY2FzZSwgYnV0IGl0cyANCj4+Pj4+ Pj4+Pj4+IHViaXF1aXRvdXMNCj4+Pj4+Pj4gbmF0dXJlDQo+Pj4+Pj4+Pj4+PiBzaG91bGQgaW1w cm92ZSBpdHMgYWRvcHRpb24uDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gICAgIFJvbg0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPj4+Pj4+Pj4+Pj4gRnJvbTogU3VtYW5kcmEgTWFqZWUgW21haWx0bzpTLk1hamVlQEY1 LmNvbV0NCj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEsIDIwMTMgMTA6MTAg UE0NCj4+Pj4+Pj4+Pj4+IFRvOiBSb24gUGFya2VyOyBUaG9tYXMgTmFydGVuOyBuc2NAaWV0Zi5v cmcNCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6IFJFOiBbbnNjXSBDdXJyZW50IFByb3Bvc2VkIFNGQyBj aGFydGVyDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gUm9uLA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IEFic29sdXRlbHksIHRoYXQgd2FzIGFuIGV4YW1wbGUgb2Ygb25lIHR5cGUgb2YgZGVy aXZhdGlvbi4gDQo+Pj4+Pj4+Pj4+PiBIb3dldmVyDQo+Pj4+Pj4+Pj4gdGhpcw0KPj4+Pj4+Pj4+ Pj4gY291bGQgYmUgYXVnbWVudGVkIHdpdGggY2xhc3NpZmljYXRpb24gcmVzdWx0LCBhZ2FpbiBv bmUgDQo+Pj4+Pj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+Pj4gZXhhbXBsZS4NCj4+Pj4+Pj4+Pj4+DQo+ Pj4+Pj4+Pj4+Pj4+IEFsbCBmbG93cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSBJUCBkbyBub3QgbmVj ZXNzYXJpbHkgDQo+Pj4+Pj4+Pj4+Pj4+IGZvbGxvdyB0aGUNCj4+Pj4+Pj4+PiBzYW1lDQo+Pj4+ Pj4+Pj4+PiBjaGFpbi4NCj4+Pj4+Pj4+Pj4+IENvcnJlY3QuIEl0IGlzIGFsc28gbm90IG5lY2Vz c2FyeSB0aGF0IGFsbCB0cmFuc2FjdGlvbiBvZiANCj4+Pj4+Pj4+Pj4+IHRoZSBzYW1lDQo+Pj4+ Pj4+Pj4gZmxvdw0KPj4+Pj4+Pj4+Pj4gZm9sbG93IHRoZSBzYW1lIGNoYWluIGVpdGhlci4gU28g d2h5IHN0b3AgYXQgZmxvdyBpdHNlbGYuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gQWdhaW4g dGhlIHBvaW50IGhlcmUgaXMgdGhhdCBkbyB3ZSBhbHdheXMgbmVlZCBTRkMgaGVhZGVyIG9yIE5v dC4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBTdW1hbmRyYQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+ Pj4gRnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJtZWRuZXR3b3Jrcy5j b21dDQo+Pj4+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE5vdmVtYmVyIDExLCAyMDEzIDc6MDIgUE0N Cj4+Pj4+Pj4+Pj4+IFRvOiBTdW1hbmRyYSBNYWplZTsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYu b3JnDQo+Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMg Y2hhcnRlcg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFN1bWFuZHJhLA0KPj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IFRoZSBpbnRlbnRpb24gb2Ygc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyBp cyB0byBhbGxvdyBmb3INCj4+Pj4+Pj4gb3BlcmF0aW9uDQo+Pj4+Pj4+Pj4gYXQNCj4+Pj4+Pj4+ Pj4+IHRoZSBmdWxseSBxdWFsaWZpZWQgZmxvdyBsZXZlbCwgb3IgZXZlbiBmaW5lciBncmFpbmVk IGF0IHRoZQ0KPj4+Pj4+Pj4+IHRyYW5zYWN0aW9uDQo+Pj4+Pj4+Pj4+PiBsZXZlbCAodGhpcyBp cyBhbiBpbXBsZW1lbnRhdGlvbiBtYXR0ZXIgZm9yIHRoZSBQRFApLiAgICAgQWxsDQo+Pj4+Pj4+ IGZsb3dzDQo+Pj4+Pj4+Pj4gZnJvbQ0KPj4+Pj4+Pj4+Pj4gdGhlIHNhbWUgc291cmNlIElQIGRv IG5vdCBuZWNlc3NhcmlseSBmb2xsb3cgdGhlIHNhbWUgY2hhaW4uDQo+Pj4+Pj4+IFNvdXJjZQ0K Pj4+Pj4+Pj4+Pj4gSVAsDQo+Pj4+Pj4+Pj4+PiB0aGVyZWZvcmUsICBkb2VzIG5vdCBpZGVudGlm eSB0aGUgY2hhaW4gSUQuICAgIEFub3RoZXIgaW50ZW50aW9uDQo+Pj4+Pj4+IG9mDQo+Pj4+Pj4+ Pj4+PiBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGlzIHRvIG9wZXJhdGUgb3ZlciBhbnkgbmV0 d29yayANCj4+Pj4+Pj4+Pj4+IHRvcG9sb2d5DQo+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4gbm90 DQo+Pj4+Pj4+Pj4+PiBiZSBsaW1pdGVkIHRvIGEgc2luZ2xlIExBTi4gICBUaHVzLCB3aGlsZSBW TEFOIG1heSBiZSBwYXJ0IG9mIHRoZQ0KPj4+Pj4+Pj4+Pj4gdHJhbnNwb3J0LCBpdCBkb2VzIG5v dCBhZGVxdWF0ZWx5IGlkZW50aWZ5IHRoZSBzZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4gY2hhaW4sDQo+ Pj4+Pj4+IGVpdGhlci4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAgUm9uDQo+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+Pj4+Pj4+Pj4+PiBGcm9tOiBTdW1hbmRyYSBNYWplZSBbbWFpbHRvOlMuTWFqZWVARjUuY29t XQ0KPj4+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAxMSwgMjAxMyA5OjU2IFBNDQo+ Pj4+Pj4+Pj4+PiBUbzogUm9uIFBhcmtlcjsgVGhvbWFzIE5hcnRlbjsgbnNjQGlldGYub3JnDQo+ Pj4+Pj4+Pj4+PiBTdWJqZWN0OiBSRTogW25zY10gQ3VycmVudCBQcm9wb3NlZCBTRkMgY2hhcnRl cg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFJvbiwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ PiBUaGUgc2VydmljZSBoZWFkZXIgaXMgbWVhbnQgdG8gY2FycnkgdGhlIGNvbnRleHQgd2hpY2gg Y2FuIA0KPj4+Pj4+Pj4+Pj4gKmFsc28qDQo+Pj4+Pj4+IGJlDQo+Pj4+Pj4+Pj4+PiBkZXJpdmVk IChmb3IgZXhhbXBsZSB1c2Ugc291cmNlIGlwIGFuZCB2bGFuIHRvIGlkZW50aWZ5IA0KPj4+Pj4+ Pj4+Pj4gY2hhaW5JRA0KPj4+Pj4+PiBhbmQNCj4+Pj4+Pj4+Pj4+IHBvc2l0aW9uKSBvciBlbmNh cHN1bGF0ZWQgYXMgcGFydCBvZiBhbm90aGVyIHR1bm5lbCBoZWFkZXIuIA0KPj4+Pj4+Pj4+Pj4g U28NCj4+Pj4+Pj4gdGhpcw0KPj4+Pj4+Pj4+Pj4gY291bGQNCj4+Pj4+Pj4+Pj4+IGJlIG9wdGlv bmFsIElNSE8uDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+Pj4+Pj4+Pj4+IEZyb206IFJvbiBQYXJrZXIgW21haWx0bzpSb25fUGFya2VyQGFm ZmlybWVkbmV0d29ya3MuY29tXQ0KPj4+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBOb3ZlbWJlciAx MSwgMjAxMyA0OjM2IFBNDQo+Pj4+Pj4+Pj4+PiBUbzogU3VtYW5kcmEgTWFqZWU7IFRob21hcyBO YXJ0ZW47IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4gU3ViamVjdDogUkU6IFtuc2NdIEN1cnJl bnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBTdW1hbmRy YSwNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBBcyBJIHVuZGVyc3RhbmQgaXQsIGFuIFNGQyBw YWNrZXQgdHJhdmVyc2luZyBmcm9tIFBEUCB0byBTRiANCj4+Pj4+Pj4+Pj4+IG9yDQo+Pj4+Pj4+ IGZyb20NCj4+Pj4+Pj4+PiBTRg0KPj4+Pj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+Pj4+IFNGIHdpbGwg bG9vayBsaWtlOg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0rDQo+Pj4+Pj4+Pj4+PiB8ICAgICAgICAidHJhbnNwb3J0IiAgICAgICAgIHwNCj4+Pj4+ Pj4+Pj4+ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+Pj4+PiB8ICAgICAgc2Vy dmljZSBoZWFkZXIgICAgfA0KPj4+Pj4+Pj4+Pj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsN Cj4+Pj4+Pj4+Pj4+IHwgICBvcmlnaW5hbCBJUCBoZWFkZXIgIHwNCj4+Pj4+Pj4+Pj4+ICstLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pj4+Pj4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICBvcmlnaW5hbCBJUCANCj4+Pj4+Pj4+Pj4+IHwgcGF5bG9h ZA0KPj4+Pj4+PiB8DQo+Pj4+Pj4+Pj4+PiB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQo+Pj4+Pj4+Pj4+PiArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFdoZXJlIHNlcnZpY2UgaGVhZGVyIGNvbnRhaW5zLCBhdCBh IG1pbmltdW0sIGVub3VnaCANCj4+Pj4+Pj4+Pj4+IGluZm9ybWF0aW9uIHRvDQo+Pj4+Pj4+Pj4g YWxsb3cNCj4+Pj4+Pj4+Pj4+IHRoZSBwYWNrZXQgdG8gYmUgcHJvcGFnYXRlZCBhbG9uZyB0aGUg ZnVsbCBsZW5ndGggb2YgdGhlIA0KPj4+Pj4+Pj4+Pj4gY2hhaW4sDQo+Pj4+Pj4+IGFuZA0KPj4+ Pj4+Pj4+Pj4gb3B0aW9uYWxseSwgb3RoZXIgbWV0YWRhdGEgdGhhdCBlbmhhbmNlcyB0aGUgb3Bl cmF0aW9uIG9mIA0KPj4+Pj4+Pj4+Pj4gb25lIG9yDQo+Pj4+Pj4+IG1vcmUNCj4+Pj4+Pj4+Pj4+ IHNlcnZpY2UgZnVuY3Rpb25zLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ICAgQW5kIHdoZXJl ICJ0cmFuc3BvcnQiIGNvdWxkIGNvbmNlaXZhYmx5IGJlIGFueSBvZiwgYnV0IG5vdA0KPj4+Pj4+ PiBsaW1pdGVkDQo+Pj4+Pj4+Pj4gdG86DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gKiBFdGhl cm5ldA0KPj4+Pj4+Pj4+Pj4gKiBFdGhlcm5ldCArIExMQzINCj4+Pj4+Pj4+Pj4+ICogRXRoZXJu ZXQgKyBNUExTDQo+Pj4+Pj4+Pj4+PiAqIEV0aGVybmV0ICsgSVAgKyBHUkUNCj4+Pj4+Pj4+Pj4+ ICogRXRoZXJuZXQgKyBJUCArVURQDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+IEFsc28sICJvcmlnaW5hbCIgaW4gdGhlIGRpYWdyYW0gYWJvdmUgaXMgbm90IG1lYW50IHRv IGltcGx5IA0KPj4+Pj4+Pj4+Pj4gaW1tdXRhYmlsaXR5LCBidXQgcmF0aGVyIHRvIHNwZWNpZnkg dGhlIHBhY2tldCB0aGF0IGlzIA0KPj4+Pj4+Pj4+Pj4gcHJvcGFnYXRlZCBmcm9tIHByZWNlZGlu ZyBlbnRpdHkgdG8gc3VjY2VlZGluZyBlbnRpdHksIHByaW9yIA0KPj4+Pj4+Pj4+Pj4gdG8gZW5j YXBzdWxhdGlvbi4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiAgICAgUm9uDQo+Pj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ Pj4+Pj4+Pj4+PiBGcm9tOiBuc2MtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOm5zYy1ib3VuY2Vz QGlldGYub3JnXSBPbiANCj4+Pj4+Pj4+Pj4+IEJlaGFsZg0KPj4+Pj4+PiBPZg0KPj4+Pj4+Pj4+ Pj4gU3VtYW5kcmEgTWFqZWUNCj4+Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTEs IDIwMTMgNjo0NiBQTQ0KPj4+Pj4+Pj4+Pj4gVG86IFRob21hcyBOYXJ0ZW47IG5zY0BpZXRmLm9y Zw0KPj4+Pj4+Pj4+Pj4gU3ViamVjdDogUmU6IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNo YXJ0ZXINCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBHZW5lcmljIFNlcnZpY2UgRnVuY3Rpb24g Q2hhaW5pbmcgRW5jYXBzdWxhdGlvbjogQSBkb2N1bWVudCB3aWxsDQo+Pj4+Pj4+Pj4+PiAgICAg IGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5lIA0KPj4+Pj4+Pj4+ Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+IGZvcg0KPj4+Pj4+ Pj4+Pj4gICAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBz ZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+PiBwYXRoLA0KPj4+Pj4+Pj4+ Pj4gICAgICBhbmQgZm9yIGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVu IG5vZGVzIHRoYXQNCj4+Pj4+Pj4+Pj4+ICAgICAgaW1wbGVtZW50IHNlcnZpY2UgZnVuY3Rpb25z LiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0KPj4+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24NCj4+Pj4+ Pj4+Pj4+ICAgICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNoIGl0IGlzIGFwcGxp ZWQgYW5kIHRoZQ0KPj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4+Pj4gdGhhdA0KPj4+Pj4+Pj4+Pj4g aXMNCj4+Pj4+Pj4+Pj4+ICAgICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQgaXMsIHRoZSBzYW1l IGVuY2Fwc3VsYXRpb24gbWF5IA0KPj4+Pj4+Pj4+Pj4gYmUgdXNlZA0KPj4+Pj4+PiBvbg0KPj4+ Pj4+Pj4+Pj4gICAgICBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXplZCBhdCB0aGUgbmV0 d29yayBsYXllciANCj4+Pj4+Pj4+Pj4+IG9yIGF0DQo+Pj4+Pj4+IGFueQ0KPj4+Pj4+Pj4+Pj4g b3RoZXINCj4+Pj4+Pj4+Pj4+ICAgICAgbGF5ZXIsIGFuZCB0aGUgc2FtZSBlbmNhcHN1bGF0aW9u IHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4+Pj4+PiBjb25zdHJ1Y3Rpb24NCj4+Pj4+Pj4+PiBvZg0K Pj4+Pj4+Pj4+Pj4gICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2FyZGxlc3Mgb2YgdGhl IGFjdHVhbCBzZXJ2aWNlLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IFtTTV0gV2hhdCBkb2Vz IGl0IG1lYW4gYnkgYSBzaW5nbGUgc2VydmljZS1sZXZlbCANCj4+Pj4+Pj4+Pj4+IGVuY2Fwc3Vs YXRpb24sICBhDQo+Pj4+Pj4+Pj4gbmV3DQo+Pj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uIGZvcm1h dA0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgICAgIG9yIGFuIGFiaWxpdHkgdG8gc2VsZWN0IG9uZSBl bmNhcHN1bGF0aW9uIA0KPj4+Pj4+Pj4+Pj4gZm9ybWF0IHRoYXQNCj4+Pj4+Pj4+PiBmaXRzDQo+ Pj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+IG5lZWQgZm9yIGEgZ2l2ZW4gc2VydmljZSBjaGFp bj8NCj4+Pj4+Pj4+Pj4+ICAgICAgICAgICAgIFRoZSBhYmlsaXR5IHRvIHNlbGVjdCBhIHNwZWNp ZmljIGVuY2Fwc3VsYXRpb24gIA0KPj4+Pj4+Pj4+Pj4gd291bGQNCj4+Pj4+Pj4gYmUNCj4+Pj4+ Pj4gYQ0KPj4+Pj4+Pj4+Pj4gbWFuYWdlbWVudCBwbGFuZSBkZWNpc2lvbi4NCj4+Pj4+Pj4+Pj4+ ICAgICAgICAgICAgVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGV4aXN0aW5nIGVuY2Fwc3VsYXRpb24g DQo+Pj4+Pj4+Pj4+PiBtZXRob2RzDQo+Pj4+Pj4+IHRoYXQNCj4+Pj4+Pj4+PiBjYW4NCj4+Pj4+ Pj4+Pj4+IHBvc3NpYmx5IGJlIHJldXNlZCB0byBwcm92aWRlDQo+Pj4+Pj4+Pj4+PiAgICAgICAg ICAgIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0d2VlbiAgIHNlcnZpY2Ugbm9kZXMuIEkgaGF2ZQ0K Pj4+Pj4+Pj4+Pj4gc2Vlbg0KPj4+Pj4+Pj4+Pj4gbWVudGlvbg0KPj4+Pj4+Pj4+Pj4gb2YgR1JF LCBmb3IgSFRUUCBiYXNlZA0KPj4+Pj4+Pj4+Pj4gICAgICAgICAgICBhcHBsaWNhdGlvbnMgY29u dGV4dHMgYXJlIHRyYW5zZmVycmVkIHZpYSBoZWFkZXJzLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+Pj4g RnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10g T24gDQo+Pj4+Pj4+Pj4+PiBCZWhhbGYNCj4+Pj4+Pj4gT2YNCj4+Pj4+Pj4+Pj4+IFRob21hcyBO YXJ0ZW4NCj4+Pj4+Pj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMDYsIDIwMTMgMTE6 MDcgQU0NCj4+Pj4+Pj4+Pj4+IFRvOiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IFN1YmplY3Q6 IFtuc2NdIEN1cnJlbnQgUHJvcG9zZWQgU0ZDIGNoYXJ0ZXINCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+ Pj4+PiBIaS4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBDdXJyZW50IGNoYXJ0ZXIgY2FuIGJl IGZvdW5kIGF0DQo+Pj4+Pj4+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9j aGFydGVyLQ0KPj4+Pj4+Pj4+Pj4gaWV0Zi1zZmMvLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+ IEl0IGNvbnRhaW5zIHRoZSByZXZpc2VkIG1hbmFnZW1lbnQgdGV4dCBhcyB3ZWxsIGFzIHVwZGF0 ZWQNCj4+Pj4+Pj4+PiBtaWxlc3RvbmVzLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEFsbCBr bm93biBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gSWYgdGhlcmUgYXJlIGFueSANCj4+Pj4+ Pj4+Pj4+IHJlbWFpbmluZw0KPj4+Pj4+Pj4+IGlzc3VlcywNCj4+Pj4+Pj4+Pj4+IHBsZWFzZSBz cGVhayB1cCENCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBDaGFydGVyIGNoYXJ0ZXItaWV0Zi1z ZmMtMDAtMDQNCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBOZXR3b3Jrcywgc2VydmVycywgc3Rv cmFnZSB0ZWNobm9sb2dpZXMsIGFuZCBhcHBsaWNhdGlvbnMsIA0KPj4+Pj4+Pj4+Pj4gaGF2ZQ0K Pj4+Pj4+PiBhbGwNCj4+Pj4+Pj4+Pj4+IHVuZGVyZ29uZSBzaWduaWZpY2FudCBjaGFuZ2UgaW4g cmVjZW50IHllYXJzIHdpdGggdGhlIA0KPj4+Pj4+Pj4+Pj4gaW50cm9kdWN0aW9uDQo+Pj4+Pj4+ IG9mDQo+Pj4+Pj4+Pj4+PiB2aXJ0dWFsaXphdGlvbiwgbmV0d29yayBvdmVybGF5cywgYW5kIG9y Y2hlc3RyYXRpb24uIFNlcnZpY2UNCj4+Pj4+Pj4gZGVsaXZlcnkNCj4+Pj4+Pj4+PiBpcw0KPj4+ Pj4+Pj4+Pj4gY3VycmVudGx5IGJvdGggYSB0ZWNobmljYWwgYW5kIG9yZ2FuaXphdGlvbmFsIGNo YWxsZW5nZSB0aGF0DQo+Pj4+Pj4+IGludm9sdmVzDQo+Pj4+Pj4+Pj4+PiBzaWduaWZpY2FudCBt b2RpZmljYXRpb24gdG8gdGhlIG5ldHdvcmsgY29uZmlndXJhdGlvbi4NCj4+Pj4+Pj4+Pj4+IFNl cnZpY2VzIGFyZSB0eXBpY2FsbHkgaW1wbGVtZW50ZWQgYnkgdGhlIG9yZGVyZWQgDQo+Pj4+Pj4+ Pj4+PiBjb21iaW5hdGlvbiBvZiBhIG51bWJlciBvZiBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFy ZSANCj4+Pj4+Pj4+Pj4+IGRlcGxveWVkIGF0IGRpZmZlcmVudCBwb2ludHMgd2l0aGluDQo+Pj4+ Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4gbmV0d29yay4gVG9kYXksIGEgY29tbW9uIGRlcGxveW1lbnQg bW9kZWwgaGFzIHNlcnZpY2UgDQo+Pj4+Pj4+Pj4+PiBmdW5jdGlvbnMgcGh5c2ljYWxseSBpbnNl cnRlZCBvbiB0aGUgZGF0YSBmb3J3YXJkaW5nIHBhdGggDQo+Pj4+Pj4+Pj4+PiBiZXR3ZWVuIGNv bW11bmljYXRpbmcgcGVlcnMuDQo+Pj4+Pj4+Pj4gR29pbmcNCj4+Pj4+Pj4+Pj4+IGZvcndhcmQs IGhvd2V2ZXIsIHRoZXJlIGlzIGEgZGVzaXJlIHRvIG1vdmUgdG8gYSBkaWZmZXJlbnQgDQo+Pj4+ Pj4+Pj4+PiBtb2RlbCwNCj4+Pj4+Pj4+PiB3aGVyZQ0KPj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5j dGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byByZXNpZGUgb24gdGhlIGRlZmF1bHQgDQo+Pj4+Pj4+ Pj4+PiBkYXRhDQo+Pj4+Pj4+IHBhdGgNCj4+Pj4+Pj4+Pj4+IGFuZA0KPj4+Pj4+Pj4+Pj4gdHJh ZmZpYyBpcyBpbnN0ZWFkIHN0ZWVyZWQgdGhyb3VnaCBzZXJ2aWNlcywgd2hlcmV2ZXIgdGhleSAN Cj4+Pj4+Pj4+Pj4+IGFyZQ0KPj4+Pj4+Pj4+IGRlcGxveWVkLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IEZvciBhIGdpdmVuIHNlcnZpY2UsIHRoZSBhYnN0cmFjdGVkIHZpZXcgb2YgdGhlIHJl cXVpcmVkIA0KPj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbnMgYW5kIHRoZSBvcmRlciBpbiB3 aGljaCB0aGV5IGFyZSB0byBiZSANCj4+Pj4+Pj4+Pj4+IGFwcGxpZWQgaXMgY2FsbGVkIGEgU2Vy dmljZSBGdW5jdGlvbiBDaGFpbiAoU0ZDKS4gU2luY2UgYSANCj4+Pj4+Pj4+Pj4+IGdpdmVuIHNl cnZpY2UgZnVuY3Rpb24gbWF5IGJlIGF2YWlsYWJsZSBvbg0KPj4+Pj4+PiBtb3JlDQo+Pj4+Pj4+ Pj4+PiB0aGFuDQo+Pj4+Pj4+Pj4+PiBvbmUgbm9kZSB3aXRoaW4gYSBuZXR3b3JrLCBhIFNlcnZp Y2UgRnVuY3Rpb24gQ2hhaW4gaXMNCj4+Pj4+Pj4gaW5zdGFudGlhdGVkDQo+Pj4+Pj4+Pj4gdmlh DQo+Pj4+Pj4+Pj4+PiB0aGUgc2VsZWN0aW9uIG9mIHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24g aW5zdGFuY2VzIGFuZCB0aGUNCj4+Pj4+Pj4gbmV0d29yaw0KPj4+Pj4+Pj4+Pj4gbm9kZXMNCj4+ Pj4+Pj4+Pj4+IG9uIHdoaWNoIHRoZXkgYXJlIHByb3ZpZGVkLCB0aGVyZWJ5IGZvcm1pbmcgYSBz ZXJ2aWNlIHRvcG9sb2d5Og0KPj4+Pj4+Pj4+Pj4gdGhpcyBpcyBjYWxsZWQgYSBTZXJ2aWNlIEZ1 bmN0aW9uIFBhdGguIFRoZSBzZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4gZnVuY3Rpb25zIG1heQ0KPj4+ Pj4+PiBiZQ0KPj4+Pj4+Pj4+Pj4gYXBwbGllZCBhdCBhIHNwZWNpZmljIGxheWVyIHdpdGhpbiB0 aGUgbmV0d29yayBwcm90b2NvbCANCj4+Pj4+Pj4+Pj4+IHN0YWNrDQo+Pj4+Pj4+Pj4gKG5ldHdv cmsNCj4+Pj4+Pj4+Pj4+IGxheWVyLCBhcHBsaWNhdGlvbiBsYXllciwgZXRjLikuDQo+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4gVGhlIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5pbmcgKFNGQykgd29y a2luZyBncm91cCB3aWxsIA0KPj4+Pj4+Pj4+Pj4gZGV2ZWxvcCBuZXcgYXBwcm9hY2hlcyB0byBz ZXJ2aWNlIGRlbGl2ZXJ5IGFuZCBkZXBsb3ltZW50LiANCj4+Pj4+Pj4+Pj4+IEl0IHdpbGwgcHJv ZHVjZSBhIGZyYW1ld29yayBmb3Igc2VydmljZSBmdW5jdGlvbiBjaGFpbmluZyANCj4+Pj4+Pj4+ Pj4+IHRoYXQgaW5jbHVkZXMgdGhlIG5lY2Vzc2FyeQ0KPj4+Pj4+PiBwcm90b2NvbHMNCj4+Pj4+ Pj4+PiBvcg0KPj4+Pj4+Pj4+Pj4gcHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBjb252ZXkgdGhlIHNl cnZpY2UgcGF0aCBhbmQgc2VydmljZSANCj4+Pj4+Pj4+Pj4+IHBhdGggaW5mb3JtYXRpb24gdG8g bm9kZXMgdGhhdCBpbXBsZW1lbnQgc2VydmljZSBmdW5jdGlvbnMsIA0KPj4+Pj4+Pj4+Pj4gYXMg d2VsbCBhcyBtZWNoYW5pc21zIGZvciBzdGVlcmluZyB0cmFmZmljIHRocm91Z2ggc2VydmljZSAN Cj4+Pj4+Pj4+Pj4+IGZ1bmN0aW9ucy4gVGhlDQo+Pj4+Pj4+Pj4gd29ya2luZw0KPj4+Pj4+Pj4+ Pj4gZ3JvdXAgd2lsbCBhbHNvIGV4YW1pbmUgd2hhdCBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSAN Cj4+Pj4+Pj4+Pj4+IGdhdGhlcmVkIGZyb20NCj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+Pj4+IG5l dHdvcmsgYW5kIHNlcnZpY2UgZnVuY3Rpb25zIGluIHN1cHBvcnQgb2Ygc2VydmljZSBmdW5jdGlv bg0KPj4+Pj4+PiBjaGFpbmluZw0KPj4+Pj4+Pj4+Pj4gYW5kDQo+Pj4+Pj4+Pj4+PiBob3cgdGhh dCBpbmZvcm1hdGlvbiBtYXkgYmUgbWFkZSBhdmFpbGFibGUgdG8gbm9kZXMgdGhhdCANCj4+Pj4+ Pj4+Pj4+IGltcGxlbWVudA0KPj4+Pj4+Pj4+IHRoZQ0KPj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5j dGlvbnMuDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gU3BlY2lmaWNhbGx5LCB0aGUgU0ZDIFdH IGlzIGNoYXJ0ZXJlZCB0byBkZWxpdmVyIHRoZSBmb2xsb3dpbmc6DQo+Pj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+Pj4gMSkgUHJvYmxlbSBTdGF0ZW1lbnQ6IFRoaXMgZG9jdW1lbnQgd2lsbCBwcm92aWRl IGEgc3VtbWFyeSBvZiB0aGUNCj4+Pj4+Pj4+Pj4+ICAgICAgcHJvYmxlbSBzcGFjZSB0byBiZSBh ZGRyZXNzZWQgYnkgdGhlIFdHIGluY2x1ZGluZyANCj4+Pj4+Pj4+Pj4+IGV4YW1wbGUNCj4+Pj4+ Pj4gaGlnaC0NCj4+Pj4+Pj4+Pj4+ICAgICAgbGV2ZWwgdXNlIGNhc2VzLiBBZGRpdGlvbmFsbHks IHRoZSBXRyB3aWxsIG5vcm1hbGl6ZQ0KPj4+Pj4+PiBub21lbmNsYXR1cmUNCj4+Pj4+Pj4+Pj4+ ICAgICAgYW5kIGRlZmluaXRpb25zIGZvciBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nLg0KPj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IDIpIEFyY2hpdGVjdHVyZTogVGhpcyBkb2N1bWVudCB3aWxs IHByb3ZpZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGUNCj4+Pj4+Pj4+Pj4+ICAgICAgYXJjaGl0ZWN0 dXJhbCBidWlsZGluZyBibG9ja3MgYW5kIHRoZWlyIHJlbGF0aW9uc2hpcHMNCj4+Pj4+Pj4gaW5j bHVkaW5nDQo+Pj4+Pj4+Pj4+PiAgICAgIGludGVyY29ubmVjdGlvbiwgcGxhY2VtZW50IG9mIGNh cGFiaWxpdGllcywgbWFuYWdlbWVudCwNCj4+Pj4+Pj4+Pj4+ICAgICAgZGlhZ25vc3RpY3MsIGRl c2lnbiBhbmFseXNpcywgYW5kIHNlY3VyaXR5IG1vZGVscywgYXMgd2VsbCBhcw0KPj4+Pj4+Pj4+ Pj4gICAgICByZXF1aXJlbWVudHMgb24gdGhlIHByb3RvY29sIG1lY2hhbmlzbXMuDQo+Pj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+Pj4gMykgR2VuZXJpYyBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIEVu Y2Fwc3VsYXRpb246IEEgDQo+Pj4+Pj4+Pj4+PiBkb2N1bWVudA0KPj4+Pj4+PiB3aWxsDQo+Pj4+ Pj4+Pj4+PiAgICAgIGRlc2NyaWJlIHRoZSBzaW5nbGUgc2VydmljZS1sZXZlbCBkYXRhIHBsYW5l IA0KPj4+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbg0KPj4+Pj4+PiBmb3JtYXQNCj4+Pj4+Pj4+Pj4+ IGZvcg0KPj4+Pj4+Pj4+Pj4gICAgICBjb252ZXlpbmcgdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hh aW4gYW5kIHRoZSBzZXJ2aWNlIA0KPj4+Pj4+Pj4+Pj4gZnVuY3Rpb24NCj4+Pj4+Pj4+PiBwYXRo LA0KPj4+Pj4+Pj4+Pj4gICAgICBhbmQgZm9yIGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1h dGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQNCj4+Pj4+Pj4+Pj4+ICAgICAgaW1wbGVtZW50IHNlcnZp Y2UgZnVuY3Rpb25zLiBJdCBpcyBpbnRlbmRlZCB0aGF0IHRoZQ0KPj4+Pj4+Pj4+IGVuY2Fwc3Vs YXRpb24NCj4+Pj4+Pj4+Pj4+ICAgICAgYmUgYWdub3N0aWMgdG8gdGhlIGxheWVyIGF0IHdoaWNo IGl0IGlzIGFwcGxpZWQgYW5kIHRoZQ0KPj4+Pj4+PiBzZXJ2aWNlDQo+Pj4+Pj4+Pj4gdGhhdA0K Pj4+Pj4+Pj4+Pj4gaXMNCj4+Pj4+Pj4+Pj4+ICAgICAgYmVpbmcgY29uc3RydWN0ZWQuIFRoYXQg aXMsIHRoZSBzYW1lIGVuY2Fwc3VsYXRpb24gbWF5IA0KPj4+Pj4+Pj4+Pj4gYmUgdXNlZA0KPj4+ Pj4+PiBvbg0KPj4+Pj4+Pj4+Pj4gICAgICBhIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCByZWFsaXpl ZCBhdCB0aGUgbmV0d29yayBsYXllciANCj4+Pj4+Pj4+Pj4+IG9yIGF0DQo+Pj4+Pj4+IGFueQ0K Pj4+Pj4+Pj4+Pj4gb3RoZXINCj4+Pj4+Pj4+Pj4+ICAgICAgbGF5ZXIsIGFuZCB0aGUgc2FtZSBl bmNhcHN1bGF0aW9uIHdpbGwgYXBwbHkgZm9yIHRoZQ0KPj4+Pj4+PiBjb25zdHJ1Y3Rpb24NCj4+ Pj4+Pj4+PiBvZg0KPj4+Pj4+Pj4+Pj4gICAgICBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGhzIHJlZ2Fy ZGxlc3Mgb2YgdGhlIGFjdHVhbCBzZXJ2aWNlLg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IDQp IENvbnRyb2wgUGxhbmUgTWVjaGFuaXNtczogQSBzZXQgb2YgZG9jdW1lbnRzIHdpbGwgYmUgDQo+ Pj4+Pj4+Pj4+PiBkZXZlbG9wZWQNCj4+Pj4+Pj4gdG8NCj4+Pj4+Pj4+Pj4+ICAgICAgZGVzY3Jp YmUgcmVxdWlyZW1lbnRzIGFuZCBwcm90b2NvbHMgbmVjZXNzYXJ5IHRvIGNvbnZleQ0KPj4+Pj4+ Pj4+IGluZm9ybWF0aW9uDQo+Pj4+Pj4+Pj4+PiAgICAgIHRvIHNlcnZpY2UgZnVuY3Rpb24gaW1w bGVtZW50YXRpb24gcG9pbnRzLiBXaGVyZSANCj4+Pj4+Pj4+Pj4+IHBvc3NpYmxlLA0KPj4+Pj4+ Pj4+IGV4aXN0aW5nDQo+Pj4+Pj4+Pj4+PiAgICAgIElFVEYgcHJvdG9jb2xzIHdpbGwgYmUgdXNl ZCBhbmQgZXh0ZW5kZWQuIEFsbCBwcm90b2NvbA0KPj4+Pj4+PiBleHRlbnNpb25zDQo+Pj4+Pj4+ Pj4+PiAgICAgIHdvcmsgc2hvdWxkIGJlIGNhcnJpZWQgb3V0IGluIHRoZSB3b3JraW5nIGdyb3Vw cyANCj4+Pj4+Pj4+Pj4+IHJlc3BvbnNpYmxlDQo+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4+IHRoZQ0K Pj4+Pj4+Pj4+Pj4gICAgICBwcm90b2NvbHMgYmVpbmcgbW9kaWZpZWQgaW4gY29vcmRpbmF0aW9u IHdpdGggdGhpcyANCj4+Pj4+Pj4+Pj4+IHdvcmtpbmcNCj4+Pj4+Pj4gZ3JvdXAsDQo+Pj4+Pj4+ Pj4+PiBidXQNCj4+Pj4+Pj4+Pj4+ICAgICAgbWF5IGJlIGRvbmUgaW4gdGhpcyB3b3JraW5nIGdy b3VwIGFmdGVyIGFncmVlbWVudCB3aXRoIA0KPj4+Pj4+Pj4+Pj4gYWxsIHRoZQ0KPj4+Pj4+Pj4+ Pj4gICAgICByZWxldmFudCBXRyBjaGFpcnMgYW5kIHJlc3BvbnNpYmxlIEFEcy4NCj4+Pj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+PiA1KSBNYW5hZ2VhYmlsaXR5OiBXb3JrIG9uIHRoZSBtYW5hZ2VtZW50 IGFuZCBjb25maWd1cmF0aW9uIA0KPj4+Pj4+Pj4+Pj4gb2YNCj4+Pj4+Pj4gc2VydmljZQ0KPj4+ Pj4+Pj4+Pj4gICAgICBmdW5jdGlvbnMgaW4gc3VwcG9ydCBvZiBTRkMgY29tcG9uZW50cyB3aWxs IGNlcnRhaW5seSANCj4+Pj4+Pj4+Pj4+IGJlDQo+Pj4+Pj4+IG5lZWRlZCwNCj4+Pj4+Pj4+Pj4+ ICAgICAgYnV0IGZpcnN0IG5lZWRzIHRvIGJlIGJldHRlciB1bmRlcnN0b29kIGFuZCBzY29wZWQu DQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gUHJvcG9zZWQgTWlsZXN0b25lcw0KPj4+Pj4+Pj4+ Pj4NCj4+Pj4+Pj4+Pj4+IEFwciAyMDE0IFN1Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9j dW1lbnQocykgZGVmaW5pbmcgDQo+Pj4+Pj4+Pj4+PiB0aGUNCj4+Pj4+Pj4+PiBwcm9ibGVtDQo+ Pj4+Pj4+Pj4+PiBzdGF0ZW1lbnQgYW5kIGNvcmUgdXNlIGNhc2VzIGZvciBTZXJ2aWNlIEZ1bmN0 aW9uIENoYWluaW5nDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gTWF5IDIwMTQgQ29uc3VsdCB3 aXRoIE9QUyBBcmVhIG9uIHBvc3NpYmxlIGNoYXJ0ZXIgDQo+Pj4+Pj4+Pj4+PiBtb2RpZmljYXRp b25zDQo+Pj4+Pj4+IGZvcg0KPj4+Pj4+Pj4+Pj4gbWFuYWdlbWVudCBhbmQgY29uZmlndXJhdGlv biBvZiBTRkMgY29tcG9uZW50cw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEphbiAyMDE1IFN1 Ym1pdCB0byBJRVNHIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgZGVmaW5pbmcgdGhlDQo+Pj4+Pj4+ Pj4gYXJjaGl0ZWN0dXJlDQo+Pj4+Pj4+Pj4+PiBmb3IgU0ZDDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pj4gSmFuIDIwMTUgU3VibWl0IHRvIElFU0cgcmVxdWlyZW1lbnRzIGZvciBhIGdlbmVyaWMg c2VydmljZQ0KPj4+Pj4+PiBmdW5jdGlvbg0KPj4+Pj4+Pj4+Pj4gY2hhaW5pbmcgZW5jYXBzdWxh dGlvbiBwcm90b2NvbA0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEF1ZyAyMDE1IFN1Ym1pdCB0 byBJRVNHIFN0YW5kYXJkcyBUcmFjayBkb2N1bWVudCBzcGVjaWZ5aW5nIA0KPj4+Pj4+Pj4+Pj4g dGhlDQo+Pj4+Pj4+Pj4gZ2VuZXJpYw0KPj4+Pj4+Pj4+Pj4gc2VydmljZSBmdW5jdGlvbiBjaGFp bmluZyBoZWFkZXIgZW5jYXBzdWxhdGlvbg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBUaG9tYXMNCj4+ Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4+Pj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4+Pj4+Pj4g bnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25zYw0KPj4+Pj4+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+Pj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4+ IG5zY0BpZXRmLm9yZw0KPj4+Pj4+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uc2MNCj4+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+Pj4+Pj4+ PiBuc2NAaWV0Zi5vcmcNCj4+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbnNjDQo+Pj4+Pj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+Pj4+Pj4+Pj4+IG5zYyBtYWlsaW5nIGxpc3QNCj4+Pj4+Pj4+Pj4g bnNjQGlldGYub3JnDQo+Pj4+Pj4+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnNjDQo+Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4+PiBuc2MgbWFpbGluZyBsaXN0DQo+Pj4+ Pj4gbnNjQGlldGYub3JnDQo+Pj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uc2MNCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+Pj4gbnNjQGlldGYub3Jn DQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPj4+Pj4N Cj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+Pj4gbnNjIG1haWxpbmcgbGlzdA0KPj4+IG5zY0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+Pg0KPj4NCj4+IC0tDQo+PiAiRXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KPj4NCj4+IERyIERpZWdvIFIuIExv cGV6DQo+PiBUZWxlZm9uaWNhIEkrRA0KPj4gaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9w ZXovDQo+Pg0KPj4gZS1tYWlsOiBkaWVnb0B0aWQuZXMNCj4+IFRlbDogICAgKzM0IDkxMyAxMjkg MDQxDQo+PiBNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4+DQo+PiBFc3RlIG1lbnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEg c3UgZGVzdGluYXRhcmlvLiBQdWVkZSANCj4+IGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBk ZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNl IHNpdHVhZG8gbcOhcyBhYmFqby4NCj4+IFRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNp dmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIA0KPj4gYW5kIHJlY2VpdmUgZW1h aWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KPj4gaHR0cDovL3d3dy50 aWQuZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuc2MgbWFpbGluZyBsaXN0DQo+PiBuc2NA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5zYyBt YWlsaW5nIGxpc3QNCj4gbnNjQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbnNjDQo+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlzdA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0K From cpignata@cisco.com Sun Nov 17 08:21:15 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF9211E8D06 for ; Sun, 17 Nov 2013 08:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lubBOcvxjSKa for ; Sun, 17 Nov 2013 08:21:10 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9011E8CFC for ; Sun, 17 Nov 2013 08:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30467; q=dns/txt; s=iport; t=1384705259; x=1385914859; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9F52XNIirAcr104gb/TVFTy1LqBwPVMu2qNkYrjS3hw=; b=lTFsMFGczJnzTqMFksyWIur7r7HJZOFc9MPLbT0I+FVAu+vcx9WcuqSF 5XCeFDbhoB/6eREXCKIjzDL5+NEh6LpLNTTKxvCiX3ywVIQ19lvBNl9L3 nAZdW858kvtqNkKx//VPQO/oMIZEXPXEjzqFmsS0lrBVC+VKKxmk2lRys 8=; X-Files: signature.asc : 203 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAInsiFKtJV2Z/2dsb2JhbABPCoMHOFO/K4EQFnSCJQEBAQMBAQEBFw0+AgcEBwUHBAIBCBEBAwEBARUSBycLFAMGCAIECgQFCQUNh2AGDcECF44dBgQGAgEGgQgJIgIFAgQEgxaBEQOQMIEwggxCg2KBL5BegyiBaAEfIg X-IronPort-AV: E=Sophos;i="4.93,718,1378857600"; d="asc'?scan'208";a="285665002" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 17 Nov 2013 16:20:58 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAHGKvNO026637 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Nov 2013 16:20:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.229]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 10:20:56 -0600 From: "Carlos Pignataro (cpignata)" To: "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAP//5+wAgAADV4CAAA7jAIAHzLoAgACN/4A= Date: Sun, 17 Nov 2013 16:20:56 +0000 Message-ID: <773085DD-99D1-4583-BC1D-68671CDBCE23@cisco.com> References: <91E7C467-6F08-40D7-B8F2-C6B39DAAC6FB@tid.es> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.230.248] Content-Type: multipart/signed; boundary="Apple-Mail=_CF2F66B4-A051-4211-97F8-43B03D42E1CC"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , "adrian.farrel@huawei.com" , "Benoit Claise \(bclaise\)" , "ext Diego R. Lopez" Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 16:21:15 -0000 --Apple-Mail=_CF2F66B4-A051-4211-97F8-43B03D42E1CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Mehmet, I think it is important for SFC to deliver chartered items with focus. = All these are good elements supporting a broader problem around SFC, and = I'd cautious SFC to focus -- it does not mean SFC (or even the IETF) = should work on the items you list. =46rom the charter, item 5, SFC need to better understand and scope what = these things mean. And in this, one of the things to avoid is: http://tools.ietf.org/html/rfc1925 (5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. Thanks, -- Carlos. On Nov 17, 2013, at 9:07 AM, Ersue, Mehmet (NSN - DE/Munich) = wrote: > Dear SFC Chairs, All, >=20 > AFAIK the management of SFC or service graphs in general needs to = address: >=20 > - the orchestration of a service graph based on the information in a = model used as input, > - lifecycle management of network services and possibly of single = VNFs, > - FCAPS as well as management of virtualization related events (e.g. = monitoring and correlation of virtualization events) > - specification of relevant information models and the standardization = of necessary data models. >=20 > AFAIU it is not easy to address all of these management aspects in the = future SFC WG and a parallel work in OPS area might be useful if started = early. >=20 > Please elaborate and argue otherwise. >=20 > Cheers,=20 > Mehmet=20 >=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of = ext Diego R. >> Lopez >> Sent: Tuesday, November 12, 2013 4:46 PM >> To: Jim Guichard (jguichar) >> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee; Kevin J Ma; Ron = Parker; Joel M. >> Halpern; Surendra Kumar (smkumar) >> Subject: Re: [nsc] Current Proposed SFC charter >>=20 >> Let me add for the record that this is the kind of management aspects = I had in mind >> when we were talking about service metadata and how to exchange = them... >>=20 >> Be goode, >>=20 >> On 12 Nov 2013, at 15:52 , Jim Guichard (jguichar) wrote: >>=20 >>> Yes optimization can certainly be built into this but I wanted to = show an >>> example of the types of things we mean when we talk about branching. = Once >>> the concept is better understood I think we will see some more = exciting >>> examples. Note also that the control logic could also utilize the = service >>> encapsulation as a mechanism to push notifications back up the = original >>> chain to inform the ingress to bypass the original chain for all >>> subsequent packets for this flow. >>>=20 >>> On 11/12/13 9:40 AM, "Joel M. Halpern" wrote: >>>=20 >>>> Jim, thank you for a concrete example. >>>> I would suggest that in the usual cases, there is a better way to = handle >>>> this than branching and rewriting at the PCRF. >>>>=20 >>>> If the DPI engine or PCRF logic (whichever makes the decision) = notifies >>>> the control logic about the decision for the flow, then the ingress = can >>>> direct subsequent packets to the correct place, avoiding needless >>>> processing of further packets in the DPI and PCRF logic. >>>> Further, the needed control information can be passed to the >>>> optimization or parental control so that it does not matter where = the >>>> first packet is sent, avoiding the need for the PCRF to understand = how >>>> to direct packets to service paths. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >>>>> Hi Kevin, >>>>>=20 >>>>> Let me try and provide a concrete example to see if this answers = your >>>>> specific question: >>>>>=20 >>>>> Use case: P-GW -> PCRF -> services applied to traffic based on >>>>> applicationID and subscriberID. >>>>>=20 >>>>> Instantiated as: >>>>>=20 >>>>> SFC1: P-GW -> DPI -> PCRF >>>>> SFC2: PCRF -> video-optimization -> metering -> FW >>>>> SFC3: PCRF -> parental-control -> metering -> FW >>>>>=20 >>>>> In this case DPI is performed on SFC1 and identifies = applicationID. The >>>>> applicationID is carried in the service encapsulation to PCRF. = PCRF uses >>>>> solution specific logic (identifies subscriber, applies policies, = etc) >>>>> and >>>>> uses the result along with the applicationID received from DPI to = select >>>>> an outbound service chain, SFC2 or SFC3. Note that in this case >>>>> branching >>>>> occurs from SFC1 to either SFC2 or SFC3. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> On 11/12/13 1:52 AM, "Kevin J Ma" = wrote: >>>>>=20 >>>>>>> Yes, reclassification can change the service path and >>>>>>> re-classification may happen at any node along a service path. >>>>>>=20 >>>>>> Just to expand on that, going back to the original question about >>>>>> service header encapsulation, is it intended that a chain that >>>>>> is re-classified will get a new chain ID which fully describes >>>>>> a chain that is a superset of the original chain ID, prior to >>>>>> DPI-based re-classification? (assuming the goal is "a single >>>>>> chain ID that is commonly understood along the entire service = chain" >>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>>>>>=20 >>>>>> And the applicable subset of the permutative list of service >>>>>> paths would be configured at each appropriate service node? >>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>> ID 2: NAT + firewall + DPI + AV >>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>> ID 6: NAT + firewall + DPI + LB >>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE >>>>>> Would every flow then be initially classified as ID 1, but >>>>>> eventually get re-classified to ID 2-11, after the DPI phase? >>>>>>=20 >>>>>> thanx. >>>>>>=20 >>>>>> -- Kevin J. Ma >>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>> nsc@ietf.org >>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" = wrote: >>>>>>>=20 >>>>>>>> Hi Surendra, >>>>>>>>=20 >>>>>>>> Classification may be out of scope, but the level of service = that >>>>>>>> is >>>>>>>> applicable is dependent upon the level of classification that = can >>>>>>>> be >>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>> implications >>>>>>>> on the level of classification being performed? If the stated >>>>>>>> goals >>>>>>> are >>>>>>>> for firewall and load balancer functionality, then the = application >>>>>>> level >>>>>>>> nature of those functions needs to be taken into account? If, = on >>>>>>>> the >>>>>>>> other hand, the service function scope is limited due to >>>>>>>> limitations >>>>>>> in >>>>>>>> classification, that would be and important piece of = information? >>>>>>>>=20 >>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the = fork >>>>>>> points >>>>>>>> of the service paths seem like re-classification points? Is = that >>>>>>>> the >>>>>>>> interpretation from the architecture perspective? Or is the >>>>>>>> service >>>>>>>> function chain classification exclusive of DPI functionality? >>>>>>> I have not fully read that draft yet. But in general, as >>>>>>> described >>>>>>> in >>>>>>> the arch draft, the collection of services form a graph, = segments of >>>>>>> which >>>>>>> are service paths. Yes, reclassification can change the service = path >>>>>>> and >>>>>>> re-classification may happen at any node along a service path. >>>>>>>=20 >>>>>>> Surendra. >>>>>>>>=20 >>>>>>>> thanx. >>>>>>>>=20 >>>>>>>> -- Kevin J. Ma >>>>>>>>=20 >>>>>>>>> -----Original Message----- >>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>> nsc@ietf.org >>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>=20 >>>>>>>>> Kevin, >>>>>>>>>=20 >>>>>>>>> Classification mechanism is outside the scope of SFC. It can = be >>>>>>>>> based >>>>>>> on >>>>>>>>> the packet or information not in the packet(environmental = attributes >>>>>>> for >>>>>>>>> instance) or a combination thereof. What is important is that = such >>>>>>>>> classification aids in traffic selection and service path >>>>>>>>> identification. >>>>>>>>> It is no different from a policy in this regard except that = the >>>>>>> policy >>>>>>>>> now >>>>>>>>> specifies the service path. >>>>>>>>> Further, classification is not limited to the network elements = but >>>>>>> the >>>>>>>>> service functions as well. Some of this is described in the >>>>>>> architecture >>>>>>>>> drafts as well - >>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>=20 >>>>>>>>> Surendra. >>>>>>>>>=20 >>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >> wrote: >>>>>>>>>=20 >>>>>>>>>> Hi Ron, >>>>>>>>>>=20 >>>>>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, = but >>>>>>> I >>>>>>>>>> had a similar question wrt bullet 11 in section 2 of the = problem >>>>>>>>>> statement: >>>>>>>>>>=20 >>>>>>>>>> 11. Per-Service (re)Classification: Classification occurs = at >>>>>>> each >>>>>>>>>> service, independent from previously applied service >>>>>>>>> functions. >>>>>>>>>> These unrelated classification events consume = resources >>>>>>>>>> per >>>>>>>>>> service. More importantly, the classification >>>>>>> functionality >>>>>>>>>> often differs per service function and service = function >>>>>>> cannot >>>>>>>>>> leverage the results from other deployed network or >>>>>>> service. >>>>>>>>>>=20 >>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>=20 >>>>>>>>>> The SFC Classifier classifies packets based on (some of) = the >>>>>>>>> contents >>>>>>>>>> of the packet header. Concretely, it classifies packets = based >>>>>>> on >>>>>>>>> the >>>>>>>>>> possible combination of one or more header fields, such as >>>>>>> source >>>>>>>>>> address, destination address, DS field, protocol ID, source >>>>>>>>>> port >>>>>>>>> and >>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>=20 >>>>>>>>>> A packet-based classifier as described in the framework = document >>>>>>>>> would >>>>>>>>>> seem to be limited in what it can classify? The service = function >>>>>>>>>> identifier lookup does not seem to be a significant = optimization >>>>>>> over >>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some = missing >>>>>>> detail >>>>>>>>>> wrt how classification information is determined and reused? >>>>>>>>>>=20 >>>>>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>>>>> encrypted >>>>>>>>>> flows, a packet-based classifier seems inadequate? I was = also >>>>>>>>> wondering >>>>>>>>>> how independent HLS segment requests might be classified and >>>>>>>>> associated? >>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>=20 >>>>>>>>>> thanx. >>>>>>>>>>=20 >>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf >>>>>>> Of >>>>>>>>>>> Ron >>>>>>>>>>> Parker >>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Sumandra, >>>>>>>>>>>=20 >>>>>>>>>>> As was discussed in Vancouver, there are already many = existing >>>>>>> ways >>>>>>>>> to >>>>>>>>>>> accomplish service chaining. But none of them provide a >>>>>>>>> sufficient >>>>>>>>>>> combination of interoperability, flexibility, and = resiliency. A >>>>>>>>> single >>>>>>>>>>> service chain encapsulation will go a long way to ensuring = these >>>>>>>>> goals. >>>>>>>>>>> It may not be the absolutely most efficient approach for = every >>>>>>>>> single >>>>>>>>>>> network topology and every single use case, but its = ubiquitous >>>>>>> nature >>>>>>>>>>> should improve its adoption. >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Ron, >>>>>>>>>>>=20 >>>>>>>>>>> Absolutely, that was an example of one type of derivation. = However >>>>>>>>> this >>>>>>>>>>> could be augmented with classification result, again one = more >>>>>>>>> example. >>>>>>>>>>>=20 >>>>>>>>>>>>> All flows from the same source IP do not necessarily = follow the >>>>>>>>> same >>>>>>>>>>> chain. >>>>>>>>>>> Correct. It is also not necessary that all transaction of = the same >>>>>>>>> flow >>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>=20 >>>>>>>>>>> Again the point here is that do we always need SFC header or = Not. >>>>>>>>>>>=20 >>>>>>>>>>> Sumandra >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Sumandra, >>>>>>>>>>>=20 >>>>>>>>>>> The intention of service function chaining is to allow for >>>>>>> operation >>>>>>>>> at >>>>>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>>>>> transaction >>>>>>>>>>> level (this is an implementation matter for the PDP). = All >>>>>>> flows >>>>>>>>> from >>>>>>>>>>> the same source IP do not necessarily follow the same chain. >>>>>>> Source >>>>>>>>>>> IP, >>>>>>>>>>> therefore, does not identify the chain ID. Another = intention >>>>>>> of >>>>>>>>>>> service function chaining is to operate over any network = topology >>>>>>> and >>>>>>>>>>> not >>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part = of the >>>>>>>>>>> transport, it does not adequately identify the service = chain, >>>>>>> either. >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Ron, >>>>>>>>>>>=20 >>>>>>>>>>> The service header is meant to carry the context which can = *also* >>>>>>> be >>>>>>>>>>> derived (for example use source ip and vlan to identify = chainID >>>>>>> and >>>>>>>>>>> position) or encapsulated as part of another tunnel header. = So >>>>>>> this >>>>>>>>>>> could >>>>>>>>>>> be optional IMHO. >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Sumandra, >>>>>>>>>>>=20 >>>>>>>>>>> As I understand it, an SFC packet traversing from PDP to SF = or >>>>>>> from >>>>>>>>> SF >>>>>>>>>>> to >>>>>>>>>>> SF will look like: >>>>>>>>>>>=20 >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | "transport" | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | service header | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | original IP header | >>>>>>>>>>> +------------------------+ >>>>>>>>>>> | | original IP = payload >>>>>>> | >>>>>>>>>>> | | >>>>>>>>>>> +------------------------+ >>>>>>>>>>>=20 >>>>>>>>>>> Where service header contains, at a minimum, enough = information to >>>>>>>>> allow >>>>>>>>>>> the packet to be propagated along the full length of the = chain, >>>>>>> and >>>>>>>>>>> optionally, other metadata that enhances the operation of = one or >>>>>>> more >>>>>>>>>>> service functions. >>>>>>>>>>>=20 >>>>>>>>>>> And where "transport" could conceivably be any of, but not >>>>>>> limited >>>>>>>>> to: >>>>>>>>>>>=20 >>>>>>>>>>> * Ethernet >>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>>>>> immutability, >>>>>>>>>>> but rather to specify the packet that is propagated from = preceding >>>>>>>>>>> entity >>>>>>>>>>> to succeeding entity, prior to encapsulation. >>>>>>>>>>>=20 >>>>>>>>>>> Ron >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf >>>>>>> Of >>>>>>>>>>> Sumandra Majee >>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Generic Service Function Chaining Encapsulation: A document = will >>>>>>>>>>> describe the single service-level data plane = encapsulation >>>>>>> format >>>>>>>>>>> for >>>>>>>>>>> conveying the service function chain and the service = function >>>>>>>>> path, >>>>>>>>>>> and for communicating context information between nodes = that >>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>> encapsulation >>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>>>>>> that >>>>>>>>>>> is >>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>> used >>>>>>> on >>>>>>>>>>> a service function path realized at the network layer or = at >>>>>>> any >>>>>>>>>>> other >>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>> construction >>>>>>>>> of >>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>>=20 >>>>>>>>>>> [SM] What does it mean by a single service-level = encapsulation, a >>>>>>>>> new >>>>>>>>>>> encapsulation format >>>>>>>>>>> or an ability to select one encapsulation format = that >>>>>>>>> fits >>>>>>>>>>> the >>>>>>>>>>> need for a given service chain? >>>>>>>>>>> The ability to select a specific encapsulation = would >>>>>>> be >>>>>>> a >>>>>>>>>>> management plane decision. >>>>>>>>>>> There are quite a few existing encapsulation = methods >>>>>>> that >>>>>>>>> can >>>>>>>>>>> possibly be reused to provide >>>>>>>>>>> context information between service nodes. I have >>>>>>>>>>> seen >>>>>>>>>>> mention >>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>> applications contexts are transferred via headers. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On = Behalf >>>>>>> Of >>>>>>>>>>> Thomas Narten >>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>=20 >>>>>>>>>>> Hi. >>>>>>>>>>>=20 >>>>>>>>>>> Current charter can be found at >>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>=20 >>>>>>>>>>> It contains the revised management text as well as updated >>>>>>>>> milestones. >>>>>>>>>>>=20 >>>>>>>>>>> All known issues have been addressed. If there are any = remaining >>>>>>>>> issues, >>>>>>>>>>> please speak up! >>>>>>>>>>>=20 >>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>=20 >>>>>>>>>>> Networks, servers, storage technologies, and applications, = have >>>>>>> all >>>>>>>>>>> undergone significant change in recent years with the = introduction >>>>>>> of >>>>>>>>>>> virtualization, network overlays, and orchestration. Service >>>>>>> delivery >>>>>>>>> is >>>>>>>>>>> currently both a technical and organizational challenge that >>>>>>> involves >>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>> Services are typically implemented by the ordered = combination of a >>>>>>>>>>> number >>>>>>>>>>> of service functions that are deployed at different points = within >>>>>>> the >>>>>>>>>>> network. Today, a common deployment model has service = functions >>>>>>>>>>> physically >>>>>>>>>>> inserted on the data forwarding path between communicating = peers. >>>>>>>>> Going >>>>>>>>>>> forward, however, there is a desire to move to a different = model, >>>>>>>>> where >>>>>>>>>>> service functions are not required to reside on the default = data >>>>>>> path >>>>>>>>>>> and >>>>>>>>>>> traffic is instead steered through services, wherever they = are >>>>>>>>> deployed. >>>>>>>>>>>=20 >>>>>>>>>>> For a given service, the abstracted view of the required = service >>>>>>>>>>> functions >>>>>>>>>>> and the order in which they are to be applied is called a = Service >>>>>>>>>>> Function >>>>>>>>>>> Chain (SFC). Since a given service function may be available = on >>>>>>> more >>>>>>>>>>> than >>>>>>>>>>> one node within a network, a Service Function Chain is >>>>>>> instantiated >>>>>>>>> via >>>>>>>>>>> the selection of specific service function instances and the >>>>>>> network >>>>>>>>>>> nodes >>>>>>>>>>> on which they are provided, thereby forming a service = topology: >>>>>>>>>>> this is called a Service Function Path. The service = functions may >>>>>>> be >>>>>>>>>>> applied at a specific layer within the network protocol = stack >>>>>>>>> (network >>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>=20 >>>>>>>>>>> The Service Function Chaining (SFC) working group will = develop new >>>>>>>>>>> approaches to service delivery and deployment. It will = produce a >>>>>>>>>>> framework >>>>>>>>>>> for service function chaining that includes the necessary >>>>>>> protocols >>>>>>>>> or >>>>>>>>>>> protocol extensions to convey the service path and service = path >>>>>>>>>>> information to nodes that implement service functions, as = well as >>>>>>>>>>> mechanisms for steering traffic through service functions. = The >>>>>>>>> working >>>>>>>>>>> group will also examine what information needs to be = gathered from >>>>>>>>> the >>>>>>>>>>> network and service functions in support of service function >>>>>>> chaining >>>>>>>>>>> and >>>>>>>>>>> how that information may be made available to nodes that = implement >>>>>>>>> the >>>>>>>>>>> service functions. >>>>>>>>>>>=20 >>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the = following: >>>>>>>>>>>=20 >>>>>>>>>>> 1) Problem Statement: This document will provide a summary = of the >>>>>>>>>>> problem space to be addressed by the WG including example >>>>>>> high- >>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>> nomenclature >>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>=20 >>>>>>>>>>> 2) Architecture: This document will provide a description of = the >>>>>>>>>>> architectural building blocks and their relationships >>>>>>> including >>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>> diagnostics, design analysis, and security models, as = well as >>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>=20 >>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A = document >>>>>>> will >>>>>>>>>>> describe the single service-level data plane = encapsulation >>>>>>> format >>>>>>>>>>> for >>>>>>>>>>> conveying the service function chain and the service = function >>>>>>>>> path, >>>>>>>>>>> and for communicating context information between nodes = that >>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>> encapsulation >>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>> service >>>>>>>>> that >>>>>>>>>>> is >>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>> used >>>>>>> on >>>>>>>>>>> a service function path realized at the network layer or = at >>>>>>> any >>>>>>>>>>> other >>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>> construction >>>>>>>>> of >>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>>=20 >>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be = developed >>>>>>> to >>>>>>>>>>> describe requirements and protocols necessary to convey >>>>>>>>> information >>>>>>>>>>> to service function implementation points. Where = possible, >>>>>>>>> existing >>>>>>>>>>> IETF protocols will be used and extended. All protocol >>>>>>> extensions >>>>>>>>>>> work should be carried out in the working groups = responsible >>>>>>> for >>>>>>>>> the >>>>>>>>>>> protocols being modified in coordination with this = working >>>>>>> group, >>>>>>>>>>> but >>>>>>>>>>> may be done in this working group after agreement with = all >>>>>>>>>>> the >>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>=20 >>>>>>>>>>> 5) Manageability: Work on the management and configuration = of >>>>>>> service >>>>>>>>>>> functions in support of SFC components will certainly be >>>>>>> needed, >>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>=20 >>>>>>>>>>> Proposed Milestones >>>>>>>>>>>=20 >>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining = the >>>>>>>>> problem >>>>>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>>>>>=20 >>>>>>>>>>> May 2014 Consult with OPS Area on possible charter = modifications >>>>>>> for >>>>>>>>>>> management and configuration of SFC components >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>>>>> architecture >>>>>>>>>>> for SFC >>>>>>>>>>>=20 >>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>>>>> function >>>>>>>>>>> chaining encapsulation protocol >>>>>>>>>>>=20 >>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying = the >>>>>>>>> generic >>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Thomas >>>>>>>>>>>=20 >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>> _______________________________________________ >>>>>>>>>> nsc mailing list >>>>>>>>>> nsc@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>>> _______________________________________________ >>>>> nsc mailing list >>>>> nsc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>=20 >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >> -- >> "Esta vez no fallaremos, Doctor Infierno" >>=20 >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >>=20 >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >>=20 >>=20 >> ________________________________ >>=20 >> Este mensaje se dirige exclusivamente a su destinatario. Puede = consultar nuestra >> pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el = enlace situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send = and receive email >> on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc --Apple-Mail=_CF2F66B4-A051-4211-97F8-43B03D42E1CC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlKI7OcACgkQtfDPGTp3USxrOgCgodvLEGZmGrZqB4a8PtqpaEtK Y9UAnAxqXoQ/Vr00GiYOS8ldJyqWUyJ2 =menq -----END PGP SIGNATURE----- --Apple-Mail=_CF2F66B4-A051-4211-97F8-43B03D42E1CC-- From jguichar@cisco.com Sun Nov 17 10:51:11 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06AF311E9097 for ; Sun, 17 Nov 2013 10:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx6XI+n0hdtR for ; Sun, 17 Nov 2013 10:51:06 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 495A011E9096 for ; Sun, 17 Nov 2013 10:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31534; q=dns/txt; s=iport; t=1384714263; x=1385923863; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WnndsKQpGvt3orI1mQ6/4s46X+wEA/pbSqln6MENjUc=; b=IxrWfGN+YHV0P6cIrEZFK7z5DSKEytA5hfplmBuaLlFn1/v+qhclkALI Pm64Ay8S/rpfG1sMKevU3dueQZsEQaGfDnDiV/tFVITfZ/znhm+ldkqSF QREtrQTOyKWhag1BVQjtToKpfVL+dnnWY5aKn+moIU9hebFhYvuEXCvys Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAOoOiVKtJV2a/2dsb2JhbABPCoMHOFO/K4EQFnSCJQEBAQQBAQEXDT4CBwQCBQwGAQgRAQMBAQEVEi4LFAMGCAIECgQFCRKHZg3BAReOHQYEBgIBBoEACCsCBQIEBIQnA4kKimJCg2KBL5BegyiBaAEfIg X-IronPort-AV: E=Sophos;i="4.93,719,1378857600"; d="scan'208";a="175690" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 17 Nov 2013 18:51:01 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAHIp1nK021860 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 17 Nov 2013 18:51:01 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Sun, 17 Nov 2013 12:50:59 -0600 From: "Jim Guichard (jguichar)" To: "Carlos Pignataro (cpignata)" , "Ersue, Mehmet (NSN - DE/Munich)" Thread-Topic: [nsc] Current Proposed SFC charter Thread-Index: AQHO2yN8m3OAQxch8keQPslbkvW+7pohHpCAgAAOHICAACcIgIAAAa6AgAACJICAAAHBAIAABOWAgAAakoCAAAqXgIAAA/qAgAAOgICAACWbAIAAXUUA//+vg4CAAGK7gIAHwAkAgAAlVAD//9YXAA== Date: Sun, 17 Nov 2013 18:50:58 +0000 Message-ID: In-Reply-To: <773085DD-99D1-4583-BC1D-68671CDBCE23@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , "Benoit Claise \(bclaise\)" , "ext Diego R. Lopez" , Melinda Shore Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 18:51:11 -0000 The current charter text calls for more study into the requirements in this area and we have a specific milestone to consult with OPS. While the approach we have taken may result in some rechartering in the future we felt that was the right thing to do at this stage while we figure out what should be in and out of scope for the SFC WG. On 11/17/13 11:20 AM, "Carlos Pignataro (cpignata)" wrote: >Mehmet, > >I think it is important for SFC to deliver chartered items with focus. >All these are good elements supporting a broader problem around SFC, and >I'd cautious SFC to focus -- it does not mean SFC (or even the IETF) >should work on the items you list. > >From the charter, item 5, SFC need to better understand and scope what >these things mean. And in this, one of the things to avoid is: >http://tools.ietf.org/html/rfc1925 > (5) It is always possible to aglutenate multiple separate problems > into a single complex interdependent solution. In most cases > this is a bad idea. >Thanks, > >-- Carlos. > > >On Nov 17, 2013, at 9:07 AM, Ersue, Mehmet (NSN - DE/Munich) > wrote: > >> Dear SFC Chairs, All, >>=20 >> AFAIK the management of SFC or service graphs in general needs to >>address: >>=20 >> - the orchestration of a service graph based on the information in a >>model used as input, >> - lifecycle management of network services and possibly of single VNFs, >> - FCAPS as well as management of virtualization related events (e.g. >>monitoring and correlation of virtualization events) >> - specification of relevant information models and the standardization >>of necessary data models. >>=20 >> AFAIU it is not easy to address all of these management aspects in the >>future SFC WG and a parallel work in OPS area might be useful if started >>early. >>=20 >> Please elaborate and argue otherwise. >>=20 >> Cheers,=20 >> Mehmet=20 >>=20 >>> -----Original Message----- >>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >>>ext Diego R. >>> Lopez >>> Sent: Tuesday, November 12, 2013 4:46 PM >>> To: Jim Guichard (jguichar) >>> Cc: Thomas Narten; nsc@ietf.org; Sumandra Majee; Kevin J Ma; Ron >>>Parker; Joel M. >>> Halpern; Surendra Kumar (smkumar) >>> Subject: Re: [nsc] Current Proposed SFC charter >>>=20 >>> Let me add for the record that this is the kind of management aspects >>>I had in mind >>> when we were talking about service metadata and how to exchange them... >>>=20 >>> Be goode, >>>=20 >>> On 12 Nov 2013, at 15:52 , Jim Guichard (jguichar) wrote: >>>=20 >>>> Yes optimization can certainly be built into this but I wanted to >>>>show an >>>> example of the types of things we mean when we talk about branching. >>>>Once >>>> the concept is better understood I think we will see some more >>>>exciting >>>> examples. Note also that the control logic could also utilize the >>>>service >>>> encapsulation as a mechanism to push notifications back up the >>>>original >>>> chain to inform the ingress to bypass the original chain for all >>>> subsequent packets for this flow. >>>>=20 >>>> On 11/12/13 9:40 AM, "Joel M. Halpern" wrote: >>>>=20 >>>>> Jim, thank you for a concrete example. >>>>> I would suggest that in the usual cases, there is a better way to >>>>>handle >>>>> this than branching and rewriting at the PCRF. >>>>>=20 >>>>> If the DPI engine or PCRF logic (whichever makes the decision) >>>>>notifies >>>>> the control logic about the decision for the flow, then the ingress >>>>>can >>>>> direct subsequent packets to the correct place, avoiding needless >>>>> processing of further packets in the DPI and PCRF logic. >>>>> Further, the needed control information can be passed to the >>>>> optimization or parental control so that it does not matter where the >>>>> first packet is sent, avoiding the need for the PCRF to understand >>>>>how >>>>> to direct packets to service paths. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 11/12/13 9:07 AM, Jim Guichard (jguichar) wrote: >>>>>> Hi Kevin, >>>>>>=20 >>>>>> Let me try and provide a concrete example to see if this answers >>>>>>your >>>>>> specific question: >>>>>>=20 >>>>>> Use case: P-GW -> PCRF -> services applied to traffic based on >>>>>> applicationID and subscriberID. >>>>>>=20 >>>>>> Instantiated as: >>>>>>=20 >>>>>> SFC1: P-GW -> DPI -> PCRF >>>>>> SFC2: PCRF -> video-optimization -> metering -> FW >>>>>> SFC3: PCRF -> parental-control -> metering -> FW >>>>>>=20 >>>>>> In this case DPI is performed on SFC1 and identifies applicationID. >>>>>>The >>>>>> applicationID is carried in the service encapsulation to PCRF. PCRF >>>>>>uses >>>>>> solution specific logic (identifies subscriber, applies policies, >>>>>>etc) >>>>>> and >>>>>> uses the result along with the applicationID received from DPI to >>>>>>select >>>>>> an outbound service chain, SFC2 or SFC3. Note that in this case >>>>>> branching >>>>>> occurs from SFC1 to either SFC2 or SFC3. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 11/12/13 1:52 AM, "Kevin J Ma" wrote: >>>>>>=20 >>>>>>>> Yes, reclassification can change the service path and >>>>>>>> re-classification may happen at any node along a service path. >>>>>>>=20 >>>>>>> Just to expand on that, going back to the original question about >>>>>>> service header encapsulation, is it intended that a chain that >>>>>>> is re-classified will get a new chain ID which fully describes >>>>>>> a chain that is a superset of the original chain ID, prior to >>>>>>> DPI-based re-classification? (assuming the goal is "a single >>>>>>> chain ID that is commonly understood along the entire service >>>>>>>chain" >>>>>>> http://www.ietf.org/mail-archive/web/nsc/current/msg00638.html) >>>>>>>=20 >>>>>>> And the applicable subset of the permutative list of service >>>>>>> paths would be configured at each appropriate service node? >>>>>>> e.g., ID 1: NAT + firewall + DPI >>>>>>> ID 2: NAT + firewall + DPI + AV >>>>>>> ID 3: NAT + firewall + DPI + AV + NAT >>>>>>> ID 4: NAT + firewall + DPI + NAT >>>>>>> ID 5: NAT + firewall + DPI + AV + LB >>>>>>> ID 6: NAT + firewall + DPI + LB >>>>>>> ID 7: NAT + firewall + DPI + LB + CACHE >>>>>>> ID 8: NAT + firewall + DPI + CACHE >>>>>>> ID 9: NAT + firewall + DPI + optimizer + LB >>>>>>> ID 10: NAT + firewall + DPI + optimizer + LB + CACHE >>>>>>> ID 11: NAT + firewall + DPI + optimizer + CACHE >>>>>>> Would every flow then be initially classified as ID 1, but >>>>>>> eventually get re-classified to ID 2-11, after the DPI phase? >>>>>>>=20 >>>>>>> thanx. >>>>>>>=20 >>>>>>> -- Kevin J. Ma >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>> Sent: Tuesday, November 12, 2013 1:01 AM >>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>> nsc@ietf.org >>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 11/11/13 9:46 PM, "Kevin J Ma" >>>>>>>>wrote: >>>>>>>>=20 >>>>>>>>> Hi Surendra, >>>>>>>>>=20 >>>>>>>>> Classification may be out of scope, but the level of service that >>>>>>>>> is >>>>>>>>> applicable is dependent upon the level of classification that can >>>>>>>>> be >>>>>>>>> performed. An assumption of packet level encapsulation has >>>>>>>> implications >>>>>>>>> on the level of classification being performed? If the stated >>>>>>>>> goals >>>>>>>> are >>>>>>>>> for firewall and load balancer functionality, then the >>>>>>>>>application >>>>>>>> level >>>>>>>>> nature of those functions needs to be taken into account? If, on >>>>>>>>> the >>>>>>>>> other hand, the service function scope is limited due to >>>>>>>>> limitations >>>>>>>> in >>>>>>>>> classification, that would be and important piece of information? >>>>>>>>>=20 >>>>>>>>> Wrt section 4.4 of draft-liu-service-chaining-use-cases the fork >>>>>>>> points >>>>>>>>> of the service paths seem like re-classification points? Is that >>>>>>>>> the >>>>>>>>> interpretation from the architecture perspective? Or is the >>>>>>>>> service >>>>>>>>> function chain classification exclusive of DPI functionality? >>>>>>>> I have not fully read that draft yet. But in general, as >>>>>>>> described >>>>>>>> in >>>>>>>> the arch draft, the collection of services form a graph, segments >>>>>>>>of >>>>>>>> which >>>>>>>> are service paths. Yes, reclassification can change the service >>>>>>>>path >>>>>>>> and >>>>>>>> re-classification may happen at any node along a service path. >>>>>>>>=20 >>>>>>>> Surendra. >>>>>>>>>=20 >>>>>>>>> thanx. >>>>>>>>>=20 >>>>>>>>> -- Kevin J. Ma >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] >>>>>>>>>> Sent: Tuesday, November 12, 2013 12:08 AM >>>>>>>>>> To: Kevin J Ma; Ron Parker; Sumandra Majee; Thomas Narten; >>>>>>>> nsc@ietf.org >>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>=20 >>>>>>>>>> Kevin, >>>>>>>>>>=20 >>>>>>>>>> Classification mechanism is outside the scope of SFC. It can be >>>>>>>>>> based >>>>>>>> on >>>>>>>>>> the packet or information not in the packet(environmental >>>>>>>>>>attributes >>>>>>>> for >>>>>>>>>> instance) or a combination thereof. What is important is that >>>>>>>>>>such >>>>>>>>>> classification aids in traffic selection and service path >>>>>>>>>> identification. >>>>>>>>>> It is no different from a policy in this regard except that the >>>>>>>> policy >>>>>>>>>> now >>>>>>>>>> specifies the service path. >>>>>>>>>> Further, classification is not limited to the network elements >>>>>>>>>>but >>>>>>>> the >>>>>>>>>> service functions as well. Some of this is described in the >>>>>>>> architecture >>>>>>>>>> drafts as well - >>>>>>>>>> "https://datatracker.ietf.org/doc/draft-quinn-sfc-arch/". >>>>>>>>>>=20 >>>>>>>>>> Surendra. >>>>>>>>>>=20 >>>>>>>>>> On 11/11/13 7:33 PM, "Kevin J Ma" >>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> Hi Ron, >>>>>>>>>>>=20 >>>>>>>>>>> I was unable to make the SFC BoF due to a conflict with CDNI, >>>>>>>>>>>but >>>>>>>> I >>>>>>>>>>> had a similar question wrt bullet 11 in section 2 of the >>>>>>>>>>>problem >>>>>>>>>>> statement: >>>>>>>>>>>=20 >>>>>>>>>>> 11. Per-Service (re)Classification: Classification occurs at >>>>>>>> each >>>>>>>>>>> service, independent from previously applied service >>>>>>>>>> functions. >>>>>>>>>>> These unrelated classification events consume resources >>>>>>>>>>> per >>>>>>>>>>> service. More importantly, the classification >>>>>>>> functionality >>>>>>>>>>> often differs per service function and service function >>>>>>>> cannot >>>>>>>>>>> leverage the results from other deployed network or >>>>>>>> service. >>>>>>>>>>>=20 >>>>>>>>>>> as it relates to section 5.2 of the framework document: >>>>>>>>>>>=20 >>>>>>>>>>> The SFC Classifier classifies packets based on (some of) the >>>>>>>>>> contents >>>>>>>>>>> of the packet header. Concretely, it classifies packets >>>>>>>>>>>based >>>>>>>> on >>>>>>>>>> the >>>>>>>>>>> possible combination of one or more header fields, such as >>>>>>>> source >>>>>>>>>>> address, destination address, DS field, protocol ID, source >>>>>>>>>>> port >>>>>>>>>> and >>>>>>>>>>> destination port numbers, and any other information. >>>>>>>>>>>=20 >>>>>>>>>>> A packet-based classifier as described in the framework >>>>>>>>>>>document >>>>>>>>>> would >>>>>>>>>>> seem to be limited in what it can classify? The service >>>>>>>>>>>function >>>>>>>>>>> identifier lookup does not seem to be a significant >>>>>>>>>>>optimization >>>>>>>> over >>>>>>>>>>> a packet-based 5-tuple lookup? There seems to be some missing >>>>>>>> detail >>>>>>>>>>> wrt how classification information is determined and reused? >>>>>>>>>>>=20 >>>>>>>>>>> When thinking about higher level services, e.g., HTTP and TLS >>>>>>>>>> encrypted >>>>>>>>>>> flows, a packet-based classifier seems inadequate? I was also >>>>>>>>>> wondering >>>>>>>>>>> how independent HLS segment requests might be classified and >>>>>>>>>> associated? >>>>>>>>>>> Were these types of use cases discussed in the BoF? >>>>>>>>>>>=20 >>>>>>>>>>> thanx. >>>>>>>>>>>=20 >>>>>>>>>>> -- Kevin J. Ma >>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>>>>Behalf >>>>>>>> Of >>>>>>>>>>>> Ron >>>>>>>>>>>> Parker >>>>>>>>>>>> Sent: Monday, November 11, 2013 10:16 PM >>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Sumandra, >>>>>>>>>>>>=20 >>>>>>>>>>>> As was discussed in Vancouver, there are already many existing >>>>>>>> ways >>>>>>>>>> to >>>>>>>>>>>> accomplish service chaining. But none of them provide a >>>>>>>>>> sufficient >>>>>>>>>>>> combination of interoperability, flexibility, and resiliency. >>>>>>>>>>>> A >>>>>>>>>> single >>>>>>>>>>>> service chain encapsulation will go a long way to ensuring >>>>>>>>>>>>these >>>>>>>>>> goals. >>>>>>>>>>>> It may not be the absolutely most efficient approach for >>>>>>>>>>>>every >>>>>>>>>> single >>>>>>>>>>>> network topology and every single use case, but its ubiquitous >>>>>>>> nature >>>>>>>>>>>> should improve its adoption. >>>>>>>>>>>>=20 >>>>>>>>>>>> Ron >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>> Sent: Monday, November 11, 2013 10:10 PM >>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Ron, >>>>>>>>>>>>=20 >>>>>>>>>>>> Absolutely, that was an example of one type of derivation. >>>>>>>>>>>>However >>>>>>>>>> this >>>>>>>>>>>> could be augmented with classification result, again one more >>>>>>>>>> example. >>>>>>>>>>>>=20 >>>>>>>>>>>>>> All flows from the same source IP do not necessarily follow >>>>>>>>>>>>>>the >>>>>>>>>> same >>>>>>>>>>>> chain. >>>>>>>>>>>> Correct. It is also not necessary that all transaction of the >>>>>>>>>>>>same >>>>>>>>>> flow >>>>>>>>>>>> follow the same chain either. So why stop at flow itself. >>>>>>>>>>>>=20 >>>>>>>>>>>> Again the point here is that do we always need SFC header or >>>>>>>>>>>>Not. >>>>>>>>>>>>=20 >>>>>>>>>>>> Sumandra >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>> Sent: Monday, November 11, 2013 7:02 PM >>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Sumandra, >>>>>>>>>>>>=20 >>>>>>>>>>>> The intention of service function chaining is to allow for >>>>>>>> operation >>>>>>>>>> at >>>>>>>>>>>> the fully qualified flow level, or even finer grained at the >>>>>>>>>> transaction >>>>>>>>>>>> level (this is an implementation matter for the PDP). All >>>>>>>> flows >>>>>>>>>> from >>>>>>>>>>>> the same source IP do not necessarily follow the same chain. >>>>>>>> Source >>>>>>>>>>>> IP, >>>>>>>>>>>> therefore, does not identify the chain ID. Another >>>>>>>>>>>>intention >>>>>>>> of >>>>>>>>>>>> service function chaining is to operate over any network >>>>>>>>>>>>topology >>>>>>>> and >>>>>>>>>>>> not >>>>>>>>>>>> be limited to a single LAN. Thus, while VLAN may be part of >>>>>>>>>>>>the >>>>>>>>>>>> transport, it does not adequately identify the service chain, >>>>>>>> either. >>>>>>>>>>>>=20 >>>>>>>>>>>> Ron >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Sumandra Majee [mailto:S.Majee@F5.com] >>>>>>>>>>>> Sent: Monday, November 11, 2013 9:56 PM >>>>>>>>>>>> To: Ron Parker; Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Ron, >>>>>>>>>>>>=20 >>>>>>>>>>>> The service header is meant to carry the context which can >>>>>>>>>>>>*also* >>>>>>>> be >>>>>>>>>>>> derived (for example use source ip and vlan to identify >>>>>>>>>>>>chainID >>>>>>>> and >>>>>>>>>>>> position) or encapsulated as part of another tunnel header. So >>>>>>>> this >>>>>>>>>>>> could >>>>>>>>>>>> be optional IMHO. >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >>>>>>>>>>>> Sent: Monday, November 11, 2013 4:36 PM >>>>>>>>>>>> To: Sumandra Majee; Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: RE: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Sumandra, >>>>>>>>>>>>=20 >>>>>>>>>>>> As I understand it, an SFC packet traversing from PDP to SF or >>>>>>>> from >>>>>>>>>> SF >>>>>>>>>>>> to >>>>>>>>>>>> SF will look like: >>>>>>>>>>>>=20 >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>> | "transport" | >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>> | service header | >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>> | original IP header | >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>> | | original IP >>>>>>>>>>>>payload >>>>>>>> | >>>>>>>>>>>> | | >>>>>>>>>>>> +------------------------+ >>>>>>>>>>>>=20 >>>>>>>>>>>> Where service header contains, at a minimum, enough >>>>>>>>>>>>information to >>>>>>>>>> allow >>>>>>>>>>>> the packet to be propagated along the full length of the >>>>>>>>>>>>chain, >>>>>>>> and >>>>>>>>>>>> optionally, other metadata that enhances the operation of one >>>>>>>>>>>>or >>>>>>>> more >>>>>>>>>>>> service functions. >>>>>>>>>>>>=20 >>>>>>>>>>>> And where "transport" could conceivably be any of, but not >>>>>>>> limited >>>>>>>>>> to: >>>>>>>>>>>>=20 >>>>>>>>>>>> * Ethernet >>>>>>>>>>>> * Ethernet + LLC2 >>>>>>>>>>>> * Ethernet + MPLS >>>>>>>>>>>> * Ethernet + IP + GRE >>>>>>>>>>>> * Ethernet + IP +UDP >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Also, "original" in the diagram above is not meant to imply >>>>>>>>>>>> immutability, >>>>>>>>>>>> but rather to specify the packet that is propagated from >>>>>>>>>>>>preceding >>>>>>>>>>>> entity >>>>>>>>>>>> to succeeding entity, prior to encapsulation. >>>>>>>>>>>>=20 >>>>>>>>>>>> Ron >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>>>>Behalf >>>>>>>> Of >>>>>>>>>>>> Sumandra Majee >>>>>>>>>>>> Sent: Monday, November 11, 2013 6:46 PM >>>>>>>>>>>> To: Thomas Narten; nsc@ietf.org >>>>>>>>>>>> Subject: Re: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Generic Service Function Chaining Encapsulation: A document >>>>>>>>>>>>will >>>>>>>>>>>> describe the single service-level data plane encapsulation >>>>>>>> format >>>>>>>>>>>> for >>>>>>>>>>>> conveying the service function chain and the service >>>>>>>>>>>>function >>>>>>>>>> path, >>>>>>>>>>>> and for communicating context information between nodes >>>>>>>>>>>>that >>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>> encapsulation >>>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>>> service >>>>>>>>>> that >>>>>>>>>>>> is >>>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>>> used >>>>>>>> on >>>>>>>>>>>> a service function path realized at the network layer or at >>>>>>>> any >>>>>>>>>>>> other >>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>> construction >>>>>>>>>> of >>>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>>>=20 >>>>>>>>>>>> [SM] What does it mean by a single service-level >>>>>>>>>>>>encapsulation, a >>>>>>>>>> new >>>>>>>>>>>> encapsulation format >>>>>>>>>>>> or an ability to select one encapsulation format >>>>>>>>>>>>that >>>>>>>>>> fits >>>>>>>>>>>> the >>>>>>>>>>>> need for a given service chain? >>>>>>>>>>>> The ability to select a specific encapsulation >>>>>>>>>>>>would >>>>>>>> be >>>>>>>> a >>>>>>>>>>>> management plane decision. >>>>>>>>>>>> There are quite a few existing encapsulation methods >>>>>>>> that >>>>>>>>>> can >>>>>>>>>>>> possibly be reused to provide >>>>>>>>>>>> context information between service nodes. I have >>>>>>>>>>>> seen >>>>>>>>>>>> mention >>>>>>>>>>>> of GRE, for HTTP based >>>>>>>>>>>> applications contexts are transferred via headers. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On >>>>>>>>>>>>Behalf >>>>>>>> Of >>>>>>>>>>>> Thomas Narten >>>>>>>>>>>> Sent: Wednesday, November 06, 2013 11:07 AM >>>>>>>>>>>> To: nsc@ietf.org >>>>>>>>>>>> Subject: [nsc] Current Proposed SFC charter >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi. >>>>>>>>>>>>=20 >>>>>>>>>>>> Current charter can be found at >>>>>>>>>>>> https://datatracker.ietf.org/doc/charter- >>>>>>>>>>>> ietf-sfc/. >>>>>>>>>>>>=20 >>>>>>>>>>>> It contains the revised management text as well as updated >>>>>>>>>> milestones. >>>>>>>>>>>>=20 >>>>>>>>>>>> All known issues have been addressed. If there are any >>>>>>>>>>>>remaining >>>>>>>>>> issues, >>>>>>>>>>>> please speak up! >>>>>>>>>>>>=20 >>>>>>>>>>>> Charter charter-ietf-sfc-00-04 >>>>>>>>>>>>=20 >>>>>>>>>>>> Networks, servers, storage technologies, and applications, >>>>>>>>>>>>have >>>>>>>> all >>>>>>>>>>>> undergone significant change in recent years with the >>>>>>>>>>>>introduction >>>>>>>> of >>>>>>>>>>>> virtualization, network overlays, and orchestration. Service >>>>>>>> delivery >>>>>>>>>> is >>>>>>>>>>>> currently both a technical and organizational challenge that >>>>>>>> involves >>>>>>>>>>>> significant modification to the network configuration. >>>>>>>>>>>> Services are typically implemented by the ordered combination >>>>>>>>>>>>of a >>>>>>>>>>>> number >>>>>>>>>>>> of service functions that are deployed at different points >>>>>>>>>>>>within >>>>>>>> the >>>>>>>>>>>> network. Today, a common deployment model has service >>>>>>>>>>>>functions >>>>>>>>>>>> physically >>>>>>>>>>>> inserted on the data forwarding path between communicating >>>>>>>>>>>>peers. >>>>>>>>>> Going >>>>>>>>>>>> forward, however, there is a desire to move to a different >>>>>>>>>>>>model, >>>>>>>>>> where >>>>>>>>>>>> service functions are not required to reside on the default >>>>>>>>>>>>data >>>>>>>> path >>>>>>>>>>>> and >>>>>>>>>>>> traffic is instead steered through services, wherever they are >>>>>>>>>> deployed. >>>>>>>>>>>>=20 >>>>>>>>>>>> For a given service, the abstracted view of the required >>>>>>>>>>>>service >>>>>>>>>>>> functions >>>>>>>>>>>> and the order in which they are to be applied is called a >>>>>>>>>>>>Service >>>>>>>>>>>> Function >>>>>>>>>>>> Chain (SFC). Since a given service function may be available >>>>>>>>>>>>on >>>>>>>> more >>>>>>>>>>>> than >>>>>>>>>>>> one node within a network, a Service Function Chain is >>>>>>>> instantiated >>>>>>>>>> via >>>>>>>>>>>> the selection of specific service function instances and the >>>>>>>> network >>>>>>>>>>>> nodes >>>>>>>>>>>> on which they are provided, thereby forming a service >>>>>>>>>>>>topology: >>>>>>>>>>>> this is called a Service Function Path. The service functions >>>>>>>>>>>>may >>>>>>>> be >>>>>>>>>>>> applied at a specific layer within the network protocol stack >>>>>>>>>> (network >>>>>>>>>>>> layer, application layer, etc.). >>>>>>>>>>>>=20 >>>>>>>>>>>> The Service Function Chaining (SFC) working group will >>>>>>>>>>>>develop new >>>>>>>>>>>> approaches to service delivery and deployment. It will >>>>>>>>>>>>produce a >>>>>>>>>>>> framework >>>>>>>>>>>> for service function chaining that includes the necessary >>>>>>>> protocols >>>>>>>>>> or >>>>>>>>>>>> protocol extensions to convey the service path and service >>>>>>>>>>>>path >>>>>>>>>>>> information to nodes that implement service functions, as >>>>>>>>>>>>well as >>>>>>>>>>>> mechanisms for steering traffic through service functions. The >>>>>>>>>> working >>>>>>>>>>>> group will also examine what information needs to be gathered >>>>>>>>>>>>from >>>>>>>>>> the >>>>>>>>>>>> network and service functions in support of service function >>>>>>>> chaining >>>>>>>>>>>> and >>>>>>>>>>>> how that information may be made available to nodes that >>>>>>>>>>>>implement >>>>>>>>>> the >>>>>>>>>>>> service functions. >>>>>>>>>>>>=20 >>>>>>>>>>>> Specifically, the SFC WG is chartered to deliver the >>>>>>>>>>>>following: >>>>>>>>>>>>=20 >>>>>>>>>>>> 1) Problem Statement: This document will provide a summary of >>>>>>>>>>>>the >>>>>>>>>>>> problem space to be addressed by the WG including example >>>>>>>> high- >>>>>>>>>>>> level use cases. Additionally, the WG will normalize >>>>>>>> nomenclature >>>>>>>>>>>> and definitions for service function chaining. >>>>>>>>>>>>=20 >>>>>>>>>>>> 2) Architecture: This document will provide a description of >>>>>>>>>>>>the >>>>>>>>>>>> architectural building blocks and their relationships >>>>>>>> including >>>>>>>>>>>> interconnection, placement of capabilities, management, >>>>>>>>>>>> diagnostics, design analysis, and security models, as well >>>>>>>>>>>>as >>>>>>>>>>>> requirements on the protocol mechanisms. >>>>>>>>>>>>=20 >>>>>>>>>>>> 3) Generic Service Function Chaining Encapsulation: A document >>>>>>>> will >>>>>>>>>>>> describe the single service-level data plane encapsulation >>>>>>>> format >>>>>>>>>>>> for >>>>>>>>>>>> conveying the service function chain and the service >>>>>>>>>>>>function >>>>>>>>>> path, >>>>>>>>>>>> and for communicating context information between nodes >>>>>>>>>>>>that >>>>>>>>>>>> implement service functions. It is intended that the >>>>>>>>>> encapsulation >>>>>>>>>>>> be agnostic to the layer at which it is applied and the >>>>>>>> service >>>>>>>>>> that >>>>>>>>>>>> is >>>>>>>>>>>> being constructed. That is, the same encapsulation may be >>>>>>>>>>>> used >>>>>>>> on >>>>>>>>>>>> a service function path realized at the network layer or at >>>>>>>> any >>>>>>>>>>>> other >>>>>>>>>>>> layer, and the same encapsulation will apply for the >>>>>>>> construction >>>>>>>>>> of >>>>>>>>>>>> service function paths regardless of the actual service. >>>>>>>>>>>>=20 >>>>>>>>>>>> 4) Control Plane Mechanisms: A set of documents will be >>>>>>>>>>>>developed >>>>>>>> to >>>>>>>>>>>> describe requirements and protocols necessary to convey >>>>>>>>>> information >>>>>>>>>>>> to service function implementation points. Where possible, >>>>>>>>>> existing >>>>>>>>>>>> IETF protocols will be used and extended. All protocol >>>>>>>> extensions >>>>>>>>>>>> work should be carried out in the working groups >>>>>>>>>>>>responsible >>>>>>>> for >>>>>>>>>> the >>>>>>>>>>>> protocols being modified in coordination with this working >>>>>>>> group, >>>>>>>>>>>> but >>>>>>>>>>>> may be done in this working group after agreement with all >>>>>>>>>>>> the >>>>>>>>>>>> relevant WG chairs and responsible ADs. >>>>>>>>>>>>=20 >>>>>>>>>>>> 5) Manageability: Work on the management and configuration of >>>>>>>> service >>>>>>>>>>>> functions in support of SFC components will certainly be >>>>>>>> needed, >>>>>>>>>>>> but first needs to be better understood and scoped. >>>>>>>>>>>>=20 >>>>>>>>>>>> Proposed Milestones >>>>>>>>>>>>=20 >>>>>>>>>>>> Apr 2014 Submit to IESG Informational document(s) defining the >>>>>>>>>> problem >>>>>>>>>>>> statement and core use cases for Service Function Chaining >>>>>>>>>>>>=20 >>>>>>>>>>>> May 2014 Consult with OPS Area on possible charter >>>>>>>>>>>>modifications >>>>>>>> for >>>>>>>>>>>> management and configuration of SFC components >>>>>>>>>>>>=20 >>>>>>>>>>>> Jan 2015 Submit to IESG Informational document defining the >>>>>>>>>> architecture >>>>>>>>>>>> for SFC >>>>>>>>>>>>=20 >>>>>>>>>>>> Jan 2015 Submit to IESG requirements for a generic service >>>>>>>> function >>>>>>>>>>>> chaining encapsulation protocol >>>>>>>>>>>>=20 >>>>>>>>>>>> Aug 2015 Submit to IESG Standards Track document specifying >>>>>>>>>>>>the >>>>>>>>>> generic >>>>>>>>>>>> service function chaining header encapsulation >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Thomas >>>>>>>>>>>>=20 >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> nsc mailing list >>>>>>>>>>>> nsc@ietf.org >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> nsc mailing list >>>>>>>>>>> nsc@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> nsc mailing list >>>>>>> nsc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>>> _______________________________________________ >>>>>> nsc mailing list >>>>>> nsc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/nsc >>>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>=20 >>>=20 >>> -- >>> "Esta vez no fallaremos, Doctor Infierno" >>>=20 >>> Dr Diego R. Lopez >>> Telefonica I+D >>> http://people.tid.es/diego.lopez/ >>>=20 >>> e-mail: diego@tid.es >>> Tel: +34 913 129 041 >>> Mobile: +34 682 051 091 >>> ----------------------------------------- >>>=20 >>>=20 >>> ________________________________ >>>=20 >>> Este mensaje se dirige exclusivamente a su destinatario. Puede >>>consultar nuestra >>> pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enlac= e >>>situado m=E1s abajo. >>> This message is intended exclusively for its addressee. We only send >>>and receive email >>> on the basis of the terms set out at: >>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > From melinda.shore@gmail.com Sun Nov 17 10:58:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459E611E90BE for ; Sun, 17 Nov 2013 10:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBMqs0HM4xyb for ; Sun, 17 Nov 2013 10:57:59 -0800 (PST) Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3F511E90BB for ; Sun, 17 Nov 2013 10:57:59 -0800 (PST) Received: by mail-pd0-f170.google.com with SMTP id g10so1275777pdj.1 for ; Sun, 17 Nov 2013 10:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qrvZEXF9pSXXel4Dn2QjJQ0Qs5uyFh1FCr+p2phLDjs=; b=lMO1aJ39PsMPxT319Vji/UUTf8E85jJpBQxAjtP1yRFNfLt7WA8qy+TfIqEV+Lv2JU vWqEZ4JC548pN/FUVN6MPx6d/qFcGAKcjykUYDF+7S668vdaawpz1+JEPtAisXcPTWeS Y9JFTwZXEQm1M50WRpxndBgAwcrqh0iIWKDbQ3zmvw44fsexcZSId3OTlL8G7KTuX3EN aJ9BOGg7CoB+ZttdvoPAqXE/kVp90L61NDApcWE6Gu8kTClJ1RdjLoEmdAFwI7rbKU2e LA9z9N2itF4gjkqkA+EIMVfjGGUzv69T951vMzbRBt/G7in0Wfz5IWrLQtLga5cjg1LH GhLg== X-Received: by 10.68.172.65 with SMTP id ba1mr17194491pbc.18.1384714642889; Sun, 17 Nov 2013 10:57:22 -0800 (PST) Received: from spandex.local (63-140-91-14.dynamic.dsl.acsalaska.net. [63.140.91.14]) by mx.google.com with ESMTPSA id fb3sm18316745pbc.29.2013.11.17.10.57.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Nov 2013 10:57:21 -0800 (PST) Message-ID: <5289118C.2060101@gmail.com> Date: Sun, 17 Nov 2013 09:57:16 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Carlos Pignataro \(cpignata\)" , "Ersue, Mehmet \(NSN - DE/Munich\)" , Thomas Narten , "Benoit Claise \(bclaise\)" , "ext Diego R. Lopez" Subject: Re: [nsc] Current Proposed SFC charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Nov 2013 18:58:00 -0000 On 11/17/13 9:50 AM, Jim Guichard (jguichar) wrote: > The current charter text calls for more study into the requirements > in this area and we have a specific milestone to consult with OPS. > While the approach we have taken may result in some rechartering in > the future we felt that was the right thing to do at this stage while > we figure out what should be in and out of scope for the SFC WG. One of the reasons that the question appears pressing is that we're already seeing some drafts. However, some of those drafts specifically reference NFV rather than nsc so wouldn't end up in an nsc working group, anyway (I think). Melinda From jguichar@cisco.com Mon Nov 18 13:17:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256861AD68D for ; Mon, 18 Nov 2013 13:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 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.525, 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 MBFY8PqTC1Dz for ; Mon, 18 Nov 2013 13:16:58 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 8517D1AD739 for ; Mon, 18 Nov 2013 13:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18769; q=dns/txt; s=iport; t=1384809413; x=1386019013; h=from:to:subject:date:message-id:mime-version; bh=dSP15iEinPq8PP8NMMRVadxsIsdnzg9F50b6s4zBOkc=; b=gp1+aDyP/P13uQgbYT3uH1AcSosYnCexYJ5QL2B92iy1aNsEeflCuwrf d0IYiaDBD++nin1oFd/d9/C8Oz0sXI6FmG9ej3SODIC4ZEamvnZj9cp7g bPFp0/jbxZuKA6IMs/sRXTxh8gcK6AdO6wGYx3OfBzcxbxaT93u/VKmet U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq8FAGGDilKtJV2b/2dsb2JhbABZgkNEgQvAVhZtB4IsZwcEGQEaZhcQBIgUoTKhS5QhA5Qug2KSDYMogio X-IronPort-AV: E=Sophos;i="4.93,726,1378857600"; d="scan'208,217";a="456253" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-4.cisco.com with ESMTP; 18 Nov 2013 21:16:38 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAILGcgF031009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 18 Nov 2013 21:16:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 15:16:38 -0600 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEA== Date: Mon, 18 Nov 2013 21:16:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: multipart/alternative; boundary="_000_CEAFEDE31168Djguicharciscocom_" MIME-Version: 1.0 Subject: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 18 Nov 2013 21:17:01 -0000 --_000_CEAFEDE31168Djguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the proble= m space to be addressed by the SFC working group including example high-lev= el use cases. Additionally, the working group will normalize nomenclature a= nd definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC arc= hitectural building blocks and their relationship including interconnection= , placement of SFC specific capabilities, management, diagnostics, design a= nalysis, and security models, as well as requirements on the protocol mecha= nisms. The initial scope is restricted to a single administrative domain, k= eeping in mind that architectural decisions made for the intra-domain case = may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single servi= ce-level data plane encapsulation format for conveying the service function= chain and the service function path, and for communicating context informa= tion between nodes that implement service functions and service function ch= ains. It is intended that the encapsulation be agnostic to the layer at whi= ch is is applied and the service that is being constructed. That is, the sa= me encapsulation may be used on a service function path realized at the net= work layer or at any other layer, and the same encapsulation will apply for= the construction of service function paths regardless of the actual servic= e. 4. Control Plane Mechanisms: A document will be developed to describe re= quirements for conveying information between control or management elements= and SFC implementation points. All protocol extension work resulting from = these requirements should be carried out in the working group responsible f= or the protocol being modified in coordination with this working group, but= may be done in this working group under a revised charter after agreement = with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC compon= ents related to the support of service function chaining will certainly be = needed, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem sta= tement and core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for ma= nagement and configuration of SFC components related to the support of serv= ice function chaining Jan 2015 Submit to IESG Informational document defining the architecture fo= r SFC Jan 2015 Submit to IESG Informational document defining the control plane r= equirements for conveying information between control or management element= s and SFC implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic ser= vice function chaining header encapsulation --_000_CEAFEDE31168Djguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7DC70588FDF7E34ABEE7C164420B6432@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

Thomas Narten and I have spent some time refining the SFC c= harter based upon discussion during the SFC BOF and several emails to the mailing list. We do not believe this is a su= bstantive change; we have clarified the management vs. control plane text a= nd added text around security. Please review the revised charter and provide comment.

Revised SFC WG= Charter:

Service delivery is undergoing significant change with= the introduction of virtualization, network overlays, and orchestration. S= ervice delivery is currently both a technical and an organizational challenge that involves significant modification to = the network configuration thereby impacting the speed at which services can= be deployed and increasing operational costs. Services are typically imple= mented by the ordered combination of a number of service functions that are deployed at different points wit= hin a network. Today, a common deployment model has service functions physi= cally inserted on the data-forwarding path between communicating peers. Goi= ng forward, however, there is a desire to move to a different model, where service functions, whether phys= ical or virtualized, are not required to reside on the direct data path and= traffic is instead steered through service functions, wherever they are de= ployed.  

 

For a give= n service, the abstracted view of the required service functions and the or= der in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function= instances and the network nodes on which they are provided, thereby formin= g a service graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer wit= hin the network protocol stack (network layer, application layer, etc.).  

 

The SFC wo= rking group will document a new approach to service delivery and operation.= It will produce an architecture for service function chaining that includes the necessary protocols or protocol extens= ions to convey the service path and service path information to nodes that = are involved in the implementation of service functions and service functio= n chains, as well as mechanisms for steering traffic through service functions. The working group will exa= mine what information needs to be gathered from the network and service fun= ctions in support of service function chaining and how that information may= be made available to the components of the service function chaining architecture. The SFC WG will= closely consider the security implications when documenting these delivera= bles. <= /font>


Specifical= ly, the SFC WG is chartered to deliver the following:<= /p>

  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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 
  2. = Architectur= e: This document will provide a description of the SFC architectural buildi= ng blocks and their relationship including interconnection, placement of SFC specific capabilities, managem= ent, diagnostics, design analysis, and security models, as well as requirem= ents on the protocol mechanisms. The initial scope is restricted to a singl= e administrative domain, keeping in mind that architectural decisions made for the intra-domain case may ha= ve implications for the inter-domain case.
  3. Generic SFC Encapsulation: T= his document will describe a single service-level data plane encapsulation = format for conveying the service function chain and the service function path, and for communic= ating context information between nodes that implement service functions an= d service function chains. It is intended that the encapsulation be agnosti= c to the layer at which is is applied and the service that is being constructed. That is, the same encapsulation= may be used on a service function path realized at the network layer or at= any other layer, and the same encapsulation will apply for the constructio= n of service function paths regardless of the actual service.
  4. Control Plane Mechanisms: A document will be de= veloped to describe requirements for conveying information between control or management elements and SFC implementation points. All protocol extensi= on work resulting from these requirements should be carried out in the work= ing group responsible for the protocol being modified in coordination with = this working group, but may be done in this working group under a revised charter after agreement with all the= relevant WG chairs and responsible ADs.
  5. Manageability: Work on the man= agement and configuration of SFC components related to the support of servi= ce function chaining will certainly be needed, but first needs to be better understood= and scoped.

Propos= ed Milestones:

Apr 20= 14 Submit to IESG Informational document defining the SFC problem state= ment and core use cases
Apr 20= 14 Consult with OPS area on possible SFC charter modifications for mana= gement and configuration of SFC components related to the support of servic= e function chaining
Jan 20= 15 Submit to IESG Informational document defining the architecture for = SFC
Jan 20= 15 Submit to IESG Informational document defining the control plane req= uirements for conveying information between control or management elements = and SFC implementation points
Aug 20= 15 Submit to IESG Standards Track document specifying the generic servi= ce function chaining header encapsulation

--_000_CEAFEDE31168Djguicharciscocom_-- From jguichar@cisco.com Mon Nov 18 16:57:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51DA1AE825 for ; Mon, 18 Nov 2013 16:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 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.525, 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 8TX5rkQJP_ff for ; Mon, 18 Nov 2013 16:57:22 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 15AE81AE81E for ; Mon, 18 Nov 2013 16:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1946; q=dns/txt; s=iport; t=1384822636; x=1386032236; h=from:to:subject:date:message-id:mime-version; bh=n/3tR/OoC2XSMOw94d6x++o7gbz8pRgQTmpKOJGj6BM=; b=GXM5jnCzjFB633UiNZr83qxMsTpDn9j4GIsLBc3g5ePp24GLrNy9u9O3 quZd95N4AyIbYdgMppxvDmRt8nUHMwHZh96DOxmFi5ojpunR2JNdhY3ZY WH8Lvu6G84BhMXLouxyOa5h7y4utjIy8bDhmkD2hmsOnU42ervRnldr8z M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcJAC+3ilKtJV2Z/2dsb2JhbABZgkNEOFO2fIlXFm0HghwQJ2QBCwF0JwQch3gNoHKhSpQhA5gQkg2DKIIq X-IronPort-AV: E=Sophos;i="4.93,727,1378857600"; d="scan'208,217";a="500054" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP; 19 Nov 2013 00:57:12 +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 rAJ0vCK0031204 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Nov 2013 00:57:12 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Mon, 18 Nov 2013 18:57:11 -0600 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: IETF 88 SFC BOF Minutes posted Thread-Index: AQHO5MJHO7LWVTgk/06YR1vFCKicYw== Date: Tue, 19 Nov 2013 00:57:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: multipart/alternative; boundary="_000_CEB02194116B8jguicharciscocom_" MIME-Version: 1.0 Subject: [nsc] IETF 88 SFC BOF Minutes posted X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 00:57:23 -0000 --_000_CEB02194116B8jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, I have just posted preliminary minutes for the SFC BOF here -> http://www.i= etf.org/proceedings/88/minutes/minutes-88-sfc .. A special thank you to our= two minute takers, Ken Gray and Maciek Konstantynowicz. Please kindly review and provide corrections where necessary. Note: due to = the lively discussion, a few comments were made where the name of the speak= er was not captured (indicated by (?) in the minutes). If you recognize a c= omment that you made please let me know and I will update the minutes accor= dingly. --_000_CEB02194116B8jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings,

I have just posted preliminary minutes for the SFC BOF here -> = ;http= ://www.ietf.org/proceedings/88/minutes/minutes-88-sfc .. A special= thank you to our two minute takers, Ken Gray and Maciek Konstantynowicz. 

Please kindly review and provide corrections where necessary. Note: du= e to the lively discussion, a few comments were made where the name of the = speaker was not captured (indicated by (?) in the minutes). If you recogniz= e a comment that you made please let me know and I will update the minutes accordingly.
--_000_CEB02194116B8jguicharciscocom_-- From Ron_Parker@affirmednetworks.com Mon Nov 18 17:37:36 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3851AE957 for ; Mon, 18 Nov 2013 17:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZvR08VjiDA2 for ; Mon, 18 Nov 2013 17:37:31 -0800 (PST) Received: from hub021-ca-7.exch021.serverdata.net (hub021-ca-7.exch021.serverdata.net [64.78.56.72]) by ietfa.amsl.com (Postfix) with ESMTP id B1F281AE95A for ; Mon, 18 Nov 2013 17:37:25 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-7.exch021.domain.local ([10.254.4.109]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 17:37:20 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJorxEmw Date: Tue, 19 Nov 2013 01:37: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: [173.76.112.207] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74E745MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 01:37:36 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74E745MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Jim. The charter looks good. I do have a minor comment regarding the following= : Generic SFC Encapsulation: This document will describe a single service-lev= el data plane encapsulation format for conveying the service function chain= and the service function path, and for communicating context information b= etween nodes that implement service functions and service function chains. = It is intended that the encapsulation be agnostic to the layer at which is = is applied and the service that is being constructed. That is, the same enc= apsulation may be used on a service function path realized at the network l= ayer or at any other layer, and the same encapsulation will apply for the c= onstruction of service function paths regardless of the actual service. Specifically, the 'and' in the following phrase could be more limiting than= necessary: for conveying the service function chain and the service function path In draft-parker-sfc-chain-to-path (http://tools.ietf.org/html/draft-parker-= sfc-chain-to-path-00), it is proposed that neither the classifier (Policy D= ecision Point) nor the service nodes be aware of the specific instances of = a service function that is multiply instantiated. Under this approach, th= e service header would need only the chain information and not the path inf= ormation. Thanks. Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the probl= em space to be addressed by the SFC working group including example high-le= vel use cases. Additionally, the working group will normalize nomenclature = and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC ar= chitectural building blocks and their relationship including interconnectio= n, placement of SFC specific capabilities, management, diagnostics, design = analysis, and security models, as well as requirements on the protocol mech= anisms. The initial scope is restricted to a single administrative domain, = keeping in mind that architectural decisions made for the intra-domain case= may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single serv= ice-level data plane encapsulation format for conveying the service functio= n chain and the service function path, and for communicating context inform= ation between nodes that implement service functions and service function c= hains. It is intended that the encapsulation be agnostic to the layer at wh= ich is is applied and the service that is being constructed. That is, the s= ame encapsulation may be used on a service function path realized at the ne= twork layer or at any other layer, and the same encapsulation will apply fo= r the construction of service function paths regardless of the actual servi= ce. 4. Control Plane Mechanisms: A document will be developed to describe r= equirements for conveying information between control or management element= s and SFC implementation points. All protocol extension work resulting from= these requirements should be carried out in the working group responsible = for the protocol being modified in coordination with this working group, bu= t may be done in this working group under a revised charter after agreement= with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC compo= nents related to the support of service function chaining will certainly be= needed, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74E745MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Jim.

 <= /p>

The charter looks good.&n= bsp;  I do have a minor comment regarding the following:

Generic SFC Encapsulation: This document will describ= e a single service-level data plane encapsulation format for conveying the = service function chain and the service function path, and for communicating context information between nodes that implement ser= vice functions and service function chains. It is intended that the encapsu= lation be agnostic to the layer at which is is applied and the service that= is being constructed. That is, the same encapsulation may be used on a service function path realized at = the network layer or at any other layer, and the same encapsulation will ap= ply for the construction of service function paths regardless of the actual= service.

Specifically, the ‘= and’ in the following phrase could be more limiting than necessary:

 <= /p>

for= conveying the service function chain and the service function path

 

In draft-parker-sfc-chain= -to-path (http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00= ), it is proposed that neither the classifier (Policy Decision Point) nor the= service nodes be aware of the specific instances of a service function tha= t is multiply instantiated.   Under this approach, the service he= ader would need only the chain information and not the path information.

 <= /p>

Thanks.=

 <= /p>

    Ron

 <= /p>

 <= /p>

 <= /p>

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,

 

Thomas Narten and I have spent some time refining the SFC charter based = upon discussion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clar= ified the management vs. control plane text and added text around security.= Please review the revised charter and provide comment.<= span style=3D"font-size:13.5pt;font-family:"Calibri","sans-s= erif";color:black">

 

Revised SFC WG Charter:

 

S= ervice delivery is undergoing significant change with the introduction of v= irtualization, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  

&= nbsp;

For a given service, the abstracted view of= the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  =

&= nbsp;

The SFC working group will document a new a= pproach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary pro= tocols or protocol extensions to convey the service path and service path i= nformation to nodes that are involved in the implementation of service func= tions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. 

 

Specifically, the SFC WG is chartered to de= liver the following:

1.  &nb= sp;  Problem Statement: This document will provide a summary of the p= roblem space to be addressed by the SFC working group including example high-level use cases. Additionally, the working group will normali= ze nomenclature and definitions for service function chaining. =

2.  &nb= sp;  Architecture: This doc= ument will provide a description of the SFC architectural building blocks a= nd their relationship including interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, an= d security models, as well as requirements on the protocol mechanisms. The = initial scope is restricted to a single administrative domain, keeping in m= ind that architectural decisions made for the intra-domain case may have implications for the inter-domain = case.

3.  &nb= sp;  Generic SFC Encapsulat= ion: This document will describe a single service-level data plane encapsul= ation format for conveying the service function chain and the service function path, and for communicating context information b= etween nodes that implement service functions and service function chains. = It is intended that the encapsulation be agnostic to the layer at which is = is applied and the service that is being constructed. That is, the same encapsulation may be used on a ser= vice function path realized at the network layer or at any other layer, and= the same encapsulation will apply for the construction of service function= paths regardless of the actual service.

4.  &nb= sp;  Control Plane Mechanis= ms: A document will be developed to describe requirements for conveying inf= ormation between control or management elements and SFC implementation points. All protocol extension work resulting from these re= quirements should be carried out in the working group responsible for the p= rotocol being modified in coordination with this working group, but may be = done in this working group under a revised charter after agreement with all the relevant WG chairs and resp= onsible ADs.

5.  &nb= sp;  Manageability: Work on= the management and configuration of SFC components related to the support = of service function chaining will certainly be needed, but first needs to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational d= ocument defining the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possi= ble SFC charter modifications for management and configuration of SFC compo= nents related to the support of service function chaining

Jan 2015

Submit to IESG Informational d= ocument defining the architecture for SFC

Jan 2015

Submit to IESG Informational d= ocument defining the control plane requirements for conveying information b= etween control or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track= document specifying the generic service function chaining header encapsula= tion

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74E745MBX021W3CA2exch_-- From kevin.ma@azukisystems.com Mon Nov 18 22:32:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803311A1F7A for ; Mon, 18 Nov 2013 22:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yV1p534tr6KQ for ; Mon, 18 Nov 2013 22:32:19 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 36BD91A1F78 for ; Mon, 18 Nov 2013 22:32:19 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1D1687AEE8A; Tue, 19 Nov 2013 01:25:49 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 35D577AE9F8; Tue, 19 Nov 2013 01:25:48 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 19 Nov 2013 01:25:47 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Tue, 19 Nov 2013 01:25:45 -0500 Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPg Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C768D4C1MAILR002maill_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 06:32:22 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D4C1MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D4C1MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

  There is a typo in item 3.  = "is is" -> "it is":

&= nbsp;

    "It is intended that the= encapsulation be agnostic to the layer at which is is applied"

 

  Wrt to the foll= owing text:

 

&nb= sp;   "the same encapsulation may be used on a service funct= ion path realized at the network layer or at any other layer"

 

  If the service fu= nction is an application layer service, and the

&= nbsp; encapsulation is at a lower layer (L2/L3), then presumably signaling<= o:p>

  would be required between the application = layer and the lower layer

  responsible for = encapsulation, so that individual packets for an

=   application layer message may be properly encapsulated.  Has th= is

  been discussed and/or is it considered = in scope?

 

 = Though this sort of thing could be called an implementation detail,

 typically higher layers do not need to know the = lower layer details,

 but in this particul= ar case, if the higher layer is re-classifying,

=  it likely wants/needs to know the ingress chain ID as it selects the =

  egress chain ID, and then needs to t= ell the lower encapsulation layer

 what the= new egress chain ID should be?

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

thanx.

 

--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounce= s@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Mon= day, November 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,

<= div>

 

Thomas Narten and I have sp= ent some time refining the SFC charter based upon discussion during the SFC= BOF and several emails to the mailing list. We do not believe this is a su= bstantive change; we have clarified the management vs. control plane text a= nd added text around security. Please review the revised charter and p= rovide comment.

 

Revised SFC WG Charter:

=

 

Service delivery is undergoi= ng significant change with the introduction of virtualization, network over= lays, and orchestration. Service delivery is currently both a technical and= an organizational challenge that involves significant modification to the = network configuration thereby impacting the speed at which services can be = deployed and increasing operational costs. Services are typically implement= ed by the ordered combination of a number of service functions that are dep= loyed at different points within a network. Today, a common deployment mode= l has service functions physically inserted on the data-forwarding path bet= ween communicating peers. Going forward, however, there is a desire to move= to a different model, where service functions, whether physical or virtual= ized, are not required to reside on the direct data path and traffic is ins= tead steered through service functions, wherever they are deployed. &n= bsp;<= /o:p>

 <= /span>=

For a given service, the abstracted view of the required= service functions and the order in which they are to be applied is called = a Service Function Chain (SFC). An SFC is instantiated through se= lection of specific service function instances and the network nodes on whi= ch they are provided, thereby forming a service graph: this is called a Ser= vice Function Path (SFP). The service functions may be applied at any layer= within the network protocol stack (network layer, application layer, etc.)= .  

 

The SFC working group will document a ne= w approach to service delivery and operation. It will produce an architectu= re for service function chaining that includes the necessary protocols or p= rotocol extensions to convey the service path and service path information = to nodes that are involved in the implementation of service functions and s= ervice function chains, as well as mechanisms for steering traffic through = service functions. The working group will examine what information needs to= be gathered from the network and service functions in support of service f= unction chaining and how that information may be made available to the comp= onents of the service function chaining architecture. The SFC WG will = closely consider the security implications when documenting these deliverab= les. 

 

Specifically, the SFC WG is chartered to deliver the= following:

1.  Problem Statement: This doc= ument will provide a summary of the problem space to be addressed by the SF= C working group including example high-level use cases. Additionally, the w= orking group will normalize nomenclature and definitions for service functi= on chaining. 

2.  Architecture: This document w= ill provide a description of the SFC architectural building blocks and thei= r relationship including interconnection, placement of SFC specific capabil= ities, management, diagnostics, design analysis, and security models, as we= ll as requirements on the protocol mechanisms. The initial scope is restric= ted to a single administrative domain, keeping in mind that architectural d= ecisions made for the intra-domain case may have implications for the inter= -domain case.

3.&n= bsp; Generic SFC Encapsulation: This docum= ent will describe a single service-level data plane encapsulation format fo= r conveying the service function chain and the service function path, and f= or communicating context information between nodes that implement service f= unctions and service function chains. It is intended that the encapsulation= be agnostic to the layer at which is is applied and the service that is be= ing constructed. That is, the same encapsulation may be used on a service f= unction path realized at the network layer or at any other layer, and the s= ame encapsulation will apply for the construction of service function paths= regardless of the actual service.

4.  Control Plane Mechan= isms: A document will be developed to describe requirements for conveying i= nformation between control or management elements and SFC implementation po= ints. All protocol extension work resulting from these requirements should = be carried out in the working group responsible for the protocol being modi= fied in coordination with this working group, but may be done in this worki= ng group under a revised charter after agreement with all the relevant WG c= hairs and responsible ADs.

5.  Manageability: Work on the m= anagement and configuration of SFC components related to the support of ser= vice function chaining will certainly be needed, but first needs to be bett= er understood and scoped.

 

= Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defining the SFC p= roblem statement and core use cases

=

Apr 2014

Consult with OPS area on possible= SFC charter modifications for management and configuration of SFC componen= ts related to the support of service function chaining

Jan 2015

Submit to IESG= Informational document defining the architecture for SFC<= /o:p>

Jan 2015

Submit to= IESG Informational document defining the control plane requirements for co= nveying information between control or management elements and SFC implemen= tation points

Aug 2015

Submit to IESG Standards Track document specifying the = generic service function chaining header encapsulation

 <= /p>

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D4C1MAILR002maill_-- From jguichar@cisco.com Tue Nov 19 06:33:17 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D41621ADFE0 for ; Tue, 19 Nov 2013 06:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 qv1rnwpui3qF for ; Tue, 19 Nov 2013 06:33:14 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id D011D1ADFA8 for ; Tue, 19 Nov 2013 06:33:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31442; q=dns/txt; s=iport; t=1384871588; x=1386081188; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=eWTgHoOtwZSWrWMUY2H3NPivVc489FYCIAHututZ/RY=; b=eIgDBOiC3Tsur6yBu0gqAqD1d4vUoBA3wCE+cay4wVtq9jkYqMqHCwrc W0g8U3pdXR1fWiWC0uv90/c2EKKusIy9KzD8Lvxhhdu0wjR+UgF8tnrr5 2CkaDW/OfyBr/qPB8dQ2HXvIHMfn1w5vFrIVOCS9TLjQpPYoumdRyAo/X c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIGAIB1i1KtJV2Z/2dsb2JhbABPCoJDRDhTtnOIS4EhFnSCJQEBAQQtOgcEGQEIEQECAQEBIQEGORQDBggCBAESiAENvwmOEYEiExcBAoQwA5Qwg2KBL5BegyiCKg X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="283075102" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 19 Nov 2013 14:33:07 +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 rAJEX77P025926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 14:33:07 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 08:33:06 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , "nsc@ietf.org" Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJorxEmwgADrtAA= Date: Tue, 19 Nov 2013 14:33:05 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.36.60] Content-Type: multipart/alternative; boundary="_000_CEB0E045116EAjguicharciscocom_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 14:33:18 -0000 --_000_CEB0E045116EAjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ron, I think the language used is meant to indicate that the service function pa= th points to the intended service function chain so that the local node is = able to identify which service function to apply and which is the next serv= ice function in the chain. Which instance of the next service function to a= pply is independent of this. From: Ron Parker > Date: Monday, November 18, 2013 8:37 PM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi, Jim. The charter looks good. I do have a minor comment regarding the following= : Generic SFC Encapsulation: This document will describe a single service-lev= el data plane encapsulation format for conveying the service function chain= and the service function path, and for communicating context information b= etween nodes that implement service functions and service function chains. = It is intended that the encapsulation be agnostic to the layer at which is = is applied and the service that is being constructed. That is, the same enc= apsulation may be used on a service function path realized at the network l= ayer or at any other layer, and the same encapsulation will apply for the c= onstruction of service function paths regardless of the actual service. Specifically, the =91and=92 in the following phrase could be more limiting = than necessary: for conveying the service function chain and the service function path In draft-parker-sfc-chain-to-path (http://tools.ietf.org/html/draft-parker-= sfc-chain-to-path-00), it is proposed that neither the classifier (Policy D= ecision Point) nor the service nodes be aware of the specific instances of = a service function that is multiply instantiated. Under this approach, th= e service header would need only the chain information and not the path inf= ormation. Thanks. Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the probl= em space to be addressed by the SFC working group including example high-le= vel use cases. Additionally, the working group will normalize nomenclature = and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC ar= chitectural building blocks and their relationship including interconnectio= n, placement of SFC specific capabilities, management, diagnostics, design = analysis, and security models, as well as requirements on the protocol mech= anisms. The initial scope is restricted to a single administrative domain, = keeping in mind that architectural decisions made for the intra-domain case= may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single serv= ice-level data plane encapsulation format for conveying the service functio= n chain and the service function path, and for communicating context inform= ation between nodes that implement service functions and service function c= hains. It is intended that the encapsulation be agnostic to the layer at wh= ich is is applied and the service that is being constructed. That is, the s= ame encapsulation may be used on a service function path realized at the ne= twork layer or at any other layer, and the same encapsulation will apply fo= r the construction of service function paths regardless of the actual servi= ce. 4. Control Plane Mechanisms: A document will be developed to describe r= equirements for conveying information between control or management element= s and SFC implementation points. All protocol extension work resulting from= these requirements should be carried out in the working group responsible = for the protocol being modified in coordination with this working group, bu= t may be done in this working group under a revised charter after agreement= with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC compo= nents related to the support of service function chaining will certainly be= needed, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_CEB0E045116EAjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4360B9E79E4CF64C9B9DF9CC0F3805EB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Ron,
I think the language used is meant to indicate that the service functi= on path points to the intended serv= ice function chain so that the local node is able to identify which service= function to apply and which is the next service function in the chain. Whi= ch instance of the next service function to apply is independent of this. 

From: Ron Parker <Ron_Parker@affirmednetworks.com>= ;
Date: Monday, November 18, 2013 8:3= 7 PM
To: Jim Guichard <jguichar@cisco.com>, "nsc@ietf.org" <n= sc@ietf.org>
Subject: RE: Revised SFC Charter

Hi, Jim.

 

The charter looks good.  = ; I do have a minor comment regarding the following:

Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context information between nodes that implement ser= vice functions and service function chains. It is intended that the encapsu= lation be agnostic to the layer at which is is applied and the service that= is being constructed. That is, the same encapsulation may be used on a service function path realized at = the network layer or at any other layer, and the same encapsulation will ap= ply for the construction of service function paths regardless of the actual= service.

Specifically, the =91and=92 in the= following phrase could be more limiting than necessary:<= /p>

 

for conveying the ser= vice function chain and the service function path

 

In draft-parker-sfc-chain-to-path = (http://tools.ietf.org/html/draft-parker-sfc-chain-to-path-00), it is proposed that neither the classifier (Policy Decision Point) nor the= service nodes be aware of the specific instances of a service function tha= t is multiply instantiated.   Under this approach, the service he= ader would need only the chain information and not the path information.

 

Thanks.

 

    Ron<= /span>

 

 

 

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,

 

Thomas Narten a= nd I have spent some time refining the SFC charter based upon discussion du= ring the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have = clarified the management vs. control plane text and added text around secur= ity. Please review the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is= undergoing significant change with the introduction of virtualization, net= work overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  

 

For a given service, the abstracted view of the required serv= ice functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  = <= o:p>

 

The SFC working group will document a new approach to service= delivery and operation. It will produce an architecture for service function chaining that includes the necessary = protocols or protocol extensions to convey the service path and service pat= h information to nodes that are involved in the implementation of service f= unctions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. 

 

Specifically, the SFC WG is chartered to deliver the followin= g:

1.  = ;   Pro= blem Statement: This document will provide a summary of the problem space t= o be addressed by the SFC working group including example high-level use cases. Additionally, the working group wi= ll normalize nomenclature and definitions for service function chaining.&nb= sp;

2.  = ;   Architecture: This document will pro= vide a description of the SFC architectural building blocks and their relat= ionship including interconnection, placement of SFC specific capabilities, management, diagnostics, design an= alysis, and security models, as well as requirements on the protocol mechan= isms. The initial scope is restricted to a single administrative domain, ke= eping in mind that architectural decisions made for the intra-domain case may have implications for the int= er-domain case.

3.  = ;   Generic SFC Encapsulation: This docu= ment will describe a single service-level data plane encapsulation format f= or conveying the service function chain and the service function path, and for communicating context informa= tion between nodes that implement service functions and service function ch= ains. It is intended that the encapsulation be agnostic to the layer at whi= ch is is applied and the service that is being constructed. That is, the same encapsulation may be used on = a service function path realized at the network layer or at any other layer= , and the same encapsulation will apply for the construction of service fun= ction paths regardless of the actual service.

4.  = ;   Control Plane Mechanisms: A document= will be developed to describe requirements for conveying information betwe= en control or management elements and SFC implementation points. All protocol extension work resulting from = these requirements should be carried out in the working group responsible f= or the protocol being modified in coordination with this working group, but= may be done in this working group under a revised charter after agreement with all the relevant WG chairs an= d responsible ADs.

5.  = ;   Manageability: Work on the managemen= t and configuration of SFC components related to the support of service fun= ction chaining will certainly be needed, but first needs to be better understood and scoped.

 

Proposed Milestones:<= /span>

 

Apr 2014

Submit to IESG Informational document defining t= he SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC charter mo= difications for management and configuration of SFC components related to t= he support of service function chaining

Jan 2015

Submit to IESG Informational document defining t= he architecture for SFC

Jan 2015

Submit to IESG Informational document defining t= he control plane requirements for conveying information between control or = management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document specifyi= ng the generic service function chaining header encapsulation 

 --_000_CEB0E045116EAjguicharciscocom_-- From jguichar@cisco.com Tue Nov 19 06:38:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA071ADFF2 for ; Tue, 19 Nov 2013 06:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 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.525, 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 WyDpTa7L2E53 for ; Tue, 19 Nov 2013 06:38:54 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id E46501ADFF0 for ; Tue, 19 Nov 2013 06:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34352; q=dns/txt; s=iport; t=1384871928; x=1386081528; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=FJMfxKB8q9UhbXiCyzUqP3oREZEFTywoKPY4xxMMDCA=; b=m7v4IrhpOpzWiJH++5+j+KQF6Q6mlLWoEBJ/7zmi2ZfuTxaJfDwII+Q2 K8q7lV24G8bP3TTHCdzaTmSGiPQGH5ju3kksJZPSltJIGimW+4OK4Zpli mS6LKJT5IrKvz7T7kSrC8O8L5MAXnUDZ7TK0CCpEhnqISPePn+KgZpIHc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAJ53i1KtJXG9/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQQnBjoHBBkBCBEBAgEBASEBBjkUAwYIAgQBEogBvxePRhcBBoQsA5Qwg2KSDYMogio X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="612977" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-2.cisco.com with ESMTP; 19 Nov 2013 14:38:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAJEclFp018441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 14:38:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 08:38:46 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "nsc@ietf.org" Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEIA= Date: Tue, 19 Nov 2013 14:38:45 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.36.60] Content-Type: multipart/alternative; boundary="_000_CEB0E128116F2jguicharciscocom_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 14:38:57 -0000 --_000_CEB0E128116F2jguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_CEB0E128116F2jguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9CD5EBBF0BE9A1489AB02CA84D93394C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kevin,

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, November 19, 2013 1:= 25 AM
To: Jim Guichard <jguichar@cisco.com>, "nsc@ietf.org" <n= sc@ietf.org>
Subject: RE: Revised SFC Charter

Hi Jim,

 

  There is a typo in item 3.  "is is" -> &= quot;it is":

 

    "It is intended that the encapsulation be= agnostic to the layer at which is is applied"

Jim> yes, thank you, I corrected the text. 

 

  Wrt to the following text:

 

    "the same encapsulation may be used on a = service function path realized at the network layer or at any other layer&q= uot;

 

  If the service function is an application layer service, a= nd the

  encapsulation is at a lower layer (L2/L3), then presumably= signaling

  would be required between the application layer and the lo= wer layer

  responsible for encapsulation, so that individual packets = for an

  application layer message may be properly encapsulated.&nb= sp; Has this

  been discussed and/or is it considered in scope?


Jim> the point here was to show that the steering function is indep= endent of the services layer. As packets traverse a service chain the encap= sulation above the steering function is used to indicate what service funct= ion to apply and which service function comes next in the service function chain. 

 

  Though this sort of thing could be called an implementatio= n detail,

 typically higher layers do not need to know the lower layer= details,

 but in this particular case, if the higher layer is re-clas= sifying,

 it likely wants/needs to know the ingress chain ID as it se= lects the

  egress chain ID, and then needs to tell the lower enc= apsulation layer

 what the new egress chain ID should be?

Jim> this would be part of the control plane which would make avail= able to the service function (or proxy) information about inbound and outbo= und service function chain encapsulation. 

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mai= lto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,

 

Thomas Narten a= nd I have spent some time refining the SFC charter based upon discussion du= ring the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have = clarified the management vs. control plane text and added text around secur= ity. Please review the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is= undergoing significant change with the introduction of virtualization, net= work overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  

 

For a given service, the abstracted view of the required serv= ice functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  = <= o:p>

 

The SFC working group will document a new approach to service= delivery and operation. It will produce an architecture for service function chaining that includes the necessary = protocols or protocol extensions to convey the service path and service pat= h information to nodes that are involved in the implementation of service f= unctions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. 

 

Specifically, the SFC WG is chartered to deliver the followin= g:

1.  Pro= blem Statement: This document will provide a summary of the problem space t= o be addressed by the SFC working group including example high-level use cases. Additionally, the working group wi= ll normalize nomenclature and definitions for service function chaining.&nb= sp;

2.  Architecture: This document will pro= vide a description of the SFC architectural building blocks and their relat= ionship including interconnection, placement of SFC specific capabilities, management, diagnostics, design an= alysis, and security models, as well as requirements on the protocol mechan= isms. The initial scope is restricted to a single administrative domain, ke= eping in mind that architectural decisions made for the intra-domain case may have implications for the int= er-domain case.

3.  Generic SFC Encapsulation: This docu= ment will describe a single service-level data plane encapsulation format f= or conveying the service function chain and the service function path, and for communicating context informa= tion between nodes that implement service functions and service function ch= ains. It is intended that the encapsulation be agnostic to the layer at whi= ch is is applied and the service that is being constructed. That is, the same encapsulation may be used on = a service function path realized at the network layer or at any other layer= , and the same encapsulation will apply for the construction of service fun= ction paths regardless of the actual service.

4.  Control Plane Mechanisms: A document= will be developed to describe requirements for conveying information betwe= en control or management elements and SFC implementation points. All protocol extension work resulting from = these requirements should be carried out in the working group responsible f= or the protocol being modified in coordination with this working group, but= may be done in this working group under a revised charter after agreement with all the relevant WG chairs an= d responsible ADs.

5.  Manageability: Work on the managemen= t and configuration of SFC components related to the support of service fun= ction chaining will certainly be needed, but first needs to be better understood and scoped.

 

Proposed Milestones:<= /span>

 

Apr 2014

Submit to IESG Informational document defining t= he SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC charter mo= difications for management and configuration of SFC components related to t= he support of service function chaining

Jan 2015

Submit to IESG Informational document defining t= he architecture for SFC

Jan 2015

Submit to IESG Informational document defining t= he control plane requirements for conveying information between control or = management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document specifyi= ng the generic service function chaining header encapsulation 

 --_000_CEB0E128116F2jguicharciscocom_-- From kevin.ma@azukisystems.com Tue Nov 19 07:15:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7231AE012 for ; Tue, 19 Nov 2013 07:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nimOlRroClLp for ; Tue, 19 Nov 2013 07:15:55 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 852D51AE00D for ; Tue, 19 Nov 2013 07:15:54 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6E05C41683D; Tue, 19 Nov 2013 10:15:48 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 61F8941689F; Tue, 19 Nov 2013 10:15:47 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 19 Nov 2013 10:15:47 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Date: Tue, 19 Nov 2013 10:15:43 -0500 Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8A== Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C768D588MAILR002maill_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 15:15:58 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D588MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D588MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim> thi= s would be part of the control plane which would make available to the serv= ice function (or proxy) information about inbound and outbound service func= tion chain encapsulation. 

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

Personally, I am still unclear as to how this would work fo= r application layer

services.  It's not a = control plane issue if it's session data dependent?

I won't rehash the previous discussion = on "packet-level" classification and

&q= uot;packet-level" encapsulation, but IMO there are a number of issues = cited in

the problem statement which are not solv= ed by simply defining an encapsulation

header. &n= bsp;Yes, there are other informational documents on the list, but if they

do not address these questions on how the encapsul= ation may be used (and how

different levels of cl= assification/re-classification will work), then the

either way.

=  

thanx.

&nbs= p;

--  Kevin J. Ma

 

From:<= /b> Jim = Guichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Tuesday, N= ovember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subje= ct: Re: Revised SFC Charter

 

Hi Kevin,<= o:p>

 =

From: Kevin J Ma <kevin.ma@azuk= isystems.com>
Date: Tuesday, November 19, 2013 1:25 AM
= To: Jim Guichard <jguichar@= cisco.com>, "nsc@ietf.org&q= uot; <nsc@ietf.org>
Subject= : RE: Revised SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  = ;"is is" -> "it is":

 

    "It is i= ntended that the encapsulation be agnostic to the layer at which is is appl= ied"

<= o:p> 

Jim> yes= , thank you, I corrected the text. 

 

  Wrt to the fol= lowing text:

 

    "the same encapsulation may be used on a = service function path realized at the network layer or at any other layer&q= uot;

=  

  If the service function is an application layer service, and the

 = encapsulation is at a lower layer (L2/L3), then presumably signaling<= /o:p>

  wou= ld be required between the application layer and the lower layer=

  responsi= ble for encapsulation, so that individual packets for an<= /p>

  application laye= r message may be properly encapsulated.  Has this

  been discussed and= /or is it considered in scope?

 

Jim> the point here was to show that the steering function is = independent of the services layer. As packets traverse a service chain the = encapsulation above the steering function is used to indicate what service = function to apply and which service function comes next in the service func= tion chain. 

 

  Though this sort of thing could be ca= lled an implementation detail,

 typically higher layers do not need to know= the lower layer details,

 but in this particular case, if the higher layer= is re-classifying,

 it likely wants/needs to know the ingress chain ID a= s it selects the

  egress chain ID, and then needs to tell the lower = encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the= control plane which would make available to the service function (or proxy= ) information about inbound and outbound service function chain encapsulati= on. 

 

thanx.

 

<= span style=3D'color:black'>--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounces@ietf.org] On = Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, = 2013 4:17 PM
To: nsc@ietf.org=
Subject: [nsc] Revised SFC Charter

 

Greetings,

 

Thomas Narten and I have spen= t some time refining the SFC charter based upon discussion during the SFC B= OF and several emails to the mailing list. We do not believe this is a subs= tantive change; we have clarified the management vs. control plane text and= added text around security. Please review the revised charter and pro= vide comment.

 

Revised S= FC WG Charter:

=

 

Service delivery is undergoing significant change with the int= roduction of virtualization, network overlays, and orchestration. Service d= elivery is currently both a technical and an organizational challenge that = involves significant modification to the network configuration thereby impa= cting the speed at which services can be deployed and increasing operationa= l costs. Services are typically implemented by the ordered combination of a= number of service functions that are deployed at different points within a= network. Today, a common deployment model has service functions physically= inserted on the data-forwarding path between communicating peers. Going fo= rward, however, there is a desire to move to a different model, where servi= ce functions, whether physical or virtualized, are not required to reside o= n the direct data path and traffic is instead steered through service funct= ions, wherever they are deployed.  

 

= For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific= service function instances and the network nodes on which they are provide= d, thereby forming a service graph: this is called a Service Function Path = (SFP). The service functions may be applied at any layer within the network= protocol stack (network layer, application layer, etc.).  

 

The SFC working group will document a new ap= proach to service delivery and operation. It will produce an architecture f= or service function chaining that includes the necessary protocols or proto= col extensions to convey the service path and service path information to n= odes that are involved in the implementation of service functions and servi= ce function chains, as well as mechanisms for steering traffic through serv= ice functions. The working group will examine what information needs to be = gathered from the network and service functions in support of service funct= ion chaining and how that information may be made available to the componen= ts of the service function chaining architecture. The SFC WG will clos= ely consider the security implications when documenting these deliverables.=  

 <= /o:p>

Specifically, the SFC WG is chartered to deliver th= e following:

1.  P= roblem 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. Additionally, the working group will normalize nomenclature and defi= nitions for service function chaining. 

2.  = Architecture: This document will provide a description of the SFC architect= ural building blocks and their relationship including interconnection, plac= ement of SFC specific capabilities, management, diagnostics, design analysi= s, and security models, as well as requirements on the protocol mechanisms.= The initial scope is restricted to a single administrative domain, keeping= in mind that architectural decisions made for the intra-domain case may ha= ve implications for the inter-domain case.

3.<= /span>  Generic S= FC Encapsulation: This document will describe a single service-level data p= lane encapsulation format for conveying the service function chain and the = service function path, and for communicating context information between no= des that implement service functions and service function chains. It is int= ended that the encapsulation be agnostic to the layer at which is is applie= d and the service that is being constructed. That is, the same encapsulatio= n may be used on a service function path realized at the network layer or a= t any other layer, and the same encapsulation will apply for the constructi= on of service function paths regardless of the actual service.

4. = ; Control Plane Mechanisms: A document will be developed to descri= be requirements for conveying information between control or management ele= ments and SFC implementation points. All protocol extension work resulting = from these requirements should be carried out in the working group responsi= ble for the protocol being modified in coordination with this working group= , but may be done in this working group under a revised charter after agree= ment with all the relevant WG chairs and responsible ADs.

5.  Manageability: Work on the management and configuration of SFC compon= ents related to the support of service function chaining will certainly be = needed, but first needs to be better understood and scoped.

&nb= sp;

Proposed Milestones:<= o:p>

 

Apr 2014

Submit to IESG Informational document defining the SFC pr= oblem statement and core use cases<= /o:p>

Apr 2014

Consult with= OPS area on possible SFC charter modifications for management and configur= ation of SFC components related to the support of service function chaining=

Jan 2015

Submit to IESG Informational document defining= the architecture for SFC

Jan 2015

Submit to IESG Inform= ational document defining the control plane requirements for conveying info= rmation between control or management elements and SFC implementation point= s

Aug 2015

Submit to IESG Standards Track document speci= fying the generic service function chaining header encapsulation

 

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D588MAILR002maill_-- From paulq@cisco.com Tue Nov 19 09:32:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13D01AE098 for ; Tue, 19 Nov 2013 09:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 rMzSeEQqXhWj for ; Tue, 19 Nov 2013 09:32:34 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 35A4A1AE08C for ; Tue, 19 Nov 2013 09:32:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44531; q=dns/txt; s=iport; t=1384882348; x=1386091948; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=usZwdg1NooywRBT0gGUy8+7O3kk/rP/xUCqRc8xFumk=; b=ZDDk74H+jdCMr8hUwzWSn5Nb+sP5cPe4y+3aYJ5QGh/SZgo+0xNbBcOb g6bw3KCU9+dlHFO/P9RMBgGleZQWsE6Uaa2K0hy24dz42LhhJIcZYD/2Z dSEBFOx8cKqHZp24u+Cu3DeekhqHMscQZk+53c+mkclH2s8Ekkr9Yvyu1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAK6fi1KtJV2b/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQQBAQEkQAcEBxACAQgRAQIBAQEhAQYHJwsUAwYIAgQOBYgBDb9HF49GDQQGAQYDgxeBEgOUMINigS+QXoMogio X-IronPort-AV: E=Sophos;i="4.93,730,1378857600"; d="scan'208,217";a="286130325" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Nov 2013 17:32:27 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJHWRWE008077 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 17:32:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 11:32:27 -0600 From: "Paul Quinn (paulq)" To: Kevin J Ma Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA Date: Tue, 19 Nov 2013 17:32:26 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.84.147] Content-Type: multipart/alternative; boundary="_000_A62CEE67BB3448A1B78FFB996D582E1Bciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 17:32:38 -0000 --_000_A62CEE67BB3448A1B78FFB996D582E1Bciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_A62CEE67BB3448A1B78FFB996D582E1Bciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Kevin,


On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:

Jim&g= t; this would be part of the control plane which would make available to th= e service function (or proxy) information about inbound and outbound servic= e function chain encapsulation. 
 =
Personally, I= am still unclear as to how this would work for application layer
services.&nbs= p; It's not a control plane issue if it's session data dependent?
 =

The control plane is responsible for the chaining/pathing aspect of SF= C: conveying network locators for forwarding, allocating service header inf= ormation and so on.  It is not responsible for function specifics (e.g= . per SFC policy).




I won't rehas= h the previous discussion on "packet-level" classification and
"packet-= level" encapsulation, but IMO there are a number of issues cited in
the problem s= tatement which are not solved by simply defining an encapsulation
header.  = ;Yes, there are other informational documents on the list, but if they=
do not addres= s these questions on how the encapsulation may be used (and how<= /span>
different lev= els of classification/re-classification will work), then the
encapsulation= spec has to stand on its own.  The charter could be interpreted<= /o:p>
either way.
 =

The encap format won't solve everything, however it creates a foundati= on to build upon.  Many of the problems will be solved at upper layers= , leveraging the encap in the data plane.

thanx.
 =
--  Kevi= n J. Ma
 =
From:=  Jim Guichard (jguicha= r) [mailto:jguichar@cisco.com] 
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org=
Subject: Re: Revis= ed SFC Charter
 
Hi Ke= vin,
 = ;
From= : Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguichar@cisco.com>, "nsc@ietf.o= rg" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter
 = ;
Hi Jim,
 
  There is a typo in item 3.  "is is" = -> "it is":
 
    "It is intended that the encapsula= tion be agnostic to the layer at which is is applied"
 = ;
Jim&g= t; yes, thank you, I corrected the text. 
 
  Wrt to the following text:
 
    "the same encapsulation may be use= d on a service function path realized at the network layer or at any other = layer"
 
  If the service function is an application layer ser= vice, and the
  encapsulation is at a lower layer (L2/L3), then pre= sumably signaling
  would be required between the application layer and= the lower layer
  responsible for encapsulation, so that individual p= ackets for an
  application layer message may be properly encapsula= ted.  Has this
  been discussed and/or is it considered in scope?
 = ;
Jim&g= t; the point here was to show that the steering function is independent of = the services layer. As packets traverse a service chain the encapsulation a= bove the steering function is used to indicate what service function to apply and which service function comes n= ext in the service function chain. 
 
  Though this sort of thing could be called an implem= entation detail,
 typically higher layers do not need to know the lowe= r layer details,
 but in this particular case, if the higher layer is = re-classifying,
 it likely wants/needs to know the ingress chain ID a= s it selects the
  egress chain ID, and then needs to tell the lo= wer encapsulation layer
 what the new egress chain ID should be?
 = ;
Jim&g= t; this would be part of the control plane which would make available to th= e service function (or proxy) information about inbound and outbound servic= e function chain encapsulation. 
 
thanx.
 
--  Kevin J. Ma
 
 
Greetings,=
 = ;
Thomas Narten and I have spent some time refining th= e SFC charter based upon discussion during the SFC BOF and several emails t= o the mailing list. We do not believe this is a substantive change; we have clarified the management vs. control= plane text and added text around security. Please review the revised = charter and provide comment.
 = ;
Revised= SFC WG Charter:
 = ;
Service de= livery is undergoing significant change with the introduction of virtualiza= tion, network overlays, and orchestration. Service delivery is currently bo= th a technical and an organizational challenge that involves significant modification to the network configurat= ion thereby impacting the speed at which services can be deployed and incre= asing operational costs. Services are typically implemented by the ordered = combination of a number of service functions that are deployed at different points within a network. Today, a= common deployment model has service functions physically inserted on the d= ata-forwarding path between communicating peers. Going forward, however, th= ere is a desire to move to a different model, where service functions, whether physical or virtualized, are not r= equired to reside on the direct data path and traffic is instead steered th= rough service functions, wherever they are deployed.  
 
For a given service, the abstracted view of the requ= ired service functions and the order in which they are to be applied is cal= led a Service Function Chain (SFC). An SFC is instantiated through selection of specific service function in= stances and the network nodes on which they are provided, thereby forming a= service graph: this is called a Service Function Path (SFP). The service f= unctions may be applied at any layer within the network protocol stack (network layer, application layer, etc.)= .  
 
The SFC working group will document a new approach t= o service delivery and operation. It will produce an architecture for servi= ce function chaining that includes the necessary protocols or protocol extensions to convey the service path and = service path information to nodes that are involved in the implementation o= f service functions and service function chains, as well as mechanisms for = steering traffic through service functions. The working group will examine what information needs to be gat= hered from the network and service functions in support of service function= chaining and how that information may be made available to the components = of the service function chaining architecture. The SFC WG will closely consider the security implicati= ons when documenting these deliverables. 
 
Specifically, the SFC WG is chartered to deliver the= following:
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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. <= /o:p>
2.  Architecture: This document will provide a description of the SFC architectural building blocks and their relations= hip including interconnection, placement of SFC specific capabilities, mana= gement, diagnostics, design analysis, and security models, as well as requi= rements on the protocol mechanisms. The initial scope is restricted to a single administrative domain, keeping= in mind that architectural decisions made for the intra-domain case may ha= ve implications for the inter-domain case.
3.  Generic SFC Encapsulation: This document will describe a single service-level data plane encapsulation format for c= onveying the service function chain and the service function path, and for = communicating context information between nodes that implement service func= tions and service function chains. It is intended that the encapsulation be agnostic to the layer at which is= is applied and the service that is being constructed. That is, the same en= capsulation may be used on a service function path realized at the network = layer or at any other layer, and the same encapsulation will apply for the construction of service function= paths regardless of the actual service.=
4.  Control Plane Mechanisms: A document will be developed to describe requirements for conveying information betwe= en control or management elements and SFC implementation points. All protoc= ol extension work resulting from these requirements should be carried out i= n the working group responsible for the protocol being modified in coordination with this working group, b= ut may be done in this working group under a revised charter after agreemen= t with all the relevant WG chairs and responsible ADs.
5.  Manageability: Work on the management and configuration of SFC components related to the support of service func= tion chaining will certainly be needed, but first needs to be better unders= tood and scoped.
 = ;
Proposed M= ilestones:
 = ;
Apr 2014
Submit to = IESG Informational document defining the SFC problem statement and core use= cases
Apr 2014
Consult wi= th OPS area on possible SFC charter modifications for management and config= uration of SFC components related to the support of service function chaini= ng
Jan 2015
Submit to = IESG Informational document defining the architecture for SFC
Jan 2015
Submit to = IESG Informational document defining the control plane requirements for con= veying information between control or management elements and SFC implement= ation points
Aug 2015
Submit to = IESG Standards Track document specifying the generic service function chain= ing header encapsulation
 = ;
_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc<= /a>

--_000_A62CEE67BB3448A1B78FFB996D582E1Bciscocom_-- From Ron_Parker@affirmednetworks.com Tue Nov 19 10:05:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34C51AE121 for ; Tue, 19 Nov 2013 10:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KotOAdpD9PJc for ; Tue, 19 Nov 2013 10:05:39 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id B74131AE119 for ; Tue, 19 Nov 2013 10:05:39 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Tue, 19 Nov 2013 10:05:33 -0800 From: Ron Parker To: "Paul Quinn (paulq)" , Kevin J Ma Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8A= Date: Tue, 19 Nov 2013 18:05:32 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A74EED0MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 18:05:44 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EED0MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EED0MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Kevin.

 <= /p>

Can you  explain you= r thinking on why service function chaining would be cognizant of the layer= at which the service function operates?   As I see it, any servi= ce function is free to modify the original packet in a manner that suits it.&= nbsp;  It also has the choice to allow the packet (modified or unmodif= ied) to progress on the original service function chain or to intercede wit= h the local service function chaining functionality such that it jumps onto a new chain.   In either case, the local= service function chaining functionality will cause the packet to be proper= ly encapsulated in order to be conveyed to the next service function (or fo= rwarded off the end of the chain, if applicable).

 <= /p>

   Ron

 <= /p>

 <= /p>

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 



Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

Personally, I am still unclear as to how this would work f= or application layer

services.  It's not a control plane issue if it's ses= sion data dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 



I won't rehash the previous discussion on "packet-lev= el" classification and

"packet-level" encapsulation, but IMO there are = a number of issues cited in

the problem statement which are not solved by simply defin= ing an encapsulation

header.  Yes, there are other informational documents= on the list, but if they

do not address these questions on how the encapsulation ma= y be used (and how

different levels of classification/re-classification will = work), then the

encapsulation spec has to stand on its own.  The char= ter could be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.



thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] 
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisys= tems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"=

 

Jim> yes, thank you, I corrected the= text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show that= the steering function is independent of the services layer. As packets tra= verse a service chain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 

Greetings= ,

 

Thomas Na= rten and I have spent some time refining the SFC charter based upon discuss= ion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the mana= gement vs. control plane text and added text around security. Please r= eview the revised charter and provide comment.

 

Revised SFC WG Charter:=

 

Service deliv= ery is undergoing significant change with the introduction of virtualizatio= n, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge that involves s= ignificant modification to the network configuration thereby impacting the = speed at which services can be deployed and increasing operational costs. S= ervices are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 =

For a given service, the abstracted view of the require= d service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 =

The SFC working group will document a new approach to s= ervice delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

Specifically, the SFC WG is chartered to deliver the fo= llowing:

1.<= span style=3D"font-size:7.0pt"> =  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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.<= span style=3D"font-size:7.0pt"> =  Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.<= span style=3D"font-size:7.0pt"> =  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= o:p>

4.<= span style=3D"font-size:7.0pt"> =  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.<= span style=3D"font-size:7.0pt"> =  Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defi= ning the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC char= ter modifications for management and configuration of SFC components relate= d to the support of service function chaining

Jan 2015

Submit to IESG Informational document defi= ning the architecture for SFC

Jan 2015

Submit to IESG Informational document defi= ning the control plane requirements for conveying information between contr= ol or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document sp= ecifying the generic service function chaining header encapsulation<= o:p>

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EED0MBX021W3CA2exch_-- From Ron_Parker@affirmednetworks.com Tue Nov 19 10:13:56 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BE1AE042 for ; Tue, 19 Nov 2013 10:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETJv-Xsrd2mw for ; Tue, 19 Nov 2013 10:13:51 -0800 (PST) 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 72A4F1ADFEF for ; Tue, 19 Nov 2013 10:13:51 -0800 (PST) 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.0158.001; Tue, 19 Nov 2013 10:13:45 -0800 From: Ron Parker To: Ken Gray , "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJorxEmwgADUiFCAAEIioA== Date: Tue, 19 Nov 2013 18:13:45 +0000 Message-ID: References: , <81b0e8326026418babc5a0f5a26a85fb@BL2PR05MB082.namprd05.prod.outlook.com> In-Reply-To: <81b0e8326026418babc5a0f5a26a85fb@BL2PR05MB082.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EEE8MBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 19 Nov 2013 18:13:56 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EEE8MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Ken. The approach proposed in draft-parker-sfc-chain-to-path does not assume a s= tateless load balancer. In contrast, it argues that nearly all real-world= load balancing is both stateful and service-function-specific. For that = reason, it is proposed that when the SFC is composed each abstract service = function is located to a single entity (i.e., abstract SFC A-->B-->C corres= ponds 1:1 to a concretely located A'-->B'-->C'). That single entity could= be any of a normal service function, a proxy service function, a stateful = service-function-specific load balancer, or a proxy stateful service-functi= on-specific load balancer. A chain could be comprised of any combination = of those types. Ron From: Ken Gray [mailto:kgray@juniper.net] Sent: Tuesday, November 19, 2013 1:00 PM To: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org Subject: RE: Revised SFC Charter Hi, Ron. I would think that every node in the chain post-PDP would need to "know" th= e path (we can argue about the word "know"). So, in the case of a single "= classifier" step, it's every node ... in the case where there are "proxies"= or new classification steps, new PDP (whatever) you need to "know" the pat= h on any intervening SF between PDP-N and PDP-N+1. As a specific comment on your doc, I would think that stateless lb potentia= lly goes away - an alternative implementation would just centralize this, d= istribute and update chains. ________________________________ From: nsc > on behalf of = Ron Parker > Sent: Monday, November 18, 2013 8:37 PM To: Jim Guichard (jguichar); nsc@ietf.org Subject: Re: [nsc] Revised SFC Charter Hi, Jim. The charter looks good. I do have a minor comment regarding the following= : Generic SFC Encapsulation: This document will describe a single service-lev= el data plane encapsulation format for conveying the service function chain= and the service function path, and for communicating context information b= etween nodes that implement service functions and service function chains. = It is intended that the encapsulation be agnostic to the layer at which is = is applied and the service that is being constructed. That is, the same enc= apsulation may be used on a service function path realized at the network l= ayer or at any other layer, and the same encapsulation will apply for the c= onstruction of service function paths regardless of the actual service. Specifically, the 'and' in the following phrase could be more limiting than= necessary: for conveying the service function chain and the service function path In draft-parker-sfc-chain-to-path (http://tools.ietf.org/html/draft-parker-= sfc-chain-to-path-00), it is proposed that neither th= e classifier (Policy Decision Point) nor the service nodes be aware of the = specific instances of a service function that is multiply instantiated. U= nder this approach, the service header would need only the chain informatio= n and not the path information. Thanks. Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 1. Problem Statement: This document will provide a summary of the probl= em space to be addressed by the SFC working group including example high-le= vel use cases. Additionally, the working group will normalize nomenclature = and definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC ar= chitectural building blocks and their relationship including interconnectio= n, placement of SFC specific capabilities, management, diagnostics, design = analysis, and security models, as well as requirements on the protocol mech= anisms. The initial scope is restricted to a single administrative domain, = keeping in mind that architectural decisions made for the intra-domain case= may have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single serv= ice-level data plane encapsulation format for conveying the service functio= n chain and the service function path, and for communicating context inform= ation between nodes that implement service functions and service function c= hains. It is intended that the encapsulation be agnostic to the layer at wh= ich is is applied and the service that is being constructed. That is, the s= ame encapsulation may be used on a service function path realized at the ne= twork layer or at any other layer, and the same encapsulation will apply fo= r the construction of service function paths regardless of the actual servi= ce. 4. Control Plane Mechanisms: A document will be developed to describe r= equirements for conveying information between control or management element= s and SFC implementation points. All protocol extension work resulting from= these requirements should be carried out in the working group responsible = for the protocol being modified in coordination with this working group, bu= t may be done in this working group under a revised charter after agreement= with all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC compo= nents related to the support of service function chaining will certainly be= needed, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EEE8MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Ken.

 <= /p>

The approach proposed in draft-parker-sfc-chain-to-path does not a= ssume a stateless load balancer.   In contrast, it argues that ne= arly all real-world load balancing is both stateful and service-function-sp= ecific.   For that reason, it is proposed that when the SFC is composed each abstrac= t service function is located to a single entity (i.e., abstract SFC A&agr= ave;BàC corresponds 1:1 to a concretely located A’àB’àC’= ;).   That single entity could be any of a normal service function, = a proxy service function, a stateful service-function-specific load balance= r, or a proxy stateful service-function-specific load balancer.  = A chain could be comprised of any combination of those types.

 <= /p>

   Ron

  

 <= /p>

From: Ken Gr= ay [mailto:kgray@juniper.net]
Sent: Tuesday, November 19, 2013 1:00 PM
To: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org
Subject: RE: Revised SFC Charter

 

Hi, Ron.

 

I would think that every node in the chain p= ost-PDP would need to "know" the path (we can argue about the wor= d "know").  So, in the case of a single "classifier&quo= t; step, it's every node ... in the case where there are "proxies" or new classifica= tion steps, new PDP (whatever) you need to "know" the path on any= intervening SF between PDP-N and PDP-N+1.

 

As a specific comment on your doc, I would t= hink that stateless lb potentially goes away - an alternative implementatio= n would just centralize this, distribute and update chains.

 

From: nsc <nsc-bounc= es@ietf.org> on behalf of Ron Parker <Ron_Parker@affirmednetworks.com>
Sent: Monday, November 18, 2013 8:37 PM
To: Jim Guichard (jguichar); nsc@iet= f.org
Subject: Re: [nsc] Revised SFC Charter

 

Hi, Jim.

 

The charter looks good.&n= bsp;  I do have a minor comment regarding the following:

Gen= eric SFC Encapsulation: This document will describe a single service-level = data plane encapsulation format for conveying the service function chain and the service function path, and for communicating contex= t information between nodes that implement service functions and service fu= nction chains. It is intended that the encapsulation be agnostic to the lay= er at which is is applied and the service that is being constructed. That is, the same encapsulation may be = used on a service function path realized at the network layer or at any oth= er layer, and the same encapsulation will apply for the construction of ser= vice function paths regardless of the actual service.=

Specifically, the ‘= and’ in the following phrase could be more limiting than necessary:

 

for= conveying the service function chain and the service function path<= span style=3D"color:#282828">

&nb= sp;

In draft-parker-sfc-chain= -to-path (http://tools.ietf.org/html/draft-parke= r-sfc-chain-to-path-00), it is proposed that neither the classifier (Policy Decision Point) nor the= service nodes be aware of the specific instances of a service function tha= t is multiply instantiated.   Under this approach, the service he= ader would need only the chain information and not the path information.

 

Thanks.

 

    Ron

 

 

 

From: nsc [mailto:n= sc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,=

 

Thomas Narten and I have spent some time refining the SFC charter based = upon discussion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clar= ified the management vs. control plane text and added text around security.= Please review the revised charter and provide comment.<= span style=3D"color:#282828">

 

Revised SFC WG Charter:

 

S= ervice delivery is undergoing significant change with the introduction of v= irtualization, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  

&= nbsp;

For a given service, the abstracted view of= the required service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  =

&= nbsp;

The SFC working group will document a new a= pproach to service delivery and operation. It will produce an architecture for service function chaining that includes the necessary pro= tocols or protocol extensions to convey the service path and service path i= nformation to nodes that are involved in the implementation of service func= tions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. 

 

Specifically, the SFC WG is chartered to de= liver the following:=

1.&nb= sp;    Problem State= ment: This document will provide a summary of the problem space to be addre= ssed by the SFC working group including example high-level use cases. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 

2.&nb= sp;    Architecture: This document will provide a des= cription of the SFC architectural building blocks and their relationship in= cluding interconnection, placement of SFC specific capabilities, management, diagnostics, design analysis, and security models, as well as = requirements on the protocol mechanisms. The initial scope is restricted to= a single administrative domain, keeping in mind that architectural decisio= ns made for the intra-domain case may have implications for the inter-domain case.

3.&nb= sp;    Generic SFC Encapsulation: This document will = describe a single service-level data plane encapsulation format for conveyi= ng the service function chain and the service function path, and for communicating context information between nodes that impleme= nt service functions and service function chains. It is intended that the e= ncapsulation be agnostic to the layer at which is is applied and the servic= e that is being constructed. That is, the same encapsulation may be used on a service function path realized= at the network layer or at any other layer, and the same encapsulation wil= l apply for the construction of service function paths regardless of the ac= tual service.

4.&nb= sp;    Control Plane Mechanisms: A document will be d= eveloped to describe requirements for conveying information between control= or management elements and SFC implementation points. All protocol extension work resulting from these requirements should be ca= rried out in the working group responsible for the protocol being modified = in coordination with this working group, but may be done in this working gr= oup under a revised charter after agreement with all the relevant WG chairs and responsible ADs.

5.&nb= sp;    Manageability: Work on the management and conf= iguration of SFC components related to the support of service function chai= ning will certainly be needed, but first needs to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational d= ocument defining the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possi= ble SFC charter modifications for management and configuration of SFC compo= nents related to the support of service function chaining

Jan 2015

Submit to IESG Informational d= ocument defining the architecture for SFC

Jan 2015

Submit to IESG Informational d= ocument defining the control plane requirements for conveying information b= etween control or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track= document specifying the generic service function chaining header encapsula= tion

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74EEE8MBX021W3CA2exch_-- From kevin.ma@azukisystems.com Tue Nov 19 22:27:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA2721AE342 for ; Tue, 19 Nov 2013 22:27:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0TKiTy4ksh6X for ; Tue, 19 Nov 2013 22:27:38 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACFF1AE33D for ; Tue, 19 Nov 2013 22:27:38 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8781F41684E; Wed, 20 Nov 2013 01:27:31 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 30FE4416830; Wed, 20 Nov 2013 01:27:30 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 20 Nov 2013 01:27:29 -0500 From: Kevin J Ma To: Ron Parker , "Paul Quinn (paulq)" Date: Wed, 20 Nov 2013 01:27:27 -0500 Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C768D9A4MAILR002maill_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 06:27:43 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D9A4MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D9A4MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Paul/Ron,

 

  My primary concern is with t= he word "packet".  If we are only considering

  network layer packets, with network layer classification= and encapsulation,

  then that is one thi= ng, but if we are talking about application layer

  classification, then network layer encapsulation poses and issue.&n= bsp; The data

  that comes out of a service = function is not necessarily the same data that

&= nbsp;went into the service function.  At the application layer, a sock= et is not

  inherently service chain aware.<= o:p>

 

=  If one bu= ilds a load balancer, AV scanner, etc. as an appliance (not part=

 of a router), today we have mechanisms for getting t= he traffic in and out

 of those appliances = by configuring VLANs and IP addresses (as noted in the

  problem statement, section 2, bullet 8).  If we want the = service chain ID

  in the encapsulation head= er to be the new mechanism, then these appliances

 need to know the ingress chain ID and the be able to set the egress= chain

 ID.  An off-the-shelf linux bo= x can support the existing IP mechanism.  It

  seems to me that a new encapsulation layer might exclude existing a= ppliance

  implementations and introduce a n= ew barrier to entry.

 

  Let me try a more concrete example:

=  

  Given a set of service chains that:= optionally terminates client-side TLS,

 pe= rforms HTTP request routing, optionally performs AV checks for HTTP POST,

 does server load balancing, and optionally = initiates back-end TLS:

 =

  --> FE_TLS --> RR --> AV --> LB --> BE_TLS -= ->

        =      /      \  =        ^  \

<= p class=3DMsoNormal>            / &n= bsp;      \      &nb= sp; /    \

  ---------+ =          +------+  &= nbsp;   +---------->

 

  Assume RR, AV, and LB are all services provided by= independent appliances,

 and FE_TLS and BE= _TLS are different instances of the same TLS service

<= p class=3DMsoNormal>  provided by a fourth independent appliance.  The possible c= hains are:

 

&nb= sp; chain 1:         RR,  &nbs= p;  LB

  chain 2:   &nbs= p;     RR, AV, LB

 = chain 3: FE_TLS, RR,     LB

=   chain 4: FE_TLS, RR, AV, LB

  chain 5= :         RR,    &nb= sp;LB, BE_TLS

  chain 6:    &= nbsp;    RR, AV, LB, BE_TLS

&= nbsp; chain 7: FE_TLS, RR,     LB, BE_TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would= always choose from either chain 1 or chain 3.

&n= bsp; (e.g., based on the TCP destination port).

<= o:p> 

  RR would then choose either chain (1= , 2) or chain (3, 4), respectively.

 

  LB would then choose either chain (1, 2, 5, 6) o= r chain (3, 4, 7, 8),

 respectively.

 

  The decisions m= ade by RR/LB seem unlikely to be made on an IP packet basis,

  yet still need to influence the chain ID encapsulation?<= o:p>

 

=   Now, TLS/= RR/LB might all be in the same appliance, but even so, the chain=

  to AV still has the same issue.

 

  So, I guess my question is: I= s this a valid DC use case for SFC?

 

thanx.

 

--  Kevin J. Ma

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> =

From: Ron Parker [mailto= :Ron_Parker@affirmednetworks.com]
Sent: Tuesday, November 19, 20= 13 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@i= etf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC C= harter

 

Hi, Kevin.

 

Can you  explain your thinking on why service function chaining would= be cognizant of the layer at which the service function operates? &nb= sp; As I see it, any service function is free to modify the original packet= in a manner that suits it.   It also has the choice to allow the= packet (modified or unmodified) to progress on the original service functi= on chain or to intercede with the local service function chaining functiona= lity such that it jumps onto a new chain.   In either case, the l= ocal service function chaining functionality will cause the packet to be pr= operly encapsulated in order to be conveyed to the next service function (o= r forwarded off the end of the chain, if applicable).

=

 

   Ron

=  

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Pa= ul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
= To: Kevin J Ma
Cc: nsc@ietf.o= rg; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Ch= arter

 

Hi Kevin,

 

 

On Nov 19, 2013, at = 10:15 AM, Kevin J Ma <kevin= .ma@azukisystems.com> wrote:

 

Jim> this = would be part of the control plane which would make available to the servic= e function (or proxy) information about inbound and outbound service functi= on chain encapsulation. 

 

Personally, I am still unclear as to ho= w this would work for application layer

 

 

<= div>

The control plane is responsible for the chai= ning/pathing aspect of SFC: conveying network locators for forwarding, allo= cating service header information and so on.  It is not responsible fo= r function specifics (e.g. per SFC policy).

 

&n= bsp;

 

 

I won't rehash the previous discussion on "packet-level" classif= ication and

"packet-level" e= ncapsulation, but IMO there are a number of issues cited in

the problem statement which are not solved by simply = defining an encapsulation

header. &nbs= p;Yes, there are other informational documents on the list, but if they

do not address these questions on how the= encapsulation may be used (and how

di= fferent levels of classification/re-classification will work), then the

encapsulation spec has to stand on its ow= n.  The charter could be interpreted

<= p class=3DMsoNormal>either way.

 

 <= /p>

The encap format won't solve everything,= however it creates a foundation to build upon.  Many of the problems = will be solved at upper layers, leveraging the encap in the data plane.

&= nbsp;

<= div>

thanx.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'> 

--  Kevin J. Ma

=

 

From: Jim Gui= chard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, November 19, 2013 9:39 AM
To: Kevin J Ma;&nb= sp;nsc@= ietf.org
Subject:&= nbsp;Re: Revised SFC Charter

=

 

Hi Kevin,

 =

From: Kevin J Ma <kevin.ma@azuk= isystems.com>
Date:=  Tuesday, November 19, 2013 1:25 AM
To: Jim Guichard <jguichar@cisco.com>, "= nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revised SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is" -> "it i= s":

 

    "It is intended th= at the encapsulation be agnostic to the layer at which is is applied"<= o:p>

 <= /p>

Jim> yes, thank you, I corrected = the text. 

 

  Wrt to the= following text:

 <= /o:p>

    "the same = encapsulation may be used on a service function path realized at the networ= k layer or at any other layer"

 

  If the s= ervice function is an application layer service, and the

  encapsulation is at a lower layer (L2/L3= ), then presumably signaling

=   would be required between the application layer and the lower layer<= o:p>

  responsible for encaps= ulation, so that individual packets for an

  application layer message may be properly encapsulated= .  Has this

  been = discussed and/or is it considered in scope?

=

 

Jim> the point here was to show that the steering function is in= dependent of the services layer. As packets traverse a service chain the en= capsulation above the steering function is used to indicate what service fu= nction to apply and which service function comes next in the service functi= on chain. 

 

  Though thi= s sort of thing could be called an implementation detail,

 typically higher layers do not need to k= now the lower layer details,

=  but in this particular case, if the higher layer is re-classifying,

 it likely wants/needs to= know the ingress chain ID as it selects the

  egress chain ID, and then needs to tell the low= er encapsulation layer

 = what the new egress chain ID should be?

 

Jim> this would be part of the control plane which would make avai= lable to the service function (or proxy) information about inbound and outb= ound service function chain encapsulation. 

 

thanx.

 =

--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To:=  nsc@ietf.org
Subjec= t: [nsc] Revised SFC Ch= arter

&nbs= p;

Greetings,

 

Thomas Narten and I have spent some time refining th= e SFC charter based upon discussion during the SFC BOF and several emails t= o the mailing list. We do not believe this is a substantive change; we have= clarified the management vs. control plane text and added text around secu= rity. Please review the revised charter and provide comment.

 =

Revised SFC WG Charter:

 =

Ser= vice delivery is undergoing significant change with the introduction of vir= tualization, network overlays, and orchestration. Service delivery is curre= ntly both a technical and an organizational challenge that involves signifi= cant modification to the network configuration thereby impacting the speed = at which services can be deployed and increasing operational costs. Service= s are typically implemented by the ordered combination of a number of servi= ce functions that are deployed at different points within a network. Today,= a common deployment model has service functions physically inserted on the= data-forwarding path between communicating peers. Going forward, however, = there is a desire to move to a different model, where service functions, wh= ether physical or virtualized, are not required to reside on the direct dat= a path and traffic is instead steered through service functions, wherever t= hey are deployed.  

 

For a given = service, the abstracted view of the required service functions and the orde= r in which they are to be applied is called a Service Function Chain (SFC).=  An SFC is instantiated through selection of specific service fun= ction instances and the network nodes on which they are provided, thereby f= orming a service graph: this is called a Service Function Path (SFP). The s= ervice functions may be applied at any layer within the network protocol st= ack (network layer, application layer, etc.).  

 =

The SFC working group will document a new approach to= service delivery and operation. It will produce an architecture for servic= e function chaining that includes the necessary protocols or protocol exten= sions to convey the service path and service path information to nodes that= are involved in the implementation of service functions and service functi= on chains, as well as mechanisms for steering traffic through service funct= ions. The working group will examine what information needs to be gathered = from the network and service functions in support of service function chain= ing and how that information may be made available to the components of the= service function chaining architecture. The SFC WG will closely consi= der the security implications when documenting these deliverables. 

 

Specifically, the SFC WG is chartered to deliver the foll= owing:

1.  Problem Statement: This document will provide a summary of t= he problem space to be addressed by the SFC working group including example= high-level use cases. Additionally, the working group will normalize nomen= clature and definitions for service function chaining. <= o:p>

2.  Architecture: This document will prov= ide a description of the SFC architectural building blocks and their relati= onship including interconnection, placement of SFC specific capabilities, m= anagement, diagnostics, design analysis, and security models, as well as re= quirements on the protocol mechanisms. The initial scope is restricted to a= single administrative domain, keeping in mind that architectural decisions= made for the intra-domain case may have implications for the inter-domain = case.

3.  Generic SFC Encapsula= tion: This document will describe a single service-level data plane encapsu= lation format for conveying the service function chain and the service func= tion path, and for communicating context information between nodes that imp= lement service functions and service function chains. It is intended that t= he encapsulation be agnostic to the layer at which is is applied and the se= rvice that is being constructed. That is, the same encapsulation may be use= d on a service function path realized at the network layer or at any other = layer, and the same encapsulation will apply for the construction of servic= e function paths regardless of the actual service.

4.  Control Plane Mechanisms: A document will be developed= to describe requirements for conveying information between control or mana= gement elements and SFC implementation points. All protocol extension work = resulting from these requirements should be carried out in the working grou= p responsible for the protocol being modified in coordination with this wor= king group, but may be done in this working group under a revised charter a= fter agreement with all the relevant WG chairs and responsible ADs.<= o:p>

5.  Manageability: Work on the management= and configuration of SFC components related to the support of service func= tion chaining will certainly be needed, but first needs to be better unders= tood and scoped.

=  <= /span>

Proposed Milestones:<= /span>

 =

Apr 2014

Submit to IESG Informational document defining the SFC = problem statement and core use cases

=

Apr 2014

Consult= with OPS area on possible SFC charter modifications for management and con= figuration of SFC components related to the support of service function cha= ining

Jan 2015=

Submit to IESG Informational document = defining the architecture for SFC

Jan 2015

= Submit to = IESG Informational document defining the control plane requirements for con= veying information between control or management elements and SFC implement= ation points

Aug 2015=

Submit to IESG Standards Track = document specifying the generic service function chaining header encapsulat= ion

 <= o:p>

___= ____________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C768D9A4MAILR002maill_-- From Ron_Parker@affirmednetworks.com Wed Nov 20 06:02:54 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FA7D1ADF92 for ; Wed, 20 Nov 2013 06:02:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tHpHBDkIQ1G for ; Wed, 20 Nov 2013 06:02:47 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 2540E1ADF8F for ; Wed, 20 Nov 2013 06:02:47 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 06:02:41 -0800 From: Ron Parker To: Kevin J Ma , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAhKag Date: Wed, 20 Nov 2013 14:02:39 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A74F586MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 14:02:54 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74F586MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Kevin. Thanks for the thoughtful analysis. Responses below. Ron From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Wednesday, November 20, 2013 1:27 AM To: Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Ron>> I don't doubt that development is required to support the new mechani= sms, natively. In draft-parker-sfc-chain-to-path, section 3.1, an SFC pro= xy is introduced to front-end legacy implementations. The SFC proxy could= conceivably be co-located with the legacy service function or could stand = alone. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Ron>> I don't see a limitation here. The RR/LB can use stateful flow anal= ysis, local policy, or any other techniques to manage the selection of chai= n for any packets that are transmitted by the RR/LB. Such packets are not= limited to packets that are received by the RR/LB (i.e., it is entirely pe= rmissible to create new flows). Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. Ron>> The multiple logical service functions could each be located to the s= ame IP address (which does, indeed have implications on the SFC service hea= der - it needs to carry both the chain ID and the hop ID within the chain s= o that the composite service function may understand which is the initial s= ervice function to apply). So, I guess my question is: Is this a valid DC use case for SFC? Ron>> I consider your use case entirely valid and exactly what I have in mi= nd when I think about SFC. Implementation issues will always exist, but t= hat is why we are employed :). I think your concerns may have been whethe= r SFC is restricted to a packet-in-packet-out type of model. In my opinio= n, it is not. A service function is free to create new flows that have no= exact correspondence to incoming flows and to subject those new flows to a= ny service chain (or none) independently. Ron>> All of this does bring up an area, in my mind, that requires further= attention by the group, and perhaps this was on your mind, too. How to h= andle the reverse direction flows? In the simple case, where we have a li= near chain with no branching and no flow creation, we could conceivably arr= ange the single classifier to see the packets upon entry to the domain in b= oth directions. If the classifier is stateful, it can easily manage rever= se propagation down the chains (i.e., upstream A, B, C; downstream C, B, A)= . But, if new flows are created at a service function, and properly stamp= ed by the service function with the correct chain information, the correspo= nding reverse flows don't enter the domain at the service function, so wher= e is the logic to place those flows on the proper reverse chain? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74F586MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Kevin.

 <= /p>

Thanks for the thoughtful= analysis.  Responses below.

 <= /p>

   Ron

 <= /p>

From: Kevin = J Ma [mailto:kevin.ma@azukisystems.com]
Sent: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi Paul/Ron,

 

  My primary concern is with the word "packet&qu= ot;.  If we are only considering

  network layer packets, with network layer classific= ation and encapsulation,

  then that is one thing, but if we are talking about= application layer

  classification, then network layer encapsulation po= ses and issue.  The data

  that comes out of a service function is not necessa= rily the same data that

 went into the service function.  At the applica= tion layer, a socket is not

  inherently service chain aware.

 

 If one builds a load balancer, AV scanner, etc. as a= n appliance (not part

 of a router), today we have mechanisms for getting t= he traffic in and out

 of those appliances by configuring VLANs and IP addr= esses (as noted in the

  problem statement, section 2, bullet 8).  If w= e want the service chain ID

  in the encapsulation header to be the new mechanism= , then these appliances

 need to know the ingress chain ID and the be able to= set the egress chain

 ID.  An off-the-shelf linux box can support the= existing IP mechanism.  It

  seems to me that a new encapsulation layer might ex= clude existing appliance

  implementations and introduce a new barrier to entr= y.

 <= /p>

Ron>> I don’t= doubt that development is required to support the new mechanisms, natively= .   In draft-parker-sfc-chain-to-path, section 3.1, an SFC proxy = is introduced to front-end legacy implementations.   The SFC proxy = could conceivably be co-located with the legacy service function or could s= tand alone.

 <= /p>

 

  Let me try a more concrete example:

 

  Given a set of service chains that: optionally term= inates client-side TLS,

 performs HTTP request routing, optionally performs A= V checks for HTTP POST,

 does server load balancing, and optionally initiates= back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> = BE_TLS -->

          &nb= sp;  /      \     &n= bsp;    ^  \

          &nb= sp; /        \    &n= bsp;   /    \

  ---------+       =    +------+      +-----= ----->

 

  Assume RR, AV, and LB are all services provided by = independent appliances,

 and FE_TLS and BE_TLS are different instances of the= same TLS service

  provided by a fourth independent appliance.  T= he possible chains are:

 

  chain 1:        =  RR,     LB

  chain 2:        =  RR, AV, LB

  chain 3: FE_TLS, RR,     LB

  chain 4: FE_TLS, RR, AV, LB

  chain 5:        =  RR,     LB, BE_TLS

  chain 6:        =  RR, AV, LB, BE_TLS

  chain 7: FE_TLS, RR,     LB, BE= _TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would always choose from eit= her chain 1 or chain 3.

  (e.g., based on the TCP destination port).

 

  RR would then choose either chain (1, 2) or chain (= 3, 4), respectively.

 

  LB would then choose either chain (1, 2, 5, 6) or c= hain (3, 4, 7, 8),

 respectively.

 

  The decisions made by RR/LB seem unlikely to be mad= e on an IP packet basis,

  yet still need to influence the chain ID encapsulat= ion?

 <= /p>

Ron>> I don’t= see a limitation here.   The RR/LB can use stateful flow analysi= s, local policy, or any other techniques to manage the selection of chain f= or any packets that are transmitted by the RR/LB.   Such packets ar= e not limited to packets that are received by the RR/LB (i.e., it is entire= ly permissible to create new flows).

 

  Now, TLS/RR/LB might all be in the same appliance, = but even so, the chain

  to AV still has the same issue.

 <= /p>

Ron>> The multiple = logical service functions could each be located to the same IP address (whi= ch does, indeed have implications on the SFC service header – it needs to carry both the chain ID and the hop ID within the chain so tha= t the composite service function may understand which is the initial servic= e function to apply).

 

  So, I guess my question is: Is this a valid DC use = case for SFC?

 <= /p>

Ron>> I consider yo= ur use case entirely valid and exactly what I have in mind when I think abo= ut SFC.   Implementation issues will always exist, but that is why we are employed :).   I think your concerns may have been wh= ether SFC is restricted to a packet-in-packet-out type of model.  = ; In my opinion, it is not.   A service function is free to creat= e new flows that have no exact correspondence to incoming flows and to subject those new flows to any service chain (or none) independentl= y.  

 <= /p>

Ron>>  All of = this does bring up an area, in my mind, that requires further attention by = the group, and perhaps this was on your mind, too.   How to handl= e the reverse direction flows?   In the simple case, where we have= a linear chain with no branching and no flow creation, we could conceivabl= y arrange the single classifier to see the packets upon entry to the domain= in both directions.   If the classifier is stateful, it can easily manage reverse propagation down the chains (i.e., = upstream A, B, C; downstream C, B, A).   But, if new flows are cr= eated at a service function, and properly stamped by the service function w= ith the correct chain information, the corresponding reverse flows don’t enter the domain at the service function, so whe= re is the logic to place those flows on the proper reverse chain?

 <= /p>

 

thanx.

 

--  Kevin J. Ma

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 <= /p>

Can you  explain you= r thinking on why service function chaining would be cognizant of the layer= at which the service function operates?   As I see it, any servi= ce function is free to modify the original packet in a manner that suits it.&= nbsp;  It also has the choice to allow the packet (modified or unmodif= ied) to progress on the original service function chain or to intercede wit= h the local service function chaining functionality such that it jumps onto a new chain.   In either case, the local= service function chaining functionality will cause the packet to be proper= ly encapsulated in order to be conveyed to the next service function (or fo= rwarded off the end of the chain, if applicable).

 <= /p>

   Ron

 <= /p>

 <= /p>

From: nsc [<= a href=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wro= te:

 

Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

Personally, I am still unclear as to how this would work f= or application layer

services.  It's not a control plane issue if it's ses= sion data dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 

 

I won't rehash the previous discussion on "packet-lev= el" classification and

"packet-level" encapsulation, but IMO there are = a number of issues cited in

the problem statement which are not solved by simply defin= ing an encapsulation

header.  Yes, there are other informational documents= on the list, but if they

do not address these questions on how the encapsulation ma= y be used (and how

different levels of classification/re-classification will = work), then the

encapsulation spec has to stand on its own.  The char= ter could be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] 
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisys= tems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"=

 

Jim> yes, thank you, I corrected the= text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show that= the steering function is independent of the services layer. As packets tra= verse a service chain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 

Greetings= ,

 

Thomas Na= rten and I have spent some time refining the SFC charter based upon discuss= ion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the mana= gement vs. control plane text and added text around security. Please r= eview the revised charter and provide comment.

 

Revised SFC WG Charter:=

 

Service deliv= ery is undergoing significant change with the introduction of virtualizatio= n, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge that involves s= ignificant modification to the network configuration thereby impacting the = speed at which services can be deployed and increasing operational costs. S= ervices are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 =

For a given service, the abstracted view of the require= d service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 =

The SFC working group will document a new approach to s= ervice delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

Specifically, the SFC WG is chartered to deliver the fo= llowing:

1.<= span style=3D"font-size:7.0pt"> =  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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.<= span style=3D"font-size:7.0pt"> =  Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.<= span style=3D"font-size:7.0pt"> =  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= o:p>

4.<= span style=3D"font-size:7.0pt"> =  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.<= span style=3D"font-size:7.0pt"> =  Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defi= ning the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC char= ter modifications for management and configuration of SFC components relate= d to the support of service function chaining

Jan 2015

Submit to IESG Informational document defi= ning the architecture for SFC

Jan 2015

Submit to IESG Informational document defi= ning the control plane requirements for conveying information between contr= ol or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document sp= ecifying the generic service function chaining header encapsulation<= o:p>

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A74F586MBX021W3CA2exch_-- From smkumar@cisco.com Wed Nov 20 07:02:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98D51ADF8E for ; Wed, 20 Nov 2013 07:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 3eG_vBIkQCKk for ; Wed, 20 Nov 2013 07:02:15 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 716AB1ADF5D for ; Wed, 20 Nov 2013 07:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61811; q=dns/txt; s=iport; t=1384959728; x=1386169328; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=kPmzB8YZq1ehbFx/thuUy/r/2vEQ3Pb3ggeXkD0uwlw=; b=GDUQnfg9BUBUSHH4OBZUSGJS+TkXjUXyCe9RjIuMeb9aZzIzNpnYhEq8 IsMbptoLPV6z7wz+qv450GjCvOYoeZ9wt4kqW+w0XU9XK7/llCjX5wm5o KLOtHsm1I7A7yuMuCQgTSlNPGL3xBrP7HaD1jNIBrq+rN9LmGXiFI8YOC g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAIvNjFKtJV2b/2dsb2JhbABZgkNEOFO+a4EWFnSCJQEBAQQBAQEXDQY4AgcEBxIBCBEBAgEBASEBBi4LFAMGCAIEAQ0FiAENwCgXjywHEw0EBgECBAOEKQOUMINigS+LKIU2gyiCKg X-IronPort-AV: E=Sophos;i="4.93,737,1378857600"; d="scan'208,217";a="286161072" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 20 Nov 2013 15:02:06 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAKF26Vd025812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 15:02:06 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 09:02:05 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma , Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAe/YA Date: Wed, 20 Nov 2013 15:02:05 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.127.182] Content-Type: multipart/alternative; boundary="_000_CEB20A7027BA3smkumarciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 15:02:20 -0000 --_000_CEB20A7027BA3smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kevin, Comments inline. From: Kevin J Ma > Date: Tuesday, November 19, 2013 10:27 PM To: Ron Parker >, "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. When a classification supports layer7, it has to look at the data stre= am. There is no assumption that it is L3 based. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Well, there is more it than just putting a service path id into the he= ader/pkt. To construct service chains, you need a non-local view of service= functions. A service controller provides such a view to enables the constr= uction of service chains. In that sense, there is already a need for co-ord= ination of these service chain/path identifiers with a control entity. We'v= e moved past VLAN stitching =96 reason we are on this list :) Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? It is a valid use case. Surendra. thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CEB20A7027BA3smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <02F8C1A790BB4B47935C0B4313EA2738@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Kevin,

Comments inline.

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, November 19, 2013 10= :27 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>,= "Paul Quinn (paulq)" <paul= q@cisco.com>
Cc: "nsc@ietf.org" <nsc@ietf.= org>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: Re: [nsc] Revised SFC Char= ter

Hi Paul/Ron,

 

  My primary concern is with the word "packet".&nb= sp; If we are only considering

  network layer packets, with network layer classification a= nd encapsulation,

  then that is one thing, but if we are talking about applic= ation layer

  classification, then network layer encapsulation poses and= issue.  The data

  that comes out of a service function is not necessarily th= e same data that

 went into the service function.  At the application la= yer, a socket is not

  inherently service chain aware.
<SK> When a classification supports layer7, it has to look at th= e data stream. There is no assumption that it is L3 based.

 

 If one builds a load balancer, AV scanner, etc. as an appli= ance (not part

 of a router), today we have mechanisms for getting the traf= fic in and out

 of those appliances by configuring VLANs and IP addresses (= as noted in the

  problem statement, section 2, bullet 8).  If we want = the service chain ID

  in the encapsulation header to be the new mechanism, then = these appliances

 need to know the ingress chain ID and the be able to set th= e egress chain

 ID.  An off-the-shelf linux box can support the existi= ng IP mechanism.  It

  seems to me that a new encapsulation layer might exclude e= xisting appliance

  implementations and introduce a new barrier to entry.
<SK> Well, there is more it than just putting a service path id = into the header/pkt. To construct service chains, you need a non-local view= of service functions. A service controller provides such a view to enables= the construction of service chains. In that sense, there is already a need for co-ordination of these service cha= in/path identifiers with a control entity. We've moved past VLAN stitching = =96 reason we are on this list :)

 

  Let me try a more concrete example:

 

  Given a set of service chains that: optionally terminates = client-side TLS,

 performs HTTP request routing, optionally performs AV check= s for HTTP POST,

 does server load balancing, and optionally initiates back-e= nd TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> BE_TLS = -->

           &nbs= p; /      \      &nb= sp;   ^  \

           &nbs= p;/        \     &nb= sp;  /    \

  ---------+        &= nbsp; +------+      +----------&g= t;

 

  Assume RR, AV, and LB are all services provided by indepen= dent appliances,

 and FE_TLS and BE_TLS are different instances of the same T= LS service

  provided by a fourth independent appliance.  The poss= ible chains are:

 

  chain 1:         R= R,     LB

  chain 2:         R= R, AV, LB

  chain 3: FE_TLS, RR,     LB=

  chain 4: FE_TLS, RR, AV, LB

  chain 5:         R= R,     LB, BE_TLS

  chain 6:         R= R, AV, LB, BE_TLS

  chain 7: FE_TLS, RR,     LB, BE_TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would always choose from either cha= in 1 or chain 3.

  (e.g., based on the TCP destination port).

 

  RR would then choose either chain (1, 2) or chain (3, 4), = respectively.

 

  LB would then choose either chain (1, 2, 5, 6) or chain (3= , 4, 7, 8),

 respectively.

 

  The decisions made by RR/LB seem unlikely to be made on an= IP packet basis,

  yet still need to influence the chain ID encapsulation?

 

  Now, TLS/RR/LB might all be in the same appliance, but eve= n so, the chain

  to AV still has the same issue.

 

  So, I guess my question is: Is this a valid DC use case fo= r SFC?
<SK> It is a valid use case.

Surendra.

 

thanx.

 

--  Kevin J. Ma

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 

Can you  explain your thinkin= g on why service function chaining would be cognizant of the layer at which= the service function operates?   As I see it, any service function is free to modify the original packet in a manner= that suits it.   It also has the choice to allow the packet (mod= ified or unmodified) to progress on the original service function chain or = to intercede with the local service function chaining functionality such that it jumps onto a new chain.   In= either case, the local service function chaining functionality will cause = the packet to be properly encapsulated in order to be conveyed to the next = service function (or forwarded off the end of the chain, if applicable).

 

   Ron=

 

 

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wro= te:

 

Jim> this would be part of the control plane which wou= ld make available to the service function (or proxy) information about inbo= und and outbound service function chain encapsulation. 

 

Personally, I am still unclear as to how this would work for appl= ication layer

services.  It's not a control plane issue if it's session da= ta dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 

 

I won't rehash the previous discussion on "packet-level"= ; classification and

"packet-level" encapsulation, but IMO there are a numbe= r of issues cited in

the problem statement which are not solved by simply defining an = encapsulation

header.  Yes, there are other informational documents on the= list, but if they

do not address these questions on how the encapsulation may be us= ed (and how

different levels of classification/re-classification will work), = then the

encapsulation spec has to stand on its own.  The charter cou= ld be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: = Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"=

 

Jim> yes, thank you, I corrected the text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show that the steering func= tion is independent of the services layer. As packets traverse a service ch= ain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the control plane which wou= ld make available to the service function (or proxy) information about inbo= und and outbound service function chain encapsulation. 

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 

Greetings,=

 

Thomas Narten and I have spen= t some time refining the SFC charter based upon discussion during the SFC B= OF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the mana= gement vs. control plane text and added text around security. Please r= eview the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is undergoing si= gnificant change with the introduction of virtualization, network overlays,= and orchestration. Service delivery is currently both a technical and an organizational challenge that involves s= ignificant modification to the network configuration thereby impacting the = speed at which services can be deployed and increasing operational costs. S= ervices are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 

= For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 

= The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

= Specifically, the SFC WG is chartered to deliver the following:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.  Architec= ture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= o:p>

4.  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.  Manageab= ility: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defining the SFC problem= statement and core use cases

Apr 2014

Consult with OPS area on possible SFC charter modifications fo= r management and configuration of SFC components related to the support of = service function chaining

Jan 2015

Submit to IESG Informational document defining the architectur= e for SFC

Jan 2015

Submit to IESG Informational document defining the control pla= ne requirements for conveying information between control or management ele= ments and SFC implementation points

Aug 2015

Submit to IESG Standards Track document specifying the generic= service function chaining header encapsulation

 

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

 

 --_000_CEB20A7027BA3smkumarciscocom_-- From kevin.ma@azukisystems.com Wed Nov 20 07:46:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E82E91AE047 for ; Wed, 20 Nov 2013 07:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zA7PRNn5nWG3 for ; Wed, 20 Nov 2013 07:46:22 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9161ADFE3 for ; Wed, 20 Nov 2013 07:46:20 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AFA858BDC9A; Wed, 20 Nov 2013 10:46:13 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 1C1C28BF579; Wed, 20 Nov 2013 10:46:08 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Wed, 20 Nov 2013 10:46:08 -0500 From: Kevin J Ma To: Ron Parker , "Paul Quinn (paulq)" Date: Wed, 20 Nov 2013 10:46:05 -0500 Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAhKaggAAcMsA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C790F7BF@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C790F7BFMAILR002maill_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 15:46:32 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7BFMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, > Ron>> ... I think your concerns may have been whether SFC is restricted = to a packet-in-packet-out type of model. In my opinion, it is not. A se= rvice function is free to create new flows that have no exact correspondenc= e to incoming flows and to subject those new flows to any service chain (or= none) independently. The packet-based nature was my primary concern, yes. Good to know its no= t just packet-based. My secondary concern is whether or not these new flows that are created are really considered part of the same chain, or whether the new flows are just part of completely independent chains (the latter always being possible)? Using a single chain has the value of a defined path/order and the greate= r possibility of reuse (by AV/LB) of classification information (obtained initially by RR). However, in this case, the first hop of FE_TLS or not i= s arguably of limited value to RR, and the chain past RR is arguably of lim= ited value to the ingress node thats just classifying port (443 vs 80). I ass= ume that any/all combinations of single/multi chain would be allowed, and lef= t up to the operator doing the deployment? > Ron>> I don't doubt that development is required to support the new mecha= nisms, natively. This I'm not so sure about. Something has to understand the encapsulatio= n header? Depending on where the header sits, a stock network stack may ju= st throw the packet away? It may end up being an "implementation detail", b= ut I just bring up that for those running on a stock linux distribution, thi= s is a concern/consideration that is hopefully not overlooked in the design of the encapsulation header. > Ron>> All of this does bring up an area, in my mind, that requires furth= er attention by the group, and perhaps this was on your mind, too. How to= handle the reverse direction flows? With the scenario below, yes, I was also wondering about the return flows= . The return flow needs to come back through BE_TLS and eventually FE_TLS, possibly through alternate middle service, but I guess I assumed it would be a completely independent chain, rather than the reverse path of the ingress chain (where in the degenerate case, the reverse path could be an independently defined set of chains)? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Wednesday, November 20, 2013 9:03 AM To: Kevin J Ma; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Thanks for the thoughtful analysis. Responses below. Ron From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Wednesday, November 20, 2013 1:27 AM To: Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Ron>> I don't doubt that development is required to support the new mechani= sms, natively. In draft-parker-sfc-chain-to-path, section 3.1, an SFC pro= xy is introduced to front-end legacy implementations. The SFC proxy could= conceivably be co-located with the legacy service function or could stand = alone. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Ron>> I don't see a limitation here. The RR/LB can use stateful flow anal= ysis, local policy, or any other techniques to manage the selection of chai= n for any packets that are transmitted by the RR/LB. Such packets are not= limited to packets that are received by the RR/LB (i.e., it is entirely pe= rmissible to create new flows). Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. Ron>> The multiple logical service functions could each be located to the s= ame IP address (which does, indeed have implications on the SFC service hea= der - it needs to carry both the chain ID and the hop ID within the chain s= o that the composite service function may understand which is the initial s= ervice function to apply). So, I guess my question is: Is this a valid DC use case for SFC? Ron>> I consider your use case entirely valid and exactly what I have in mi= nd when I think about SFC. Implementation issues will always exist, but t= hat is why we are employed :). I think your concerns may have been whethe= r SFC is restricted to a packet-in-packet-out type of model. In my opinio= n, it is not. A service function is free to create new flows that have no= exact correspondence to incoming flows and to subject those new flows to a= ny service chain (or none) independently. Ron>> All of this does bring up an area, in my mind, that requires further= attention by the group, and perhaps this was on your mind, too. How to h= andle the reverse direction flows? In the simple case, where we have a li= near chain with no branching and no flow creation, we could conceivably arr= ange the single classifier to see the packets upon entry to the domain in b= oth directions. If the classifier is stateful, it can easily manage rever= se propagation down the chains (i.e., upstream A, B, C; downstream C, B, A)= . But, if new flows are created at a service function, and properly stamp= ed by the service function with the correct chain information, the correspo= nding reverse flows don't enter the domain at the service function, so wher= e is the logic to place those flows on the proper reverse chain? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7BFMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ron,

> Ron>>  ...= I think your concerns may have been whether SFC is restricted to a packet-= in-packet-out type of model.   In my opinion, it is not. &nb= sp; A service function is free to create new flows that have no exact corre= spondence to incoming flows and to subject those new flows to any service c= hain (or none) independently.

 

  The packet-based nature was my primary concern, yes.  Goo= d to know its not

 just packet-based. = My secondary concern is whether or not these new flows

  that are created are really considered part of the same chain= , or whether

  the new flows are just part o= f completely independent chains (the latter

&n= bsp;always being possible)?

 

  Using a single chain has the value of a defined path/ord= er and the greater

  possibility of reuse (b= y AV/LB) of classification information (obtained

=  initially by RR).  However, in this case, the first hop of FE_T= LS or not is

  arguably of limited value to = RR, and the chain past RR is arguably of limited

=   value to the ingress node thats just classifying port (443 vs 80).&n= bsp; I assume

  that any/all combinations of= single/multi chain would be allowed, and left

&n= bsp; up to the operator doing the deployment?

 

> Ron>> I don’t = doubt that development is required to support the new mechanisms, natively.=

 

  This I'm not so s= ure about.  Something has to understand the encapsulation

  header?  Depending on where the header sits, a st= ock network stack may just

  throw the packe= t away?  It may end up being an "implementation detail", but=

  I just bring up that for those running on= a stock linux distribution, this

  is a con= cern/consideration that is hopefully not overlooked in the design

  of the encapsulation header.

<= p class=3DMsoNormal> 

> Ron>>  A= ll of this does bring up an area, in my mind, that requires further attenti= on by the group, and perhaps this was on your mind, too.   How to= handle the reverse direction flows?   

&nb= sp;

  With the scenario below, yes, I was also wo= ndering about the return flows.

<= span style=3D'font-size:10.0pt;font-family:"Courier New"'>  The return= flow needs to come back through BE_TLS and eventually FE_TLS,

  possibly through alternate middle service, but I guess= I assumed it would

  be a completely inde= pendent chain, rather than the reverse path of the

  independently defined set of chain= s)?

 

thanx.<= /o:p>

 

--  Kevin J. Ma<= o:p>

 

=

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com= ]
Sent: Wednesday, November 20, 2013 9:03 AM
To: Kevin= J Ma; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguicha= r)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 = ;

Thanks for the thoughtful ana= lysis.  Responses below.

 

   Ro= n

 =

From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
Sen= t: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul = Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter=

 

Hi Paul/Ron,

 

  network layer pack= ets, with network layer classification and encapsulation,=

  then that is one thing, but if we are talking about applica= tion layer

  classification, then network la= yer encapsulation poses and issue.  The data

  that comes out of a service function is not necessarily the same da= ta that

 went into the service function.&nbs= p; At the application layer, a socket is not

&nb= sp; inherently service chain aware.

 

 If one builds a load balancer, AV scanner, etc. a= s an appliance (not part

 of a router), toda= y we have mechanisms for getting the traffic in and out

 of those appliances by configuring VLANs and IP addresses (as = noted in the

  problem statement, section 2,= bullet 8).  If we want the service chain ID

  in the encapsulation header to be the new mechanism, then these app= liances

 need to know the ingress chain ID a= nd the be able to set the egress chain

 ID.&= nbsp; An off-the-shelf linux box can support the existing IP mechanism.&nbs= p; It

  seems to me that a new encapsulation= layer might exclude existing appliance

  im= plementations and introduce a new barrier to entry.

 

= Ron>> I don’t doubt that development is required to supp= ort the new mechanisms, natively.   In draft-parker-sfc-chain-to-= path, section 3.1, an SFC proxy is introduced to front-end legacy implement= ations.   The SFC proxy could conceivably be co-located with the = legacy service function or could stand alone.

 

 

  Let me try a more concrete example:

=

 

  Given a set of service chains = that: optionally terminates client-side TLS,

&nb= sp;performs HTTP request routing, optionally performs AV checks for HTTP PO= ST,

 does server load balancing, and optiona= lly initiates back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> BE_T= LS -->

       &n= bsp;     /      \ &n= bsp;        ^  \<= /p>

            = /        \      = ;  /    \

  -------= --+          +------+ &nb= sp;    +---------->

 =

  Assume RR, AV, and LB are all services provide= d by independent appliances,

 and FE_TLS and= BE_TLS are different instances of the same TLS service

  provided by a fourth independent appliance.  The possibl= e chains are:

 

&n= bsp; chain 1:         RR,  &nb= sp;  LB

  chain 2:   &nb= sp;     RR, AV, LB

&nb= sp; chain 3: FE_TLS, RR,     LB

  chai= n 5:         RR,    =  LB, BE_TLS

  chain 6:   &nbs= p;     RR, AV, LB, BE_TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification wo= uld always choose from either chain 1 or chain 3.

  (e.g., based on the TCP destination port).

  RR would then choose either chain= (1, 2) or chain (3, 4), respectively.

 = ;

  LB would then choose either chain (1, 2, 5, 6= ) or chain (3, 4, 7, 8),

 respectively.=

 

  The decisions= made by RR/LB seem unlikely to be made on an IP packet basis,

  yet still need to influence the chain ID encapsulation= ?

 =

Ron>> I don’t see a limitation = here.   The RR/LB can use stateful flow analysis, local policy, o= r any other techniques to manage the selection of chain for any packets tha= t are transmitted by the RR/LB.   Such packets are not limited to= packets that are received by the RR/LB (i.e., it is entirely permissible t= o create new flows).

 

  Now, TLS/RR/LB might all be in the same appliance, but even so= , the chain

  to AV still has the same issue= .

 =

Ron>> The multiple logical service fu= nctions could each be located to the same IP address (which does, indeed ha= ve implications on the SFC service header – it needs to carry both th= e chain ID and the hop ID within the chain so that the composite service fu= nction may understand which is the initial service function to apply).=

 

  So, I guess m= y question is: Is this a valid DC use case for SFC?

 

= Ron>> I consider your use case entirely valid and exactly what= I have in mind when I think about SFC.   Implementation issues w= ill always exist, but that is why we are employed :).   I think y= our concerns may have been whether SFC is restricted to a packet-in-packet-= out type of model.   In my opinion, it is not.   A serv= ice function is free to create new flows that have no exact correspondence = to incoming flows and to subject those new flows to any service chain (or n= one) independently.  

=  

Ron>>&= nbsp; All of this does bring up an area, in my mind, that requires further = attention by the group, and perhaps this was on your mind, too.   = ;How to handle the reverse direction flows?   In the simple case,= where we have a linear chain with no branching and no flow creation, we co= uld conceivably arrange the single classifier to see the packets upon entry= to the domain in both directions.   If the classifier is statefu= l, it can easily manage reverse propagation down the chains (i.e., upstream= A, B, C; downstream C, B, A).   But, if new flows are created at= a service function, and properly stamped by the service function with the = correct chain information, the corresponding reverse flows don’t ente= r the domain at the service function, so where is the logic to place those = flows on the proper reverse chain?

 

 

= thanx.

 

--  = Kevin J. Ma

 

 <= /p>

Hi, Kevin.

 

Can= you  explain your thinking on why service function chaining would be = cognizant of the layer at which the service function operates?   = As I see it, any service function is free to modify the original packet in = a manner that suits it.   It also has the choice to allow the pac= ket (modified or unmodified) to progress on the original service function c= hain or to intercede with the local service function chaining functionality= such that it jumps onto a new chain.   In either case, the local= service function chaining functionality will cause the packet to be proper= ly encapsulated in order to be conveyed to the next service function (or fo= rwarded off the end of the chain, if applicable).

 

   Ron

 

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Q= uinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To:<= /b> Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charte= r

 

Hi Kevin,

 

Jim> this woul= d be part of the control plane which would make available to the service fu= nction (or proxy) information about inbound and outbound service function c= hain encapsulation. 

 

Personally, I am still unclear as to how th= is would work for application layer

se= rvices.  It's not a control plane issue if it's session data dependent= ?

 

 

=

The control plane is responsible for the chaining= /pathing aspect of SFC: conveying network locators for forwarding, allocati= ng service header information and so on.  It is not responsible for fu= nction specifics (e.g. per SFC policy).

 

&nbs= p;

 

 

=

I= won't rehash the previous discussion on "packet-level" classific= ation and

"packet-level" en= capsulation, but IMO there are a number of issues cited in

the problem statement which are not solved by simply d= efining an encapsulation

header.  = ;Yes, there are other informational documents on the list, but if they

do not address these questions on how the = encapsulation may be used (and how

dif= ferent levels of classification/re-classification will work), then the

encapsulation spec has to stand on its own= .  The charter could be interpreted

 

 

The encap format won't solve everything, = however it creates a foundation to build upon.  Many of the problems w= ill be solved at upper layers, leveraging the encap in the data plane.=

&n= bsp;

thanx.

 =

--  Kevin J. Ma

<= div>

 

From: Jim Gui= chard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, November 19, 2013 9:39 AM
To: Kevin J Ma;&nb= sp;nsc@= ietf.org
Subject:&= nbsp;Re: Revised SFC Charter

=

 

Hi Kevin,

 =

From: Kevin J Ma <kevin.ma@azuk= isystems.com>
Date:=  Tuesday, November 19, 2013 1:25 AM
To: Jim Guichard <jguichar@cisco.com>, "= nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revised SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is" -> "it i= s":

 

    "It is intended th= at the encapsulation be agnostic to the layer at which is is applied"<= o:p>

 <= /p>

Jim> yes, thank you, I corrected = the text. 

 

  Wrt to the= following text:

 <= /o:p>

    "the same = encapsulation may be used on a service function path realized at the networ= k layer or at any other layer"

 

  If the s= ervice function is an application layer service, and the

  encapsulation is at a lower layer (L2/L3= ), then presumably signaling

=   would be required between the application layer and the lower layer<= o:p>

  responsible for encaps= ulation, so that individual packets for an

  application layer message may be properly encapsulated= .  Has this

  been = discussed and/or is it considered in scope?

=

 

Jim> the point here was to show that the steering function is in= dependent of the services layer. As packets traverse a service chain the en= capsulation above the steering function is used to indicate what service fu= nction to apply and which service function comes next in the service functi= on chain. 

 

  Though thi= s sort of thing could be called an implementation detail,

 typically higher layers do not need to k= now the lower layer details,

=  but in this particular case, if the higher layer is re-classifying,

 it likely wants/needs to= know the ingress chain ID as it selects the

  egress chain ID, and then needs to tell the low= er encapsulation layer

 = what the new egress chain ID should be?

 

Jim> this would be part of the control plane which would make avai= lable to the service function (or proxy) information about inbound and outb= ound service function chain encapsulation. 

 

thanx.

 =

--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 PM
To:=  nsc@ietf.org
Subjec= t: [nsc] Revised SFC Ch= arter

&nbs= p;

Greetings,

 

Thomas Narten and I have spent some time refining th= e SFC charter based upon discussion during the SFC BOF and several emails t= o the mailing list. We do not believe this is a substantive change; we have= clarified the management vs. control plane text and added text around secu= rity. Please review the revised charter and provide comment.

 =

Revised SFC WG Charter:

 =

Ser= vice delivery is undergoing significant change with the introduction of vir= tualization, network overlays, and orchestration. Service delivery is curre= ntly both a technical and an organizational challenge that involves signifi= cant modification to the network configuration thereby impacting the speed = at which services can be deployed and increasing operational costs. Service= s are typically implemented by the ordered combination of a number of servi= ce functions that are deployed at different points within a network. Today,= a common deployment model has service functions physically inserted on the= data-forwarding path between communicating peers. Going forward, however, = there is a desire to move to a different model, where service functions, wh= ether physical or virtualized, are not required to reside on the direct dat= a path and traffic is instead steered through service functions, wherever t= hey are deployed.  

 

For a given = service, the abstracted view of the required service functions and the orde= r in which they are to be applied is called a Service Function Chain (SFC).=  An SFC is instantiated through selection of specific service fun= ction instances and the network nodes on which they are provided, thereby f= orming a service graph: this is called a Service Function Path (SFP). The s= ervice functions may be applied at any layer within the network protocol st= ack (network layer, application layer, etc.).  

 =

The SFC working group will document a new approach to= service delivery and operation. It will produce an architecture for servic= e function chaining that includes the necessary protocols or protocol exten= sions to convey the service path and service path information to nodes that= are involved in the implementation of service functions and service functi= on chains, as well as mechanisms for steering traffic through service funct= ions. The working group will examine what information needs to be gathered = from the network and service functions in support of service function chain= ing and how that information may be made available to the components of the= service function chaining architecture. The SFC WG will closely consi= der the security implications when documenting these deliverables. 

 

Specifically, the SFC WG is chartered to deliver the foll= owing:

1.  Problem Statement: This document will provide a summary of t= he problem space to be addressed by the SFC working group including example= high-level use cases. Additionally, the working group will normalize nomen= clature and definitions for service function chaining. <= o:p>

2.  Architecture: This document will prov= ide a description of the SFC architectural building blocks and their relati= onship including interconnection, placement of SFC specific capabilities, m= anagement, diagnostics, design analysis, and security models, as well as re= quirements on the protocol mechanisms. The initial scope is restricted to a= single administrative domain, keeping in mind that architectural decisions= made for the intra-domain case may have implications for the inter-domain = case.

3.  Generic SFC Encapsula= tion: This document will describe a single service-level data plane encapsu= lation format for conveying the service function chain and the service func= tion path, and for communicating context information between nodes that imp= lement service functions and service function chains. It is intended that t= he encapsulation be agnostic to the layer at which is is applied and the se= rvice that is being constructed. That is, the same encapsulation may be use= d on a service function path realized at the network layer or at any other = layer, and the same encapsulation will apply for the construction of servic= e function paths regardless of the actual service.

4.  Control Plane Mechanisms: A document will be developed= to describe requirements for conveying information between control or mana= gement elements and SFC implementation points. All protocol extension work = resulting from these requirements should be carried out in the working grou= p responsible for the protocol being modified in coordination with this wor= king group, but may be done in this working group under a revised charter a= fter agreement with all the relevant WG chairs and responsible ADs.<= o:p>

5.  Manageability: Work on the management= and configuration of SFC components related to the support of service func= tion chaining will certainly be needed, but first needs to be better unders= tood and scoped.

=  <= /span>

Proposed Milestones:<= /span>

 =

Apr 2014

Submit to IESG Informational document defining the SFC = problem statement and core use cases

=

Apr 2014

Consult= with OPS area on possible SFC charter modifications for management and con= figuration of SFC components related to the support of service function cha= ining

Jan 2015=

Submit to IESG Informational document = defining the architecture for SFC

Jan 2015

= Submit to = IESG Informational document defining the control plane requirements for con= veying information between control or management elements and SFC implement= ation points

Aug 2015=

Submit to IESG Standards Track = document specifying the generic service function chaining header encapsulat= ion

 <= o:p>

___= ____________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7BFMAILR002maill_-- From kevin.ma@azukisystems.com Wed Nov 20 07:52:10 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EA41AE43D for ; Wed, 20 Nov 2013 07:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3y9PJxq5DCv2 for ; Wed, 20 Nov 2013 07:52:02 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id E598B1AE044 for ; Wed, 20 Nov 2013 07:52:00 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 891A37AF510; Wed, 20 Nov 2013 10:51:54 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1D6CE7AF52B; Wed, 20 Nov 2013 10:51:50 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 20 Nov 2013 10:51:49 -0500 From: Kevin J Ma To: "Surendra Kumar (smkumar)" , Ron Parker , "Paul Quinn (paulq)" Date: Wed, 20 Nov 2013 10:51:46 -0500 Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAe/YAgAAuJpA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C790F7C7@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C790F7C7MAILR002maill_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 15:52:10 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7C7MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Surendra, > Well, there is more it than just putting a service path id into the = header/pkt. To construct service chains, you need a non-local view of servi= ce functions. A service controller provides such a view to enables the cons= truction of service chains. In that sense, there is already a need for co-o= rdination of these service chain/path identifiers with a control entity. We= 've moved past VLAN stitching - reason we are on this list :) Understood, but since the control plane function is not in the scope of t= he charter, and the only standards track document in the charter is the head= er encapsulation, my concern is how well the encapsulation spec will take in= to account the different deployment scenarios that need to be supported by t= he control plane functions. The point of the example was that the applicati= on layer service is the data plane. It terminates the TCP connection and th= en generates a new TCP connection, but that is still the same data plane for= a given end user session. I wanted to make sure this is not overlooked. thanx. -- Kevin J. Ma From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 20, 2013 10:02 AM To: Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Kevin, Comments inline. From: Kevin J Ma > Date: Tuesday, November 19, 2013 10:27 PM To: Ron Parker >, "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. When a classification supports layer7, it has to look at the data stre= am. There is no assumption that it is L3 based. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Well, there is more it than just putting a service path id into the he= ader/pkt. To construct service chains, you need a non-local view of service= functions. A service controller provides such a view to enables the constr= uction of service chains. In that sense, there is already a need for co-ord= ination of these service chain/path identifiers with a control entity. We'v= e moved past VLAN stitching - reason we are on this list :) Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? It is a valid use case. Surendra. thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7C7MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Surendra,

 

> <SK> Well, t= here is more it than just putting a service path id into the header/pkt. To= construct service chains, you need a non-local view of service functions. = A service controller provides such a view to enables the construction of se= rvice chains. In that sense, there is already a need for co-ordination of t= hese service chain/path identifiers with a control entity. We've moved past= VLAN stitching – reason we are on this list :)

 

  Understood, but since the control plan= e function is not in the scope of the

  char= ter, and the only standards track document in the charter is the header

  encapsulation, my concern is how well the enc= apsulation spec will take into

  account the= different deployment scenarios that need to be supported by the=

  control plane functions.  The point of the exam= ple was that the application

  layer service= is the data plane.  It terminates the TCP connection and then

  generates a new TCP connection, but that is still= the same data plane for a

  given end user = session.  I wanted to make sure this is not overlooked.

 

thanx.

--  Kevin J. Ma<= /p>

 

Fr= om: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent:= Wednesday, November 20, 2013 10:02 AM
To: Kevin J Ma; Ron Parker= ; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)Subject: Re: [nsc] Revised SFC Charter

<= /div>

 

Kevin,

&= nbsp;

Comments inline.=

 

From: Kevin J Ma <kevin.ma@azu= kisystems.com>
Date: Tuesday, November 19, 2013 10:27 PMTo: Ron Parker <Ron_Parker@affirmednetworks.com>, "Paul Quinn (paulq)"= <paulq@cisco.com>
Cc: <= /b>"nsc@ietf.org" <nsc@ietf.org>, "Jim Guichard (jguichar= )" <jguichar@cisco.com>= ;
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,=

 

  My pri= mary concern is with the word "packet".  If we are only cons= idering

  network layer packets, with network layer classification and enca= psulation,

  then that is one thing, but if we are talking about applicatio= n layer

  classification, then network layer encapsulation poses and issue.=   The data

  that comes out of a service function is not necessarily t= he same data that

 went into the service function.  At the application= layer, a socket is not

  inherently service chain aware.=

<SK> When a classifica= tion supports layer7, it has to look at the data stream. There is no assump= tion that it is L3 based.

 

 If one builds a load balance= r, AV scanner, etc. as an appliance (not part

 of a router), today we have = mechanisms for getting the traffic in and out

 of those appliances by confi= guring VLANs and IP addresses (as noted in the

  problem statement, section= 2, bullet 8).  If we want the service chain ID

<= p class=3DMsoNormal>  in the encapsulation= header to be the new mechanism, then these appliances

 need to know the in= gress chain ID and the be able to set the egress chain

 ID.  An off-th= e-shelf linux box can support the existing IP mechanism.  It

  seems t= o me that a new encapsulation layer might exclude existing appliance

  impl= ementations and introduce a new barrier to entry.

<SK> Well, there is more it th= an just putting a service path id into the header/pkt. To construct service= chains, you need a non-local view of service functions. A service controll= er provides such a view to enables the construction of service chains. In t= hat sense, there is already a need for co-ordination of these service chain= /path identifiers with a control entity. We've moved past VLAN stitching &#= 8211; reason we are on this list :)

 

=

  Let me try a more c= oncrete example:

 

  Given a set of service chains that: optionally termina= tes client-side TLS,

 performs HTTP request routing, optionally performs A= V checks for HTTP POST,

 does server load balancing, and optionally initiat= es back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> = BE_TLS -->

            = ; /      \      &nbs= p;   ^  \

        &n= bsp;   /        \   =      /    \

  ---------+  &nbs= p;       +------+    = ;  +---------->

 

  Assume RR, AV, and LB are all services provided= by independent appliances,

 and FE_TLS and BE_TLS are different instances = of the same TLS service

  provided by a fourth independent appliance.  = ;The possible chains are:

 

  chain 1:       =   RR,     LB

  chain 2:    &nb= sp;    RR, AV, LB

  chain 3: FE_TLS, RR,   &n= bsp; LB

  chain 4: FE_TLS, RR, AV, LB

  chain 5:    &nb= sp;    RR,     LB, BE_TLS

  chain 6= :         RR, AV, LB, BE_TLS

  chai= n 7: FE_TLS, RR,     LB, BE_TLS

  chain 8: FE_TLS, RR, = AV, LB, BE_TLS

 

  Initial classification would always choose from either c= hain 1 or chain 3.

  (e.g., based on the TCP destination port).<= /span>

 

  RR woul= d then choose either chain (1, 2) or chain (3, 4), respectively.=

 

  LB wou= ld then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8),<= /span>

 respective= ly.

&= nbsp;

  The decisions made by RR/LB seem unlikely to be made on an IP packe= t basis,

  yet still need to influence the chain ID encapsulation?

 

  Now,= TLS/RR/LB might all be in the same appliance, but even so, the chain<= /o:p>

  to = AV still has the same issue.

 

  So, I guess my question is: Is this a vali= d DC use case for SFC?

<SK> It is a valid use case.

<= div>

 

Surendra.

 

thanx.

 

--  Kevin J. Ma

 <= /o:p>

From: Ron Parker [m= ailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, Novemb= er 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc:<= /b> nsc@ietf.org; Jim Guichard (jguicha= r)
Subject: RE: [nsc] Revised SFC Charter

 

= Hi, Kevin.

 

Can you  explain your thinking on = why service function chaining would be cognizant of the layer at which the = service function operates?   As I see it, any service function is= free to modify the original packet in a manner that suits it.   = It also has the choice to allow the packet (modified or unmodified) to prog= ress on the original service function chain or to intercede with the local = service function chaining functionality such that it jumps onto a new chain= .   In either case, the local service function chaining functiona= lity will cause the packet to be properly encapsulated in order to be conve= yed to the next service function (or forwarded off the end of the chain, if= applicable).

 =

   Ron

 

 

From: nsc [mailto:nsc-bounces@ietf.org] On Beh= alf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12= :32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] R= evised SFC Charter

=

 

Hi Kevin,

&= nbsp;

 

On Nov 19, 2013, at 10:15 AM,= Kevin J Ma <kevin.ma@azuki= systems.com> wrote:

 

Jim> this would be part of the control p= lane which would make available to the service function (or proxy) informat= ion about inbound and outbound service function chain encapsulation. <= /span>

 

=

Personally, I am stil= l unclear as to how this would work for application layer=

services.&n= bsp; It's not a control plane issue if it's session data dependent?

&= nbsp;

 

=

The control plane is respo= nsible for the chaining/pathing aspect of SFC: conveying network locators f= or forwarding, allocating service header information and so on.  It is= not responsible for function specifics (e.g. per SFC policy).

 =

 

 

 

I won't rehash= the previous discussion on "packet-level" classification and

"packet-level" encapsulation, but IMO there are a number of is= sues cited in

the problem statement which are not solved by simply de= fining an encapsulation

header.  Yes, there are other informatio= nal documents on the list, but if they

do not address these questions= on how the encapsulation may be used (and how

<= div>

different levels of cl= assification/re-classification will work), then the

encapsulation spe= c has to stand on its own.  The charter could be interpreted

eit= her way.

 

=

 

The encap for= mat won't solve everything, however it creates a foundation to build upon. =  Many of the problems will be solved at upper layers, leveraging the e= ncap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [<= a href=3D"mailto:jguichar@">mailto:jguichar@cisco.com] 
Sent: Tuesday, November 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revised SFC Charter

<= span style=3D'color:black'> 

Hi Kevin,

 <= span style=3D'color:black'>

=

From: = ;Kevin J Ma <kevin.ma@azukisystems.com&= gt;
Date: Tuesday= , November 19, 2013 1:25 AM
To:&n= bsp;Jim Guichard <jguichar@cisco.com>, "nsc@ietf.org&= quot; <nsc@= ietf.org>
Subject:&= nbsp;RE: Revised SFC Charter<= o:p>

 =

<= div>

Hi Jim,

 

  There is a typo in item 3.  "is is" -> "= it is":

 

    "It is intended tha= t the encapsulation be agnostic to the layer at which is is applied"

 =

<= div>

Jim> yes, thank you, I corrected the text.=  

=

 

&nb= sp; Wrt to the following text:

 

    "= the same encapsulation may be used on a service function path realized at t= he network layer or at any other layer"

 =

  If t= he service function is an application layer service, and the

  e= ncapsulation is at a lower layer (L2/L3), then presumably signaling

&= nbsp; would be required between the application layer and the lower layer

  responsible for encapsulation, so that individual packets for a= n

  application layer message may be properly encapsulated. = ; Has this

  been discussed and/or is it considered in scope?

 =

<= div>

Jim> the point here was to show that the s= teering function is independent of the services layer. As packets traverse = a service chain the encapsulation above the steering function is used to in= dicate what service function to apply and which service function comes next= in the service function chain. 

 

  Though this sort of thing could be cal= led an implementation detail,

 typically higher layers do not ne= ed to know the lower layer details,

 but in this particular case= , if the higher layer is re-classifying,

 it likely wants/needs = to know the ingress chain ID as it selects the

<= div>

  egress cha= in ID, and then needs to tell the lower encapsulation layer

 wha= t the new egress chain ID should be?

=

 

Jim>= ; this would be part of the control plane which would make available to the= service function (or proxy) information about inbound and outbound service= function chain encapsulation. 

 

<= span style=3D'color:black'>thanx.

 

=

--  Kevin J. Ma<= o:p>

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, November 18, 2013 4:17 = PM
To: nsc@ietf.org<= br>Subject: [nsc] Re= vised SFC Charter

<= /div>

&nbs= p;

Greetings,

&nbs= p;

Thomas Narten a= nd I have spent some time refining the SFC charter based upon discussion du= ring the SFC BOF and several emails to the mailing list. We do not believe = this is a substantive change; we have clarified the management vs. control = plane text and added text around security. Please review the revised c= harter and provide comment.<= /o:p>

 

<= p class=3DMsoNormal>Revised SFC WG Charter:

 

Servic= e delivery is undergoing significant change with the introduction of virtua= lization, network overlays, and orchestration. Service delivery is currentl= y both a technical and an organizational challenge that involves significan= t modification to the network configuration thereby impacting the speed at = which services can be deployed and increasing operational costs. Services a= re typically implemented by the ordered combination of a number of service = functions that are deployed at different points within a network. Today, a = common deployment model has service functions physically inserted on the da= ta-forwarding path between communicating peers. Going forward, however, the= re is a desire to move to a different model, where service functions, wheth= er physical or virtualized, are not required to reside on the direct data p= ath and traffic is instead steered through service functions, wherever they= are deployed.  

&nbs= p;

For a given service, the abstracted view of the required service functio= ns and the order in which they are to be applied is called a Service Functi= on Chain (SFC). An SFC is instantiated through selection of speci= fic service function instances and the network nodes on which they are prov= ided, thereby forming a service graph: this is called a Service Function Pa= th (SFP). The service functions may be applied at any layer within the netw= ork protocol stack (network layer, application layer, etc.).  

 

The SFC working g= roup will document a new approach to service delivery and operation. It wil= l produce an architecture for service function chaining that includes the n= ecessary protocols or protocol extensions to convey the service path and se= rvice path information to nodes that are involved in the implementation of = service functions and service function chains, as well as mechanisms for st= eering traffic through service functions. The working group will examine wh= at information needs to be gathered from the network and service functions = in support of service function chaining and how that information may be mad= e available to the components of the service function chaining architecture= . The SFC WG will closely consider the security implications when docu= menting these deliverables. =

 

= Specifically, the SFC WG is chartered to deliver the following:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.  Architecture: This document will provide a description of the= SFC architectural building blocks and their relationship including interco= nnection, placement of SFC specific capabilities, management, diagnostics, = design analysis, and security models, as well as requirements on the protoc= ol mechanisms. The initial scope is restricted to a single administrative d= omain, keeping in mind that architectural decisions made for the intra-doma= in case may have implications for the inter-domain case.

3.  Generic SFC Encapsulation: This document will descr= ibe a single service-level data plane encapsulation format for conveying th= e service function chain and the service function path, and for communicati= ng context information between nodes that implement service functions and s= ervice function chains. It is intended that the encapsulation be agnostic t= o the layer at which is is applied and the service that is being constructe= d. That is, the same encapsulation may be used on a service function path r= ealized at the network layer or at any other layer, and the same encapsulat= ion will apply for the construction of service function paths regardless of= the actual service.

4.&n= bsp; Control Plane= Mechanisms: A document will be developed to describe requirements for conv= eying information between control or management elements and SFC implementa= tion points. All protocol extension work resulting from these requirements = should be carried out in the working group responsible for the protocol bei= ng modified in coordination with this working group, but may be done in thi= s working group under a revised charter after agreement with all the releva= nt WG chairs and responsible ADs.

5.  = Manageability: Work on the management and configuration of SFC components r= elated to the support of service function chaining will certainly be needed= , but first needs to be better understood and scoped.

 

Proposed Milestones:

 

=

Apr 2014

Submit= to IESG Informational document defining the SFC problem statement and core= use cases

Apr 2014

Consult with O= PS area on possible SFC charter modifications for management and configurat= ion of SFC components related to the support of service function chaining

Jan 2015

Submit to IESG Information= al document defining the architecture for SFC

Jan= 2015

Submit to IESG Informational document defining the con= trol plane requirements for conveying information between control or manage= ment elements and SFC implementation points

Aug 2= 015

Submit to IESG Standards Track document specifying the g= eneric service function chaining header encapsulation

 

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

 

= = --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7C7MAILR002maill_-- From jguichar@cisco.com Wed Nov 20 07:56:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D481AE012 for ; Wed, 20 Nov 2013 07:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 RBg0KoTw-feS for ; Wed, 20 Nov 2013 07:56:53 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA1AD1AE431 for ; Wed, 20 Nov 2013 07:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=71648; q=dns/txt; s=iport; t=1384963006; x=1386172606; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=iPyDzr3MfbXVSjtoQi/cGgc6xHGCn9lZVKGkI2PU5JY=; b=VdHh5OIexZSSLKaby7Pn22jKI8N0HpSy+bQiAIWG3+qyM76T3tt6I8V3 ELPstisrBGc1ETgQD7626diE4HfszILsKGqsAs6+G3iOyjgxiBjIPa+h2 ea2vf7zMML+OHc2q5HywdkRjnJDdquhVvAea7BdABEOnhyQWKOKyglLt9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAG3ajFKtJV2Y/2dsb2JhbABZgkNEOFO+a4EWFnSCJQEBAQQBAQEXAQwGOAIHBAcSAQgRAQIBAQEWCwEGLgsUAwYIAgQBDQWIAQ3AORePLAcTDQQGAQIEAwGEKAOUMINigS+LKIU2gyiCKg X-IronPort-AV: E=Sophos;i="4.93,737,1378857600"; d="scan'208,217";a="286387635" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 20 Nov 2013 15:56:45 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAKFujdg029169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 15:56:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 09:56:44 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "Surendra Kumar (smkumar)" , Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAe/YAgAAuJpCAABNngA== Date: Wed, 20 Nov 2013 15:56:44 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C790F7C7@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.184] Content-Type: multipart/alternative; boundary="_000_CEB2457B1183Fjguicharciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 15:56:58 -0000 --_000_CEB2457B1183Fjguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Kevin, It is not accurate to say that the control plane function is not part of th= e charter. We have a work item to produce control plane requirements and th= ose should reflect the functions necessary in the data plane encapsulation.= It is true that the charter does not support working on the control plane = standards per-se. From: Kevin J Ma > Date: Wednesday, November 20, 2013 10:51 AM To: "Surendra Kumar (smkumar)" = >, Ron Parker >, Paul Quinn > Cc: "nsc@ietf.org" >= , Jim Guichard > Subject: RE: [nsc] Revised SFC Charter Hi Surendra, > Well, there is more it than just putting a service path id into the = header/pkt. To construct service chains, you need a non-local view of servi= ce functions. A service controller provides such a view to enables the cons= truction of service chains. In that sense, there is already a need for co-o= rdination of these service chain/path identifiers with a control entity. We= 've moved past VLAN stitching =96 reason we are on this list :) Understood, but since the control plane function is not in the scope of t= he charter, and the only standards track document in the charter is the head= er encapsulation, my concern is how well the encapsulation spec will take in= to account the different deployment scenarios that need to be supported by t= he control plane functions. The point of the example was that the applicati= on layer service is the data plane. It terminates the TCP connection and th= en generates a new TCP connection, but that is still the same data plane for= a given end user session. I wanted to make sure this is not overlooked. thanx. -- Kevin J. Ma From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 20, 2013 10:02 AM To: Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Kevin, Comments inline. From: Kevin J Ma > Date: Tuesday, November 19, 2013 10:27 PM To: Ron Parker >, "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. When a classification supports layer7, it has to look at the data stre= am. There is no assumption that it is L3 based. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Well, there is more it than just putting a service path id into the he= ader/pkt. To construct service chains, you need a non-local view of service= functions. A service controller provides such a view to enables the constr= uction of service chains. In that sense, there is already a need for co-ord= ination of these service chain/path identifiers with a control entity. We'v= e moved past VLAN stitching =96 reason we are on this list :) Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? It is a valid use case. Surendra. thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CEB2457B1183Fjguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1E2A4E1C9DF15047BF70DA411B22FD3C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kevin,
It is not accurate to say that the control plane function is not part = of the charter. We have a work item to produce control plane requirements a= nd those should reflect the functions necessary in the data plane encapsula= tion. It is true that the charter does not support working on the control plane standards per-se. 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Wednesday, November 20, 2013 = 10:51 AM
To: "Surendra Kumar (smkumar)&= quot; <smkumar@cisco.com>, R= on Parker <Ron_Parker= @affirmednetworks.com>, Paul Quinn <paulq@cisco.com>
Cc: "nsc@ietf.org" <nsc@ietf.= org>, Jim Guichard <jguicha= r@cisco.com>
Subject: RE: [nsc] Revised SFC Char= ter

Hi Surendra,

 

> <SK> Well, there is more it than just putting a servi= ce path id into the header/pkt. To construct service chains, you need a non= -local view of service functions. A service controller provides such a view to enables the construction of service cha= ins. In that sense, there is already a need for co-ordination of these serv= ice chain/path identifiers with a control entity. We've moved past VLAN sti= tching =96 reason we are on this list :)

 

  Understood, but since the control plane function is not in= the scope of the

  charter, and the only standards track document in the char= ter is the header

  encapsulation, my concern is how well the encapsulation sp= ec will take into

  account the different deployment scenarios that need to be= supported by the

  control plane functions.  The point of the example wa= s that the application

  layer service is the data plane.  It terminates the T= CP connection and then

  generates a new TCP connection, but that is still the same= data plane for a

  given end user session.  I wanted to make sure this i= s not overlooked.

 

thanx.

 

--  Kevin J. Ma

 

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Wednesday, November 20, 2013 10:02 AM
To: Kevin J Ma; Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Kevin,

 

Comments inline.

 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, November 19, 2013 10:27 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Paul Quinn (paulq)" &= lt;paulq@cisco.com>
Cc: "nsc@ietf.org" <= ;nsc@ietf.org>, "Jim Guichard (= jguichar)" <jguichar@cisco.co= m>
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,<= /span>

 =

  My primary concer= n is with the word "packet".  If we are only considering

  network layer pac= kets, with network layer classification and encapsulation,

  then that is one = thing, but if we are talking about application layer

  classification, t= hen network layer encapsulation poses and issue.  The data<= /span>

  that comes out of= a service function is not necessarily the same data that=

 went into the serv= ice function.  At the application layer, a socket is not

  inherently servic= e chain aware.

<SK> When a classification supports l= ayer7, it has to look at the data stream. There is no assumption that it is= L3 based.

 =

 If one builds a lo= ad balancer, AV scanner, etc. as an appliance (not part

 of a router), toda= y we have mechanisms for getting the traffic in and out

 of those appliance= s by configuring VLANs and IP addresses (as noted in the<= /p>

  problem statement= , section 2, bullet 8).  If we want the service chain ID

  in the encapsulat= ion header to be the new mechanism, then these appliances=

 need to know the i= ngress chain ID and the be able to set the egress chain

 ID.  An off-t= he-shelf linux box can support the existing IP mechanism.  It

  seems to me that = a new encapsulation layer might exclude existing appliance

  implementations a= nd introduce a new barrier to entry.

<SK> Well, there is more it than just= putting a service path id into the header/pkt. To construct service chains= , you need a non-local view of service functions. A service controller provides such a view to enables the construction of s= ervice chains. In that sense, there is already a need for co-ordination of = these service chain/path identifiers with a control entity. We've moved pas= t VLAN stitching =96 reason we are on this list :)

 =

  Let me try a more= concrete example:

 =

  Given a set of se= rvice chains that: optionally terminates client-side TLS,=

 performs HTTP requ= est routing, optionally performs AV checks for HTTP POST,=

 does server load b= alancing, and optionally initiates back-end TLS:

 =

  --> FE_TLS --&= gt; RR --> AV --> LB --> BE_TLS -->

    =          /     =  \          ^  \

    =         /      =   \        /   = \

  ---------+ &n= bsp;        +------+ &= nbsp;    +---------->

 =

  Assume RR, AV, an= d LB are all services provided by independent appliances,=

 and FE_TLS and BE_= TLS are different instances of the same TLS service

  provided by a fou= rth independent appliance.  The possible chains are:=

 =

  chain 1:  &n= bsp;      RR,     LB=

  chain 2:  &n= bsp;      RR, AV, LB

  chain 3: FE_TLS, = RR,     LB

  chain 4: FE_TLS, = RR, AV, LB

  chain 5:  &n= bsp;      RR,     LB, BE_= TLS

  chain 6:  &n= bsp;      RR, AV, LB, BE_TLS

  chain 7: FE_TLS, = RR,     LB, BE_TLS

  chain 8: FE_TLS, = RR, AV, LB, BE_TLS

 =

  Initial classific= ation would always choose from either chain 1 or chain 3.=

  (e.g., based on t= he TCP destination port).

 =

  RR would then cho= ose either chain (1, 2) or chain (3, 4), respectively.

 =

  LB would then cho= ose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8),

 respectively.=

 =

  The decisions mad= e by RR/LB seem unlikely to be made on an IP packet basis,

  yet still need to= influence the chain ID encapsulation?

 =

  Now, TLS/RR/LB mi= ght all be in the same appliance, but even so, the chain<= /p>

  to AV still has t= he same issue.

 =

  So, I guess my qu= estion is: Is this a valid DC use case for SFC?

<SK> It is a valid use case.

 

Surendra.

 =

thanx.=

 =

--  Kevin J. Ma

 =

From: Ron Parker [mailto:Ron_Parker@affirmednetwo= rks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 =

Hi, Kevin.

 

Can you  explain your thinkin= g on why service function chaining would be cognizant of the layer at which= the service function operates?   As I see it, any service function is free to modify the original packet in a manner= that suits it.   It also has the choice to allow the packet (mod= ified or unmodified) to progress on the original service function chain or = to intercede with the local service function chaining functionality such that it jumps onto a new chain.   In= either case, the local service function chaining functionality will cause = the packet to be properly encapsulated in order to be conveyed to the next = service function (or forwarded off the end of the chain, if applicable).

 

   Ron

 

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 =

Hi Kevin,

 =

 =

On Nov 19, 2013, at 10:1= 5 AM, Kevin J Ma <kevin.ma@= azukisystems.com> wrote:

 

Jim> this would be part of the control p= lane which would make available to the service function (or proxy) informat= ion about inbound and outbound service function chain encapsulation. 

 =

Personally, I am still u= nclear as to how this would work for application layer

services.  It's not= a control plane issue if it's session data dependent?

 =

 =

The control plane is res= ponsible for the chaining/pathing aspect of SFC: conveying network locators= for forwarding, allocating service header information and so on.  It = is not responsible for function specifics (e.g. per SFC policy).

 =

 =

 =

 

I won't rehash the previ= ous discussion on "packet-level" classification and

"packet-level"= encapsulation, but IMO there are a number of issues cited in

the problem statement wh= ich are not solved by simply defining an encapsulation

header.  Yes, there= are other informational documents on the list, but if they

do not address these que= stions on how the encapsulation may be used (and how

different levels of clas= sification/re-classification will work), then the

encapsulation spec has t= o stand on its own.  The charter could be interpreted

either way.

 =

 =

The encap format won't s= olve everything, however it creates a foundation to build upon.  Many = of the problems will be solved at upper layers, leveraging the encap in the= data plane.

 

thanx.=

 =

--  Kevin J. Ma

 =

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 =

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 =

  There is a typo i= n item 3.  "is is" -> "it is":

 =

    "= ;It is intended that the encapsulation be agnostic to the layer at which is= is applied"

 

Jim> yes, thank you, I corrected the tex= t. 

 =

  Wrt to the follow= ing text:

 =

    "= ;the same encapsulation may be used on a service function path realized at = the network layer or at any other layer"

 =

  If the service fu= nction is an application layer service, and the

  encapsulation is = at a lower layer (L2/L3), then presumably signaling

  would be required= between the application layer and the lower layer

  responsible for e= ncapsulation, so that individual packets for an

  application layer= message may be properly encapsulated.  Has this

  been discussed an= d/or is it considered in scope?

 

Jim> the point here was to show that the= steering function is independent of the services layer. As packets travers= e a service chain the encapsulation above the steering function is used to indicate what service function to apply a= nd which service function comes next in the service function chain. 

 =

  Though this sort = of thing could be called an implementation detail,

 typically higher l= ayers do not need to know the lower layer details,

 but in this partic= ular case, if the higher layer is re-classifying,

 it likely wants/ne= eds to know the ingress chain ID as it selects the

  egress chain= ID, and then needs to tell the lower encapsulation layer=

 what the new egres= s chain ID should be?

 

Jim> this would be part of the control p= lane which would make available to the service function (or proxy) informat= ion about inbound and outbound service function chain encapsulation. 

 =

thanx.=

 =

--  Kevin J. Ma

 =

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 =

Greetings,

 

Thomas Narten a= nd I have spent some time refining the SFC charter based upon discussion du= ring the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have = clarified the management vs. control plane text and added text around secur= ity. Please review the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is= undergoing significant change with the introduction of virtualization, net= work overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  =

 

For a given service, the abstracted view of the required serv= ice functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  =

 

The SFC working group will document a new approach to service= delivery and operation. It will produce an architecture for service function chaining that includes the necessary = protocols or protocol extensions to convey the service path and service pat= h information to nodes that are involved in the implementation of service f= unctions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. =

 

Specifically, the SFC WG is chartered to deliver the followin= g:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.  Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= span style=3D"color:black">

4.  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.  Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.<= o:p>

 

Proposed Milestones:

 

Apr 2014=

Submit to IESG Informational document defining t= he SFC problem statement and core use cases

Apr 2014=

Consult with OPS area on possible SFC charter mo= difications for management and configuration of SFC components related to t= he support of service function chaining<= o:p>

Jan 2015=

Submit to IESG Informational document defining t= he architecture for SFC

Jan 2015=

Submit to IESG Informational document defining t= he control plane requirements for conveying information between control or = management elements and SFC implementation points

Aug 2015=

Submit to IESG Standards Track document specifyi= ng the generic service function chaining header encapsulation

 

_________________________________________= ______
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 =

--_000_CEB2457B1183Fjguicharciscocom_-- From kevin.ma@azukisystems.com Wed Nov 20 08:05:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA27D1AE45F for ; Wed, 20 Nov 2013 08:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 nKlR6y9LmrgA for ; Wed, 20 Nov 2013 08:05:38 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 596621AE3F1 for ; Wed, 20 Nov 2013 08:05:37 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0154B8BF699; Wed, 20 Nov 2013 11:05:31 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 206888BF4CA; Wed, 20 Nov 2013 11:05:25 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Wed, 20 Nov 2013 11:05:24 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "Surendra Kumar (smkumar)" , Ron Parker , "Paul Quinn (paulq)" Date: Wed, 20 Nov 2013 11:05:21 -0500 Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAe/YAgAAuJpCAABNngP//8CGQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C790F7F8@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C790F7C7@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C790F7F8MAILR002maill_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 16:05:46 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7F8MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Fair enough. But, requirements tend to get revised as you do a more thorough consideration of an implementation. I question whether we can really anticipate all of the control plane issues without doing the actual control plane standard. I brought up my questions below as I try to think through how the control plane and encap will work, but I can't say I've thought of it all. Writing a requirements doc with no implementations to vet it out concerns me. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Wednesday, November 20, 2013 10:57 AM To: Kevin J Ma; Surendra Kumar (smkumar); Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org Subject: Re: [nsc] Revised SFC Charter Hi Kevin, It is not accurate to say that the control plane function is not part of th= e charter. We have a work item to produce control plane requirements and th= ose should reflect the functions necessary in the data plane encapsulation.= It is true that the charter does not support working on the control plane = standards per-se. From: Kevin J Ma > Date: Wednesday, November 20, 2013 10:51 AM To: "Surendra Kumar (smkumar)" = >, Ron Parker >, Paul Quinn > Cc: "nsc@ietf.org" >= , Jim Guichard > Subject: RE: [nsc] Revised SFC Charter Hi Surendra, > Well, there is more it than just putting a service path id into the = header/pkt. To construct service chains, you need a non-local view of servi= ce functions. A service controller provides such a view to enables the cons= truction of service chains. In that sense, there is already a need for co-o= rdination of these service chain/path identifiers with a control entity. We= 've moved past VLAN stitching - reason we are on this list :) Understood, but since the control plane function is not in the scope of t= he charter, and the only standards track document in the charter is the head= er encapsulation, my concern is how well the encapsulation spec will take in= to account the different deployment scenarios that need to be supported by t= he control plane functions. The point of the example was that the applicati= on layer service is the data plane. It terminates the TCP connection and th= en generates a new TCP connection, but that is still the same data plane for= a given end user session. I wanted to make sure this is not overlooked. thanx. -- Kevin J. Ma From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 20, 2013 10:02 AM To: Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Kevin, Comments inline. From: Kevin J Ma > Date: Tuesday, November 19, 2013 10:27 PM To: Ron Parker >, "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. When a classification supports layer7, it has to look at the data stre= am. There is no assumption that it is L3 based. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Well, there is more it than just putting a service path id into the he= ader/pkt. To construct service chains, you need a non-local view of service= functions. A service controller provides such a view to enables the constr= uction of service chains. In that sense, there is already a need for co-ord= ination of these service chain/path identifiers with a control entity. We'v= e moved past VLAN stitching - reason we are on this list :) Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? It is a valid use case. Surendra. thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7F8MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

  Fair enough.  But, requireme= nts tend to get revised as you do a more

  t= horough consideration of an implementation.  I question whether we

  can really anticipate all of the control plan= e issues without doing

  the actual control = plane standard.  I brought up my questions below

=

  as I try to think through how the control plane and encap will = work,

  but I can't say I've thought of it a= ll.  Writing a requirements doc

  with = no implementations to vet it out concerns me.

 

thanx.

 <= /o:p>

--  Kevin J. Ma

&n= bsp;

From:<= span style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Jim Guic= hard (jguichar) [mailto:jguichar@cisco.com]
Sent: Wednesday, Nov= ember 20, 2013 10:57 AM
To: Kevin J Ma; Surendra Kumar (smkumar);= Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,<= o:p>

It is not accurat= e to say that the control plane function is not part of the charter. We hav= e a work item to produce control plane requirements and those should reflec= t the functions necessary in the data plane encapsulation. It is true that = the charter does not support working on the control plane standards per-se.=  

 = ;

From: = Kevin J Ma <kevin.= ma@azukisystems.com>
Date: Wednesday, November 20, 2013 10= :51 AM
To: "Surendra Kumar (smkumar)" <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com= >, Paul Quinn <paulq@cisco.com= >
Cc: "nsc@ietf.org" <nsc@ietf.org>, Jim Guic= hard <jguichar@cisco.com>Subject: RE: [nsc] Revised SFC Charter

=

 

=

Hi Surendra,

 <= /span>

> <SK> Well, there is more it than just putting a service path id into= the header/pkt. To construct service chains, you need a non-local view of = service functions. A service controller provides such a view to enables the= construction of service chains. In that sense, there is already a need for= co-ordination of these service chain/path identifiers with a control entit= y. We've moved past VLAN stitching – reason we are on this list :)

=  

  Understood, but since the control plan= e function is not in the scope of the

  charter, and the only standards tra= ck document in the charter is the header

  encapsulation, my concern is how= well the encapsulation spec will take into

  account the different deplo= yment scenarios that need to be supported by the

  control plane functions.=   The point of the example was that the application<= /p>

  layer service is= the data plane.  It terminates the TCP connection and then=

  generate= s a new TCP connection, but that is still the same data plane for a

  given= end user session.  I wanted to make sure this is not overlooked.=

 

thanx.<= o:p>

 = ;

--&= nbsp; Kevin J. Ma

 

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Wedn= esday, November 20, 2013 10:02 AM
To: Kevin J Ma; Ron Parker; Pau= l Quinn (paulq)
Cc: nsc@ietf.org<= /a>; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Chart= er

 

Kevin,=

From= : Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, November 19, = 2013 10:27 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Paul Quin= n (paulq)" <paulq@cisco.com&= gt;
Cc: "nsc@ietf.org&qu= ot; <nsc@ietf.org>, "Jim Gui= chard (jguichar)" <jguichar@c= isco.com>
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,<= o:p>

 = ;

&nb= sp; My primary concern is with the word "packet".  If we are= only considering

  network layer packets, with network layer classificatio= n and encapsulation,

  then that is one thing, but if we are talking about= application layer

  classification, then network layer encapsulation poses= and issue.  The data

  that comes out of a service function is not ne= cessarily the same data that

 went into the service function.  At the = application layer, a socket is not

  inherently service chain aware.

<SK> When a= classification supports layer7, it has to look at the data stream. There i= s no assumption that it is L3 based.

 

 If one builds a load balancer, AV scanner, etc. as an appli= ance (not part

 of a router), today we have mechanisms for getting the traf= fic in and out

 of those appliances by configuring VLANs and IP addresses (= as noted in the

  problem statement, section 2, bullet 8).  If we want= the service chain ID

  in the encapsulation header to be the new mechanism= , then these appliances

 need to know the ingress chain ID and the be able = to set the egress chain

 ID.  An off-the-shelf linux box can support t= he existing IP mechanism.  It

  seems to me that a new encapsulation l= ayer might exclude existing appliance

  implementations and introduce a new= barrier to entry.

<SK> Well, there is more it than just putting a service path = id into the header/pkt. To construct service chains, you need a non-local v= iew of service functions. A service controller provides such a view to enab= les the construction of service chains. In that sense, there is already a n= eed for co-ordination of these service chain/path identifiers with a contro= l entity. We've moved past VLAN stitching – reason we are on this lis= t :)

 =

  Let me try a mo= re concrete example:

 

  Given a set of service chains that: optionally te= rminates client-side TLS,

 performs HTTP request routing, optionally perfor= ms AV checks for HTTP POST,

 does server load balancing, and optionally ini= tiates back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB -->= ; BE_TLS -->

           &nb= sp; /      \      &n= bsp;   ^  \

<= span style=3D'color:black'>        =     /        \  &nbs= p;     /    \

=

  ---------+  &n= bsp;       +------+   &nb= sp;  +---------->

 

  Assume RR, AV, and LB are all services provid= ed by independent appliances,

 and FE_TLS and BE_TLS are different instance= s of the same TLS service

  provided by a fourth independent appliance. &nb= sp;The possible chains are:

 

  chain 1:      &nbs= p;  RR,     LB

  chain 2:    =      RR, AV, LB

  chain 3: FE_TLS, RR,   = ;  LB

  chain 4: FE_TLS, RR, AV, LB

  chain 5:    =      RR,     LB, BE_TLS

  chai= n 6:         RR, AV, LB, BE_TLS

  c= hain 7: FE_TLS, RR,     LB, BE_TLS

  chain 8: FE_TLS, R= R, AV, LB, BE_TLS

 

  Initial classification would always choose from eit= her chain 1 or chain 3.

  (e.g., based on the TCP destination port).

 =

  RR= would then choose either chain (1, 2) or chain (3, 4), respectively.<= /o:p>

 

  L= B would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8),

 respe= ctively.

 

  The decisions made by RR/LB seem unlikely to be made on an IP = packet basis,

  yet still need to influence the chain ID encapsulation?

 

 = Now, TLS/RR/LB might all be in the same appliance, but even so, the chain<= o:p>

 = ; to AV still has the same issue.

 

  So, I guess my question is: Is this a= valid DC use case for SFC?

<SK> It is a valid use case.

&nbs= p;

Surendra.

 

thanx.

 

--  Kevin J. Ma

 

<= p class=3DMsoNormal>From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com<= /a>]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul= Quinn (paulq); Kevin J Ma
Cc: ns= c@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revise= d SFC Charter

 

Hi, Kevin.

 

Ca= n you  explain your thinking on why service function chaining would be= cognizant of the layer at which the service function operates?  = As I see it, any service function is free to modify the original packet in= a manner that suits it.   It also has the choice to allow the pa= cket (modified or unmodified) to progress on the original service function = chain or to intercede with the local service function chaining functionalit= y such that it jumps onto a new chain.   In either case, the loca= l service function chaining functionality will cause the packet to be prope= rly encapsulated in order to be conveyed to the next service function (or f= orwarded off the end of the chain, if applicable).

 

   Ron

<= p class=3DMsoNormal> 

 

F= rom: nsc [mailto:ns= c-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent:<= /b> Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc:<= /b> nsc@ietf.org; Jim Guichard (jguicha= r)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 <= /p>

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wrote:

 

Jim> th= is would be part of the control plane which would make available to the ser= vice function (or proxy) information about inbound and outbound service fun= ction chain encapsulation. 

&= nbsp;

Personally, I am still unclear as to how this would work for ap= plication layer

services.  It's not a control plane issue if it'= s session data dependent?

 

 =

The control plane is responsible for the chaining/pathing aspect of = SFC: conveying network locators for forwarding, allocating service header i= nformation and so on.  It is not responsible for function specifics (e= .g. per SFC policy).

<= span style=3D'color:black'> 

 

=

 

 

I won't rehash the previous discussion on "packet-= level" classification and

"packet-level" encapsulation= , but IMO there are a number of issues cited in

=

the problem statement= which are not solved by simply defining an encapsulation=

header. &nb= sp;Yes, there are other informational documents on the list, but if they

do not address these questions on how the encapsulation may be used (an= d how

different levels of classification/re-classification will work)= , then the

encapsulation spec has to stand on its own.  The char= ter could be interpreted

either way.

=

 

 

The encap format won't solve everything, however it crea= tes a foundation to build upon.  Many of the problems will be solved a= t upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

= From: Jim Guichard (jguichar) [mailto:jguichar@= cisco.com] 
Sent: Tuesday, November 19, 2013 9= :39 AM
To: Kevin = J Ma; nsc@ietf.org
Subje= ct: Re: Revised SFC Cha= rter

 =

Hi Kevin,

 

From: Kevin J Ma <kevin= .ma@azukisystems.com>
Date: Tuesday, November 19, 2013 1:25 AM
To: Jim Guichard <jguichar@cisco.com<= /span>>, "nsc@ietf.org" <<= span style=3D'color:purple'>nsc@ietf.org>
Subject: RE: Revised SFC Charter

=

 

Hi Jim,

 

  There is a typo in item 3. &nbs= p;"is is" -> "it is":

 =

  &nbs= p; "It is intended that the encapsulation be agnostic to the laye= r at which is is applied"

<= p class=3DMsoNormal> 

Jim> yes, t= hank you, I corrected the text. 

 

  Wrt to the following text:<= /span>

 = ;

    "the same encapsulation may be used on a se= rvice function path realized at the network layer or at any other layer&quo= t;

 

  If the service function is an application laye= r service, and the

  encapsulation is at a lower layer (L2/L3), = then presumably signaling

  would be required between the applic= ation layer and the lower layer

  responsible for encapsulation,= so that individual packets for an

  application layer message m= ay be properly encapsulated.  Has this

  been discussed and= /or is it considered in scope?

<= p class=3DMsoNormal> 

Jim> the po= int here was to show that the steering function is independent of the servi= ces layer. As packets traverse a service chain the encapsulation above the = steering function is used to indicate what service function to apply and wh= ich service function comes next in the service function chain. =

 

<= /div>

  Though th= is sort of thing could be called an implementation detail,

 typi= cally higher layers do not need to know the lower layer details,=

&nbs= p;but in this particular case, if the higher layer is re-classifying,<= /o:p>

 it likely wants/needs to know the ingress chain ID as it selects the=

  egress chain ID, and then needs to tell the lower encaps= ulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the control plane which = would make available to the service function (or proxy) information about i= nbound and outbound service function chain encapsulation. 

 

=

thanx.

 

--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounces@ietf.or= g] On Behalf = Of Jim Guichard (jguich= ar)
Sent: Monday,= November 18, 2013 4:17 PM
To: = nsc@ietf.org
Subject: [nsc] Revised SFC Charter

 

Greetings,

 

Thomas Narten and I have spent some time refining the SFC charter = based upon discussion during the SFC BOF and several emails to the mailing = list. We do not believe this is a substantive change; we have clarified the= management vs. control plane text and added text around security. Please&n= bsp;review the revised charter and provide comment.

 

Revised SFC WG Charter:

=

 

Service delivery is undergoing significant change with th= e introduction of virtualization, network overlays, and orchestration. Serv= ice delivery is currently both a technical and an organizational challenge = that involves significant modification to the network configuration thereby= impacting the speed at which services can be deployed and increasing opera= tional costs. Services are typically implemented by the ordered combination= of a number of service functions that are deployed at different points wit= hin a network. Today, a common deployment model has service functions physi= cally inserted on the data-forwarding path between communicating peers. Goi= ng forward, however, there is a desire to move to a different model, where = service functions, whether physical or virtualized, are not required to res= ide on the direct data path and traffic is instead steered through service = functions, wherever they are deployed.  

 

For a given service, the abstracted view of the = required service functions and the order in which they are to be applied is= called a Service Function Chain (SFC). An SFC is instantiated th= rough selection of specific service function instances and the network node= s on which they are provided, thereby forming a service graph: this is call= ed a Service Function Path (SFP). The service functions may be applied at a= ny layer within the network protocol stack (network layer, application laye= r, etc.).  <= /span>

&n= bsp;

The SFC working group will document a new approach to service delivery= and operation. It will produce an architecture for service function chaini= ng that includes the necessary protocols or protocol extensions to convey t= he service path and service path information to nodes that are involved in = the implementation of service functions and service function chains, as wel= l as mechanisms for steering traffic through service functions. The working= group will examine what information needs to be gathered from the network = and service functions in support of service function chaining and how that = information may be made available to the components of the service function= chaining architecture. The SFC WG will closely consider the security = implications when documenting these deliverables. 

 

Specifically, the SFC WG is chartered to deliver the = following:

<= /div>

1. = ; Problem Statement: This document will provide a summary of t= he problem space to be addressed by the SFC working group including example= high-level use cases. Additionally, the working group will normalize nomen= clature and definitions for service function chaining. <= span style=3D'color:black'>

2.  Architecture: This document will provid= e a description of the SFC architectural building blocks and their relation= ship including interconnection, placement of SFC specific capabilities, man= agement, diagnostics, design analysis, and security models, as well as requ= irements on the protocol mechanisms. The initial scope is restricted to a s= ingle administrative domain, keeping in mind that architectural decisions m= ade for the intra-domain case may have implications for the inter-domain ca= se.

3.  Generic SFC Encapsulation: T= his document will describe a single service-level data plane encapsulation = format for conveying the service function chain and the service function pa= th, and for communicating context information between nodes that implement = service functions and service function chains. It is intended that the enca= psulation be agnostic to the layer at which is is applied and the service t= hat is being constructed. That is, the same encapsulation may be used on a = service function path realized at the network layer or at any other layer, = and the same encapsulation will apply for the construction of service funct= ion paths regardless of the actual service.

4.  Control Plane Mechanisms: A document will be developed to describ= e requirements for conveying information between control or management elem= ents and SFC implementation points. All protocol extension work resulting f= rom these requirements should be carried out in the working group responsib= le for the protocol being modified in coordination with this working group,= but may be done in this working group under a revised charter after agreem= ent with all the relevant WG chairs and responsible ADs.

5.  Manageability: Work on the management and configura= tion of SFC components related to the support of service function chaining = will certainly be needed, but first needs to be better understood and scope= d.

=

 

Proposed Milesto= nes:

 =

Apr 2014=

Submit to IESG Informational document defining the SFC prob= lem statement and core use cases

Apr 2014<= span style=3D'color:black'>

Consult with OPS area on possible SFC charter modifications for man= agement and configuration of SFC components related to the support of servi= ce function chaining

Jan 2015

Su= bmit to IESG Informational document defining the architecture for SFC

Jan 2015=

Submit to IESG Informational d= ocument defining the control plane requirements for conveying information b= etween control or management elements and SFC implementation points<= span style=3D'color:black'>

Aug 2015

Submit to IESG Standards Track d= ocument specifying the generic service function chaining header encapsulati= on

 

_______________________________________________
nsc maili= ng list
nsc= @ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C790F7F8MAILR002maill_-- From sarikaya2012@gmail.com Wed Nov 20 08:09:41 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E7081AE01B for ; Wed, 20 Nov 2013 08:09:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 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, J_CHICKENPOX_26=0.6, 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 PkxEsO7XCfLQ for ; Wed, 20 Nov 2013 08:09:38 -0800 (PST) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6125D1ADF6D for ; Wed, 20 Nov 2013 08:09:37 -0800 (PST) Received: by mail-la0-f50.google.com with SMTP id el20so7451227lab.37 for ; Wed, 20 Nov 2013 08:09:30 -0800 (PST) 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=O1vSlLaCUQ/0sIDGXvnjihRxwWIcsuVh9ThDjbzNo+s=; b=ZLs/csEcUagTG28wvZVYcCDa5PRKxUiJ2uRpnxWL18nl59p64LZx6e5EWzg3v62CaR 5Rflc4ddslbdLQciVy6DBQ3ViJLi280cUcutIYIE4Jblnu7diItALpUnelRvbN4ANCAQ hc5CMv+dWg61wptVjU2+9tGGpwesPuIajSKppv0WWCdEYNTj5ETb4gK1Frzrz7ee7cJj BTdHvbxnLSTrhuhZiuvcDBuYmsIjizxrBe0cp2xKDfPLtkw5oIlWJy9027ImcWkod87F 9Lq23oP1QeXJl+j8ySyrKnsawdk4mBuj7xjpv1VVf0VhmmdU/5rI68Wq3aK9OVNramSi GUxw== MIME-Version: 1.0 X-Received: by 10.112.125.33 with SMTP id mn1mr988923lbb.8.1384963769770; Wed, 20 Nov 2013 08:09:29 -0800 (PST) Received: by 10.114.217.129 with HTTP; Wed, 20 Nov 2013 08:09:29 -0800 (PST) In-Reply-To: <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> <94C682931C08B048B7A8645303FDC9F36F32426362@PUEXCB1B.nanterre.francetelecom.fr> Date: Wed, 20 Nov 2013 10:09:29 -0600 Message-ID: From: Behcet Sarikaya To: Mohamed Boucadair Content-Type: multipart/alternative; boundary=089e0116136a8627f404eb9e01cf Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Ron Parker , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@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, 20 Nov 2013 16:09:41 -0000 --089e0116136a8627f404eb9e01cf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Med, I think that the parental control service is an example. Another example is the traffic offloader service that we defined in draft-xue-aps-service chaining-usecase-00.txt. Regards, Behcet On Fri, Nov 15, 2013 at 3:08 AM, wrote: > Hi Behcet, > > > > Which requirements document are you referring to? This one > http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00? > > > > We should make a distinction between classification rules and the set of > SFCs themselves. Classification rules may be subscriber-inferred while I= =92m > still not convinced the set of SFCs should be built on a per-subscriber > basis. > > > > Cheers, > > Med > > > > *De :* nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] *De la part de*= Behcet Sarikaya > *Envoy=E9 :* mercredi 16 octobre 2013 00:11 > *=C0 :* Ian Smith > *Cc :* nsc@ietf.org; Jim Guichard (jguichar); Liushucheng (Will); Ron > Parker > *Objet :* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > Folks, I checked and found out that in the requirements draft > per-subscriber service issue is pretty clearly stated. > > My suggestion is to remove the paragraph that starts with SFC are not > per-subscriber. It is confusing. > > Regards, > > Behcet > > > > On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith wrote: > > I'll see what I can do. > ------------------------------ > > *From:* Jim Guichard (jguichar) [jguichar@cisco.com] > > *Sent:* Tuesday, October 15, 2013 5:14 PM > *To:* Ian Smith > *Cc:* Ron Parker; ; nsc@ietf.org; Liushucheng (Will) > > > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > Use cases from real operators would be a start. > > Sent from my iPhone > > > On Oct 15, 2013, at 5:11 PM, "Ian Smith" wrote: > > what do you need to make this reality driven? > ------------------------------ > > *From:* Jim Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 5:02 PM > *To:* Ron Parker > *Cc:* ; nsc@ietf.org; Liushucheng (Will); Ian Smith > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > Sure but we should deal in reality driven by use cases and I have yet to > see anyone suggest they will build an individual service chain for every > client. In fact the complete opposite seems true. > > Sent from my iPhone > > > On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: > > Agree that is the typical usage of policy. And, the degenerate case is > that the world is comprised of subscriber groups that have exactly 1 > subscriber. Probably not practical, but why prevent it? > > > > Ron > > > > *From:* nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Jim Guichard (jguichar) > *Sent:* Tuesday, October 15, 2013 4:48 PM > *To:* > *Cc:* nsc@ietf.org; Liushucheng (Will); Ian Smith > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > No, to me this is most certainly a per-subscriber-group. > > Sent from my iPhone > > > On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: > > I was talking about something like parental control. > > Do you qualify such an SFC as each mobile client getting its own SFC? > > I think it is more like per-subscriber-group. It could be per subscriber > as well but I can not think of an example at this moment. > > > > On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) < > jguichar@cisco.com> wrote: > > Hi Ian, > > If by subscriber you mean per-tenant or per-subscriber-group then I will > agree that SFC's will be built for these but that's a far cry from > per-subscriber which implies to me an individual broadband or mobile clie= nt. > > Sent from my iPhone > > > On Oct 15, 2013, at 1:51 PM, "Ian Smith" wrote: > > I don't think that is a foregone conclusion. > > When you combine what is being done in IaaS environments for muti-tenant > dynamic datacenters with what you can do with policy defined networking a= nd > IPv6, for an access provider to provision per-subscriber VAS LANs and > default gateways takes away a lot of the big problems caused by aggregati= on > that you're trying to solve with service chains. More to the point, you > don't need to disaggregate anything when you know that all the traffic > belongs to a single customer, and that the default gateway of each node i= s > the next hop in the service chain. Solving the problem for 1 > subscriber@1Gbps is trivial; what makes what we're talking about in this > list hard is that you are trying to solve it for 10 million subscribers > @100Gbps but in truth the only technology-based reason you do that is > because of administrative challenges that the cloud world is solving (and > may have solved before anything is produced in a WG) and that are squarel= y > in the domain of things already proven to be better done by computers tha= n > people. > > I tend to argue that per-subscriber provisioning of the access path > triggered by identity-based authentication is the obvious and natural > evolution of the technology being fielded today. > > > ------------------------------ > > *From:* nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim > Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 1:34 PM > *To:* sarikaya@ieee.org; Liushucheng (Will) > *Cc:* nsc@ietf.org > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > It seems very unlikely that one would opt for a solution whereby a > separate SFC is required per-subscriber; clearly millions of SFC's is not > desirable no matter how you cut it. IMHO, the support of services that > require per-subscriber policy are more likely to be realized using > something like the solution described in draft-quinn-sfc-nsh. > > > > *From: *Behcet Sarikaya > *Reply-To: *"sarikaya@ieee.org" > *Date: *Tuesday, October 15, 2013 11:44 AM > *To: *"Liushucheng (Will)" > *Cc: *"nsc@ietf.org" > *Subject: *Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > Hi Shucheng, > > In the use cases draft, you say that > > SFC are not per-subscriber. In other words, this document assumes > per-subscriber SFCs are not instantiated in the network. > Deployments cases that would require per-subscriber SFCs are out > of scope. > > However you have at least three parental control use cases. How would it > be possible to have parental control not being per-subscriber? > > Regards, > > Behcet > > > > On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) < > liushucheng@huawei.com> wrote: > > Folks, > > We've uploaded the updated and renamed use case draft. Looking forward to > your comments. > > Regards, > Shucheng LIU (Will) > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 10, 2013 3:42 PM > To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); > Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao > Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt > > > A new version of I-D, draft-liu-sfc-use-cases-00.txt > has been successfully submitted by Will(Shucheng) Liu and posted to the > IETF repository. > > Filename: draft-liu-sfc-use-cases > Revision: 00 > Title: Service Function Chaining Use Cases > Creation date: 2013-10-10 > Group: Individual Submission > Number of pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt > Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases > Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 > > > Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > > 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 > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > > --089e0116136a8627f404eb9e01cf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Med,

I think that the paren= tal control service is an example. Another example is the traffic offloader= service that we defined in draft-xue-aps-service chaining-usecase-00.txt.<= br>
Regards,

Behcet
=

On Fri, Nov 15, 2013 at 3:08 AM, <mohamed.boucadair@orange.com> wrote:

Hi Behcet,<= /p>

=A0

Which requirements document are you referring to? This one <= a href=3D"http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00" t= arget=3D"_blank">http://tools.ietf.org/html/draft-boucadair-sfc-requirement= s-00?

=A0

We should make a distinction between classification rules an= d the set of SFCs themselves. Classification rules may be subscriber-inferr= ed while I=92m still not convinced the set of SFCs should be built on a per= -subscriber basis.

=A0

Cheers,

Med

=A0

De= =A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la p= art de Behcet Sarikaya
Envoy=E9=A0: mercredi 16 octobre 2013 00:11
=C0=A0: Ian Sm= ith
Cc=A0: nsc@= ietf.org; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker
Objet=A0: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use= -cases-00.txt

=A0=

Folks, I checked and found out that in the requirements draft per-subscr= iber service issue is pretty clearly stated.

My suggestion i= s to remove the paragraph that starts with SFC are not per-subscriber. It i= s confusing.

Regards,

Behcet=

=A0

On Tue, Oct 15, 2013 at 4:14 PM,= Ian Smith <I.Smith@= f5.com> wrote:

I'll see what I can do.

From: Jim Guichard (jguichar) [jguichar@cisco.com]

Sent: Tuesday, October 15, 2013 5:14 PMTo: Ian Smith
Cc: Ron Parker; <sarikaya@ieee.org>; nsc@ietf.org; Liushucheng (Will)

=


Subject: Re: [nsc] FW: New Version Notificatio= n for draft-liu-sfc-use-cases-00.txt

=A0

Use c= ases from real operators would be a start.

Sent from my iPhone


On Oct 15, 2013, at 5:11 PM, "Ian Smith" <I.Smith@F5.com> wrote:=

<= div>

what do you need to make this reality dr= iven?=A0

From: Jim Guichard (jguichar) [jguichar@cisco.com= ]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
= Cc: <sarik= aya@ieee.org>; nsc= @ietf.org; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cases and I have yet to= see anyone suggest they will build an individual service chain for every c= lient. In fact the complete opposite seems true.

Sent from my iPhone


On Oct 15, 2013, at 4:52 PM, "Ron P= arker" <Ron_Parker@affirmednetworks.com> wrote:

=

Agree that is the typical= usage of policy.=A0=A0 And, the degenerate case is that the world is compr= ised of subscriber groups that have exactly 1 subscriber.=A0=A0 Probably no= t practical, but why prevent it?

=A0<= /p>

=A0=A0 Ron

=A0<= /p>

= =A0

=

=A0I was talking about something like pare= ntal control.

Do you qualify such an SFC as each mobile client getting its own SFC?

I t= hink it is more like per-subscriber-group. It could be per subscriber as we= ll but I can not think of an example at this moment.

= =A0

On Tue, Oct 15, 2013 at 2:= 52 PM, Jim Guichard (jguichar) <jguichar@cisco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-sub= scriber-group then I will agree that SFC's will be built for these but = that's a far cry from per-subscriber which implies to me an individual = broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, &= quot;Ian Smith" <I.Smith@F5.com> wrote:

=

I don't think that is a foregone con= clusion.=A0

When you combine what is being done in IaaS environments for muti-tenan= t dynamic datacenters with what you can do with policy defined networking a= nd IPv6, for an access provider to provision per-subscriber VAS LANs and de= fault gateways takes away a lot of the big problems caused by aggregation t= hat you're trying to solve with service chains.=A0 More to the point, y= ou don't need to disaggregate anything when you know that all the traff= ic belongs to a single customer, and that the default gateway of each node = is the next hop in the service chain.=A0 Solving the problem for 1 subscrib= er@1Gbps is trivial; what makes what we're talking about in this list h= ard is that you are trying to solve it for 10 million subscribers @100Gbps = but in truth the only technology-based reason you do that is because of adm= inistrative challenges that the cloud world is solving (and may have solved= before anything is produced in a WG) and that are squarely in the domain o= f things already proven to be better done by computers than people.

I tend to argue that per-subscriber provisioning of the access path tri= ggered by identity-based authentication is the obvious and natural evolutio= n of the technology being fielded today.

=A0

=

From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf = of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@ieee.org; Liushucheng= (Will)
Cc: nsc= @ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a separ= ate SFC is required per-subscriber; clearly millions of SFC's is not de= sirable no matter how you cut it. IMHO, the support of services that requir= e per-subscriber policy are more likely to be realized using something like= the solution described in draft-quinn-sfc-nsh.=A0

=A0

From: Behcet Sari= kaya <sarika= ya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 1= 5, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf.org&q= uot; <nsc@ietf.org= >
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

= =A0

Hi Shucheng,

In the use cases draft, you say that

SFC are not per= -subscriber.=A0 In other words, this document assumes
=A0=A0=A0=A0=A0 pe= r-subscriber SFCs are not instantiated in the network.
=A0=A0=A0=A0=A0 Deployments cases that would require per-subscriber SFCs ar= e out
=A0=A0=A0=A0=A0 of scope.

However you have at least three parent= al control use cases. How would it be possible to have parental control not= being per-subscriber?

Regards,=

Behcet

=

=A0

=

On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) <liushucheng@huawei.com> wro= te:

Folks,

We've uploaded the updated and ren= amed use case draft. Looking forward to your comments.

Regards,
S= hucheng LIU (Will)


-----Original Message-----
From: internet-drafts@ietf= .org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu;= Hongyu Li (Julio); Huangyong (Oliver); Mohamed Boucadair; Liushucheng (Wil= l); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draf= t-liu-sfc-use-cases-00.txt


A new version of I-D, draft-liu-sfc-use-cases-00.txt
has been su= ccessfully submitted by Will(Shucheng) Liu and posted to the
IETF reposi= tory.

Filename: =A0 =A0 =A0 =A0draft-liu-sfc-use-cases
Revision: = =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Service Function Chaining Use Cases
Creation = date: =A0 2013-10-10
Group: =A0 =A0 =A0 =A0 =A0 Individual SubmissionNumber of pages: 14
URL: =A0 =A0 =A0 =A0 =A0 =A0 = http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases
Htmlized: =A0 =A0 =A0 =A0http://tools.ie= tf.org/html/draft-liu-sfc-use-cases-00


Abstract:
=A0 =A0The delivery of value-added services relies on = the invocation of
=A0 =A0advanced Service Functions in a sequential orde= r. =A0This mechanism is
=A0 =A0called Service Function Chaining (SFC). = =A0The set of involved Service
=A0 =A0Functions and their order depends on the service context.

=A0= =A0This document presents a set of use cases of Service Function
=A0 = =A0Chaining (SFC).




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

_______________________________________________
nsc mailing li= st
nsc@ietf.org
https://= www.ietf.org/mailman/listinfo/nsc

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

=A0<= /u>

=A0


--089e0116136a8627f404eb9e01cf-- From kgray@juniper.net Wed Nov 20 09:58:27 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B101AE427 for ; Wed, 20 Nov 2013 09:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UICopHgL59gE for ; Wed, 20 Nov 2013 09:58:22 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 937001AE3F3 for ; Wed, 20 Nov 2013 09:58:22 -0800 (PST) Received: from mail88-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.22; Wed, 20 Nov 2013 17:58:16 +0000 Received: from mail88-co9 (localhost [127.0.0.1]) by mail88-co9-R.bigfish.com (Postfix) with ESMTP id EB0C21E01ED; Wed, 20 Nov 2013 17:58:15 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehz98dI9371Ic89bh936eI1444Mc85eh542I1418I9a6kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz8275ch16d858h1de098h1033IL17326ah18de19h8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h9a9j1155h) Received-SPF: pass (mail88-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51444003)(24454002)(377454003)(377424004)(13464003)(189002)(199002)(51884002)(80976001)(54356001)(74502001)(51856001)(66066001)(79102001)(87936001)(31966008)(47736001)(81542001)(49866001)(19580405001)(83322001)(80022001)(47446002)(4396001)(87266001)(14971765001)(65816001)(224313003)(53806001)(46102001)(63696002)(76482001)(76796001)(74876001)(76786001)(77982001)(33646001)(15975445006)(76576001)(83072001)(16297215004)(15202345003)(59766001)(69226001)(224303002)(19580395003)(50986001)(81686001)(47976001)(16236675002)(74366001)(2656002)(81342001)(74662001)(56816003)(56776001)(85306002)(81816001)(74706001)(74316001)(54316002)(77096001)(24704002)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail88-co9 (localhost.localdomain [127.0.0.1]) by mail88-co9 (MessageSwitch) id 1384970293760981_940; Wed, 20 Nov 2013 17:58:13 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.233]) by mail88-co9.bigfish.com (Postfix) with ESMTP id AE51D440075; Wed, 20 Nov 2013 17:58:13 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 20 Nov 2013 17:58:12 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 20 Nov 2013 17:58:09 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) with Microsoft SMTP Server (TLS) id 15.0.820.5; Wed, 20 Nov 2013 17:58:08 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.31]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.246]) with mapi id 15.00.0820.005; Wed, 20 Nov 2013 17:58:07 +0000 From: Ken Gray To: Mohamed Boucadair , "sarikaya@ieee.org" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHO5gr0Qq8hHVmfakC0RtFaYFc4TZouXrt2 Date: Wed, 20 Nov 2013 17:58:06 +0000 Message-ID: <28666084ac6d4041a790387557b92a4e@BL2PR05MB082.namprd05.prod.outlook.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> <94C682931C08B048B7A8645303FDC9F36F32426362@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: [66.129.241.10] x-forefront-prvs: 0036736630 Content-Type: multipart/alternative; boundary="_000_28666084ac6d4041a790387557b92a4eBL2PR05MB082namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Liushucheng \(Will\)" , Ron Parker , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 17:58:27 -0000 --_000_28666084ac6d4041a790387557b92a4eBL2PR05MB082namprd05pro_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To me the difference is between making decisions within a chain based on us= er-data (which could be metadata placed by the initial classifier at the he= ad of the chain) versus establishing a new chain per-user. These examples = (so far) don't illustrate the latter. A separate chain would be required "per user" because the service required = a separate, per-subscriber interface (e.g. for some non-common/unshared con= figuration ... like on a FW ... or some treatment within the function that = can't be handled solely by the metadata) on at least one of the SF in the c= hain. Clearly, there are cases where a particular service might branch based on u= ser-id and some pre-condition at the decision point. But I still don't see= a separate per-user chain beyond that point. Arguably, when I come up with an example of a per-user chain, it's normally= at a fan-out point at the terminus of the chain - which may still not qual= ify as an example we'd want to chase, since you'd be racing the scalability= of placing some stateless LB function in the NNH of the chain against the = scalability of per-user chain state management for that last step steering = (LB in the central chain-building process). My .02 ________________________________ From: nsc on behalf of Behcet Sarikaya Sent: Wednesday, November 20, 2013 11:09 AM To: Mohamed Boucadair Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker; Liushucheng (Will); = Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Med, I think that the parental control service is an example. Another example is= the traffic offloader service that we defined in draft-xue-aps-service cha= ining-usecase-00.txt. Regards, Behcet On Fri, Nov 15, 2013 at 3:08 AM, > wrote: Hi Behcet, Which requirements document are you referring to? This one http://tools.iet= f.org/html/draft-boucadair-sfc-requirements-00? We should make a distinction between classification rules and the set of SF= Cs themselves. Classification rules may be subscriber-inferred while I=92m = still not convinced the set of SFCs should be built on a per-subscriber bas= is. Cheers, Med De : nsc-bounces@ietf.org [mailto:nsc-bounces@= ietf.org] De la part de Behcet Sarikaya Envoy=E9 : mercredi 16 octobre 2013 00:11 =C0 : Ian Smith Cc : nsc@ietf.org; Jim Guichard (jguichar); Liushuchen= g (Will); Ron Parker Objet : Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-= 00.txt Folks, I checked and found out that in the requirements draft per-subscribe= r service issue is pretty clearly stated. My suggestion is to remove the paragraph that starts with SFC are not per-s= ubscriber. It is confusing. Regards, Behcet On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith > wrote: I'll see what I can do. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:14 PM To: Ian Smith Cc: Ron Parker; >; nsc@ietf.org= ; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Use cases from real operators would be a start. Sent from my iPhone On Oct 15, 2013, at 5:11 PM, "Ian Smith" > wrote: what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: >; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). 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 _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_28666084ac6d4041a790387557b92a4eBL2PR05MB082namprd05pro_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

To me the difference is between making decisions within a chain based on= user-data (which could be metadata placed by the initial classifier at the= head of the chain) versus establishing a new chain per-user.  These e= xamples (so far) don't illustrate the latter.


A separate chain would be required "per user" because the serv= ice required a separate, per-subscriber interface (e.g. for some non-common= /unshared configuration ... like on a FW ... or some treatment within the f= unction that can't be handled solely by the metadata) on at least one of the SF in the chain.


Clearly, there are cases where a particular service might branch based o= n user-id and some pre-condition at the decision point.  But I still d= on't see a separate per-user chain beyond that point.


Arguably, when I come up with an example of a per-user chain, it's norma= lly at a fan-out point at the terminus of the chain - which may still not q= ualify as an example we'd want to chase, since you'd be racing the scalabil= ity of placing some stateless LB function in the NNH of the chain against the scalability of per-user chain= state management for that last step steering (LB in the central chain-buil= ding process).


My .02

From: nsc <nsc-bounces@i= etf.org> on behalf of Behcet Sarikaya <sarikaya2012@gmail.com>
Sent: Wednesday, November 20, 2013 11:09 AM
To: Mohamed Boucadair
Cc: nsc@ietf.org; Jim Guichard (jguichar); Ron Parker; Liushucheng (= Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt
 
Hi Med,

I think that the parental control service is an example. Another example is= the traffic offloader service that we defined in draft-xue-aps-service cha= ining-usecase-00.txt.

Regards,

Behcet


On Fri, Nov 15, 2013 at 3:08 AM, <mo= hamed.boucadair@orange.com> wrote:

Hi Behcet,

 

Which requirements document are you referr= ing to? This one http://tools.ietf.org/html/draft-boucadair-sfc-requirements-00? =

 

We should make a distinction between class= ification rules and the set of SFCs themselves. Classification rules may be= subscriber-inferred while I=92m still not convinced the set of SFCs should be built on a per-subscriber basis.

 

Cheers,

Med

 

De : nsc-bounces@ietf.= org [mailto:n= sc-bounces@ietf.org] De la part de Behcet Sarikaya
Envoy=E9 : mercredi 16 octobre 2013 00:11
=C0 : Ian Smith
Cc : nsc@ietf= .org; Jim Guichard (jguichar); Liushucheng (Will); Ron Parker
Objet : Re: [nsc] FW: New Version Notification for draft-liu-sf= c-use-cases-00.txt

 

Folks, I checked and = found out that in the requirements draft per-subscriber service issue is pr= etty clearly stated.

My suggestion is to r= emove the paragraph that starts with SFC are not per-subscriber. It is conf= using.

Regards,

Behcet

 <= /p>

On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith <I.Smith@f5.com> wrote= :

I'll see= what I can do.

From: Jim Guichard (jguichar) [jguichar@cisco.com]

Sent: Tuesday, October 15, 2013 5:14 PM
To: Ian Smith
Cc: Ron Parker; <sarikaya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will)


Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Use cases from real operators would be a start.

Sent from my iPhone


On Oct 15, 2013, at 5:11 PM, "Ian Smith" <I.Smith@F5.com> wrote:=

what do you need to make this reality d= riven? 

From: Jim Guichar= d (jguichar) [jguic= har@cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarik= aya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cas= es and I have yet to see anyone suggest they will build an individual servi= ce chain for every client. In fact the complete opposite seems true.

Sent from my iPhone


On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typic= al usage of policy.   And, the degenerate case is that the world = is comprised of subscriber groups that have exactly 1 subscriber. &nbs= p; Probably not practical, but why prevent it?

 =

   Ron=

 =

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 <= /p>

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:=

I don't think that is a foregone conclu= sion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 <= /p>

On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) = <liushucheng= @huawei.com> wrote:

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


A new version of I-D, draft-liu-sfc-use-cases-00.txt
has been successfully submitted by Will(Shucheng) Liu and posted to the
IETF repository.

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/draft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

   This document presents a set of use cases of Service Function<= br>    Chaining (SFC).




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

_______________________________________________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinf= o/nsc

 

 

 


--_000_28666084ac6d4041a790387557b92a4eBL2PR05MB082namprd05pro_-- From jmoisand@juniper.net Wed Nov 20 10:05:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7591AE0CB for ; Wed, 20 Nov 2013 10:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45aCOAtagLyT for ; Wed, 20 Nov 2013 10:05:33 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id DB0DA1AE02C for ; Wed, 20 Nov 2013 10:05:32 -0800 (PST) Received: from mail103-co1-R.bigfish.com (10.243.78.229) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.22; Wed, 20 Nov 2013 18:05:26 +0000 Received: from mail103-co1 (localhost [127.0.0.1]) by mail103-co1-R.bigfish.com (Postfix) with ESMTP id 45399AC070B; Wed, 20 Nov 2013 18:05:26 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zz98dI9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1c8fb4h1de097h186068h1954cbhz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h9a9j1155h) Received-SPF: pass (mail103-co1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(24454002)(199002)(189002)(47446002)(31966008)(80022001)(79102001)(66066001)(87936001)(56776001)(74502001)(59766001)(74662001)(63696002)(74316001)(65816001)(33646001)(4396001)(49866001)(76482001)(81542001)(54356001)(76786001)(81342001)(2656002)(85306002)(46102001)(47736001)(16601075003)(19580395003)(19580405001)(83322001)(56816003)(51856001)(83072001)(16236675002)(77096001)(81816001)(81686001)(74366001)(76576001)(87266001)(74706001)(69226001)(50986001)(15202345003)(54316002)(80976001)(77982001)(47976001)(76796001)(15975445006)(18717965001)(74876001)(53806001)(19609705001)(19300405004)(24736002)(579004); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB250; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail103-co1 (localhost.localdomain [127.0.0.1]) by mail103-co1 (MessageSwitch) id 1384970722529742_31860; Wed, 20 Nov 2013 18:05:22 +0000 (UTC) Received: from CO1EHSMHS010.bigfish.com (unknown [10.243.78.234]) by mail103-co1.bigfish.com (Postfix) with ESMTP id 7D66488004B; Wed, 20 Nov 2013 18:05:22 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS010.bigfish.com (10.243.66.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 20 Nov 2013 18:05:22 +0000 Received: from BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 20 Nov 2013 18:05:15 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 20 Nov 2013 18:05:13 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.83]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.138]) with mapi id 15.00.0815.000; Wed, 20 Nov 2013 18:05:13 +0000 From: Jerome Moisand To: Kevin J Ma , Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAzNug Date: Wed, 20 Nov 2013 18:05:13 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0036736630 Content-Type: multipart/alternative; boundary="_000_da77203932d44bc4ba489f602d87b0b8BN1PR05MB251namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 18:05:40 -0000 --_000_da77203932d44bc4ba489f602d87b0b8BN1PR05MB251namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I share a similar concern. If the service function software takes good care= of untagging incoming packets on the way in, and retagging outgoing packet= s (maybe the same packets as the incoming one or maybe something completely= different as Kevin illustrated) with the appropriate metadata on the way o= ut, then we should be fine. Whether the SF is an application proxy or a mor= e simple L3-centric packet processor, it then shouldn't matter. Packet-cent= ric devices (e.g. routers) are usually pretty good at keep some form of con= text on their internal data path when processing a packet in/out, but app-c= entric software may not be designed like that. So... that is quite an assumption (*all* SF software will have to do so -un= tagging/retagging-, whether they are actively interested in the packet meta= data or not), and indeed a possibly severe barrier to entry. From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Wednesday, November 20, 2013 1:27 AM To: Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_da77203932d44bc4ba489f602d87b0b8BN1PR05MB251namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I share a similar concern= . If the service function software takes good care of untagging incoming pa= ckets on the way in, and retagging outgoing packets (maybe the same packets as the incoming one or maybe something completely differe= nt as Kevin illustrated) with the appropriate metadata on the way out, then= we should be fine. Whether the SF is an application proxy or a more simple= L3-centric packet processor, it then shouldn’t matter. Packet-centric devices (e.g. routers) are usu= ally pretty good at keep some form of context on their internal data path w= hen processing a packet in/out, but app-centric software may not be designe= d like that.

 <= /p>

So… that is quite a= n assumption (*all* SF software will have to do so –untagging/retaggi= ng-, whether they are actively interested in the packet metadata or not), and indeed a possibly severe barrier to entry.

 <= /p>

 <= /p>

From: nsc [mai= lto:nsc-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,

 

  My primary concern is with the word "packet&qu= ot;.  If we are only considering

  network layer packets, with network layer classific= ation and encapsulation,

  then that is one thing, but if we are talking about= application layer

  classification, then network layer encapsulation po= ses and issue.  The data

  that comes out of a service function is not necessa= rily the same data that

 went into the service function.  At the applica= tion layer, a socket is not

  inherently service chain aware.

 

 If one builds a load balancer, AV scanner, etc. as a= n appliance (not part

 of a router), today we have mechanisms for getting t= he traffic in and out

 of those appliances by configuring VLANs and IP addr= esses (as noted in the

  problem statement, section 2, bullet 8).  If w= e want the service chain ID

  in the encapsulation header to be the new mechanism= , then these appliances

 need to know the ingress chain ID and the be able to= set the egress chain

 ID.  An off-the-shelf linux box can support the= existing IP mechanism.  It

  seems to me that a new encapsulation layer might ex= clude existing appliance

  implementations and introduce a new barrier to entr= y.

 

  Let me try a more concrete example:

 

  Given a set of service chains that: optionally term= inates client-side TLS,

 performs HTTP request routing, optionally performs A= V checks for HTTP POST,

 does server load balancing, and optionally initiates= back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> = BE_TLS -->

          &nb= sp;  /      \     &n= bsp;    ^  \

          &nb= sp; /        \    &n= bsp;   /    \

  ---------+       =    +------+      +-----= ----->

 

  Assume RR, AV, and LB are all services provided by = independent appliances,

 and FE_TLS and BE_TLS are different instances of the= same TLS service

  provided by a fourth independent appliance.  T= he possible chains are:

 

  chain 1:        =  RR,     LB

  chain 2:        =  RR, AV, LB

  chain 3: FE_TLS, RR,     LB

  chain 4: FE_TLS, RR, AV, LB

  chain 5:        =  RR,     LB, BE_TLS

  chain 6:        =  RR, AV, LB, BE_TLS

  chain 7: FE_TLS, RR,     LB, BE= _TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would always choose from eit= her chain 1 or chain 3.

  (e.g., based on the TCP destination port).

 

  RR would then choose either chain (1, 2) or chain (= 3, 4), respectively.

 

  LB would then choose either chain (1, 2, 5, 6) or c= hain (3, 4, 7, 8),

 respectively.

 

  The decisions made by RR/LB seem unlikely to be mad= e on an IP packet basis,

  yet still need to influence the chain ID encapsulat= ion?

 

  Now, TLS/RR/LB might all be in the same appliance, = but even so, the chain

  to AV still has the same issue.

 

  So, I guess my question is: Is this a valid DC use = case for SFC?

 

thanx.

 

--  Kevin J. Ma

 

From: Ron Park= er [mailto:Ron_Parker@af= firmednetworks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 <= /p>

Can you  explain you= r thinking on why service function chaining would be cognizant of the layer= at which the service function operates?   As I see it, any servi= ce function is free to modify the original packet in a manner that suits it.&= nbsp;  It also has the choice to allow the packet (modified or unmodif= ied) to progress on the original service function chain or to intercede wit= h the local service function chaining functionality such that it jumps onto a new chain.   In either case, the local= service function chaining functionality will cause the packet to be proper= ly encapsulated in order to be conveyed to the next service function (or fo= rwarded off the end of the chain, if applicable).

 <= /p>

   Ron

 <= /p>

 <= /p>

From: nsc [<= a href=3D"mailto:nsc-bounces@ietf.org">mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wro= te:

 

Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

Personally, I am still unclear as to how this would work f= or application layer

services.  It's not a control plane issue if it's ses= sion data dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 

 

I won't rehash the previous discussion on "packet-lev= el" classification and

"packet-level" encapsulation, but IMO there are = a number of issues cited in

the problem statement which are not solved by simply defin= ing an encapsulation

header.  Yes, there are other informational documents= on the list, but if they

do not address these questions on how the encapsulation ma= y be used (and how

different levels of classification/re-classification will = work), then the

encapsulation spec has to stand on its own.  The char= ter could be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] 
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisys= tems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"=

 

Jim> yes, thank you, I corrected the= text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show that= the steering function is independent of the services layer. As packets tra= verse a service chain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the contr= ol plane which would make available to the service function (or proxy) info= rmation about inbound and outbound service function chain encapsulation.&nb= sp;

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 

Greetings= ,

 

Thomas Na= rten and I have spent some time refining the SFC charter based upon discuss= ion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the mana= gement vs. control plane text and added text around security. Please r= eview the revised charter and provide comment.

 

Revised SFC WG Charter:=

 

Service deliv= ery is undergoing significant change with the introduction of virtualizatio= n, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge that involves s= ignificant modification to the network configuration thereby impacting the = speed at which services can be deployed and increasing operational costs. S= ervices are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 =

For a given service, the abstracted view of the require= d service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 =

The SFC working group will document a new approach to s= ervice delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

Specifically, the SFC WG is chartered to deliver the fo= llowing:

1.<= span style=3D"font-size:7.0pt"> =  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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.<= span style=3D"font-size:7.0pt"> =  Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.<= span style=3D"font-size:7.0pt"> =  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= o:p>

4.<= span style=3D"font-size:7.0pt"> =  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.<= span style=3D"font-size:7.0pt"> =  Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defi= ning the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC char= ter modifications for management and configuration of SFC components relate= d to the support of service function chaining

Jan 2015

Submit to IESG Informational document defi= ning the architecture for SFC

Jan 2015

Submit to IESG Informational document defi= ning the control plane requirements for conveying information between contr= ol or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document sp= ecifying the generic service function chaining header encapsulation<= o:p>

 

_____________________________________= __________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 

--_000_da77203932d44bc4ba489f602d87b0b8BN1PR05MB251namprd05pro_-- From S.Majee@f5.com Wed Nov 20 10:17:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35171AE4B2 for ; Wed, 20 Nov 2013 10:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.525 X-Spam-Level: X-Spam-Status: No, score=-7.525 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.525, 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 UwCKjZE3KRC3 for ; Wed, 20 Nov 2013 10:17:38 -0800 (PST) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 56B781AE4FA for ; Wed, 20 Nov 2013 10:17:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1384971452; x=1416507452; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=REv8FVj4UO0vWaByDJ+QACVjKq3SuzbZ343DdCvo/rE=; b=ro/4eLyBEwgMyEp3TOh+1bxTMvfvLBsj0EQ7dEI7LXC1v9scPMCwDttE piNddPFzPxDfwR1E3qdWS8a0LBQIpiObBCQKAx9Evtby9FK61kCjvDSPd 58xK8QMs9YZqlSKL7Gbh4W6TlKChmQP8xYL5v2N1LpW/zONd5XWyUZjHT A=; X-IronPort-AV: E=Sophos;i="4.93,738,1378857600"; d="scan'208,217";a="87976220" X-IPAS-Result: AqQEAPn7jFLAqArr/2dsb2JhbABZgkN8U71vgTB0giUBAQEBAwEBARcBDD4CBwQHEAIBCA0EAQIBAQELFgEGBycLFAMGCAIEAQ0FCIgGrlKSJBeOFYERIAcGBAYBBgODF4ESA5QwhRGFN45PgWhC Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 20 Nov 2013 18:17:30 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 20 Nov 2013 10:17:29 -0800 From: Sumandra Majee To: Ron Parker , Kevin J Ma , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAhKaggABNsOI= Date: Wed, 20 Nov 2013 18:17:29 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E41609884935304@SEAEMBX01.olympus.F5Net.com> References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_0BF7E0211CA62B42AE3FD4020E41609884935304SEAEMBX01olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 18:17:44 -0000 --_000_0BF7E0211CA62B42AE3FD4020E41609884935304SEAEMBX01olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >>A service function is free to create new flows that have no exact corresp= ondence to incoming flows and to subject those new flows to any service cha= in (or none) independently. That is quite possible. However what is the logic that says a new Flow F2 i= s actually part of the original flow (f0). The presence of header, possibly= . Let me provide two example, a) A caching server creates a new flow to bring in content from OWS, thi= s is a new flow sip=3Dcache_server_ip. However this is not really the part= of the original flow. b) A flow gets terminated by WAP proxy and creates a brand new flow on t= he internet side. This is definitely the part of the original flow f0. In both cases some cooperation from actual service implementation may be re= quired. Sumandra ________________________________ From: nsc [nsc-bounces@ietf.org] on behalf of Ron Parker [Ron_Parker@affirm= ednetworks.com] Sent: Wednesday, November 20, 2013 6:02 AM To: Kevin J Ma; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi, Kevin. Thanks for the thoughtful analysis. Responses below. Ron From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Wednesday, November 20, 2013 1:27 AM To: Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Ron>> I don=92t doubt that development is required to support the new mecha= nisms, natively. In draft-parker-sfc-chain-to-path, section 3.1, an SFC p= roxy is introduced to front-end legacy implementations. The SFC proxy cou= ld conceivably be co-located with the legacy service function or could stan= d alone. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Ron>> I don=92t see a limitation here. The RR/LB can use stateful flow an= alysis, local policy, or any other techniques to manage the selection of ch= ain for any packets that are transmitted by the RR/LB. Such packets are n= ot limited to packets that are received by the RR/LB (i.e., it is entirely = permissible to create new flows). Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. Ron>> The multiple logical service functions could each be located to the s= ame IP address (which does, indeed have implications on the SFC service hea= der =96 it needs to carry both the chain ID and the hop ID within the chain= so that the composite service function may understand which is the initial= service function to apply). So, I guess my question is: Is this a valid DC use case for SFC? Ron>> I consider your use case entirely valid and exactly what I have in mi= nd when I think about SFC. Implementation issues will always exist, but t= hat is why we are employed :). I think your concerns may have been whethe= r SFC is restricted to a packet-in-packet-out type of model. In my opinio= n, it is not. A service function is free to create new flows that have no= exact correspondence to incoming flows and to subject those new flows to a= ny service chain (or none) independently. Ron>> All of this does bring up an area, in my mind, that requires further= attention by the group, and perhaps this was on your mind, too. How to h= andle the reverse direction flows? In the simple case, where we have a li= near chain with no branching and no flow creation, we could conceivably arr= ange the single classifier to see the packets upon entry to the domain in b= oth directions. If the classifier is stateful, it can easily manage rever= se propagation down the chains (i.e., upstream A, B, C; downstream C, B, A)= . But, if new flows are created at a service function, and properly stamp= ed by the service function with the correct chain information, the correspo= nding reverse flows don=92t enter the domain at the service function, so wh= ere is the logic to place those flows on the proper reverse chain? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_0BF7E0211CA62B42AE3FD4020E41609884935304SEAEMBX01olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
>>A service function is free to create new flows that have no exact correspond= ence to incoming flows and to subject those new flows to any service chain = (or none) independently.

That is quite possible. However what is the logic that says a new Flow F2 i= s actually part of the original flow (f0). The presence of header, possibly= .  Let me provide two example,

   a) A caching server creates a new flow to bring in content fro= m OWS, this is a new flow sip=3Dcache_server_ip.  However this is not = really the part of the original flow.
   b) A flow gets terminated by WAP proxy and creates a brand new= flow on the internet side. This is definitely the part of the original flo= w f0.

In both cases some cooperation from actual service implementation may be re= quired.

Sumandra
From: nsc [nsc-bounces@ietf.org] on behal= f of Ron Parker [Ron_Parker@affirmednetworks.com]
Sent: Wednesday, November 20, 2013 6:02 AM
To: Kevin J Ma; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

Hi, Kevin.

 

Thanks for the thoughtf= ul analysis.  Responses below.

 

   Ron=

 

From: Kevi= n J Ma [mailto:kevin.ma@azukisystems.com]
Sent: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi Paul/Ron,

 

  My primary concern is with the word "packet&q= uot;.  If we are only considering

  network layer packets, with network layer classifi= cation and encapsulation,

  then that is one thing, but if we are talking abou= t application layer

  classification, then network layer encapsulation p= oses and issue.  The data

  that comes out of a service function is not necess= arily the same data that

 went into the service function.  At the applic= ation layer, a socket is not

  inherently service chain aware.

 

 If one builds a load balancer, AV scanner, etc. as = an appliance (not part

 of a router), today we have mechanisms for getting = the traffic in and out

 of those appliances by configuring VLANs and IP add= resses (as noted in the

  problem statement, section 2, bullet 8).  If = we want the service chain ID

  in the encapsulation header to be the new mechanis= m, then these appliances

 need to know the ingress chain ID and the be able t= o set the egress chain

 ID.  An off-the-shelf linux box can support th= e existing IP mechanism.  It

  seems to me that a new encapsulation layer might e= xclude existing appliance

  implementations and introduce a new barrier to ent= ry.

 

Ron>> I don=92t d= oubt that development is required to support the new mechanisms, natively. =   In draft-parker-sfc-chain-to-path, section 3.1, an SFC proxy is introduced to front-end legacy implementations.   The SFC proxy = could conceivably be co-located with the legacy service function or could s= tand alone.

 

 

  Let me try a more concrete example:

 

  Given a set of service chains that: optionally ter= minates client-side TLS,

 performs HTTP request routing, optionally performs = AV checks for HTTP POST,

 does server load balancing, and optionally initiate= s back-end TLS:

 

  --> FE_TLS --> RR --> AV --> LB -->= BE_TLS -->

          &n= bsp;  /      \     &= nbsp;    ^  \

          &n= bsp; /        \    &= nbsp;   /    \

  ---------+       = ;   +------+      +----= ------>

 

  Assume RR, AV, and LB are all services provided by= independent appliances,

 and FE_TLS and BE_TLS are different instances of th= e same TLS service

  provided by a fourth independent appliance.  = The possible chains are:

 

  chain 1:        = ; RR,     LB

  chain 2:        = ; RR, AV, LB

  chain 3: FE_TLS, RR,     LB

  chain 4: FE_TLS, RR, AV, LB

  chain 5:        = ; RR,     LB, BE_TLS

  chain 6:        = ; RR, AV, LB, BE_TLS

  chain 7: FE_TLS, RR,     LB, B= E_TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would always choose from ei= ther chain 1 or chain 3.

  (e.g., based on the TCP destination port).<= /p>

 

  RR would then choose either chain (1, 2) or chain = (3, 4), respectively.

 

  LB would then choose either chain (1, 2, 5, 6) or = chain (3, 4, 7, 8),

 respectively.

 

  The decisions made by RR/LB seem unlikely to be ma= de on an IP packet basis,

  yet still need to influence the chain ID encapsula= tion?

 

Ron>> I don=92t s= ee a limitation here.   The RR/LB can use stateful flow analysis,= local policy, or any other techniques to manage the selection of chain for any packets that are transmitted by the RR/LB.   Such packets ar= e not limited to packets that are received by the RR/LB (i.e., it is entire= ly permissible to create new flows).

 

  Now, TLS/RR/LB might all be in the same appliance,= but even so, the chain

  to AV still has the same issue.

 

Ron>> The multipl= e logical service functions could each be located to the same IP address (w= hich does, indeed have implications on the SFC service header =96 it needs to carry both the chain ID and the hop ID within the chain so= that the composite service function may understand which is the initial se= rvice function to apply).

 

  So, I guess my question is: Is this a valid DC use= case for SFC?

 

Ron>> I consider = your use case entirely valid and exactly what I have in mind when I think a= bout SFC.   Implementation issues will always exist, but that is why we are employed :).   I think your concerns may have been= whether SFC is restricted to a packet-in-packet-out type of model. &n= bsp; In my opinion, it is not.   A service function is free to cr= eate new flows that have no exact correspondence to incoming flows and to subject those new flows to any service chain (or none) independentl= y.  

 

Ron>>  All o= f this does bring up an area, in my mind, that requires further attention b= y the group, and perhaps this was on your mind, too.   How to han= dle the reverse direction flows?   In the simple case, where we have= a linear chain with no branching and no flow creation, we could conceivabl= y arrange the single classifier to see the packets upon entry to the domain= in both directions.   If the classifier is stateful, it can easily manage reverse propagation down the chains (i.e., = upstream A, B, C; downstream C, B, A).   But, if new flows are cr= eated at a service function, and properly stamped by the service function w= ith the correct chain information, the corresponding reverse flows don=92t enter the domain at the service function, so where i= s the logic to place those flows on the proper reverse chain?

 

 

thanx.

 

--  Kevin J. Ma

 

From: Ron Pa= rker [= mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 

Can you  explain y= our thinking on why service function chaining would be cognizant of the lay= er at which the service function operates?   As I see it, any service function is free to modify the original packet in a manner that su= its it.   It also has the choice to allow the packet (modified or= unmodified) to progress on the original service function chain or to inter= cede with the local service function chaining functionality such that it jumps onto a new chain.   In either c= ase, the local service function chaining functionality will cause the packe= t to be properly encapsulated in order to be conveyed to the next service f= unction (or forwarded off the end of the chain, if applicable).

 

   Ron=

 

 

From: nsc = [mailto:nsc-bounc= es@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 

 

Jim> this would be part of the cont= rol plane which would make available to the service function (or proxy) inf= ormation about inbound and outbound service function chain encapsulation. 

 

Personally, I am still unclear as to how this would work = for application layer

services.  It's not a control plane issue if it's se= ssion data dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 

 

I won't rehash the previous discussion on "packet-le= vel" classification and

"packet-level" encapsulation, but IMO there are= a number of issues cited in

the problem statement which are not solved by simply defi= ning an encapsulation

header.  Yes, there are other informational document= s on the list, but if they

do not address these questions on how the encapsulation m= ay be used (and how

different levels of classification/re-classification will= work), then the

encapsulation spec has to stand on its own.  The cha= rter could be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] 
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org=
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguichar@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"

 

Jim> yes, thank you, I corrected th= e text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show tha= t the steering function is independent of the services layer. As packets tr= averse a service chain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the cont= rol plane which would make available to the service function (or proxy) inf= ormation about inbound and outbound service function chain encapsulation. 

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.o= rg
Subject: [nsc] Rev= ised SFC Charter

 

Greeting= s,

 

Thomas N= arten and I have spent some time refining the SFC charter based upon discus= sion during the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified th= e management vs. control plane text and added text around security. Please&= nbsp;review the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service deli= very is undergoing significant change with the introduction of virtualizati= on, network overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge that involve= s significant modification to the network configuration thereby impacting t= he speed at which services can be deployed and increasing operational costs= . Services are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 

For a given service, the abstracted view of the requir= ed service functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 

The SFC working group will document a new approach to = service delivery and operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

Specifically, the SFC WG is chartered to deliver the f= ollowing:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.=   Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.=   Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= /p>

4.=   Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.=   Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document def= ining the SFC problem statement and core use cases

Apr 2014

Consult with OPS area on possible SFC cha= rter modifications for management and configuration of SFC components relat= ed to the support of service function chaining

Jan 2015

Submit to IESG Informational document def= ining the architecture for SFC

Jan 2015

Submit to IESG Informational document def= ining the control plane requirements for conveying information between cont= rol or management elements and SFC implementation points

Aug 2015

Submit to IESG Standards Track document s= pecifying the generic service function chaining header encapsulation=

 

____________________________________= ___________
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc<= /a>

 

--_000_0BF7E0211CA62B42AE3FD4020E41609884935304SEAEMBX01olympu_-- From jmh@joelhalpern.com Wed Nov 20 10:27:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE98A1AE434 for ; Wed, 20 Nov 2013 10:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fjc7V6h_LUxI for ; Wed, 20 Nov 2013 10:27:52 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id EDA8B1AE0A2 for ; Wed, 20 Nov 2013 10:27:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CBDB01E4AC5; Wed, 20 Nov 2013 10:27:45 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id E7F401E4AC3; Wed, 20 Nov 2013 10:27:42 -0800 (PST) Message-ID: <528CFF1C.3090200@joelhalpern.com> Date: Wed, 20 Nov 2013 13:27:40 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Jerome Moisand , Kevin J Ma , Ron Parker , "Paul Quinn (paulq)" References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 18:27:56 -0000 Unless we want to assume that SFs are single threaded (I very much hope not), then if the application modifies the packet, how does the SF know which metadata to re-attach to which packet? Yours, Joel On 11/20/13 1:05 PM, Jerome Moisand wrote: > I share a similar concern. If the service function software takes good > care of untagging incoming packets on the way in, and retagging outgoing > packets (maybe the same packets as the incoming one or maybe something > completely different as Kevin illustrated) with the appropriate metadata > on the way out, then we should be fine. Whether the SF is an application > proxy or a more simple L3-centric packet processor, it then shouldn’t > matter. Packet-centric devices (e.g. routers) are usually pretty good at > keep some form of context on their internal data path when processing a > packet in/out, but app-centric software may not be designed like that. > > So… that is quite an assumption (*all* SF software will have to do so > –untagging/retagging-, whether they are actively interested in the > packet metadata or not), and indeed a possibly severe barrier to entry. > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Kevin J Ma > *Sent:* Wednesday, November 20, 2013 1:27 AM > *To:* Ron Parker; Paul Quinn (paulq) > *Cc:* nsc@ietf.org; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Paul/Ron, > > My primary concern is with the word "packet". If we are only considering > > network layer packets, with network layer classification and > encapsulation, > > then that is one thing, but if we are talking about application layer > > classification, then network layer encapsulation poses and issue. > The data > > that comes out of a service function is not necessarily the same data > that > > went into the service function. At the application layer, a socket is not > > inherently service chain aware. > > If one builds a load balancer, AV scanner, etc. as an appliance (not part > > of a router), today we have mechanisms for getting the traffic in and out > > of those appliances by configuring VLANs and IP addresses (as noted in the > > problem statement, section 2, bullet 8). If we want the service chain ID > > in the encapsulation header to be the new mechanism, then these > appliances > > need to know the ingress chain ID and the be able to set the egress chain > > ID. An off-the-shelf linux box can support the existing IP mechanism. It > > seems to me that a new encapsulation layer might exclude existing > appliance > > implementations and introduce a new barrier to entry. > > Let me try a more concrete example: > > Given a set of service chains that: optionally terminates client-side > TLS, > > performs HTTP request routing, optionally performs AV checks for HTTP > POST, > > does server load balancing, and optionally initiates back-end TLS: > > --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> > > / \ ^ \ > > / \ / \ > > ---------+ +------+ +----------> > > Assume RR, AV, and LB are all services provided by independent > appliances, > > and FE_TLS and BE_TLS are different instances of the same TLS service > > provided by a fourth independent appliance. The possible chains are: > > chain 1: RR, LB > > chain 2: RR, AV, LB > > chain 3: FE_TLS, RR, LB > > chain 4: FE_TLS, RR, AV, LB > > chain 5: RR, LB, BE_TLS > > chain 6: RR, AV, LB, BE_TLS > > chain 7: FE_TLS, RR, LB, BE_TLS > > chain 8: FE_TLS, RR, AV, LB, BE_TLS > > Initial classification would always choose from either chain 1 or > chain 3. > > (e.g., based on the TCP destination port). > > RR would then choose either chain (1, 2) or chain (3, 4), respectively. > > LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), > > respectively. > > The decisions made by RR/LB seem unlikely to be made on an IP packet > basis, > > yet still need to influence the chain ID encapsulation? > > Now, TLS/RR/LB might all be in the same appliance, but even so, the chain > > to AV still has the same issue. > > So, I guess my question is: Is this a valid DC use case for SFC? > > thanx. > > -- Kevin J. Ma > > *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > *Sent:* Tuesday, November 19, 2013 1:06 PM > *To:* Paul Quinn (paulq); Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* RE: [nsc] Revised SFC Charter > > Hi, Kevin. > > Can you explain your thinking on why service function chaining would be > cognizant of the layer at which the service function operates? As I > see it, any service function is free to modify the original packet in a > manner that suits it. It also has the choice to allow the packet > (modified or unmodified) to progress on the original service function > chain or to intercede with the local service function chaining > functionality such that it jumps onto a new chain. In either case, the > local service function chaining functionality will cause the packet to > be properly encapsulated in order to be conveyed to the next service > function (or forwarded off the end of the chain, if applicable). > > Ron > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Paul Quinn (paulq) > *Sent:* Tuesday, November 19, 2013 12:32 PM > *To:* Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Kevin, > > On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > Personally, I am still unclear as to how this would work for > application layer > > services. It's not a control plane issue if it's session data > dependent? > > The control plane is responsible for the chaining/pathing aspect of SFC: > conveying network locators for forwarding, allocating service header > information and so on. It is not responsible for function specifics > (e.g. per SFC policy). > > I won't rehash the previous discussion on "packet-level" > classification and > > "packet-level" encapsulation, but IMO there are a number of issues > cited in > > the problem statement which are not solved by simply defining an > encapsulation > > header. Yes, there are other informational documents on the list, > but if they > > do not address these questions on how the encapsulation may be used > (and how > > different levels of classification/re-classification will work), > then the > > encapsulation spec has to stand on its own. The charter could be > interpreted > > either way. > > The encap format won't solve everything, however it creates a foundation > to build upon. Many of the problems will be solved at upper layers, > leveraging the encap in the data plane. > > thanx. > > -- Kevin J. Ma > > *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com > ] > *Sent:*Tuesday, November 19, 2013 9:39 AM > *To:*Kevin J Ma;nsc@ietf.org > *Subject:*Re: Revised SFC Charter > > Hi Kevin, > > *From:*Kevin J Ma > > *Date:*Tuesday, November 19, 2013 1:25 AM > *To:*Jim Guichard >, > "nsc@ietf.org " > > *Subject:*RE: Revised SFC Charter > > Hi Jim, > > There is a typo in item 3. "is is" -> "it is": > > "It is intended that the encapsulation be agnostic to the layer > at which is is applied" > > Jim> yes, thank you, I corrected the text. > > Wrt to the following text: > > "the same encapsulation may be used on a service function path > realized at the network layer or at any other layer" > > If the service function is an application layer service, and the > > encapsulation is at a lower layer (L2/L3), then presumably signaling > > would be required between the application layer and the lower layer > > responsible for encapsulation, so that individual packets for an > > application layer message may be properly encapsulated. Has this > > been discussed and/or is it considered in scope? > > Jim> the point here was to show that the steering function is > independent of the services layer. As packets traverse a service > chain the encapsulation above the steering function is used to > indicate what service function to apply and which service function > comes next in the service function chain. > > Though this sort of thing could be called an implementation detail, > > typically higher layers do not need to know the lower layer details, > > but in this particular case, if the higher layer is re-classifying, > > it likely wants/needs to know the ingress chain ID as it selects the > > egress chain ID, and then needs to tell the lower encapsulation layer > > what the new egress chain ID should be? > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > thanx. > > -- Kevin J. Ma > > *From:*nsc [mailto:nsc-bounces@ietf.org]*On Behalf Of*Jim Guichard > (jguichar) > *Sent:*Monday, November 18, 2013 4:17 PM > *To:*nsc@ietf.org > *Subject:*[nsc] Revised SFC Charter > > Greetings, > > Thomas Narten and I have spent some time refining the SFC charter > based upon discussion during the SFC BOF and several emails to the > mailing list. We do not believe this is a substantive change; we > have clarified the management vs. control plane text and added text > around security. Please review the revised charter and provide comment. > > _Revised SFC WG Charter:_ > > Service delivery is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > Service delivery is currently both a technical and an organizational > challenge that involves significant modification to the network > configuration thereby impacting the speed at which services can be > deployed and increasing operational costs. Services are typically > implemented by the ordered combination of a number of service > functions that are deployed at different points within a network. > Today, a common deployment model has service functions physically > inserted on the data-forwarding path between communicating peers. > Going forward, however, there is a desire to move to a different > model, where service functions, whether physical or virtualized, are > not required to reside on the direct data path and traffic is > instead steered through service functions, wherever they are deployed. > > For a given service, the abstracted view of the required service > functions and the order in which they are to be applied is called a > Service Function Chain (SFC). An SFC is instantiated through > selection of specific service function instances and the network > nodes on which they are provided, thereby forming a service graph: > this is called a Service Function Path (SFP). The service functions > may be applied at any layer within the network protocol stack > (network layer, application layer, etc.). > > The SFC working group will document a new approach to service > delivery and operation. It will produce an architecture for service > function chaining that includes the necessary protocols or protocol > extensions to convey the service path and service path information > to nodes that are involved in the implementation of service > functions and service function chains, as well as mechanisms for > steering traffic through service functions. The working group will > examine what information needs to be gathered from the network and > service functions in support of service function chaining and how > that information may be made available to the components of the > service function chaining architecture. The SFC WG will closely > consider the security implications when documenting these deliverables. > > Specifically, the SFC WG is chartered to deliver the following: > > 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. Additionally, the working group will > normalize nomenclature and definitions for service function chaining. > > 2.Architecture: This document will provide a description of the SFC > architectural building blocks and their relationship including > interconnection, placement of SFC specific capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. The initial scope is > restricted to a single administrative domain, keeping in mind that > architectural decisions made for the intra-domain case may have > implications for the inter-domain case. > > 3.Generic SFC Encapsulation: This document will describe a single > service-level data plane encapsulation format for conveying the > service function chain and the service function path, and for > communicating context information between nodes that implement > service functions and service function chains. It is intended that > the encapsulation be agnostic to the layer at which is is applied > and the service that is being constructed. That is, the same > encapsulation may be used on a service function path realized at the > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service. > > 4.Control Plane Mechanisms: A document will be developed to describe > requirements for conveying information between control or management > elements and SFC implementation points. All protocol extension work > resulting from these requirements should be carried out in the > working group responsible for the protocol being modified in > coordination with this working group, but may be done in this > working group under a revised charter after agreement with all the > relevant WG chairs and responsible ADs. > > 5.Manageability: Work on the management and configuration of SFC > components related to the support of service function chaining will > certainly be needed, but first needs to be better understood and scoped. > > Proposed Milestones: > > Apr 2014 > > Submit to IESG Informational document defining the SFC problem > statement and core use cases > > Apr 2014 > > Consult with OPS area on possible SFC charter modifications for > management and configuration of SFC components related to the > support of service function chaining > > Jan 2015 > > Submit to IESG Informational document defining the architecture for SFC > > Jan 2015 > > Submit to IESG Informational document defining the control plane > requirements for conveying information between control or management > elements and SFC implementation points > > Aug 2015 > > Submit to IESG Standards Track document specifying the generic > service function chaining header encapsulation > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From jmoisand@juniper.net Wed Nov 20 10:39:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 006571AE10A for ; Wed, 20 Nov 2013 10:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEBuNanfVjUx for ; Wed, 20 Nov 2013 10:39:51 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id CD5251AE0EC for ; Wed, 20 Nov 2013 10:39:50 -0800 (PST) Received: from mail70-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Wed, 20 Nov 2013 18:39:42 +0000 Received: from mail70-ch1 (localhost [127.0.0.1]) by mail70-ch1-R.bigfish.com (Postfix) with ESMTP id 71B8E1C0281; Wed, 20 Nov 2013 18:39:42 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h9a9j1155h) Received-SPF: pass (mail70-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(13464003)(51704005)(377454003)(24454002)(199002)(189002)(47446002)(31966008)(80022001)(79102001)(66066001)(87936001)(56776001)(74502001)(59766001)(74662001)(63696002)(74316001)(65816001)(33646001)(4396001)(49866001)(76482001)(81542001)(54356001)(76786001)(81342001)(2656002)(85306002)(46102001)(47736001)(19580395003)(19580405001)(83322001)(56816003)(51856001)(83072001)(77096001)(81816001)(81686001)(74366001)(76576001)(87266001)(74706001)(69226001)(50986001)(54316002)(80976001)(77982001)(47976001)(76796001)(15975445006)(74876001)(53806001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB250; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail70-ch1 (localhost.localdomain [127.0.0.1]) by mail70-ch1 (MessageSwitch) id 1384972780696031_10097; Wed, 20 Nov 2013 18:39:40 +0000 (UTC) Received: from CH1EHSMHS005.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.246]) by mail70-ch1.bigfish.com (Postfix) with ESMTP id A49E71A0051; Wed, 20 Nov 2013 18:39:40 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS005.bigfish.com (10.43.70.5) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 20 Nov 2013 18:39:40 +0000 Received: from BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 20 Nov 2013 18:39:37 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB250.namprd05.prod.outlook.com (10.255.206.24) with Microsoft SMTP Server (TLS) id 15.0.815.6; Wed, 20 Nov 2013 18:39:23 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.83]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.7.138]) with mapi id 15.00.0815.000; Wed, 20 Nov 2013 18:39:17 +0000 From: Jerome Moisand To: "Joel M. Halpern" , Kevin J Ma , Ron Parker , "Paul Quinn (paulq)" Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAzNuggAAKEwCAAAFP0A== Date: Wed, 20 Nov 2013 18:39:16 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> <528CFF1C.3090200@joelhalpern.com> In-Reply-To: <528CFF1C.3090200@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-forefront-prvs: 0036736630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 18:39:55 -0000 Well, it probably has its own flow/state tables where this can be stored an= d used when needs be on the way out. Making an assumption that for a given = incoming flow (or collection of flows with affinity), the metadata is unlik= ely to change (which isn't entirely obvious in theory, but likely in practi= ce).=20 And yeah, this (weak?) answer just reinforces the barrier to entry problem.= Sounds like quite an issue. Being bugging me (and other folks I know) for = a while.=20 -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com]=20 Sent: Wednesday, November 20, 2013 1:28 PM To: Jerome Moisand; Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Unless we want to assume that SFs are single threaded (I very much hope not= ), then if the application modifies the packet, how does the SF know which = metadata to re-attach to which packet? Yours, Joel On 11/20/13 1:05 PM, Jerome Moisand wrote: > I share a similar concern. If the service function software takes good=20 > care of untagging incoming packets on the way in, and retagging=20 > outgoing packets (maybe the same packets as the incoming one or maybe=20 > something completely different as Kevin illustrated) with the=20 > appropriate metadata on the way out, then we should be fine. Whether=20 > the SF is an application proxy or a more simple L3-centric packet=20 > processor, it then shouldn't matter. Packet-centric devices (e.g.=20 > routers) are usually pretty good at keep some form of context on their=20 > internal data path when processing a packet in/out, but app-centric softw= are may not be designed like that. > > So... that is quite an assumption (*all* SF software will have to do so=20 > -untagging/retagging-, whether they are actively interested in the=20 > packet metadata or not), and indeed a possibly severe barrier to entry. > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Kevin J Ma > *Sent:* Wednesday, November 20, 2013 1:27 AM > *To:* Ron Parker; Paul Quinn (paulq) > *Cc:* nsc@ietf.org; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Paul/Ron, > > My primary concern is with the word "packet". If we are only=20 > considering > > network layer packets, with network layer classification and=20 > encapsulation, > > then that is one thing, but if we are talking about application=20 > layer > > classification, then network layer encapsulation poses and issue. > The data > > that comes out of a service function is not necessarily the same=20 > data that > > went into the service function. At the application layer, a socket=20 > is not > > inherently service chain aware. > > If one builds a load balancer, AV scanner, etc. as an appliance (not=20 > part > > of a router), today we have mechanisms for getting the traffic in=20 > and out > > of those appliances by configuring VLANs and IP addresses (as noted=20 > in the > > problem statement, section 2, bullet 8). If we want the service=20 > chain ID > > in the encapsulation header to be the new mechanism, then these=20 > appliances > > need to know the ingress chain ID and the be able to set the egress=20 > chain > > ID. An off-the-shelf linux box can support the existing IP=20 > mechanism. It > > seems to me that a new encapsulation layer might exclude existing=20 > appliance > > implementations and introduce a new barrier to entry. > > Let me try a more concrete example: > > Given a set of service chains that: optionally terminates=20 > client-side TLS, > > performs HTTP request routing, optionally performs AV checks for=20 > HTTP POST, > > does server load balancing, and optionally initiates back-end TLS: > > --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> > > / \ ^ \ > > / \ / \ > > ---------+ +------+ +----------> > > Assume RR, AV, and LB are all services provided by independent=20 > appliances, > > and FE_TLS and BE_TLS are different instances of the same TLS=20 > service > > provided by a fourth independent appliance. The possible chains are: > > chain 1: RR, LB > > chain 2: RR, AV, LB > > chain 3: FE_TLS, RR, LB > > chain 4: FE_TLS, RR, AV, LB > > chain 5: RR, LB, BE_TLS > > chain 6: RR, AV, LB, BE_TLS > > chain 7: FE_TLS, RR, LB, BE_TLS > > chain 8: FE_TLS, RR, AV, LB, BE_TLS > > Initial classification would always choose from either chain 1 or=20 > chain 3. > > (e.g., based on the TCP destination port). > > RR would then choose either chain (1, 2) or chain (3, 4), respectively= . > > LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7,=20 > 8), > > respectively. > > The decisions made by RR/LB seem unlikely to be made on an IP=20 > packet basis, > > yet still need to influence the chain ID encapsulation? > > Now, TLS/RR/LB might all be in the same appliance, but even so, the=20 > chain > > to AV still has the same issue. > > So, I guess my question is: Is this a valid DC use case for SFC? > > thanx. > > -- Kevin J. Ma > > *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > *Sent:* Tuesday, November 19, 2013 1:06 PM > *To:* Paul Quinn (paulq); Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* RE: [nsc] Revised SFC Charter > > Hi, Kevin. > > Can you explain your thinking on why service function chaining would be > cognizant of the layer at which the service function operates? As I > see it, any service function is free to modify the original packet in a > manner that suits it. It also has the choice to allow the packet > (modified or unmodified) to progress on the original service function=20 > chain or to intercede with the local service function chaining > functionality such that it jumps onto a new chain. In either case, the > local service function chaining functionality will cause the packet to=20 > be properly encapsulated in order to be conveyed to the next service=20 > function (or forwarded off the end of the chain, if applicable). > > Ron > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Paul Quinn=20 > (paulq) > *Sent:* Tuesday, November 19, 2013 12:32 PM > *To:* Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Kevin, > > On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > Personally, I am still unclear as to how this would work for > application layer > > services. It's not a control plane issue if it's session data > dependent? > > The control plane is responsible for the chaining/pathing aspect of SFC: > conveying network locators for forwarding, allocating service header=20 > information and so on. It is not responsible for function specifics=20 > (e.g. per SFC policy). > > I won't rehash the previous discussion on "packet-level" > classification and > > "packet-level" encapsulation, but IMO there are a number of issues > cited in > > the problem statement which are not solved by simply defining an > encapsulation > > header. Yes, there are other informational documents on the list, > but if they > > do not address these questions on how the encapsulation may be used > (and how > > different levels of classification/re-classification will work), > then the > > encapsulation spec has to stand on its own. The charter could be > interpreted > > either way. > > The encap format won't solve everything, however it creates a=20 > foundation to build upon. Many of the problems will be solved at=20 > upper layers, leveraging the encap in the data plane. > > thanx. > > -- Kevin J. Ma > > *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com > ] > *Sent:*Tuesday, November 19, 2013 9:39 AM > *To:*Kevin J Ma;nsc@ietf.org > *Subject:*Re: Revised SFC Charter > > Hi Kevin, > > *From:*Kevin J Ma > > *Date:*Tuesday, November 19, 2013 1:25 AM > *To:*Jim Guichard >, > "nsc@ietf.org " > > *Subject:*RE: Revised SFC Charter > > Hi Jim, > > There is a typo in item 3. "is is" -> "it is": > > "It is intended that the encapsulation be agnostic to the layer > at which is is applied" > > Jim> yes, thank you, I corrected the text. > > Wrt to the following text: > > "the same encapsulation may be used on a service function path > realized at the network layer or at any other layer" > > If the service function is an application layer service, and=20 > the > > encapsulation is at a lower layer (L2/L3), then presumably=20 > signaling > > would be required between the application layer and the lower=20 > layer > > responsible for encapsulation, so that individual packets for=20 > an > > application layer message may be properly encapsulated. Has=20 > this > > been discussed and/or is it considered in scope? > > Jim> the point here was to show that the steering function is > independent of the services layer. As packets traverse a service > chain the encapsulation above the steering function is used to > indicate what service function to apply and which service function > comes next in the service function chain. > > Though this sort of thing could be called an implementation=20 > detail, > > typically higher layers do not need to know the lower layer=20 > details, > > but in this particular case, if the higher layer is=20 > re-classifying, > > it likely wants/needs to know the ingress chain ID as it selects=20 > the > > egress chain ID, and then needs to tell the lower encapsulation=20 > layer > > what the new egress chain ID should be? > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > thanx. > > -- Kevin J. Ma > > *From:*nsc [mailto:nsc-bounces@ietf.org]*On Behalf Of*Jim Guichard > (jguichar) > *Sent:*Monday, November 18, 2013 4:17 PM > *To:*nsc@ietf.org > *Subject:*[nsc] Revised SFC Charter > > Greetings, > > Thomas Narten and I have spent some time refining the SFC charter > based upon discussion during the SFC BOF and several emails to the > mailing list. We do not believe this is a substantive change; we > have clarified the management vs. control plane text and added text > around security. Please review the revised charter and provide commen= t. > > _Revised SFC WG Charter:_ > > Service delivery is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > Service delivery is currently both a technical and an organizational > challenge that involves significant modification to the network > configuration thereby impacting the speed at which services can be > deployed and increasing operational costs. Services are typically > implemented by the ordered combination of a number of service > functions that are deployed at different points within a network. > Today, a common deployment model has service functions physically > inserted on the data-forwarding path between communicating peers. > Going forward, however, there is a desire to move to a different > model, where service functions, whether physical or virtualized, are > not required to reside on the direct data path and traffic is > instead steered through service functions, wherever they are deployed= . > > For a given service, the abstracted view of the required service > functions and the order in which they are to be applied is called a > Service Function Chain (SFC). An SFC is instantiated through > selection of specific service function instances and the network > nodes on which they are provided, thereby forming a service graph: > this is called a Service Function Path (SFP). The service functions > may be applied at any layer within the network protocol stack > (network layer, application layer, etc.). > > The SFC working group will document a new approach to service > delivery and operation. It will produce an architecture for service > function chaining that includes the necessary protocols or protocol > extensions to convey the service path and service path information > to nodes that are involved in the implementation of service > functions and service function chains, as well as mechanisms for > steering traffic through service functions. The working group will > examine what information needs to be gathered from the network and > service functions in support of service function chaining and how > that information may be made available to the components of the > service function chaining architecture. The SFC WG will closely > consider the security implications when documenting these deliverable= s. > > Specifically, the SFC WG is chartered to deliver the following: > > 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. Additionally, the working group will > normalize nomenclature and definitions for service function chaining. > > 2.Architecture: This document will provide a description of the SFC > architectural building blocks and their relationship including > interconnection, placement of SFC specific capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. The initial scope is > restricted to a single administrative domain, keeping in mind that > architectural decisions made for the intra-domain case may have > implications for the inter-domain case. > > 3.Generic SFC Encapsulation: This document will describe a single > service-level data plane encapsulation format for conveying the > service function chain and the service function path, and for > communicating context information between nodes that implement > service functions and service function chains. It is intended that > the encapsulation be agnostic to the layer at which is is applied > and the service that is being constructed. That is, the same > encapsulation may be used on a service function path realized at the > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service. > > 4.Control Plane Mechanisms: A document will be developed to describe > requirements for conveying information between control or management > elements and SFC implementation points. All protocol extension work > resulting from these requirements should be carried out in the > working group responsible for the protocol being modified in > coordination with this working group, but may be done in this > working group under a revised charter after agreement with all the > relevant WG chairs and responsible ADs. > > 5.Manageability: Work on the management and configuration of SFC > components related to the support of service function chaining will > certainly be needed, but first needs to be better understood and scop= ed. > > Proposed Milestones: > > Apr 2014 > > Submit to IESG Informational document defining the SFC problem > statement and core use cases > > Apr 2014 > > Consult with OPS area on possible SFC charter modifications for > management and configuration of SFC components related to the > support of service function chaining > > Jan 2015 > > Submit to IESG Informational document defining the architecture=20 > for SFC > > Jan 2015 > > Submit to IESG Informational document defining the control plane > requirements for conveying information between control or management > elements and SFC implementation points > > Aug 2015 > > Submit to IESG Standards Track document specifying the generic > service function chaining header encapsulation > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From ramk@Brocade.com Wed Nov 20 11:10:52 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561171AE0E3 for ; Wed, 20 Nov 2013 11:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3hP9cGkO1jI for ; Wed, 20 Nov 2013 11:10:49 -0800 (PST) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [67.231.152.113]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9B81AE109 for ; Wed, 20 Nov 2013 11:10:49 -0800 (PST) Received: from pps.filterd (m0000700 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id rAKIlxfe010716; Wed, 20 Nov 2013 11:10:37 -0800 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0b-000f0801.pphosted.com with ESMTP id 1g90rer3m0-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 20 Nov 2013 11:10:37 -0800 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; Wed, 20 Nov 2013 11:10:36 -0800 Received: from HQ1-EXCH01.corp.brocade.com ([fe80::ed42:173e:fe7d:d0a6]) by HQ1WP-EXHUB01.corp.brocade.com ([::1]) with mapi; Wed, 20 Nov 2013 11:10:36 -0800 From: ramki Krishnan To: Jerome Moisand , "Joel M. Halpern" , Kevin J Ma , Ron Parker , "Paul Quinn (paulq)" Date: Wed, 20 Nov 2013 11:10:32 -0800 Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAzNuggAAKEwCAAAFP0IAACHnw Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C768D4C1@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D588@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C768D9A4@MAILR002.mail.lan> <528CFF1C.3090200@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.14, 0.0.0000 definitions=2013-11-20_07:2013-11-20,2013-11-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-1305240000 definitions=main-1311200127 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 20 Nov 2013 19:10:52 -0000 >> Well, it probably has its own flow/state tables where this can be stored= and used when needs be on the way out. Making an assumption that for a giv= en incoming flow (or collection of flows with affinity), the metadata is un= likely to change (which isn't entirely obvious in theory, but likely in pra= ctice). I think it is the right assumption to make; the metadata should be invarian= t per flow (or group of flows). Else, things will start quickly falling apa= rt. Thanks, Ramki -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jerome Moisand Sent: Wednesday, November 20, 2013 10:39 AM To: Joel M. Halpern; Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Well, it probably has its own flow/state tables where this can be stored an= d used when needs be on the way out. Making an assumption that for a given = incoming flow (or collection of flows with affinity), the metadata is unlik= ely to change (which isn't entirely obvious in theory, but likely in practi= ce). And yeah, this (weak?) answer just reinforces the barrier to entry problem.= Sounds like quite an issue. Being bugging me (and other folks I know) for = a while. -----Original Message----- From: Joel M. Halpern [mailto:jmh@joelhalpern.com] Sent: Wednesday, November 20, 2013 1:28 PM To: Jerome Moisand; Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Unless we want to assume that SFs are single threaded (I very much hope not= ), then if the application modifies the packet, how does the SF know which = metadata to re-attach to which packet? Yours, Joel On 11/20/13 1:05 PM, Jerome Moisand wrote: > I share a similar concern. If the service function software takes good > care of untagging incoming packets on the way in, and retagging > outgoing packets (maybe the same packets as the incoming one or maybe > something completely different as Kevin illustrated) with the > appropriate metadata on the way out, then we should be fine. Whether > the SF is an application proxy or a more simple L3-centric packet > processor, it then shouldn't matter. Packet-centric devices (e.g. > routers) are usually pretty good at keep some form of context on their > internal data path when processing a packet in/out, but app-centric softw= are may not be designed like that. > > So... that is quite an assumption (*all* SF software will have to do so > -untagging/retagging-, whether they are actively interested in the > packet metadata or not), and indeed a possibly severe barrier to entry. > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Kevin J Ma > *Sent:* Wednesday, November 20, 2013 1:27 AM > *To:* Ron Parker; Paul Quinn (paulq) > *Cc:* nsc@ietf.org; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Paul/Ron, > > My primary concern is with the word "packet". If we are only > considering > > network layer packets, with network layer classification and > encapsulation, > > then that is one thing, but if we are talking about application > layer > > classification, then network layer encapsulation poses and issue. > The data > > that comes out of a service function is not necessarily the same > data that > > went into the service function. At the application layer, a socket > is not > > inherently service chain aware. > > If one builds a load balancer, AV scanner, etc. as an appliance (not > part > > of a router), today we have mechanisms for getting the traffic in > and out > > of those appliances by configuring VLANs and IP addresses (as noted > in the > > problem statement, section 2, bullet 8). If we want the service > chain ID > > in the encapsulation header to be the new mechanism, then these > appliances > > need to know the ingress chain ID and the be able to set the egress > chain > > ID. An off-the-shelf linux box can support the existing IP > mechanism. It > > seems to me that a new encapsulation layer might exclude existing > appliance > > implementations and introduce a new barrier to entry. > > Let me try a more concrete example: > > Given a set of service chains that: optionally terminates > client-side TLS, > > performs HTTP request routing, optionally performs AV checks for > HTTP POST, > > does server load balancing, and optionally initiates back-end TLS: > > --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> > > / \ ^ \ > > / \ / \ > > ---------+ +------+ +----------> > > Assume RR, AV, and LB are all services provided by independent > appliances, > > and FE_TLS and BE_TLS are different instances of the same TLS > service > > provided by a fourth independent appliance. The possible chains are: > > chain 1: RR, LB > > chain 2: RR, AV, LB > > chain 3: FE_TLS, RR, LB > > chain 4: FE_TLS, RR, AV, LB > > chain 5: RR, LB, BE_TLS > > chain 6: RR, AV, LB, BE_TLS > > chain 7: FE_TLS, RR, LB, BE_TLS > > chain 8: FE_TLS, RR, AV, LB, BE_TLS > > Initial classification would always choose from either chain 1 or > chain 3. > > (e.g., based on the TCP destination port). > > RR would then choose either chain (1, 2) or chain (3, 4), respectively= . > > LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, > 8), > > respectively. > > The decisions made by RR/LB seem unlikely to be made on an IP > packet basis, > > yet still need to influence the chain ID encapsulation? > > Now, TLS/RR/LB might all be in the same appliance, but even so, the > chain > > to AV still has the same issue. > > So, I guess my question is: Is this a valid DC use case for SFC? > > thanx. > > -- Kevin J. Ma > > *From:*Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > *Sent:* Tuesday, November 19, 2013 1:06 PM > *To:* Paul Quinn (paulq); Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* RE: [nsc] Revised SFC Charter > > Hi, Kevin. > > Can you explain your thinking on why service function chaining would be > cognizant of the layer at which the service function operates? As I > see it, any service function is free to modify the original packet in a > manner that suits it. It also has the choice to allow the packet > (modified or unmodified) to progress on the original service function > chain or to intercede with the local service function chaining > functionality such that it jumps onto a new chain. In either case, the > local service function chaining functionality will cause the packet to > be properly encapsulated in order to be conveyed to the next service > function (or forwarded off the end of the chain, if applicable). > > Ron > > *From:*nsc [mailto:nsc-bounces@ietf.org] *On Behalf Of *Paul Quinn > (paulq) > *Sent:* Tuesday, November 19, 2013 12:32 PM > *To:* Kevin J Ma > *Cc:* nsc@ietf.org ; Jim Guichard (jguichar) > *Subject:* Re: [nsc] Revised SFC Charter > > Hi Kevin, > > On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > Personally, I am still unclear as to how this would work for > application layer > > services. It's not a control plane issue if it's session data > dependent? > > The control plane is responsible for the chaining/pathing aspect of SFC: > conveying network locators for forwarding, allocating service header > information and so on. It is not responsible for function specifics > (e.g. per SFC policy). > > I won't rehash the previous discussion on "packet-level" > classification and > > "packet-level" encapsulation, but IMO there are a number of issues > cited in > > the problem statement which are not solved by simply defining an > encapsulation > > header. Yes, there are other informational documents on the list, > but if they > > do not address these questions on how the encapsulation may be used > (and how > > different levels of classification/re-classification will work), > then the > > encapsulation spec has to stand on its own. The charter could be > interpreted > > either way. > > The encap format won't solve everything, however it creates a > foundation to build upon. Many of the problems will be solved at > upper layers, leveraging the encap in the data plane. > > thanx. > > -- Kevin J. Ma > > *From:*Jim Guichard (jguichar) [mailto:jguichar@cisco.com > ] > *Sent:*Tuesday, November 19, 2013 9:39 AM > *To:*Kevin J Ma;nsc@ietf.org > *Subject:*Re: Revised SFC Charter > > Hi Kevin, > > *From:*Kevin J Ma > > *Date:*Tuesday, November 19, 2013 1:25 AM > *To:*Jim Guichard >, > "nsc@ietf.org " > > *Subject:*RE: Revised SFC Charter > > Hi Jim, > > There is a typo in item 3. "is is" -> "it is": > > "It is intended that the encapsulation be agnostic to the layer > at which is is applied" > > Jim> yes, thank you, I corrected the text. > > Wrt to the following text: > > "the same encapsulation may be used on a service function path > realized at the network layer or at any other layer" > > If the service function is an application layer service, and > the > > encapsulation is at a lower layer (L2/L3), then presumably > signaling > > would be required between the application layer and the lower > layer > > responsible for encapsulation, so that individual packets for > an > > application layer message may be properly encapsulated. Has > this > > been discussed and/or is it considered in scope? > > Jim> the point here was to show that the steering function is > independent of the services layer. As packets traverse a service > chain the encapsulation above the steering function is used to > indicate what service function to apply and which service function > comes next in the service function chain. > > Though this sort of thing could be called an implementation > detail, > > typically higher layers do not need to know the lower layer > details, > > but in this particular case, if the higher layer is > re-classifying, > > it likely wants/needs to know the ingress chain ID as it selects > the > > egress chain ID, and then needs to tell the lower encapsulation > layer > > what the new egress chain ID should be? > > Jim> this would be part of the control plane which would make > available to the service function (or proxy) information about > inbound and outbound service function chain encapsulation. > > thanx. > > -- Kevin J. Ma > > *From:*nsc [mailto:nsc-bounces@ietf.org]*On Behalf Of*Jim Guichard > (jguichar) > *Sent:*Monday, November 18, 2013 4:17 PM > *To:*nsc@ietf.org > *Subject:*[nsc] Revised SFC Charter > > Greetings, > > Thomas Narten and I have spent some time refining the SFC charter > based upon discussion during the SFC BOF and several emails to the > mailing list. We do not believe this is a substantive change; we > have clarified the management vs. control plane text and added text > around security. Please review the revised charter and provide commen= t. > > _Revised SFC WG Charter:_ > > Service delivery is undergoing significant change with the > introduction of virtualization, network overlays, and orchestration. > Service delivery is currently both a technical and an organizational > challenge that involves significant modification to the network > configuration thereby impacting the speed at which services can be > deployed and increasing operational costs. Services are typically > implemented by the ordered combination of a number of service > functions that are deployed at different points within a network. > Today, a common deployment model has service functions physically > inserted on the data-forwarding path between communicating peers. > Going forward, however, there is a desire to move to a different > model, where service functions, whether physical or virtualized, are > not required to reside on the direct data path and traffic is > instead steered through service functions, wherever they are deployed= . > > For a given service, the abstracted view of the required service > functions and the order in which they are to be applied is called a > Service Function Chain (SFC). An SFC is instantiated through > selection of specific service function instances and the network > nodes on which they are provided, thereby forming a service graph: > this is called a Service Function Path (SFP). The service functions > may be applied at any layer within the network protocol stack > (network layer, application layer, etc.). > > The SFC working group will document a new approach to service > delivery and operation. It will produce an architecture for service > function chaining that includes the necessary protocols or protocol > extensions to convey the service path and service path information > to nodes that are involved in the implementation of service > functions and service function chains, as well as mechanisms for > steering traffic through service functions. The working group will > examine what information needs to be gathered from the network and > service functions in support of service function chaining and how > that information may be made available to the components of the > service function chaining architecture. The SFC WG will closely > consider the security implications when documenting these deliverable= s. > > Specifically, the SFC WG is chartered to deliver the following: > > 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. Additionally, the working group will > normalize nomenclature and definitions for service function chaining. > > 2.Architecture: This document will provide a description of the SFC > architectural building blocks and their relationship including > interconnection, placement of SFC specific capabilities, management, > diagnostics, design analysis, and security models, as well as > requirements on the protocol mechanisms. The initial scope is > restricted to a single administrative domain, keeping in mind that > architectural decisions made for the intra-domain case may have > implications for the inter-domain case. > > 3.Generic SFC Encapsulation: This document will describe a single > service-level data plane encapsulation format for conveying the > service function chain and the service function path, and for > communicating context information between nodes that implement > service functions and service function chains. It is intended that > the encapsulation be agnostic to the layer at which is is applied > and the service that is being constructed. That is, the same > encapsulation may be used on a service function path realized at the > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service. > > 4.Control Plane Mechanisms: A document will be developed to describe > requirements for conveying information between control or management > elements and SFC implementation points. All protocol extension work > resulting from these requirements should be carried out in the > working group responsible for the protocol being modified in > coordination with this working group, but may be done in this > working group under a revised charter after agreement with all the > relevant WG chairs and responsible ADs. > > 5.Manageability: Work on the management and configuration of SFC > components related to the support of service function chaining will > certainly be needed, but first needs to be better understood and scop= ed. > > Proposed Milestones: > > Apr 2014 > > Submit to IESG Informational document defining the SFC problem > statement and core use cases > > Apr 2014 > > Consult with OPS area on possible SFC charter modifications for > management and configuration of SFC components related to the > support of service function chaining > > Jan 2015 > > Submit to IESG Informational document defining the architecture > for SFC > > Jan 2015 > > Submit to IESG Informational document defining the control plane > requirements for conveying information between control or management > elements and SFC implementation points > > Aug 2015 > > Submit to IESG Standards Track document specifying the generic > service function chaining header encapsulation > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From smkumar@cisco.com Wed Nov 20 19:59:53 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E946A1AE09C for ; Wed, 20 Nov 2013 19:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.025 X-Spam-Level: X-Spam-Status: No, score=-15.025 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.525, 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 FFyKQRtq7oe4 for ; Wed, 20 Nov 2013 19:59:47 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4F401AE09B for ; Wed, 20 Nov 2013 19:59:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=74629; q=dns/txt; s=iport; t=1385006380; x=1386215980; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=9pWSKdXMe477xxHmliYhJbQ9i3dCKtRrzNgw8y2pzmA=; b=ImyoP+XfzMLafETxbw0SZjWvWkqtxaGW9ZvG4X5Af4OpI4Zax1uMmlDJ pZbHyF7Y3kOL2A2glF3M6h7+KkzOjTe/P2SVlv78fi+vMYDpLHzh/QoBn wGYjT9xgHFz/bTvhAyZ5h/aAbmh/I23Exvhrqw2CD7ahDwZc/nvGhqZt4 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIHAKCEjVKtJXG//2dsb2JhbABYgkNEOFO1HohLgR8WdIIlAQEBBAEBARcBDAY4AgcEBxIBCBEBAgEBARYLAQYuCxQDBggCBA4FiAENwFAXj0AHEw0EBgECBAMBhCgDlDCDYoEviyiFNoMogio X-IronPort-AV: E=Sophos;i="4.93,741,1378857600"; d="scan'208,217";a="286322932" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 21 Nov 2013 03:59:39 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAL3xdjW029874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 03:59:39 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 21:59:38 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAe/YAgAAuJpCAAKsYgA== Date: Thu, 21 Nov 2013 03:59:38 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C790F7C7@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.123.14] Content-Type: multipart/alternative; boundary="_000_CEB2BFFB27DE7smkumarciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 21 Nov 2013 03:59:53 -0000 --_000_CEB2BFFB27DE7smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Kevin, -- The point of the example was that the application layer service is the data plane. It terminates the TCP connection and th= en generates a new TCP connection, but that is still the same data plane for= a given end user session. I wanted to make sure this is not overlooked. -- Noted: A non-transparent proxy application and one that is stream packet ba= sed. I don't think the architecture prevents this. At the minimum an effect= similar to VLAN stitching should be achievable by having the application n= ot directly participate in service chaining. As an example, using proxy nod= es as described in http://tools.ietf.org/html/draft-quinn-nsh-01 All the stuff that Jim/Thomas mentioned about Control plane still applies. Surendra. From: Kevin J Ma > Date: Wednesday, November 20, 2013 7:51 AM To: Surendra Kumar >, Ron Parke= r >= , "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: RE: [nsc] Revised SFC Charter Hi Surendra, > Well, there is more it than just putting a service path id into the = header/pkt. To construct service chains, you need a non-local view of servi= ce functions. A service controller provides such a view to enables the cons= truction of service chains. In that sense, there is already a need for co-o= rdination of these service chain/path identifiers with a control entity. We= 've moved past VLAN stitching =96 reason we are on this list :) Understood, but since the control plane function is not in the scope of t= he charter, and the only standards track document in the charter is the head= er encapsulation, my concern is how well the encapsulation spec will take in= to account the different deployment scenarios that need to be supported by t= he control plane functions. The point of the example was that the applicati= on layer service is the data plane. It terminates the TCP connection and th= en generates a new TCP connection, but that is still the same data plane for= a given end user session. I wanted to make sure this is not overlooked. thanx. -- Kevin J. Ma From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Wednesday, November 20, 2013 10:02 AM To: Kevin J Ma; Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Kevin, Comments inline. From: Kevin J Ma > Date: Tuesday, November 19, 2013 10:27 PM To: Ron Parker >, "Paul Quinn (paulq)" > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. When a classification supports layer7, it has to look at the data stre= am. There is no assumption that it is L3 based. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Well, there is more it than just putting a service path id into the he= ader/pkt. To construct service chains, you need a non-local view of service= functions. A service controller provides such a view to enables the constr= uction of service chains. In that sense, there is already a need for co-ord= ination of these service chain/path identifiers with a control entity. We'v= e moved past VLAN stitching =96 reason we are on this list :) Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? It is a valid use case. Surendra. thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CEB2BFFB27DE7smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <334816F82AE6184F8785B0B0CBDDA6EE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Wednesday, November 20, 2013 = 7:51 AM
To: Surendra Kumar <smkumar@cisco.com>, Ron Parker <Ron_Parker@affirmednetworks.com= >, "Paul Quinn (paulq)" <paulq@cisco.com>
Cc: "nsc@ietf.org" <nsc@ietf.= org>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: RE: [nsc] Revised SFC Char= ter

Hi Surendra,

 

> <SK> Well, there is more it than just putting a servi= ce path id into the header/pkt. To construct service chains, you need a non= -local view of service functions. A service controller provides such a view to enables the construction of service cha= ins. In that sense, there is already a need for co-ordination of these serv= ice chain/path identifiers with a control entity. We've moved past VLAN sti= tching =96 reason we are on this list :)

 

  Understood, but since the control plane function is not in= the scope of the

  charter, and the only standards track document in the char= ter is the header

  encapsulation, my concern is how well the encapsulation sp= ec will take into

  account the different deployment scenarios that need to be= supported by the

  control plane functions.  The point of the example wa= s that the application

  layer service is the data plane.  It terminates the T= CP connection and then

  generates a new TCP connection, but that is still the same= data plane for a

  given end user session.  I wanted to make sure this i= s not overlooked.

 

thanx.

 

--  Kevin J. Ma

 

From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Wednesday, November 20, 2013 10:02 AM
To: Kevin J Ma; Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Kevin,

 

Comments inline.

 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, November 19, 2013 10:27 PM
To: Ron Parker <Ron_Parker@affirmednetworks.com>, "Paul Quinn (paulq)" &= lt;paulq@cisco.com>
Cc: "nsc@ietf.org" <= ;nsc@ietf.org>, "Jim Guichard (= jguichar)" <jguichar@cisco.co= m>
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,<= /span>

 =

  My primary concer= n is with the word "packet".  If we are only considering

  network layer pac= kets, with network layer classification and encapsulation,

  then that is one = thing, but if we are talking about application layer

  classification, t= hen network layer encapsulation poses and issue.  The data<= /span>

  that comes out of= a service function is not necessarily the same data that=

 went into the serv= ice function.  At the application layer, a socket is not

  inherently servic= e chain aware.

<SK> When a classification supports l= ayer7, it has to look at the data stream. There is no assumption that it is= L3 based.

 =

 If one builds a lo= ad balancer, AV scanner, etc. as an appliance (not part

 of a router), toda= y we have mechanisms for getting the traffic in and out

 of those appliance= s by configuring VLANs and IP addresses (as noted in the<= /p>

  problem statement= , section 2, bullet 8).  If we want the service chain ID

  in the encapsulat= ion header to be the new mechanism, then these appliances=

 need to know the i= ngress chain ID and the be able to set the egress chain

 ID.  An off-t= he-shelf linux box can support the existing IP mechanism.  It

  seems to me that = a new encapsulation layer might exclude existing appliance

  implementations a= nd introduce a new barrier to entry.

<SK> Well, there is more it than just= putting a service path id into the header/pkt. To construct service chains= , you need a non-local view of service functions. A service controller provides such a view to enables the construction of s= ervice chains. In that sense, there is already a need for co-ordination of = these service chain/path identifiers with a control entity. We've moved pas= t VLAN stitching =96 reason we are on this list :)

 =

  Let me try a more= concrete example:

 =

  Given a set of se= rvice chains that: optionally terminates client-side TLS,=

 performs HTTP requ= est routing, optionally performs AV checks for HTTP POST,=

 does server load b= alancing, and optionally initiates back-end TLS:

 =

  --> FE_TLS --&= gt; RR --> AV --> LB --> BE_TLS -->

    =          /     =  \          ^  \

    =         /      =   \        /   = \

  ---------+ &n= bsp;        +------+ &= nbsp;    +---------->

 =

  Assume RR, AV, an= d LB are all services provided by independent appliances,=

 and FE_TLS and BE_= TLS are different instances of the same TLS service

  provided by a fou= rth independent appliance.  The possible chains are:=

 =

  chain 1:  &n= bsp;      RR,     LB=

  chain 2:  &n= bsp;      RR, AV, LB

  chain 3: FE_TLS, = RR,     LB

  chain 4: FE_TLS, = RR, AV, LB

  chain 5:  &n= bsp;      RR,     LB, BE_= TLS

  chain 6:  &n= bsp;      RR, AV, LB, BE_TLS

  chain 7: FE_TLS, = RR,     LB, BE_TLS

  chain 8: FE_TLS, = RR, AV, LB, BE_TLS

 =

  Initial classific= ation would always choose from either chain 1 or chain 3.=

  (e.g., based on t= he TCP destination port).

 =

  RR would then cho= ose either chain (1, 2) or chain (3, 4), respectively.

 =

  LB would then cho= ose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8),

 respectively.=

 =

  The decisions mad= e by RR/LB seem unlikely to be made on an IP packet basis,

  yet still need to= influence the chain ID encapsulation?

 =

  Now, TLS/RR/LB mi= ght all be in the same appliance, but even so, the chain<= /p>

  to AV still has t= he same issue.

 =

  So, I guess my qu= estion is: Is this a valid DC use case for SFC?

<SK> It is a valid use case.

 

Surendra.

 =

thanx.=

 =

--  Kevin J. Ma

 =

From: Ron Parker [mailto:Ron_Parker@affirmednetwo= rks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 =

Hi, Kevin.

 

Can you  explain your thinkin= g on why service function chaining would be cognizant of the layer at which= the service function operates?   As I see it, any service function is free to modify the original packet in a manner= that suits it.   It also has the choice to allow the packet (mod= ified or unmodified) to progress on the original service function chain or = to intercede with the local service function chaining functionality such that it jumps onto a new chain.   In= either case, the local service function chaining functionality will cause = the packet to be properly encapsulated in order to be conveyed to the next = service function (or forwarded off the end of the chain, if applicable).

 

   Ron

 

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 =

Hi Kevin,

 =

 =

On Nov 19, 2013, at 10:1= 5 AM, Kevin J Ma <kevin.ma@= azukisystems.com> wrote:

 

Jim> this would be part of the control p= lane which would make available to the service function (or proxy) informat= ion about inbound and outbound service function chain encapsulation. 

 =

Personally, I am still u= nclear as to how this would work for application layer

services.  It's not= a control plane issue if it's session data dependent?

 =

 =

The control plane is res= ponsible for the chaining/pathing aspect of SFC: conveying network locators= for forwarding, allocating service header information and so on.  It = is not responsible for function specifics (e.g. per SFC policy).

 =

 =

 =

 

I won't rehash the previ= ous discussion on "packet-level" classification and

"packet-level"= encapsulation, but IMO there are a number of issues cited in

the problem statement wh= ich are not solved by simply defining an encapsulation

header.  Yes, there= are other informational documents on the list, but if they

do not address these que= stions on how the encapsulation may be used (and how

different levels of clas= sification/re-classification will work), then the

encapsulation spec has t= o stand on its own.  The charter could be interpreted

either way.

 =

 =

The encap format won't s= olve everything, however it creates a foundation to build upon.  Many = of the problems will be solved at upper layers, leveraging the encap in the= data plane.

 

thanx.=

 =

--  Kevin J. Ma

 =

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 =

Hi Kevin,

 

From: Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 =

  There is a typo i= n item 3.  "is is" -> "it is":

 =

    "= ;It is intended that the encapsulation be agnostic to the layer at which is= is applied"

 

Jim> yes, thank you, I corrected the tex= t. 

 =

  Wrt to the follow= ing text:

 =

    "= ;the same encapsulation may be used on a service function path realized at = the network layer or at any other layer"

 =

  If the service fu= nction is an application layer service, and the

  encapsulation is = at a lower layer (L2/L3), then presumably signaling

  would be required= between the application layer and the lower layer

  responsible for e= ncapsulation, so that individual packets for an

  application layer= message may be properly encapsulated.  Has this

  been discussed an= d/or is it considered in scope?

 

Jim> the point here was to show that the= steering function is independent of the services layer. As packets travers= e a service chain the encapsulation above the steering function is used to indicate what service function to apply a= nd which service function comes next in the service function chain. 

 =

  Though this sort = of thing could be called an implementation detail,

 typically higher l= ayers do not need to know the lower layer details,

 but in this partic= ular case, if the higher layer is re-classifying,

 it likely wants/ne= eds to know the ingress chain ID as it selects the

  egress chain= ID, and then needs to tell the lower encapsulation layer=

 what the new egres= s chain ID should be?

 

Jim> this would be part of the control p= lane which would make available to the service function (or proxy) informat= ion about inbound and outbound service function chain encapsulation. 

 =

thanx.=

 =

--  Kevin J. Ma

 =

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 =

Greetings,

 

Thomas Narten a= nd I have spent some time refining the SFC charter based upon discussion du= ring the SFC BOF and several emails to the mailing list. We do not believe this is a substantive change; we have = clarified the management vs. control plane text and added text around secur= ity. Please review the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is= undergoing significant change with the introduction of virtualization, net= work overlays, and orchestration. Service delivery is currently both a technical and an organizational challenge tha= t involves significant modification to the network configuration thereby im= pacting the speed at which services can be deployed and increasing operatio= nal costs. Services are typically implemented by the ordered combination of a number of service functions th= at are deployed at different points within a network. Today, a common deplo= yment model has service functions physically inserted on the data-forwardin= g path between communicating peers. Going forward, however, there is a desire to move to a different model, wh= ere service functions, whether physical or virtualized, are not required to= reside on the direct data path and traffic is instead steered through serv= ice functions, wherever they are deployed.  =

 

For a given service, the abstracted view of the required serv= ice functions and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC&nb= sp;is instantiated through selection of specific service function instances= and the network nodes on which they are provided, thereby forming a servic= e graph: this is called a Service Function Path (SFP). The service functions may be applied at any layer within the n= etwork protocol stack (network layer, application layer, etc.).  =

 

The SFC working group will document a new approach to service= delivery and operation. It will produce an architecture for service function chaining that includes the necessary = protocols or protocol extensions to convey the service path and service pat= h information to nodes that are involved in the implementation of service f= unctions and service function chains, as well as mechanisms for steering traffic through service functions. The = working group will examine what information needs to be gathered from the n= etwork and service functions in support of service function chaining and ho= w that information may be made available to the components of the service function chaining architecture. The = SFC WG will closely consider the security implications when documenting the= se deliverables. =

 

Specifically, the SFC WG is chartered to deliver the followin= g:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.  Architecture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= span style=3D"color:black">

4.  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.  Manageability: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.<= o:p>

 

Proposed Milestones:

 

Apr 2014=

Submit to IESG Informational document defining t= he SFC problem statement and core use cases

Apr 2014=

Consult with OPS area on possible SFC charter mo= difications for management and configuration of SFC components related to t= he support of service function chaining<= o:p>

Jan 2015=

Submit to IESG Informational document defining t= he architecture for SFC

Jan 2015=

Submit to IESG Informational document defining t= he control plane requirements for conveying information between control or = management elements and SFC implementation points

Aug 2015=

Submit to IESG Standards Track document specifyi= ng the generic service function chaining header encapsulation

 

_________________________________________= ______
nsc mailing list
nsc@ietf.org
https://www.ietf.org/mailman/listinfo/nsc

 =

--_000_CEB2BFFB27DE7smkumarciscocom_-- From smkumar@cisco.com Wed Nov 20 23:05:31 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A891AE0F2 for ; Wed, 20 Nov 2013 23:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 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.525, 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 T3bLoaFBSKJQ for ; Wed, 20 Nov 2013 23:05:25 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 06CB91AE0F5 for ; Wed, 20 Nov 2013 23:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64560; q=dns/txt; s=iport; t=1385017518; x=1386227118; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=UcHbjgwSgnFcb1YLVQXXZQxSmZ0V1DhEJ8onGS0LdUA=; b=Ur6ptgdtkuLsTz20jvMfri4AWng6cdlOm/4pOVyG+YVdkYYzuLWvlt15 lgmrmxg1YNt8dLRueX71BU61koy1HmappRgk56FFGuWW5baHl5DApMTyc yRYaQ2RpwafrGosIwOPUr3oz1tk35axwE5U6plorXTWTNYa9SLstYh7J4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHevjVKtJXG+/2dsb2JhbABZgkNEOFO9cYEeFnSCJQEBAQQBAQEXDQY4AgcEBxIBCA4DAQIBAQEhAQYuCxQDBggCBA4FiAENwGcXj0AHEw0EBgECBAOEKQOUMINigTCLKoU2gyiCKg X-IronPort-AV: E=Sophos;i="4.93,742,1378857600"; d="scan'208,217";a="1137613" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by alln-iport-4.cisco.com with ESMTP; 21 Nov 2013 07:05:17 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAL75HwX015541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 07:05:17 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 01:05:17 -0600 From: "Surendra Kumar (smkumar)" To: Jerome Moisand Thread-Topic: [nsc] Revised SFC Charter Thread-Index: AQHO5KN3f6VynYS+hEyMJgWlGC9UEJosCYPggACoEID///Ey8IAAkyiA//+ix8CAAMN6IIAAzNuggAC8N4A= Date: Thu, 21 Nov 2013 07:05:17 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.123.72] Content-Type: multipart/alternative; boundary="_000_CEB2EA2C27EBCsmkumarciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] Revised SFC Charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 21 Nov 2013 07:05:31 -0000 --_000_CEB2EA2C27EBCsmkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I don't see it that way. I'm assuming you are including L4-7 services (firewalls and load balancers,= for instance) in the packet-centric devices, which are a considerable perc= entage and even a majority of the services. If an application software is n= ot written that way, maybe it does not want to participate directly in SFC.= As long as we don't make such applications worse, they can function the wa= y they do today. At the same time, if they do participate then I don't see = why they do not want to take advantage of the header. In the worst case it = becomes a NOP and MTU is a non-issue in the current overlay world (assuming= we are smart in service header size) while enabling it to be part of SFC. For all I know, this could be an area of innovation. For even in such appli= cations, the flow state exists (in the OS stack) although not used by the a= pplication directly. Surendra. From: Jerome Moisand > Date: Wednesday, November 20, 2013 10:05 AM To: Kevin J Ma = >, Ron Parker >, "Paul Quinn (paulq)" = > Cc: "nsc@ietf.org" >= , "Jim Guichard (jguichar)" > Subject: Re: [nsc] Revised SFC Charter I share a similar concern. If the service function software takes good care= of untagging incoming packets on the way in, and retagging outgoing packet= s (maybe the same packets as the incoming one or maybe something completely= different as Kevin illustrated) with the appropriate metadata on the way o= ut, then we should be fine. Whether the SF is an application proxy or a mor= e simple L3-centric packet processor, it then shouldn=92t matter. Packet-ce= ntric devices (e.g. routers) are usually pretty good at keep some form of c= ontext on their internal data path when processing a packet in/out, but app= -centric software may not be designed like that. So=85 that is quite an assumption (*all* SF software will have to do so =96= untagging/retagging-, whether they are actively interested in the packet me= tadata or not), and indeed a possibly severe barrier to entry. From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Wednesday, November 20, 2013 1:27 AM To: Ron Parker; Paul Quinn (paulq) Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Paul/Ron, My primary concern is with the word "packet". If we are only considering network layer packets, with network layer classification and encapsulatio= n, then that is one thing, but if we are talking about application layer classification, then network layer encapsulation poses and issue. The da= ta that comes out of a service function is not necessarily the same data tha= t went into the service function. At the application layer, a socket is not inherently service chain aware. If one builds a load balancer, AV scanner, etc. as an appliance (not part of a router), today we have mechanisms for getting the traffic in and out of those appliances by configuring VLANs and IP addresses (as noted in the problem statement, section 2, bullet 8). If we want the service chain ID in the encapsulation header to be the new mechanism, then these appliance= s need to know the ingress chain ID and the be able to set the egress chain ID. An off-the-shelf linux box can support the existing IP mechanism. It seems to me that a new encapsulation layer might exclude existing applian= ce implementations and introduce a new barrier to entry. Let me try a more concrete example: Given a set of service chains that: optionally terminates client-side TLS= , performs HTTP request routing, optionally performs AV checks for HTTP POST= , does server load balancing, and optionally initiates back-end TLS: --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> / \ ^ \ / \ / \ ---------+ +------+ +----------> Assume RR, AV, and LB are all services provided by independent appliances= , and FE_TLS and BE_TLS are different instances of the same TLS service provided by a fourth independent appliance. The possible chains are: chain 1: RR, LB chain 2: RR, AV, LB chain 3: FE_TLS, RR, LB chain 4: FE_TLS, RR, AV, LB chain 5: RR, LB, BE_TLS chain 6: RR, AV, LB, BE_TLS chain 7: FE_TLS, RR, LB, BE_TLS chain 8: FE_TLS, RR, AV, LB, BE_TLS Initial classification would always choose from either chain 1 or chain 3= . (e.g., based on the TCP destination port). RR would then choose either chain (1, 2) or chain (3, 4), respectively. LB would then choose either chain (1, 2, 5, 6) or chain (3, 4, 7, 8), respectively. The decisions made by RR/LB seem unlikely to be made on an IP packet basi= s, yet still need to influence the chain ID encapsulation? Now, TLS/RR/LB might all be in the same appliance, but even so, the chain to AV still has the same issue. So, I guess my question is: Is this a valid DC use case for SFC? thanx. -- Kevin J. Ma From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, November 19, 2013 1:06 PM To: Paul Quinn (paulq); Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: RE: [nsc] Revised SFC Charter Hi, Kevin. Can you explain your thinking on why service function chaining would be co= gnizant of the layer at which the service function operates? As I see it,= any service function is free to modify the original packet in a manner tha= t suits it. It also has the choice to allow the packet (modified or unmod= ified) to progress on the original service function chain or to intercede w= ith the local service function chaining functionality such that it jumps on= to a new chain. In either case, the local service function chaining funct= ionality will cause the packet to be properly encapsulated in order to be c= onveyed to the next service function (or forwarded off the end of the chain= , if applicable). Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 19, 2013 12:32 PM To: Kevin J Ma Cc: nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Revised SFC Charter Hi Kevin, On Nov 19, 2013, at 10:15 AM, Kevin J Ma > wrote: Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. Personally, I am still unclear as to how this would work for application la= yer services. It's not a control plane issue if it's session data dependent? The control plane is responsible for the chaining/pathing aspect of SFC: co= nveying network locators for forwarding, allocating service header informat= ion and so on. It is not responsible for function specifics (e.g. per SFC = policy). I won't rehash the previous discussion on "packet-level" classification and "packet-level" encapsulation, but IMO there are a number of issues cited in the problem statement which are not solved by simply defining an encapsulat= ion header. Yes, there are other informational documents on the list, but if t= hey do not address these questions on how the encapsulation may be used (and ho= w different levels of classification/re-classification will work), then the encapsulation spec has to stand on its own. The charter could be interpret= ed either way. The encap format won't solve everything, however it creates a foundation to= build upon. Many of the problems will be solved at upper layers, leveragi= ng the encap in the data plane. thanx. -- Kevin J. Ma From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, November 19, 2013 9:39 AM To: Kevin J Ma; nsc@ietf.org Subject: Re: Revised SFC Charter Hi Kevin, From: Kevin J Ma > Date: Tuesday, November 19, 2013 1:25 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: Revised SFC Charter Hi Jim, There is a typo in item 3. "is is" -> "it is": "It is intended that the encapsulation be agnostic to the layer at whic= h is is applied" Jim> yes, thank you, I corrected the text. Wrt to the following text: "the same encapsulation may be used on a service function path realized= at the network layer or at any other layer" If the service function is an application layer service, and the encapsulation is at a lower layer (L2/L3), then presumably signaling would be required between the application layer and the lower layer responsible for encapsulation, so that individual packets for an application layer message may be properly encapsulated. Has this been discussed and/or is it considered in scope? Jim> the point here was to show that the steering function is independent o= f the services layer. As packets traverse a service chain the encapsulation= above the steering function is used to indicate what service function to a= pply and which service function comes next in the service function chain. Though this sort of thing could be called an implementation detail, typically higher layers do not need to know the lower layer details, but in this particular case, if the higher layer is re-classifying, it likely wants/needs to know the ingress chain ID as it selects the egress chain ID, and then needs to tell the lower encapsulation layer what the new egress chain ID should be? Jim> this would be part of the control plane which would make available to = the service function (or proxy) information about inbound and outbound serv= ice function chain encapsulation. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Monday, November 18, 2013 4:17 PM To: nsc@ietf.org Subject: [nsc] Revised SFC Charter Greetings, Thomas Narten and I have spent some time refining the SFC charter based upo= n discussion during the SFC BOF and several emails to the mailing list. We = do not believe this is a substantive change; we have clarified the manageme= nt vs. control plane text and added text around security. Please review the= revised charter and provide comment. Revised SFC WG Charter: Service delivery is undergoing significant change with the introduction of = virtualization, network overlays, and orchestration. Service delivery is cu= rrently both a technical and an organizational challenge that involves sign= ificant modification to the network configuration thereby impacting the spe= ed at which services can be deployed and increasing operational costs. Serv= ices are typically implemented by the ordered combination of a number of se= rvice functions that are deployed at different points within a network. Tod= ay, a common deployment model has service functions physically inserted on = the data-forwarding path between communicating peers. Going forward, howeve= r, there is a desire to move to a different model, where service functions,= whether physical or virtualized, are not required to reside on the direct = data path and traffic is instead steered through service functions, whereve= r they are deployed. For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function = Chain (SFC). An SFC is instantiated through selection of specific service f= unction instances and the network nodes on which they are provided, thereby= forming a service graph: this is called a Service Function Path (SFP). The= service functions may be applied at any layer within the network protocol = stack (network layer, application layer, etc.). The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining th= at includes the necessary protocols or protocol extensions to convey the se= rvice path and service path information to nodes that are involved in the i= mplementation of service functions and service function chains, as well as = mechanisms for steering traffic through service functions. The working grou= p will examine what information needs to be gathered from the network and s= ervice functions in support of service function chaining and how that infor= mation may be made available to the components of the service function chai= ning architecture. The SFC WG will closely consider the security implicatio= ns when documenting these deliverables. Specifically, the SFC WG is chartered to deliver the following: 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. Additionally, the working group will normalize nomenclature and= definitions for service function chaining. 2. Architecture: This document will provide a description of the SFC archi= tectural building blocks and their relationship including interconnection, = placement of SFC specific capabilities, management, diagnostics, design ana= lysis, and security models, as well as requirements on the protocol mechani= sms. The initial scope is restricted to a single administrative domain, kee= ping in mind that architectural decisions made for the intra-domain case ma= y have implications for the inter-domain case. 3. Generic SFC Encapsulation: This document will describe a single service= -level data plane encapsulation format for conveying the service function c= hain and the service function path, and for communicating context informati= on between nodes that implement service functions and service function chai= ns. It is intended that the encapsulation be agnostic to the layer at which= is is applied and the service that is being constructed. That is, the same= encapsulation may be used on a service function path realized at the netwo= rk layer or at any other layer, and the same encapsulation will apply for t= he construction of service function paths regardless of the actual service. 4. Control Plane Mechanisms: A document will be developed to describe requ= irements for conveying information between control or management elements a= nd SFC implementation points. All protocol extension work resulting from th= ese requirements should be carried out in the working group responsible for= the protocol being modified in coordination with this working group, but m= ay be done in this working group under a revised charter after agreement wi= th all the relevant WG chairs and responsible ADs. 5. Manageability: Work on the management and configuration of SFC componen= ts related to the support of service function chaining will certainly be ne= eded, but first needs to be better understood and scoped. Proposed Milestones: Apr 2014 Submit to IESG Informational document defining the SFC problem statement an= d core use cases Apr 2014 Consult with OPS area on possible SFC charter modifications for management = and configuration of SFC components related to the support of service funct= ion chaining Jan 2015 Submit to IESG Informational document defining the architecture for SFC Jan 2015 Submit to IESG Informational document defining the control plane requiremen= ts for conveying information between control or management elements and SFC= implementation points Aug 2015 Submit to IESG Standards Track document specifying the generic service func= tion chaining header encapsulation _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CEB2EA2C27EBCsmkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
I don't see it that way.

I'm assuming you are including L4-7 services (firewalls and load balan= cers, for instance) in the packet-centric devices, which are a considerable= percentage and even a majority of the services. If an application software= is not written that way, maybe it does not want to participate directly in SFC. As long as we don't make = such applications worse, they can function the way they do today. At the sa= me time, if they do participate then I don't see why they do not want to ta= ke advantage of the header. In the worst case it becomes a NOP and MTU is a non-issue in the current overlay = world (assuming we are smart in service header size) while enabling it to b= e part of SFC.

For all I know, this could be an area of innovation. For even in such = applications, the flow state exists (in the OS stack) although not used by = the application directly.

Surendra.

From: Jerome Moisand <jmoisand@juniper.net>
Date: Wednesday, November 20, 2013 = 10:05 AM
To: Kevin J Ma <kevin.ma@azukisystems.com>, Ron Parker = <Ron_Parker@affirmedn= etworks.com>, "Paul Quinn (paulq)" <paulq@cisco.com>
Cc: "nsc@ietf.org" <nsc@ietf.= org>, "Jim Guichard (jguichar)" <jguichar@cisco.com>
Subject: Re: [nsc] Revised SFC Char= ter

I share a similar concern. If the = service function software takes good care of untagging incoming packets on = the way in, and retagging outgoing packets (maybe the same packets as the incoming one or maybe something completely = different as Kevin illustrated) with the appropriate metadata on the way ou= t, then we should be fine. Whether the SF is an application proxy or a more= simple L3-centric packet processor, it then shouldn=92t matter. Packet-centric devices (e.g. routers) are usua= lly pretty good at keep some form of context on their internal data path wh= en processing a packet in/out, but app-centric software may not be designed= like that.

 

So=85 that is quite an assumption = (*all* SF software will have to do so =96untagging/retagging-, whether they= are actively interested in the packet metadata or not), and indeed a possibly severe barrier to entry. =

 

 

From: nsc [mai= lto:nsc-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent: Wednesday, November 20, 2013 1:27 AM
To: Ron Parker; Paul Quinn (paulq)
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Paul/Ron,

 

  My primary concern is with the word "packet".&nb= sp; If we are only considering

  network layer packets, with network layer classification a= nd encapsulation,

  then that is one thing, but if we are talking about applic= ation layer

  classification, then network layer encapsulation poses and= issue.  The data

  that comes out of a service function is not necessarily th= e same data that

 went into the service function.  At the application la= yer, a socket is not

  inherently service chain aware.

 

 If one builds a load balancer, AV scanner, etc. as an appli= ance (not part

 of a router), today we have mechanisms for getting the traf= fic in and out

 of those appliances by configuring VLANs and IP addresses (= as noted in the

  problem statement, section 2, bullet 8).  If we want = the service chain ID

  in the encapsulation header to be the new mechanism, then = these appliances

 need to know the ingress chain ID and the be able to set th= e egress chain

 ID.  An off-the-shelf linux box can support the existi= ng IP mechanism.  It

  seems to me that a new encapsulation layer might exclude e= xisting appliance

  implementations and introduce a new barrier to entry.=

 

  Let me try a more concrete example:

 

  Given a set of service chains that: optionally terminates = client-side TLS,

 performs HTTP request routing, optionally performs AV check= s for HTTP POST,

 does server load balancing, and optionally initiates back-e= nd TLS:

 

  --> FE_TLS --> RR --> AV --> LB --> BE_TLS = -->

           &nbs= p; /      \      &nb= sp;   ^  \

           &nbs= p;/        \     &nb= sp;  /    \

  ---------+        &= nbsp; +------+      +----------&g= t;

 

  Assume RR, AV, and LB are all services provided by indepen= dent appliances,

 and FE_TLS and BE_TLS are different instances of the same T= LS service

  provided by a fourth independent appliance.  The poss= ible chains are:

 

  chain 1:         R= R,     LB

  chain 2:         R= R, AV, LB

  chain 3: FE_TLS, RR,     LB=

  chain 4: FE_TLS, RR, AV, LB

  chain 5:         R= R,     LB, BE_TLS

  chain 6:         R= R, AV, LB, BE_TLS

  chain 7: FE_TLS, RR,     LB, BE_TLS

  chain 8: FE_TLS, RR, AV, LB, BE_TLS

 

  Initial classification would always choose from either cha= in 1 or chain 3.

  (e.g., based on the TCP destination port).

 

  RR would then choose either chain (1, 2) or chain (3, 4), = respectively.

 

  LB would then choose either chain (1, 2, 5, 6) or chain (3= , 4, 7, 8),

 respectively.

 

  The decisions made by RR/LB seem unlikely to be made on an= IP packet basis,

  yet still need to influence the chain ID encapsulation?

 

  Now, TLS/RR/LB might all be in the same appliance, but eve= n so, the chain

  to AV still has the same issue.

 

  So, I guess my question is: Is this a valid DC use case fo= r SFC?

 

thanx.

 

--  Kevin J. Ma

 

From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]
Sent: Tuesday, November 19, 2013 1:06 PM
To: Paul Quinn (paulq); Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: RE: [nsc] Revised SFC Charter

 

Hi, Kevin.

 

Can you  explain your thinkin= g on why service function chaining would be cognizant of the layer at which= the service function operates?   As I see it, any service function is free to modify the original packet in a manner= that suits it.   It also has the choice to allow the packet (mod= ified or unmodified) to progress on the original service function chain or = to intercede with the local service function chaining functionality such that it jumps onto a new chain.   In= either case, the local service function chaining functionality will cause = the packet to be properly encapsulated in order to be conveyed to the next = service function (or forwarded off the end of the chain, if applicable).

 

   Ron=

 

 

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 19, 2013 12:32 PM
To: Kevin J Ma
Cc: nsc@ietf.org; Jim Guichard (= jguichar)
Subject: Re: [nsc] Revised SFC Charter

 

Hi Kevin,

 

 

On Nov 19, 2013, at 10:15 AM, Kevin J Ma <kevin.ma@azukisystems.com> wro= te:

 

Jim> this would be part of the control plane which wou= ld make available to the service function (or proxy) information about inbo= und and outbound service function chain encapsulation. 

 

Personally, I am still unclear as to how this would work for appl= ication layer

services.  It's not a control plane issue if it's session da= ta dependent?

 

 

The control plane is responsible for the chaining/pa= thing aspect of SFC: conveying network locators for forwarding, allocating = service header information and so on.  It is not responsible for funct= ion specifics (e.g. per SFC policy).

 

 

 

 

I won't rehash the previous discussion on "packet-level"= ; classification and

"packet-level" encapsulation, but IMO there are a numbe= r of issues cited in

the problem statement which are not solved by simply defining an = encapsulation

header.  Yes, there are other informational documents on the= list, but if they

do not address these questions on how the encapsulation may be us= ed (and how

different levels of classification/re-classification will work), = then the

encapsulation spec has to stand on its own.  The charter cou= ld be interpreted

either way.

 

 

The encap format won't solve everything, however it = creates a foundation to build upon.  Many of the problems will be solv= ed at upper layers, leveraging the encap in the data plane.

 

thanx.

 

--  Kevin J. Ma

 

From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=  
Sent: Tuesday, Nov= ember 19, 2013 9:39 AM
To: Kevin J Ma; nsc@ietf.org
Subject: Re: Revis= ed SFC Charter

 

Hi Kevin,

 

From: = Kevin J Ma <kevin.ma@azukisystems.com>
Date: Tuesday, Nov= ember 19, 2013 1:25 AM
To: Jim Guichard &= lt;jguic= har@cisco.com>, "nsc@ietf.org" <nsc@ietf.org>
Subject: RE: Revis= ed SFC Charter

 

Hi Jim,

 

  There is a typo in item 3.  "is is&= quot; -> "it is":

 

    "It is intended that the enc= apsulation be agnostic to the layer at which is is applied"=

 

Jim> yes, thank you, I corrected the text. 

 

  Wrt to the following text:

 

    "the same encapsulation may = be used on a service function path realized at the network layer or at any = other layer"

 

  If the service function is an application lay= er service, and the

  encapsulation is at a lower layer (L2/L3), th= en presumably signaling

  would be required between the application lay= er and the lower layer

  responsible for encapsulation, so that indivi= dual packets for an

  application layer message may be properly enc= apsulated.  Has this

  been discussed and/or is it considered in sco= pe?

 

Jim> the point here was to show that the steering func= tion is independent of the services layer. As packets traverse a service ch= ain the encapsulation above the steering function is used to indicate what service function to apply and which serv= ice function comes next in the service function chain. 

 

  Though this sort of thing could be called an = implementation detail,

 typically higher layers do not need to know th= e lower layer details,

 but in this particular case, if the higher lay= er is re-classifying,

 it likely wants/needs to know the ingress chai= n ID as it selects the

  egress chain ID, and then needs to tell = the lower encapsulation layer

 what the new egress chain ID should be?

 

Jim> this would be part of the control plane which wou= ld make available to the service function (or proxy) information about inbo= und and outbound service function chain encapsulation. 

 

thanx.

 

--  Kevin J. Ma

 

From: nsc [mail= to:nsc-bounces@ietf.org]&n= bsp;On Behalf Of Jim Guichard (jguichar)
Sent: Monday, Nove= mber 18, 2013 4:17 PM
To: nsc@ietf.org
Subject: [nsc] Rev= ised SFC Charter

 

Greetings,=

 

Thomas Narten and I have spen= t some time refining the SFC charter based upon discussion during the SFC B= OF and several emails to the mailing list. We do not believe this is a substantive change; we have clarified the mana= gement vs. control plane text and added text around security. Please r= eview the revised charter and provide comment.

 

Revised SFC WG Charter:

 

Service delivery is undergoing si= gnificant change with the introduction of virtualization, network overlays,= and orchestration. Service delivery is currently both a technical and an organizational challenge that involves s= ignificant modification to the network configuration thereby impacting the = speed at which services can be deployed and increasing operational costs. S= ervices are typically implemented by the ordered combination of a number of service functions that are deplo= yed at different points within a network. Today, a common deployment model = has service functions physically inserted on the data-forwarding path betwe= en communicating peers. Going forward, however, there is a desire to move to a different model, where service fun= ctions, whether physical or virtualized, are not required to reside on the = direct data path and traffic is instead steered through service functions, = wherever they are deployed.  

 

= For a given service, the abstracted view of the required service functions = and the order in which they are to be applied is called a Service Function Chain (SFC). An SFC is instantiated= through selection of specific service function instances and the network n= odes on which they are provided, thereby forming a service graph: this is c= alled a Service Function Path (SFP). The service functions may be applied at any layer within the network protocol stack (n= etwork layer, application layer, etc.).  

 

= The SFC working group will document a new approach to service delivery and = operation. It will produce an architecture for service function chaining that includes the necessary protocols or pro= tocol extensions to convey the service path and service path information to= nodes that are involved in the implementation of service functions and ser= vice function chains, as well as mechanisms for steering traffic through service functions. The working gro= up will examine what information needs to be gathered from the network and = service functions in support of service function chaining and how that info= rmation may be made available to the components of the service function chaining architecture. The SFC= WG will closely consider the security implications when documenting these = deliverables. 

 

= Specifically, the SFC WG is chartered to deliver the following:

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.= Additionally, the working group will normalize nomenclature and definition= s for service function chaining. 

2.  Architec= ture: This document will provide a description of the SFC architectural building= blocks and their relationship including interconnection, placement of SFC = specific capabilities, management, diagnostics, design analysis, and securi= ty models, as well as requirements on the protocol mechanisms. The initial scope is restricted to a single ad= ministrative domain, keeping in mind that architectural decisions made for = the intra-domain case may have implications for the inter-domain case.

3.  Generic SFC Encapsulation: This document will describe a single service-level data= plane encapsulation format for conveying the service function chain and th= e service function path, and for communicating context information between = nodes that implement service functions and service function chains. It is intended that the encapsulation be agno= stic to the layer at which is is applied and the service that is being cons= tructed. That is, the same encapsulation may be used on a service function = path realized at the network layer or at any other layer, and the same encapsulation will apply for the const= ruction of service function paths regardless of the actual service.<= o:p>

4.  Control Plane Mechanisms: A document will be developed to describe requirements fo= r conveying information between control or management elements and SFC impl= ementation points. All protocol extension work resulting from these require= ments should be carried out in the working group responsible for the protocol being modified in coordination = with this working group, but may be done in this working group under a revi= sed charter after agreement with all the relevant WG chairs and responsible= ADs.

5.  Manageab= ility: Work on the management and configuration of SFC components related to the = support of service function chaining will certainly be needed, but first ne= eds to be better understood and scoped.

 

Proposed Milestones:

 

Apr 2014

Submit to IESG Informational document defining the SFC problem= statement and core use cases

Apr 2014

Consult with OPS area on possible SFC charter modifications fo= r management and configuration of SFC components related to the support of = service function chaining

Jan 2015

Submit to IESG Informational document defining the architectur= e for SFC

Jan 2015

Submit to IESG Informational document defining the control pla= ne requirements for conveying information between control or management ele= ments and SFC implementation points

Aug 2015

Submit to IESG Standards Track document specifying the generic= service function chaining header encapsulation

 

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

 

 --_000_CEB2EA2C27EBCsmkumarciscocom_-- From adrian@olddog.co.uk Tue Nov 26 13:27:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FC1ADFB8 for ; Tue, 26 Nov 2013 13:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4IpZgNVQNliv for ; Tue, 26 Nov 2013 13:27:23 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 113BC1ADFAB for ; Tue, 26 Nov 2013 13:27:22 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQLRL2S026152 for ; Tue, 26 Nov 2013 21:27:21 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQLRJHx026130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Nov 2013 21:27:20 GMT From: "Adrian Farrel" To: Date: Tue, 26 Nov 2013 21:27:19 -0000 Message-ID: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQ== Content-Language: en-gb Subject: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 21:27:26 -0000 Hi SFC list (still pretending to be NSC), Jim and Thomas have collated the discussion on a proposed WG charter and I have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I have still two tasks: 1. Read the mailing list to make sure they have captured consensus 2. Read the charter to make sure I support it. You can help me by commenting (on the list is preferred) about any deficiencies in the charter text or proposed milestones. My plan is to put the charter before the IESG on Thursday December 5th, and if all goes well it should go out for IESG and external review before coming to the IESG again for final approval on the 19th. Just be aware that snafus are "normal". As soon as we know the WG is forming, I will get the Secretariat to migrate the list to sfc@ietf.org. They're pretty good at that and you should feel no pain (mostly). Thanks, Adrian From lucy.yong@huawei.com Tue Nov 26 14:15:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1301ADF7F for ; Tue, 26 Nov 2013 14:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 I6ixUr9B-sBP for ; Tue, 26 Nov 2013 14:15:20 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B07681ADF7A for ; Tue, 26 Nov 2013 14:14:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAS89397; Tue, 26 Nov 2013 22:14:56 +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; Tue, 26 Nov 2013 22:14:28 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 26 Nov 2013 22:14:55 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 14:14:51 -0800 From: Lucy yong To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: Clarification RE: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQAAoKwQ Date: Tue, 26 Nov 2013 22:14:50 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> In-Reply-To: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.158] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "sfc@ietf.org" Subject: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 26 Nov 2013 22:15:25 -0000 Text: An SFC is instantiated through selection of specific service function insta= nces and the network nodes on which they are provided, thereby forming a se= rvice graph: this is called a Service Function Path (SFP). -end Does it mean to say this? A SFC is instantiated through selection of specific service function instan= ces and/or the network nodes on which they are provided, thereby forming a = service graph: this is called a Service Function Path (SFP). "and/or" means different from "and". Text in Generic SFC Encapsulation: a single service-level data plane encapsulation format for conveying the se= rvice function chain and the service function path, and for communicating c= ontext information between nodes that implement service functions and servi= ce function chains. -end Do these nested "and" means that the data plane encapsulation format has to= have the fields for all of these? I thought that only service function cha= in is mandated in data plane; other two are optional in data plane because = some solutions may want to convey them via other mechanism such as control = plane, is that right? If the text does not imply that the last two have to = be present, then I am fine with it. Lucy -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 26, 2013 3:27 PM To: nsc@ietf.org Subject: [nsc] Progress toward WG formation Hi SFC list (still pretending to be NSC), Jim and Thomas have collated the discussion on a proposed WG charter and I = have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I have still two tasks: 1. Read the mailing list to make sure they have captured consensus 2. Read = the charter to make sure I support it. You can help me by commenting (on the list is preferred) about any deficien= cies in the charter text or proposed milestones. My plan is to put the charter before the IESG on Thursday December 5th, and= if all goes well it should go out for IESG and external review before comi= ng to the IESG again for final approval on the 19th. Just be aware that sna= fus are "normal". As soon as we know the WG is forming, I will get the Secretariat to migrate= the list to sfc@ietf.org. They're pretty good at that and you should feel = no pain (mostly). Thanks, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 26 14:46:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4A81ADE72 for ; Tue, 26 Nov 2013 14:46:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E3mUqz8vR1Fc for ; Tue, 26 Nov 2013 14:46:25 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB71AE01B for ; Tue, 26 Nov 2013 14:46:21 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0760C7AF4FA; Tue, 26 Nov 2013 17:46:21 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9461E7AF471; Tue, 26 Nov 2013 17:46:20 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 26 Nov 2013 17:46:20 -0500 From: Kevin J Ma To: "adrian@olddog.co.uk" , "nsc@ietf.org" Date: Tue, 26 Nov 2013 17:46:19 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQA Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FAEBC@MAILR002.mail.lan> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> In-Reply-To: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 26 Nov 2013 22:46:34 -0000 Hi all, This may be a nit, but wrt the encapsulation spec: "It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same=20 encapsulation may be used on a service function path realized at the=20 network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." The first sentance says "layer at which it is applied". That implies to me that the encapsulation header can be applied at different layers? Is that really the intent? To have encapsulation happen at different layers for different legs of the service path?=20 From the second sentance, it seems like what we really want to say is "layer from which it is applied" (i.e., application layer service vs. L2 service that provides the information necessary for encapsulation)? This then goes back to my previous questions related to cross-layer signalling of encapsulation information. Is the discussion of such requirements and/or mechanisms (API)s in or out of scope? Note: As previously stated, I dont believe this to be a control plane issue. thanx. -- Kevin J. Ma > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Tuesday, November 26, 2013 4:27 PM > To: nsc@ietf.org > Subject: [nsc] Progress toward WG formation >=20 > Hi SFC list (still pretending to be NSC), >=20 > Jim and Thomas have collated the discussion on a proposed WG charter and = I > have > updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ >=20 > I have still two tasks: > 1. Read the mailing list to make sure they have captured consensus > 2. Read the charter to make sure I support it. >=20 > You can help me by commenting (on the list is preferred) about any > deficiencies > in the charter text or proposed milestones. >=20 > My plan is to put the charter before the IESG on Thursday December 5th, > and if > all goes well it should go out for IESG and external review before coming > to the > IESG again for final approval on the 19th. Just be aware that snafus are > "normal". >=20 > As soon as we know the WG is forming, I will get the Secretariat to > migrate the > list to sfc@ietf.org. They're pretty good at that and you should feel no > pain > (mostly). >=20 > Thanks, > Adrian >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Tue Nov 26 14:53:35 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9141AE038 for ; Tue, 26 Nov 2013 14:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjomLbn6FWp5 for ; Tue, 26 Nov 2013 14:53:20 -0800 (PST) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id AAC081AE026 for ; Tue, 26 Nov 2013 14:53:19 -0800 (PST) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQMrEuQ002591; Tue, 26 Nov 2013 22:53:15 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAQMrDZs002583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 22:53:14 GMT From: "Adrian Farrel" To: "'Lucy yong'" , References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> Date: Tue, 26 Nov 2013 22:53:13 -0000 Message-ID: <05d501ceeafa$4a0ad2f0$de2078d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK/dDKwSoHjFKWN3dwll9zR6hI5xQMwfx4amD2ETXA= Content-Language: en-gb Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 22:53:35 -0000 Hi Lucy, I think you may be trying to be a lawyer here. > Text: > An SFC is instantiated through selection of specific service function instances and > the network nodes on which they are provided, thereby forming a service graph: > this is called a Service Function Path (SFP). -end > > Does it mean to say this? > > A SFC is instantiated through selection of specific service function instances > and/or the network nodes on which they are provided, thereby forming a service > graph: this is called a Service Function Path (SFP). > > "and/or" means different from "and". If I select a specific service function instance I have presumably selected the node on which it is provided. So I guess you are suggesting that we might want to select a node for the path, but not worry about which instance of the service on that node is used. Of course, if we read selection of specific service function instances [NB plural] then we note that selection of a node could encompass all of the instances on that node. If you feel strongly about this we could change "and" to "and/or" but frankly I think it is all the same thing. > Text in Generic SFC Encapsulation: > a single service-level data plane encapsulation format for conveying the service > function chain and the service function path, and for communicating context > information between nodes that implement service functions and service > function chains. -end > > Do these nested "and" means that the data plane encapsulation format has to > have the fields for all of these? I thought that only service function chain is > mandated in data plane; other two are optional in data plane because some > solutions may want to convey them via other mechanism such as control plane, is > that right? If the text does not imply that the last two have to be present, then I > am fine with it. What does "has to have" mean? You have four seats in your car - do you always carry four people? However, the design spec of the car allows you to carry four people if that is the choice of the day. Thus, the service-level encapsulation has some purposes: - it is for conveying: - the service function chain - the service function path - it is for communicating context information When designing the encapsulation you must design for all of these. When using the encapsulation, you only use what you need. Now, it MIGHT be a reasonable design goal to make sure that the encapsulation is optimal on the wire when only a subset of the information needs to be carried. And you MIGHT observe that "context information" might be of varying size. This all sounds like solution-specific details arising from the requirements that haven't been written/agreed yet. Cheers, Adrian From narten@us.ibm.com Tue Nov 26 14:59:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42DA1AE037 for ; Tue, 26 Nov 2013 14:59:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 EhXQGDnNFDi3 for ; Tue, 26 Nov 2013 14:59:14 -0800 (PST) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by ietfa.amsl.com (Postfix) with ESMTP id B8FD71AE026 for ; Tue, 26 Nov 2013 14:59:12 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 26 Nov 2013 15:59:12 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 26 Nov 2013 15:59:11 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 8FAC73E4004E for ; Tue, 26 Nov 2013 15:59:10 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08025.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAQKvLNX328004 for ; Tue, 26 Nov 2013 21:57:21 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rAQMx8QL006205 for ; Tue, 26 Nov 2013 15:59:10 -0700 Received: from cichlid.raleigh.ibm.com ([9.49.221.66]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id rAQMwwM1005531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Nov 2013 15:59:06 -0700 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id rAQMwup2015372; Tue, 26 Nov 2013 17:58:56 -0500 Message-Id: <201311262258.rAQMwup2015372@cichlid.raleigh.ibm.com> To: Lucy yong In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> Comments: In-reply-to Lucy yong message dated "Tue, 26 Nov 2013 22:14:50 +0000." Date: Tue, 26 Nov 2013 17:58:56 -0500 From: Thomas Narten X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13112622-7164-0000-0000-000003B26A09 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 26 Nov 2013 22:59:19 -0000 Hi Lucy. > Text: > An SFC is instantiated through selection of specific service > function instances and the network nodes on which they are provided, > thereby forming a service graph: this is called a Service Function > Path (SFP). -end > Does it mean to say this? > A SFC is instantiated through selection of specific service function > instances and/or the network nodes on which they are provided, > thereby forming a service graph: this is called a Service Function > Path (SFP). > "and/or" means different from "and". To be clear, you are asking that "and" be changed to "and/or"? Actually, better text would probably be something like: An SFC is instantiated through selection of specific service function instances on specific network nodes on which they are provided, thereby forming a service graph: this is called a Service Function Path (SFP). -end I.e., change the "and the network nodes ..." to "on specific network nodes..." Would that work? > Text in Generic SFC Encapsulation: > a single service-level data plane encapsulation format for conveying > the service function chain and the service function path, and for > communicating context information between nodes that implement > service functions and service function chains. -end > Do these nested "and" means that the data plane encapsulation format > has to have the fields for all of these? I thought that only service > function chain is mandated in data plane; other two are optional in > data plane because some solutions may want to convey them via other > mechanism such as control plane, is that right? I think the answer is both yes and no. Yes, those fields will be needed, but there may be cases where some fields can be omitted. But that sort of detail is for the WG to decide later. E.g., even if the fields aren't needed it may be simpler just to always have them to keep the header size constant in all packets. But in no way should the wording in the charter be taken to mean that this sort of (detailed) decision has already been made. These sorts of details need to be worked out in the WG. > If the text does not imply that the last two have to be present, > then I am fine with it. I do not believe the charter text implies that. Thomas (with concurrence from Jim) From kevin.ma@azukisystems.com Tue Nov 26 18:29:02 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FF61AE0DB for ; Tue, 26 Nov 2013 18:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oFDgCdwIXlZj for ; Tue, 26 Nov 2013 18:29:00 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2951A1F08 for ; Tue, 26 Nov 2013 18:29:00 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A68E67AFCA9; Tue, 26 Nov 2013 21:28:59 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 38F307AFC8C; Tue, 26 Nov 2013 21:28:59 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 26 Nov 2013 21:28:59 -0500 From: Kevin J Ma To: "adrian@olddog.co.uk" , "nsc@ietf.org" Date: Tue, 26 Nov 2013 21:28:56 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 02:29:02 -0000 just to clarify, as an example, do we expect to be able to: - use L2 encapsulation to get from the classifier to the firewall - use L4 encapsulation to get from the firewall to the TLS offload - use L5 encapsulation to get from the TLS offload to the load balancer - use L3 encapsulation to get from the load balancer to AV scanner etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... (with all the necessary re-classification steps in between)? > -----Original Message----- > From: Kevin J Ma > Sent: Tuesday, November 26, 2013 5:46 PM > To: 'adrian@olddog.co.uk'; nsc@ietf.org > Subject: RE: [nsc] Progress toward WG formation >=20 > Hi all, >=20 > This may be a nit, but wrt the encapsulation spec: >=20 > "It is intended that > the encapsulation be agnostic to the layer at which it is applied and > the service that is being constructed. That is, the same > encapsulation may be used on a service function path realized at the > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service." >=20 > The first sentance says "layer at which it is applied". That implies > to me that the encapsulation header can be applied at different layers? > Is that really the intent? To have encapsulation happen at different > layers for different legs of the service path? >=20 > From the second sentance, it seems like what we really want to say is > "layer from which it is applied" (i.e., application layer service vs. > L2 service that provides the information necessary for encapsulation)? >=20 > This then goes back to my previous questions related to cross-layer > signalling of encapsulation information. Is the discussion of such > requirements and/or mechanisms (API)s in or out of scope? Note: As > previously stated, I dont believe this to be a control plane issue. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Tuesday, November 26, 2013 4:27 PM > > To: nsc@ietf.org > > Subject: [nsc] Progress toward WG formation > > > > Hi SFC list (still pretending to be NSC), > > > > Jim and Thomas have collated the discussion on a proposed WG charter an= d > I > > have > > updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ > > > > I have still two tasks: > > 1. Read the mailing list to make sure they have captured consensus > > 2. Read the charter to make sure I support it. > > > > You can help me by commenting (on the list is preferred) about any > > deficiencies > > in the charter text or proposed milestones. > > > > My plan is to put the charter before the IESG on Thursday December 5th, > > and if > > all goes well it should go out for IESG and external review before > coming > > to the > > IESG again for final approval on the 19th. Just be aware that snafus ar= e > > "normal". > > > > As soon as we know the WG is forming, I will get the Secretariat to > > migrate the > > list to sfc@ietf.org. They're pretty good at that and you should feel n= o > > pain > > (mostly). > > > > Thanks, > > Adrian > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From lucy.yong@huawei.com Tue Nov 26 18:59:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF6E1AE0AD for ; Tue, 26 Nov 2013 18:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 oaEMiCho4uP7 for ; Tue, 26 Nov 2013 18:59:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 26DDC1AE0A0 for ; Tue, 26 Nov 2013 18:59:49 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT03591; Wed, 27 Nov 2013 02:59:47 +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, 27 Nov 2013 02:59:16 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 02:59:45 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 18:59:42 -0800 From: Lucy yong To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: Clarification RE: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQAAoKwQABMjGoAADUujAA== Date: Wed, 27 Nov 2013 02:59:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453024CC@dfweml509-mbx.china.huawei.com> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> <05d501ceeafa$4a0ad2f0$de2078d0$@olddog.co.uk> In-Reply-To: <05d501ceeafa$4a0ad2f0$de2078d0$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 02:59:51 -0000 Hi Adrian, I think you may be trying to be a lawyer here. [Lucy] never thought about it; not my intention at all. :)=20 > Text: > An SFC is instantiated through selection of specific service function instances and > the network nodes on which they are provided, thereby forming a service g= raph: > this is called a Service Function Path (SFP). -end >=20 > Does it mean to say this? >=20 > A SFC is instantiated through selection of specific service function=20 > instances and/or the network nodes on which they are provided, thereby=20 > forming a service > graph: this is called a Service Function Path (SFP). >=20 > "and/or" means different from "and". If I select a specific service function instance I have presumably selected= the node on which it is provided. So I guess you are suggesting that we might want to select a node for the p= ath, but not worry about which instance of the service on that node is used= . Of course, if we read selection of specific service function instances [NB = plural] then we note that selection of a node could encompass all of the in= stances on that node. If you feel strongly about this we could change "and" to "and/or" but frank= ly I think it is all the same thing. [Lucy] The sentence confuses me on whether the service function path (SFP) = for a SFC will be presented as a list of service function instances, or bot= h a list of service function instances and the network nodes on which they = are provided, or ... I don't have strong feeling, just want to get a bit mo= re clear on it.=20 > Text in Generic SFC Encapsulation: > a single service-level data plane encapsulation format for conveying=20 > the service > function chain and the service function path, and for communicating=20 > context information between nodes that implement service functions and=20 > service function chains. -end >=20 > Do these nested "and" means that the data plane encapsulation format=20 > has to have the fields for all of these? I thought that only service=20 > function chain is > mandated in data plane; other two are optional in data plane because=20 > some solutions may want to convey them via other mechanism such as=20 > control plane, is > that right? If the text does not imply that the last two have to be=20 > present, then I > am fine with it. What does "has to have" mean? [Lucy] means "always presence, not optional". You have four seats in your car - do you always carry four people? However, the design spec of the car allows you to carry four people if that= is the choice of the day. [Lucy] I don't think that this is a good example to use here. If we use car= as example, my point would be if the last two are as the ceiling window or= the seat of car. One is optional, another is included in all models.=20 Thus, the service-level encapsulation has some purposes:=20 - it is for conveying: - the service function chain - the service function path - it is for communicating context information When designing the encapsulation you must design for all of these. When using the encapsulation, you only use what you need. [Lucy] This is what I want to hear. Thank you for the clarification. Now, it MIGHT be a reasonable design goal to make sure that the encapsulati= on is optimal on the wire when only a subset of the information needs to be= carried. And you MIGHT observe that "context information" might be of varying size. = This all sounds like solution-specific details arising from the requiremen= ts that haven't been written/agreed yet. [Lucy] Sorry, IMO: my point is not solution-specific.=20 Regards, Lucy Lucy Cheers, Adrian From lucy.yong@huawei.com Tue Nov 26 19:14:08 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCEF1AE0D8 for ; Tue, 26 Nov 2013 19:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 JztOoVjfMs-v for ; Tue, 26 Nov 2013 19:14:06 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8470D1A8034 for ; Tue, 26 Nov 2013 19:14:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYI83526; Wed, 27 Nov 2013 03:14:04 +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; Wed, 27 Nov 2013 03:13:34 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 03:14:03 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Tue, 26 Nov 2013 19:14:00 -0800 From: Lucy yong To: Thomas Narten Thread-Topic: [nsc] Clarification RE: Progress toward WG formation Thread-Index: AQHO6vsmzfp9hUhF10GvlbwFJWmqQZo4ZGpA Date: Wed, 27 Nov 2013 03:14:00 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453024EB@dfweml509-mbx.china.huawei.com> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> <201311262258.rAQMwup2015372@cichlid.raleigh.ibm.com> In-Reply-To: <201311262258.rAQMwup2015372@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.141.240] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 03:14:09 -0000 Hi Thomas, Please see inline below. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com]=20 Sent: Tuesday, November 26, 2013 4:59 PM To: Lucy yong Cc: adrian@olddog.co.uk; nsc@ietf.org Subject: Re: [nsc] Clarification RE: Progress toward WG formation Hi Lucy. > Text: > An SFC is instantiated through selection of specific service function=20 > instances and the network nodes on which they are provided, thereby=20 > forming a service graph: this is called a Service Function Path (SFP).=20 > -end > Does it mean to say this? > A SFC is instantiated through selection of specific service function=20 > instances and/or the network nodes on which they are provided, thereby=20 > forming a service graph: this is called a Service Function Path (SFP). > "and/or" means different from "and". To be clear, you are asking that "and" be changed to "and/or"? Actually, better text would probably be something like: An SFC is instantiated through selection of specific service function instances on specific network nodes on which they are provided, thereby forming a service graph: this is called a Service Function Path (SFP). -end I.e., change the "and the network nodes ..." to "on specific network nodes.= .." Would that work? [Lucy] This is better. The point is what is used to form the service graph,= service function instances, nodes, or both. If you think that should be di= scussed in the solution development, I am fine with the text. BTW, why use = "An SFC"? > Text in Generic SFC Encapsulation: > a single service-level data plane encapsulation format for conveying=20 > the service function chain and the service function path, and for=20 > communicating context information between nodes that implement service=20 > functions and service function chains. -end > Do these nested "and" means that the data plane encapsulation format=20 > has to have the fields for all of these? I thought that only service=20 > function chain is mandated in data plane; other two are optional in=20 > data plane because some solutions may want to convey them via other=20 > mechanism such as control plane, is that right? I think the answer is both yes and no. Yes, those fields will be needed, bu= t there may be cases where some fields can be omitted. But that sort of det= ail is for the WG to decide later. E.g., even if the fields aren't needed i= t may be simpler just to always have them to keep the header size constant = in all packets. But in no way should the wording in the charter be taken to= mean that this sort of (detailed) decision has already been made. These so= rts of details need to be worked out in the WG. [Lucy] Good. I am fine with this approach. Regards, Lucy > If the text does not imply that the last two have to be present, then=20 > I am fine with it. I do not believe the charter text implies that. Thomas (with concurrence from Jim) From hongyu.li@huawei.com Tue Nov 26 19:43:07 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8774D1AE102 for ; Tue, 26 Nov 2013 19:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 M3qAWq2fjGIU for ; Tue, 26 Nov 2013 19:43:03 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DD24E1AE0AB for ; Tue, 26 Nov 2013 19:43:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT06873; Wed, 27 Nov 2013 03:43:00 +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, 27 Nov 2013 03:42:27 +0000 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 03:42:56 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 11:42:47 +0800 From: "Hongyu Li (Julio)" To: Lucy yong , Thomas Narten Thread-Topic: [nsc] Clarification RE: Progress toward WG formation Thread-Index: AQHO6vstwmBG70Qr0kKWIgBByOdFrpo34VwAgACMQyA= Date: Wed, 27 Nov 2013 03:42:46 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E99AC64@SZXEMA509-MBX.china.huawei.com> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <2691CE0099834E4A9C5044EEC662BB9D453023CF@dfweml509-mbx.china.huawei.com> <201311262258.rAQMwup2015372@cichlid.raleigh.ibm.com> <2691CE0099834E4A9C5044EEC662BB9D453024EB@dfweml509-mbx.china.huawei.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D453024EB@dfweml509-mbx.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 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 03:43:09 -0000 QWN0dWFsbHksIEkgaGF2ZSBhIHNpbWlsYXIgcXVlc3Rpb24uIFNvbHV0aW9uIGFkZHJlc3MgYnkg U0ZDIFdHICh3aGVuIGl0IGNvbWVzIGludG8gcmVhbGl0eSkgc2hvdWxkIGJlIGFwcGxpY2FibGUg dG8gYm90aCBwaHlzaWNhbCBub2RlcyBhbmQgdmlydHVhbCBpbnN0YW5jZSwgb3IgZXZlbiBhIG1p eCBvZiB0aGUgdHdvLiBJbiBvdGhlciB3b3JkcywgYW4gImluc3RhbmNlIiBtYXkgcmVzaWRlcyBp biBhIG5ldHdvcmsgbm9kZSwgb3IgaW4gYSBzZXJ2ZXIsIHdoZXJlIG1heSBjb250YWlucyBtdWx0 aXBsZSBpbnN0YW5jZXMuIEhhdmluZyB0aGF0IHNhaWQsIHRvIGNvdmVyIGFsbCBjYXNlcywgSSdk IHN1Z2dlc3QgZm9sbG93aW5nIHRleHQ6DQoNCg0KICAgQW4gU0ZDIGlzIGluc3RhbnRpYXRlZCB0 aHJvdWdoIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcywg dGhlcmVieSBmb3JtaW5nIGEgc2VydmljZSBncmFwaDogdGhpcyBpcyBjYWxsZWQgYSBTZXJ2aWNl IEZ1bmN0aW9uIFBhdGggKFNGUCkuIC1lbmQNCg0KUmVtb3ZpbmcgIm9uIHNwZWNpZmljIG5ldHdv cmsgbm9kZXMgb24gd2hpY2ggdGhleSBhcmUgcHJvdmlkZWQiLg0KDQpXb3VsZCB0aGlzIGJlIE9L Pw0KDQpDaGVlcnMsDQpIb25neXUNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IG5zYyBbbWFpbHRvOm5zYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTHVjeSB5b25n DQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDI3LCAyMDEzIDExOjE0IEFNDQpUbzogVGhvbWFz IE5hcnRlbg0KQ2M6IG5zY0BpZXRmLm9yZzsgYWRyaWFuQG9sZGRvZy5jby51aw0KU3ViamVjdDog UmU6IFtuc2NdIENsYXJpZmljYXRpb24gUkU6IFByb2dyZXNzIHRvd2FyZCBXRyBmb3JtYXRpb24N Cg0KSGkgVGhvbWFzLA0KDQpQbGVhc2Ugc2VlIGlubGluZSBiZWxvdy4NCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFRob21hcyBOYXJ0ZW4gW21haWx0bzpuYXJ0ZW5AdXMuaWJt LmNvbV0NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDI2LCAyMDEzIDQ6NTkgUE0NClRvOiBMdWN5 IHlvbmcNCkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBuc2NAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbbnNjXSBDbGFyaWZpY2F0aW9uIFJFOiBQcm9ncmVzcyB0b3dhcmQgV0cgZm9ybWF0aW9uDQoN CkhpIEx1Y3kuDQoNCj4gVGV4dDoNCg0KPiBBbiBTRkMgaXMgaW5zdGFudGlhdGVkIHRocm91Z2gg c2VsZWN0aW9uIG9mIHNwZWNpZmljIHNlcnZpY2UgZnVuY3Rpb24gDQo+IGluc3RhbmNlcyBhbmQg dGhlIG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhleSBhcmUgcHJvdmlkZWQsIHRoZXJlYnkgDQo+ IGZvcm1pbmcgYSBzZXJ2aWNlIGdyYXBoOiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rp b24gUGF0aCAoU0ZQKS4NCj4gLWVuZA0KDQo+IERvZXMgaXQgbWVhbiB0byBzYXkgdGhpcz8NCg0K PiBBIFNGQyBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2Vy dmljZSBmdW5jdGlvbiANCj4gaW5zdGFuY2VzIGFuZC9vciB0aGUgbmV0d29yayBub2RlcyBvbiB3 aGljaCB0aGV5IGFyZSBwcm92aWRlZCwgdGhlcmVieSANCj4gZm9ybWluZyBhIHNlcnZpY2UgZ3Jh cGg6IHRoaXMgaXMgY2FsbGVkIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApLg0KDQo+ICJh bmQvb3IiIG1lYW5zIGRpZmZlcmVudCBmcm9tICJhbmQiLg0KDQpUbyBiZSBjbGVhciwgeW91IGFy ZSBhc2tpbmcgdGhhdCAiYW5kIiBiZSBjaGFuZ2VkIHRvICJhbmQvb3IiPw0KDQpBY3R1YWxseSwg YmV0dGVyIHRleHQgd291bGQgcHJvYmFibHkgYmUgc29tZXRoaW5nIGxpa2U6DQoNCiAgIEFuIFNG QyBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZQ0K ICAgZnVuY3Rpb24gaW5zdGFuY2VzIG9uIHNwZWNpZmljIG5ldHdvcmsgbm9kZXMgb24gd2hpY2gg dGhleSBhcmUNCiAgIHByb3ZpZGVkLCB0aGVyZWJ5IGZvcm1pbmcgYSBzZXJ2aWNlIGdyYXBoOiB0 aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UNCiAgIEZ1bmN0aW9uIFBhdGggKFNGUCkuIC1lbmQNCg0K SS5lLiwgY2hhbmdlIHRoZSAiYW5kIHRoZSBuZXR3b3JrIG5vZGVzIC4uLiIgdG8gIm9uIHNwZWNp ZmljIG5ldHdvcmsgbm9kZXMuLi4iDQoNCldvdWxkIHRoYXQgd29yaz8NCltMdWN5XSBUaGlzIGlz IGJldHRlci4gVGhlIHBvaW50IGlzIHdoYXQgaXMgdXNlZCB0byBmb3JtIHRoZSBzZXJ2aWNlIGdy YXBoLCBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlcywgbm9kZXMsIG9yIGJvdGguIElmIHlvdSB0 aGluayB0aGF0IHNob3VsZCBiZSBkaXNjdXNzZWQgaW4gdGhlIHNvbHV0aW9uIGRldmVsb3BtZW50 LCBJIGFtIGZpbmUgd2l0aCB0aGUgdGV4dC4gQlRXLCB3aHkgdXNlICJBbiBTRkMiPw0KDQo+IFRl eHQgaW4gR2VuZXJpYyBTRkMgRW5jYXBzdWxhdGlvbjoNCg0KPiBhIHNpbmdsZSBzZXJ2aWNlLWxl dmVsIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgZm9yIGNvbnZleWluZyANCj4gdGhl IHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGgsIGFu ZCBmb3IgDQo+IGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVz IHRoYXQgaW1wbGVtZW50IHNlcnZpY2UgDQo+IGZ1bmN0aW9ucyBhbmQgc2VydmljZSBmdW5jdGlv biBjaGFpbnMuIC1lbmQNCg0KPiBEbyB0aGVzZSBuZXN0ZWQgImFuZCIgbWVhbnMgdGhhdCB0aGUg ZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIGZvcm1hdCANCj4gaGFzIHRvIGhhdmUgdGhlIGZpZWxk cyBmb3IgYWxsIG9mIHRoZXNlPyBJIHRob3VnaHQgdGhhdCBvbmx5IHNlcnZpY2UgDQo+IGZ1bmN0 aW9uIGNoYWluIGlzIG1hbmRhdGVkIGluIGRhdGEgcGxhbmU7IG90aGVyIHR3byBhcmUgb3B0aW9u YWwgaW4gDQo+IGRhdGEgcGxhbmUgYmVjYXVzZSBzb21lIHNvbHV0aW9ucyBtYXkgd2FudCB0byBj b252ZXkgdGhlbSB2aWEgb3RoZXIgDQo+IG1lY2hhbmlzbSBzdWNoIGFzIGNvbnRyb2wgcGxhbmUs IGlzIHRoYXQgcmlnaHQ/DQoNCkkgdGhpbmsgdGhlIGFuc3dlciBpcyBib3RoIHllcyBhbmQgbm8u IFllcywgdGhvc2UgZmllbGRzIHdpbGwgYmUgbmVlZGVkLCBidXQgdGhlcmUgbWF5IGJlIGNhc2Vz IHdoZXJlIHNvbWUgZmllbGRzIGNhbiBiZSBvbWl0dGVkLiBCdXQgdGhhdCBzb3J0IG9mIGRldGFp bCBpcyBmb3IgdGhlIFdHIHRvIGRlY2lkZSBsYXRlci4gRS5nLiwgZXZlbiBpZiB0aGUgZmllbGRz IGFyZW4ndCBuZWVkZWQgaXQgbWF5IGJlIHNpbXBsZXIganVzdCB0byBhbHdheXMgaGF2ZSB0aGVt IHRvIGtlZXAgdGhlIGhlYWRlciBzaXplIGNvbnN0YW50IGluIGFsbCBwYWNrZXRzLiBCdXQgaW4g bm8gd2F5IHNob3VsZCB0aGUgd29yZGluZyBpbiB0aGUgY2hhcnRlciBiZSB0YWtlbiB0byBtZWFu IHRoYXQgdGhpcyBzb3J0IG9mIChkZXRhaWxlZCkgZGVjaXNpb24gaGFzIGFscmVhZHkgYmVlbiBt YWRlLiBUaGVzZSBzb3J0cyBvZiBkZXRhaWxzIG5lZWQgdG8gYmUgd29ya2VkIG91dCBpbiB0aGUg V0cuDQpbTHVjeV0gR29vZC4gSSBhbSBmaW5lIHdpdGggdGhpcyBhcHByb2FjaC4NCg0KUmVnYXJk cywNCkx1Y3kNCg0KPiBJZiB0aGUgdGV4dCBkb2VzIG5vdCBpbXBseSB0aGF0IHRoZSBsYXN0IHR3 byBoYXZlIHRvIGJlIHByZXNlbnQsIHRoZW4gDQo+IEkgYW0gZmluZSB3aXRoIGl0Lg0KDQpJIGRv IG5vdCBiZWxpZXZlIHRoZSBjaGFydGVyIHRleHQgaW1wbGllcyB0aGF0Lg0KDQpUaG9tYXMgKHdp dGggY29uY3VycmVuY2UgZnJvbSBKaW0pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpuc2MgbWFpbGluZyBsaXN0DQpuc2NAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo= From melinda.shore@gmail.com Tue Nov 26 20:11:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC16D1ADFC4 for ; Tue, 26 Nov 2013 20:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iQi1VKD3INj for ; Tue, 26 Nov 2013 20:11:56 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9581F1AE032 for ; Tue, 26 Nov 2013 20:11:56 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so9454026pbb.2 for ; Tue, 26 Nov 2013 20:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=YbNeP924AVLcSZCox7fOEjdfPMu8Qjb1Biv0nrKNGyc=; b=eKoldzND3yZdk0RnnPazuk/xTlLGNDDHLHol3Zd56EPzAmOc2m91UWqD181i6PREQh mjS5sP9uYRCFcDuT9CIpxCp+PyDPFvdsH70/oXyEMgey9NhiK/WLYYEd/SgEJy6f3OpY 5eacbjQ/GtjGRe2zDRS8pbjfLR2utMW8+um/+wIVB1frKQASGLIoYPExFVWGaZRA35SQ tonahKceeN0zCykw3d0q+oL+QNKhm9G6WEP2Wjoklf24IVwJKpD34ocQrogDjNggwHLV P/364ziXTybHyyM4R9FyPxgNq/tnTSw9/sW7RzD4ceKOLrllGwhpBjmm4sfDSCwv+IDS w1kQ== X-Received: by 10.66.146.170 with SMTP id td10mr13736426pab.161.1385525516256; Tue, 26 Nov 2013 20:11:56 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id yh1sm84443572pbc.21.2013.11.26.20.11.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Nov 2013 20:11:55 -0800 (PST) Message-ID: <52957109.4000705@gmail.com> Date: Tue, 26 Nov 2013 19:11:53 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:11:59 -0000 On 11/26/13 5:28 PM, Kevin J Ma wrote: > just to clarify, as an example, do we expect to be able to: > - use L2 encapsulation to get from the classifier to the firewall > - use L4 encapsulation to get from the firewall to the TLS offload > - use L5 encapsulation to get from the TLS offload to the load balancer > - use L3 encapsulation to get from the load balancer to AV scanner > etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... > (with all the necessary re-classification steps in between)? No. I'm also not sure what you mean by "reclassification" in this context. I don't see this mechanism as being significantly different from how everything from network stacks to filesystems are implemented - they have a demultiplexing element in the messages. What you're suggesting sounds unfortunately and unnecessarily complicated. Melinda From smkumar@cisco.com Tue Nov 26 20:12:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EBD1AE0DB for ; Tue, 26 Nov 2013 20:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 EDTamrjiCPp0 for ; Tue, 26 Nov 2013 20:12:13 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 920911AE0DC for ; Tue, 26 Nov 2013 20:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4118; q=dns/txt; s=iport; t=1385525533; x=1386735133; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kqXfVDmHJlkRevY8hjPYKMpwm6/fogd/2fcbkITWK9k=; b=ESo8MPkHOMGofRMwzZtxrE9STxwy+Ow3pO/uKgoShBEWIDNGUcyi3DYl yc4jy0nNDc4J/J2PZja289NmAnyIh8wwMHp6cph4fQokiCCQdtSb58zlb J8LfN5tE+ODHRjaxtkBMPYIo0tX6PjYs0yB+2o7ICBVEIt6ku/Ys112Ni w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANtvlVKtJXG9/2dsb2JhbABZgwc4U7sIgSYWdIIlAQEBAwEBAQEkEysJEAcGAQgRBAEBHwkuCxQJCAEBBAESh3sGDb9FEwSPAwaELQOYFJITgyiCKg X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="2548700" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-8.cisco.com with ESMTP; 27 Nov 2013 04:12:12 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAR4CC3i029292 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 04:12:12 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 22:12:12 -0600 From: "Surendra Kumar (smkumar)" To: Kevin J Ma , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TAAADw3gA== Date: Wed, 27 Nov 2013 04:12:11 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.150.199] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:12:18 -0000 +-----------+-----------+---------+ | Transport | SFC-Encap | Payload | +-----------+-----------+---------+ It means SFC-Encap being independent of the Transport/Payload and the overall service. In your example, you could have L2/3/4/5 (or a mix of the same) for transport, as dictated by the implementation. You may find some discussion around this in the NSC archive. Surendra. On 11/26/13 6:28 PM, "Kevin J Ma" wrote: >just to clarify, as an example, do we expect to be able to: >- use L2 encapsulation to get from the classifier to the firewall >- use L4 encapsulation to get from the firewall to the TLS offload >- use L5 encapsulation to get from the TLS offload to the load balancer >- use L3 encapsulation to get from the load balancer to AV scanner >etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... >(with all the necessary re-classification steps in between)? > >> -----Original Message----- >> From: Kevin J Ma >> Sent: Tuesday, November 26, 2013 5:46 PM >> To: 'adrian@olddog.co.uk'; nsc@ietf.org >> Subject: RE: [nsc] Progress toward WG formation >>=20 >> Hi all, >>=20 >> This may be a nit, but wrt the encapsulation spec: >>=20 >> "It is intended that >> the encapsulation be agnostic to the layer at which it is applied and >> the service that is being constructed. That is, the same >> encapsulation may be used on a service function path realized at the >> network layer or at any other layer, and the same encapsulation will >> apply for the construction of service function paths regardless of >> the actual service." >>=20 >> The first sentance says "layer at which it is applied". That implies >> to me that the encapsulation header can be applied at different >>layers? >> Is that really the intent? To have encapsulation happen at different >> layers for different legs of the service path? >>=20 >> From the second sentance, it seems like what we really want to say is >> "layer from which it is applied" (i.e., application layer service vs. >> L2 service that provides the information necessary for encapsulation)? >>=20 >> This then goes back to my previous questions related to cross-layer >> signalling of encapsulation information. Is the discussion of such >> requirements and/or mechanisms (API)s in or out of scope? Note: As >> previously stated, I dont believe this to be a control plane issue. >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >> > -----Original Message----- >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >> > Sent: Tuesday, November 26, 2013 4:27 PM >> > To: nsc@ietf.org >> > Subject: [nsc] Progress toward WG formation >> > >> > Hi SFC list (still pretending to be NSC), >> > >> > Jim and Thomas have collated the discussion on a proposed WG charter >>and >> I >> > have >> > updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ >> > >> > I have still two tasks: >> > 1. Read the mailing list to make sure they have captured consensus >> > 2. Read the charter to make sure I support it. >> > >> > You can help me by commenting (on the list is preferred) about any >> > deficiencies >> > in the charter text or proposed milestones. >> > >> > My plan is to put the charter before the IESG on Thursday December >>5th, >> > and if >> > all goes well it should go out for IESG and external review before >> coming >> > to the >> > IESG again for final approval on the 19th. Just be aware that snafus >>are >> > "normal". >> > >> > As soon as we know the WG is forming, I will get the Secretariat to >> > migrate the >> > list to sfc@ietf.org. They're pretty good at that and you should feel >>no >> > pain >> > (mostly). >> > >> > Thanks, >> > Adrian >> > >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 26 20:32:12 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699631A1F4E for ; Tue, 26 Nov 2013 20:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 XJRxncbuLXFQ for ; Tue, 26 Nov 2013 20:32:10 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 535741ADFC4 for ; Tue, 26 Nov 2013 20:32:10 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EEDD6416F8B for ; Tue, 26 Nov 2013 23:32:09 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6E9CE416868 for ; Tue, 26 Nov 2013 23:32:09 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Tue, 26 Nov 2013 23:32:09 -0500 From: Kevin J Ma To: Melinda Shore , "nsc@ietf.org" Date: Tue, 26 Nov 2013 23:32:08 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rJtT0HZa78HNxRq283S2sLZwrrQAAi7Xw Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF29@MAILR002.mail.lan> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> <52957109.4000705@gmail.com> In-Reply-To: <52957109.4000705@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:32:12 -0000 Hi Melinda, > What you're suggesting sounds unfortunately and > unnecessarily complicated. I'm not suggesting anything. I'm trying to understand what the charter say= s. As stated in my original email: > "It is intended that > the encapsulation be agnostic to the layer at which it is applied and > the service that is being constructed. That is, the same > encapsulation may be used on a service function path realized at the > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service." >=20 > The first sentance says "layer at which it is applied". That implies > to me that the encapsulation header can be applied at different layers? > Is that really the intent? To have encapsulation happen at different > layers for different legs of the service path? >=20 > From the second sentance, it seems like what we really want to say is > "layer from which it is applied" (i.e., application layer service vs. > L2 service that provides the information necessary for encapsulation)? The wording is not clear to me whether it means the encapsulation is at any layer, or if the encapsulation is at a single layer, and it is the service that can be at any layer, which influences encapsulation at a single layer. thanx. -- Kevin J. Ma > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Tuesday, November 26, 2013 11:12 PM > To: nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > On 11/26/13 5:28 PM, Kevin J Ma wrote: > > just to clarify, as an example, do we expect to be able to: > > - use L2 encapsulation to get from the classifier to the firewall > > - use L4 encapsulation to get from the firewall to the TLS offload > > - use L5 encapsulation to get from the TLS offload to the load balancer > > - use L3 encapsulation to get from the load balancer to AV scanner > > etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... > > (with all the necessary re-classification steps in between)? >=20 > No. I'm also not sure what you mean by "reclassification" > in this context. I don't see this mechanism as being significantly > different from how everything from network stacks to filesystems > are implemented - they have a demultiplexing element in the > messages. What you're suggesting sounds unfortunately and > unnecessarily complicated. >=20 > Melinda >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Tue Nov 26 20:40:10 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976FA1AE0F3 for ; Tue, 26 Nov 2013 20:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZvQkxw7Xl4D for ; Tue, 26 Nov 2013 20:40:05 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id F3B1F1AE049 for ; Tue, 26 Nov 2013 20:40:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id E005B1C0544; Tue, 26 Nov 2013 20:40:04 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 02AFA1C04E8; Tue, 26 Nov 2013 20:40:03 -0800 (PST) Message-ID: <529577A2.80503@joelhalpern.com> Date: Tue, 26 Nov 2013 23:40:02 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Kevin J Ma , Melinda Shore , "nsc@ietf.org" References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> <52957109.4000705@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF29@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF29@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:40:11 -0000 The way I read the "agnostic" is that one transport might be MPLS, while another might be VxLAN, and a third might be IP-in-IP. However, they both carry the same common header so that logic which needs to extract metadata or other related operations is always working with the same constructs. Yours, Joel On 11/26/13 11:32 PM, Kevin J Ma wrote: > Hi Melinda, > >> What you're suggesting sounds unfortunately and >> unnecessarily complicated. > > I'm not suggesting anything. I'm trying to understand what the charter says. > > As stated in my original email: > >> "It is intended that >> the encapsulation be agnostic to the layer at which it is applied and >> the service that is being constructed. That is, the same >> encapsulation may be used on a service function path realized at the >> network layer or at any other layer, and the same encapsulation will >> apply for the construction of service function paths regardless of >> the actual service." >> >> The first sentance says "layer at which it is applied". That implies >> to me that the encapsulation header can be applied at different layers? >> Is that really the intent? To have encapsulation happen at different >> layers for different legs of the service path? >> >> From the second sentance, it seems like what we really want to say is >> "layer from which it is applied" (i.e., application layer service vs. >> L2 service that provides the information necessary for encapsulation)? > > The wording is not clear to me whether it means the encapsulation is at any > layer, or if the encapsulation is at a single layer, and it is the service > that can be at any layer, which influences encapsulation at a single layer. > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore >> Sent: Tuesday, November 26, 2013 11:12 PM >> To: nsc@ietf.org >> Subject: Re: [nsc] Progress toward WG formation >> >> On 11/26/13 5:28 PM, Kevin J Ma wrote: >>> just to clarify, as an example, do we expect to be able to: >>> - use L2 encapsulation to get from the classifier to the firewall >>> - use L4 encapsulation to get from the firewall to the TLS offload >>> - use L5 encapsulation to get from the TLS offload to the load balancer >>> - use L3 encapsulation to get from the load balancer to AV scanner >>> etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... >>> (with all the necessary re-classification steps in between)? >> >> No. I'm also not sure what you mean by "reclassification" >> in this context. I don't see this mechanism as being significantly >> different from how everything from network stacks to filesystems >> are implemented - they have a demultiplexing element in the >> messages. What you're suggesting sounds unfortunately and >> unnecessarily complicated. >> >> Melinda >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From smkumar@cisco.com Tue Nov 26 20:45:04 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5561E1AE11C for ; Tue, 26 Nov 2013 20:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 hVDM1ONLnAjV for ; Tue, 26 Nov 2013 20:45:00 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B8F101AE118 for ; Tue, 26 Nov 2013 20:45:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4501; q=dns/txt; s=iport; t=1385527500; x=1386737100; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lgnhO2QIhICo4t4tuwXHNHhr5H4MUuy5QRL4pAbEe18=; b=N++CrW3aIoKA1Zund2MBqeWvWLSphBRFUoMZlFyoYPhQIwjjN/7gtR2A WnH3dJqsxv9M/YdvJbe1mwOqu12dZ8ug7vDZO3yNSuiJsRBHaQYQ2mIxW 4nllGIRQzRUTGiVs/o+DHDwkcoZTUaZ5QuuIW2vkRn6j/WsZjxZ//m4qL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAGB4lVKtJXG+/2dsb2JhbABZgwc4U7sJgSMWdIIlAQEBBAEBATc0CwwGAQgRBAEBHwkuCxQJCAIEAQ0FG4dmDb9GEwSOfAcGhC0DmBSSE4Mogio X-IronPort-AV: E=Sophos;i="4.93,779,1378857600"; d="scan'208";a="287604129" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 27 Nov 2013 04:45:00 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAR4ixMi011784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 04:44:59 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 26 Nov 2013 22:44:59 -0600 From: "Surendra Kumar (smkumar)" To: "Hongyu Li (Julio)" , Lucy yong , Thomas Narten Thread-Topic: [nsc] Clarification RE: Progress toward WG formation Thread-Index: AQHO6vsvhr3m92oHZES351udDt6qLpo4zA0AgAAICgD//4tDgA== Date: Wed, 27 Nov 2013 04:44:58 +0000 Message-ID: In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E99AC64@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.8.130913 x-originating-ip: [10.21.150.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <911787938C37934196BD4BF03665E533@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:45:04 -0000 Irrespective of the no of virtual layers, you need a physical node and that being on a network is conveyed by "network node". I would think this whole effort is moot if either one is excluded. Surendra. On 11/26/13 7:42 PM, "Hongyu Li (Julio)" wrote: >Actually, I have a similar question. Solution address by SFC WG (when it >comes into reality) should be applicable to both physical nodes and >virtual instance, or even a mix of the two. In other words, an "instance" >may resides in a network node, or in a server, where may contains >multiple instances. Having that said, to cover all cases, I'd suggest >following text: > > > An SFC is instantiated through selection of specific service function >instances, thereby forming a service graph: this is called a Service >Function Path (SFP). -end > >Removing "on specific network nodes on which they are provided". > >Would this be OK? > >Cheers, >Hongyu > >-----Original Message----- >From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Lucy yong >Sent: Wednesday, November 27, 2013 11:14 AM >To: Thomas Narten >Cc: nsc@ietf.org; adrian@olddog.co.uk >Subject: Re: [nsc] Clarification RE: Progress toward WG formation > >Hi Thomas, > >Please see inline below. > >-----Original Message----- >From: Thomas Narten [mailto:narten@us.ibm.com] >Sent: Tuesday, November 26, 2013 4:59 PM >To: Lucy yong >Cc: adrian@olddog.co.uk; nsc@ietf.org >Subject: Re: [nsc] Clarification RE: Progress toward WG formation > >Hi Lucy. > >> Text: > >> An SFC is instantiated through selection of specific service function >> instances and the network nodes on which they are provided, thereby >> forming a service graph: this is called a Service Function Path (SFP). >> -end > >> Does it mean to say this? > >> A SFC is instantiated through selection of specific service function >> instances and/or the network nodes on which they are provided, thereby >> forming a service graph: this is called a Service Function Path (SFP). > >> "and/or" means different from "and". > >To be clear, you are asking that "and" be changed to "and/or"? > >Actually, better text would probably be something like: > > An SFC is instantiated through selection of specific service > function instances on specific network nodes on which they are > provided, thereby forming a service graph: this is called a Service > Function Path (SFP). -end > >I.e., change the "and the network nodes ..." to "on specific network >nodes..." > >Would that work? >[Lucy] This is better. The point is what is used to form the service >graph, service function instances, nodes, or both. If you think that >should be discussed in the solution development, I am fine with the text. >BTW, why use "An SFC"? > >> Text in Generic SFC Encapsulation: > >> a single service-level data plane encapsulation format for conveying >> the service function chain and the service function path, and for >> communicating context information between nodes that implement service >> functions and service function chains. -end > >> Do these nested "and" means that the data plane encapsulation format >> has to have the fields for all of these? I thought that only service >> function chain is mandated in data plane; other two are optional in >> data plane because some solutions may want to convey them via other >> mechanism such as control plane, is that right? > >I think the answer is both yes and no. Yes, those fields will be needed, >but there may be cases where some fields can be omitted. But that sort of >detail is for the WG to decide later. E.g., even if the fields aren't >needed it may be simpler just to always have them to keep the header size >constant in all packets. But in no way should the wording in the charter >be taken to mean that this sort of (detailed) decision has already been >made. These sorts of details need to be worked out in the WG. >[Lucy] Good. I am fine with this approach. > >Regards, >Lucy > >> If the text does not imply that the last two have to be present, then >> I am fine with it. > >I do not believe the charter text implies that. > >Thomas (with concurrence from Jim) > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 26 20:48:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEEC1AE06D for ; Tue, 26 Nov 2013 20:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WuCdHmrJa6ma for ; Tue, 26 Nov 2013 20:48:12 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 5B56D1ADFC6 for ; Tue, 26 Nov 2013 20:48:12 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1E558416F8B; Tue, 26 Nov 2013 23:48:12 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 94B51416868; Tue, 26 Nov 2013 23:48:11 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 26 Nov 2013 23:48:11 -0500 From: Kevin J Ma To: "Surendra Kumar (smkumar)" , "adrian@olddog.co.uk" , "nsc@ietf.org" Date: Tue, 26 Nov 2013 23:48:09 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TAAADw3gAAE/WUw Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF2A@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 04:48:15 -0000 Hi Surendra, I have some questions about how that would work, but if that is the goal, thank you for the clarification. -- Kevin J. Ma > -----Original Message----- > From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] > Sent: Tuesday, November 26, 2013 11:12 PM > To: Kevin J Ma; adrian@olddog.co.uk; nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 >=20 > +-----------+-----------+---------+ > | Transport | SFC-Encap | Payload | > +-----------+-----------+---------+ >=20 >=20 > It means SFC-Encap being independent of the Transport/Payload and the > overall service. > In your example, you could have L2/3/4/5 (or a mix of the same) for > transport, as dictated by the implementation. You may find some discussio= n > around this in the NSC archive. >=20 > Surendra. >=20 >=20 >=20 > On 11/26/13 6:28 PM, "Kevin J Ma" wrote: >=20 > >just to clarify, as an example, do we expect to be able to: > >- use L2 encapsulation to get from the classifier to the firewall > >- use L4 encapsulation to get from the firewall to the TLS offload > >- use L5 encapsulation to get from the TLS offload to the load balancer > >- use L3 encapsulation to get from the load balancer to AV scanner > >etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... > >(with all the necessary re-classification steps in between)? > > > >> -----Original Message----- > >> From: Kevin J Ma > >> Sent: Tuesday, November 26, 2013 5:46 PM > >> To: 'adrian@olddog.co.uk'; nsc@ietf.org > >> Subject: RE: [nsc] Progress toward WG formation > >> > >> Hi all, > >> > >> This may be a nit, but wrt the encapsulation spec: > >> > >> "It is intended that > >> the encapsulation be agnostic to the layer at which it is applied > and > >> the service that is being constructed. That is, the same > >> encapsulation may be used on a service function path realized at th= e > >> network layer or at any other layer, and the same encapsulation wil= l > >> apply for the construction of service function paths regardless of > >> the actual service." > >> > >> The first sentance says "layer at which it is applied". That implie= s > >> to me that the encapsulation header can be applied at different > >>layers? > >> Is that really the intent? To have encapsulation happen at differen= t > >> layers for different legs of the service path? > >> > >> From the second sentance, it seems like what we really want to say i= s > >> "layer from which it is applied" (i.e., application layer service vs= . > >> L2 service that provides the information necessary for > encapsulation)? > >> > >> This then goes back to my previous questions related to cross-layer > >> signalling of encapsulation information. Is the discussion of such > >> requirements and/or mechanisms (API)s in or out of scope? Note: As > >> previously stated, I dont believe this to be a control plane issue. > >> > >> thanx. > >> > >> -- Kevin J. Ma > >> > >> > -----Original Message----- > >> > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > >> > Sent: Tuesday, November 26, 2013 4:27 PM > >> > To: nsc@ietf.org > >> > Subject: [nsc] Progress toward WG formation > >> > > >> > Hi SFC list (still pretending to be NSC), > >> > > >> > Jim and Thomas have collated the discussion on a proposed WG charter > >>and > >> I > >> > have > >> > updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ > >> > > >> > I have still two tasks: > >> > 1. Read the mailing list to make sure they have captured consensus > >> > 2. Read the charter to make sure I support it. > >> > > >> > You can help me by commenting (on the list is preferred) about any > >> > deficiencies > >> > in the charter text or proposed milestones. > >> > > >> > My plan is to put the charter before the IESG on Thursday December > >>5th, > >> > and if > >> > all goes well it should go out for IESG and external review before > >> coming > >> > to the > >> > IESG again for final approval on the 19th. Just be aware that snafus > >>are > >> > "normal". > >> > > >> > As soon as we know the WG is forming, I will get the Secretariat to > >> > migrate the > >> > list to sfc@ietf.org. They're pretty good at that and you should fee= l > >>no > >> > pain > >> > (mostly). > >> > > >> > Thanks, > >> > Adrian > >> > > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Tue Nov 26 21:08:34 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B931AE12A for ; Tue, 26 Nov 2013 21:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 JlmuBbIs59eI for ; Tue, 26 Nov 2013 21:08:30 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE961AE122 for ; Tue, 26 Nov 2013 21:08:30 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BE6C08BE176; Wed, 27 Nov 2013 00:08:29 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 4B70C8BDEF3; Wed, 27 Nov 2013 00:08:29 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 27 Nov 2013 00:08:27 -0500 From: Kevin J Ma To: "Joel M. Halpern" , Melinda Shore , "nsc@ietf.org" Date: Wed, 27 Nov 2013 00:08:25 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rKsJEZGjzL3lbSzuG+vCi0nLH1AAAfcYQ Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF2B@MAILR002.mail.lan> References: <05ac01ceeaee$4a3d9930$deb8cb90$@olddog.co.uk> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF12@MAILR002.mail.lan> <52957109.4000705@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FAF29@MAILR002.mail.lan> <529577A2.80503@joelhalpern.com> In-Reply-To: <529577A2.80503@joelhalpern.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 05:08:34 -0000 Hi Joel, I read "encapsulation" as the act of encapsulating, and therefore also the act of decapsulating, not as the header itself. It's not immediately clear to me how this could be made "agnostic". The entity that decap's the lower layer needs some way to know that the next layer up is an SFC encap, and that seems like it would be lower-layer-protocol-specific? I can see making the parsing of the encap header: "agnostic", but not the recognition of the encap? thanx. -- Kevin J. Ma > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Tuesday, November 26, 2013 11:40 PM > To: Kevin J Ma; Melinda Shore; nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > The way I read the "agnostic" is that one transport might be MPLS, while > another might be VxLAN, and a third might be IP-in-IP. However, they > both carry the same common header so that logic which needs to extract > metadata or other related operations is always working with the same > constructs. >=20 > Yours, > Joel >=20 > On 11/26/13 11:32 PM, Kevin J Ma wrote: > > Hi Melinda, > > > >> What you're suggesting sounds unfortunately and > >> unnecessarily complicated. > > > > I'm not suggesting anything. I'm trying to understand what the charter > says. > > > > As stated in my original email: > > > >> "It is intended that > >> the encapsulation be agnostic to the layer at which it is applied > and > >> the service that is being constructed. That is, the same > >> encapsulation may be used on a service function path realized at > the > >> network layer or at any other layer, and the same encapsulation > will > >> apply for the construction of service function paths regardless of > >> the actual service." > >> > >> The first sentance says "layer at which it is applied". That > implies > >> to me that the encapsulation header can be applied at different > layers? > >> Is that really the intent? To have encapsulation happen at > different > >> layers for different legs of the service path? > >> > >> From the second sentance, it seems like what we really want to say > is > >> "layer from which it is applied" (i.e., application layer service > vs. > >> L2 service that provides the information necessary for > encapsulation)? > > > > The wording is not clear to me whether it means the encapsulation is at > any > > layer, or if the encapsulation is at a single layer, and it is the > service > > that can be at any layer, which influences encapsulation at a single > layer. > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > >> Sent: Tuesday, November 26, 2013 11:12 PM > >> To: nsc@ietf.org > >> Subject: Re: [nsc] Progress toward WG formation > >> > >> On 11/26/13 5:28 PM, Kevin J Ma wrote: > >>> just to clarify, as an example, do we expect to be able to: > >>> - use L2 encapsulation to get from the classifier to the firewall > >>> - use L4 encapsulation to get from the firewall to the TLS offload > >>> - use L5 encapsulation to get from the TLS offload to the load > balancer > >>> - use L3 encapsulation to get from the load balancer to AV scanner > >>> etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... > >>> (with all the necessary re-classification steps in between)? > >> > >> No. I'm also not sure what you mean by "reclassification" > >> in this context. I don't see this mechanism as being significantly > >> different from how everything from network stacks to filesystems > >> are implemented - they have a demultiplexing element in the > >> messages. What you're suggesting sounds unfortunately and > >> unnecessarily complicated. > >> > >> Melinda > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > From hongyu.li@huawei.com Wed Nov 27 00:49:09 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD941AD944 for ; Wed, 27 Nov 2013 00:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 F8SrLMOW9UBA for ; Wed, 27 Nov 2013 00:49:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 487A71A1F72 for ; Wed, 27 Nov 2013 00:49:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAT32242; Wed, 27 Nov 2013 08:49:03 +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; Wed, 27 Nov 2013 08:48:21 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 08:48:52 +0000 Received: from SZXEMA509-MBX.china.huawei.com ([169.254.1.24]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 16:48:41 +0800 From: "Hongyu Li (Julio)" To: "Surendra Kumar (smkumar)" , Lucy yong , Thomas Narten Thread-Topic: [nsc] Clarification RE: Progress toward WG formation Thread-Index: AQHO6vstwmBG70Qr0kKWIgBByOdFrpo34VwAgACMQyD//40nAIAAycQw Date: Wed, 27 Nov 2013 08:48:40 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E99AD6F@SZXEMA509-MBX.china.huawei.com> References: <6EB34CB5D82C4645B826C56144826EA97E99AC64@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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 08:49:11 -0000 SSBhbSBhZnJhaWQgIm5ldHdvcmsgbm9kZSIgZG9lc24ndCBpbmNsdWRlIGEgc2VydmVyIGluIGEg REMsIHdoZXJlIHZpcnR1YWwgU0ZzIGFyZSBydW5uaW5nLiBUaGF0J3Mgd2h5IEkgcHJvcG9zZWQg dG8gcmVtb3ZlICJuZXR3b3JrIG5vZGUiIGluIGNhc2Ugd2UgZG9u4oCZdCBhZGQgInNlcnZlciIg ZXhwbGljaXRseSBoZXJlIGFuZCBhZGQgbW9yZSBjb21wbGV4aXR5Lg0KDQpIb25neXUNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFyKSBb bWFpbHRvOnNta3VtYXJAY2lzY28uY29tXSANClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcs IDIwMTMgMTI6NDUgUE0NClRvOiBIb25neXUgTGkgKEp1bGlvKTsgTHVjeSB5b25nOyBUaG9tYXMg TmFydGVuDQpDYzogbnNjQGlldGYub3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVrDQpTdWJqZWN0OiBS ZTogW25zY10gQ2xhcmlmaWNhdGlvbiBSRTogUHJvZ3Jlc3MgdG93YXJkIFdHIGZvcm1hdGlvbg0K DQoNCklycmVzcGVjdGl2ZSBvZiB0aGUgbm8gb2YgdmlydHVhbCBsYXllcnMsIHlvdSBuZWVkIGEg cGh5c2ljYWwgbm9kZSBhbmQgdGhhdCBiZWluZyBvbiBhIG5ldHdvcmsgaXMgY29udmV5ZWQgYnkg Im5ldHdvcmsgbm9kZSIuIEkgd291bGQgdGhpbmsgdGhpcyB3aG9sZSBlZmZvcnQgaXMgbW9vdCBp ZiBlaXRoZXIgb25lIGlzIGV4Y2x1ZGVkLg0KDQpTdXJlbmRyYS4NCg0KDQpPbiAxMS8yNi8xMyA3 OjQyIFBNLCAiSG9uZ3l1IExpIChKdWxpbykiIDxob25neXUubGlAaHVhd2VpLmNvbT4gd3JvdGU6 DQoNCj5BY3R1YWxseSwgSSBoYXZlIGEgc2ltaWxhciBxdWVzdGlvbi4gU29sdXRpb24gYWRkcmVz cyBieSBTRkMgV0cgKHdoZW4gDQo+aXQgY29tZXMgaW50byByZWFsaXR5KSBzaG91bGQgYmUgYXBw bGljYWJsZSB0byBib3RoIHBoeXNpY2FsIG5vZGVzIGFuZCANCj52aXJ0dWFsIGluc3RhbmNlLCBv ciBldmVuIGEgbWl4IG9mIHRoZSB0d28uIEluIG90aGVyIHdvcmRzLCBhbiAiaW5zdGFuY2UiDQo+ bWF5IHJlc2lkZXMgaW4gYSBuZXR3b3JrIG5vZGUsIG9yIGluIGEgc2VydmVyLCB3aGVyZSBtYXkg Y29udGFpbnMgDQo+bXVsdGlwbGUgaW5zdGFuY2VzLiBIYXZpbmcgdGhhdCBzYWlkLCB0byBjb3Zl ciBhbGwgY2FzZXMsIEknZCBzdWdnZXN0IA0KPmZvbGxvd2luZyB0ZXh0Og0KPg0KPg0KPiAgIEFu IFNGQyBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2Vydmlj ZSANCj5mdW5jdGlvbiBpbnN0YW5jZXMsIHRoZXJlYnkgZm9ybWluZyBhIHNlcnZpY2UgZ3JhcGg6 IHRoaXMgaXMgY2FsbGVkIGEgDQo+U2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApLiAtZW5kDQo+ DQo+UmVtb3ZpbmcgIm9uIHNwZWNpZmljIG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhleSBhcmUg cHJvdmlkZWQiLg0KPg0KPldvdWxkIHRoaXMgYmUgT0s/DQo+DQo+Q2hlZXJzLA0KPkhvbmd5dQ0K Pg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbnNjIFttYWlsdG86bnNjLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWN5IHlvbmcNCj5TZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDI3LCAyMDEzIDExOjE0IEFNDQo+VG86IFRob21hcyBOYXJ0ZW4NCj5DYzogbnNj QGlldGYub3JnOyBhZHJpYW5Ab2xkZG9nLmNvLnVrDQo+U3ViamVjdDogUmU6IFtuc2NdIENsYXJp ZmljYXRpb24gUkU6IFByb2dyZXNzIHRvd2FyZCBXRyBmb3JtYXRpb24NCj4NCj5IaSBUaG9tYXMs DQo+DQo+UGxlYXNlIHNlZSBpbmxpbmUgYmVsb3cuDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj5Gcm9tOiBUaG9tYXMgTmFydGVuIFttYWlsdG86bmFydGVuQHVzLmlibS5jb21dDQo+ U2VudDogVHVlc2RheSwgTm92ZW1iZXIgMjYsIDIwMTMgNDo1OSBQTQ0KPlRvOiBMdWN5IHlvbmcN Cj5DYzogYWRyaWFuQG9sZGRvZy5jby51azsgbnNjQGlldGYub3JnDQo+U3ViamVjdDogUmU6IFtu c2NdIENsYXJpZmljYXRpb24gUkU6IFByb2dyZXNzIHRvd2FyZCBXRyBmb3JtYXRpb24NCj4NCj5I aSBMdWN5Lg0KPg0KPj4gVGV4dDoNCj4NCj4+IEFuIFNGQyBpcyBpbnN0YW50aWF0ZWQgdGhyb3Vn aCBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiANCj4+IGluc3RhbmNlcyBh bmQgdGhlIG5ldHdvcmsgbm9kZXMgb24gd2hpY2ggdGhleSBhcmUgcHJvdmlkZWQsIHRoZXJlYnkg DQo+PiBmb3JtaW5nIGEgc2VydmljZSBncmFwaDogdGhpcyBpcyBjYWxsZWQgYSBTZXJ2aWNlIEZ1 bmN0aW9uIFBhdGggKFNGUCkuDQo+PiAtZW5kDQo+DQo+PiBEb2VzIGl0IG1lYW4gdG8gc2F5IHRo aXM/DQo+DQo+PiBBIFNGQyBpcyBpbnN0YW50aWF0ZWQgdGhyb3VnaCBzZWxlY3Rpb24gb2Ygc3Bl Y2lmaWMgc2VydmljZSBmdW5jdGlvbiANCj4+IGluc3RhbmNlcyBhbmQvb3IgdGhlIG5ldHdvcmsg bm9kZXMgb24gd2hpY2ggdGhleSBhcmUgcHJvdmlkZWQsIA0KPj4gdGhlcmVieSBmb3JtaW5nIGEg c2VydmljZSBncmFwaDogdGhpcyBpcyBjYWxsZWQgYSBTZXJ2aWNlIEZ1bmN0aW9uIFBhdGggKFNG UCkuDQo+DQo+PiAiYW5kL29yIiBtZWFucyBkaWZmZXJlbnQgZnJvbSAiYW5kIi4NCj4NCj5UbyBi ZSBjbGVhciwgeW91IGFyZSBhc2tpbmcgdGhhdCAiYW5kIiBiZSBjaGFuZ2VkIHRvICJhbmQvb3Ii Pw0KPg0KPkFjdHVhbGx5LCBiZXR0ZXIgdGV4dCB3b3VsZCBwcm9iYWJseSBiZSBzb21ldGhpbmcg bGlrZToNCj4NCj4gICBBbiBTRkMgaXMgaW5zdGFudGlhdGVkIHRocm91Z2ggc2VsZWN0aW9uIG9m IHNwZWNpZmljIHNlcnZpY2UNCj4gICBmdW5jdGlvbiBpbnN0YW5jZXMgb24gc3BlY2lmaWMgbmV0 d29yayBub2RlcyBvbiB3aGljaCB0aGV5IGFyZQ0KPiAgIHByb3ZpZGVkLCB0aGVyZWJ5IGZvcm1p bmcgYSBzZXJ2aWNlIGdyYXBoOiB0aGlzIGlzIGNhbGxlZCBhIFNlcnZpY2UNCj4gICBGdW5jdGlv biBQYXRoIChTRlApLiAtZW5kDQo+DQo+SS5lLiwgY2hhbmdlIHRoZSAiYW5kIHRoZSBuZXR3b3Jr IG5vZGVzIC4uLiIgdG8gIm9uIHNwZWNpZmljIG5ldHdvcmsgDQo+bm9kZXMuLi4iDQo+DQo+V291 bGQgdGhhdCB3b3JrPw0KPltMdWN5XSBUaGlzIGlzIGJldHRlci4gVGhlIHBvaW50IGlzIHdoYXQg aXMgdXNlZCB0byBmb3JtIHRoZSBzZXJ2aWNlIA0KPmdyYXBoLCBzZXJ2aWNlIGZ1bmN0aW9uIGlu c3RhbmNlcywgbm9kZXMsIG9yIGJvdGguIElmIHlvdSB0aGluayB0aGF0IA0KPnNob3VsZCBiZSBk aXNjdXNzZWQgaW4gdGhlIHNvbHV0aW9uIGRldmVsb3BtZW50LCBJIGFtIGZpbmUgd2l0aCB0aGUg dGV4dC4NCj5CVFcsIHdoeSB1c2UgIkFuIFNGQyI/DQo+DQo+PiBUZXh0IGluIEdlbmVyaWMgU0ZD IEVuY2Fwc3VsYXRpb246DQo+DQo+PiBhIHNpbmdsZSBzZXJ2aWNlLWxldmVsIGRhdGEgcGxhbmUg ZW5jYXBzdWxhdGlvbiBmb3JtYXQgZm9yIGNvbnZleWluZyANCj4+IHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIGNoYWluIGFuZCB0aGUgc2VydmljZSBmdW5jdGlvbiBwYXRoLCBhbmQgZm9yIA0KPj4gY29t bXVuaWNhdGluZyBjb250ZXh0IGluZm9ybWF0aW9uIGJldHdlZW4gbm9kZXMgdGhhdCBpbXBsZW1l bnQgDQo+PiBzZXJ2aWNlIGZ1bmN0aW9ucyBhbmQgc2VydmljZSBmdW5jdGlvbiBjaGFpbnMuIC1l bmQNCj4NCj4+IERvIHRoZXNlIG5lc3RlZCAiYW5kIiBtZWFucyB0aGF0IHRoZSBkYXRhIHBsYW5l IGVuY2Fwc3VsYXRpb24gZm9ybWF0IA0KPj4gaGFzIHRvIGhhdmUgdGhlIGZpZWxkcyBmb3IgYWxs IG9mIHRoZXNlPyBJIHRob3VnaHQgdGhhdCBvbmx5IHNlcnZpY2UgDQo+PiBmdW5jdGlvbiBjaGFp biBpcyBtYW5kYXRlZCBpbiBkYXRhIHBsYW5lOyBvdGhlciB0d28gYXJlIG9wdGlvbmFsIGluIA0K Pj4gZGF0YSBwbGFuZSBiZWNhdXNlIHNvbWUgc29sdXRpb25zIG1heSB3YW50IHRvIGNvbnZleSB0 aGVtIHZpYSBvdGhlciANCj4+IG1lY2hhbmlzbSBzdWNoIGFzIGNvbnRyb2wgcGxhbmUsIGlzIHRo YXQgcmlnaHQ/DQo+DQo+SSB0aGluayB0aGUgYW5zd2VyIGlzIGJvdGggeWVzIGFuZCBuby4gWWVz LCB0aG9zZSBmaWVsZHMgd2lsbCBiZSANCj5uZWVkZWQsIGJ1dCB0aGVyZSBtYXkgYmUgY2FzZXMg d2hlcmUgc29tZSBmaWVsZHMgY2FuIGJlIG9taXR0ZWQuIEJ1dCANCj50aGF0IHNvcnQgb2YgZGV0 YWlsIGlzIGZvciB0aGUgV0cgdG8gZGVjaWRlIGxhdGVyLiBFLmcuLCBldmVuIGlmIHRoZSANCj5m aWVsZHMgYXJlbid0IG5lZWRlZCBpdCBtYXkgYmUgc2ltcGxlciBqdXN0IHRvIGFsd2F5cyBoYXZl IHRoZW0gdG8ga2VlcCANCj50aGUgaGVhZGVyIHNpemUgY29uc3RhbnQgaW4gYWxsIHBhY2tldHMu IEJ1dCBpbiBubyB3YXkgc2hvdWxkIHRoZSANCj53b3JkaW5nIGluIHRoZSBjaGFydGVyIGJlIHRh a2VuIHRvIG1lYW4gdGhhdCB0aGlzIHNvcnQgb2YgKGRldGFpbGVkKSANCj5kZWNpc2lvbiBoYXMg YWxyZWFkeSBiZWVuIG1hZGUuIFRoZXNlIHNvcnRzIG9mIGRldGFpbHMgbmVlZCB0byBiZSB3b3Jr ZWQgb3V0IGluIHRoZSBXRy4NCj5bTHVjeV0gR29vZC4gSSBhbSBmaW5lIHdpdGggdGhpcyBhcHBy b2FjaC4NCj4NCj5SZWdhcmRzLA0KPkx1Y3kNCj4NCj4+IElmIHRoZSB0ZXh0IGRvZXMgbm90IGlt cGx5IHRoYXQgdGhlIGxhc3QgdHdvIGhhdmUgdG8gYmUgcHJlc2VudCwgdGhlbiANCj4+IEkgYW0g ZmluZSB3aXRoIGl0Lg0KPg0KPkkgZG8gbm90IGJlbGlldmUgdGhlIGNoYXJ0ZXIgdGV4dCBpbXBs aWVzIHRoYXQuDQo+DQo+VGhvbWFzICh3aXRoIGNvbmN1cnJlbmNlIGZyb20gSmltKQ0KPg0KPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnNjIG1haWxp bmcgbGlzdA0KPm5zY0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbnNjDQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj5uc2MgbWFpbGluZyBsaXN0DQo+bnNjQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg0K From jguichar@cisco.com Wed Nov 27 05:08:10 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F631AE1C8 for ; Wed, 27 Nov 2013 05:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 CzivDxFKFyXd for ; Wed, 27 Nov 2013 05:08:08 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id BB0C21AD943 for ; Wed, 27 Nov 2013 05:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4715; q=dns/txt; s=iport; t=1385557687; x=1386767287; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=gBZcqAH1j0xtNasofaLCbcP94Cs2O2XddCCtkqwTXSo=; b=BRDol05GNXb8mS6o/DhegoL2JIrEz5+/3s3Gnc0jOkfIOPc5brLKZ1MG inIKYh9bbJqvZPP14HJjj8Enq4YxalgY1wH1N+2cmmcfbg4n5PWZVTx6Z bor/6rNHjhST/VNlyRjJFdgTIWAUIz977t4KL0a7Dd3XfOLO+x+/oUOX0 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAJXtlVKtJV2d/2dsb2JhbABZgwc4U7pxgR0WdIIlAQEBBAEBASQTKwkXBgEIEQQBAQEeCS4LFAkIAgQBEogBDcAxEwSOIBEBVwaELQOYFJITgymBcTk X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208";a="2641589" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 27 Nov 2013 13:08:07 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rARD86AH020779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 13:08:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 07:08:06 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "Joel M. Halpern" , Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TAAEP1dgAAAtQ0AAABGoQAAAP3FgAAGReYA Date: Wed, 27 Nov 2013 13:08:05 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF2B@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <3ADFC2A8964832409A73EA7885C39A07@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 13:08:10 -0000 Hi Kevin, The lower layer encapsulation (e.g. the "transport") needs some way of indicating that an SFC encapsulation follows. This will be addressed as part of the SFC encapsulation work item. On 11/27/13 12:08 AM, "Kevin J Ma" wrote: >Hi Joel, > > I read "encapsulation" as the act of encapsulating, and therefore > also the act of decapsulating, not as the header itself. > > It's not immediately clear to me how this could be made "agnostic". > The entity that decap's the lower layer needs some way to know that > the next layer up is an SFC encap, and that seems like it would be > lower-layer-protocol-specific? I can see making the parsing of the > encap header: "agnostic", but not the recognition of the encap? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, November 26, 2013 11:40 PM >> To: Kevin J Ma; Melinda Shore; nsc@ietf.org >> Subject: Re: [nsc] Progress toward WG formation >>=20 >> The way I read the "agnostic" is that one transport might be MPLS, while >> another might be VxLAN, and a third might be IP-in-IP. However, they >> both carry the same common header so that logic which needs to extract >> metadata or other related operations is always working with the same >> constructs. >>=20 >> Yours, >> Joel >>=20 >> On 11/26/13 11:32 PM, Kevin J Ma wrote: >> > Hi Melinda, >> > >> >> What you're suggesting sounds unfortunately and >> >> unnecessarily complicated. >> > >> > I'm not suggesting anything. I'm trying to understand what the >>charter >> says. >> > >> > As stated in my original email: >> > >> >> "It is intended that >> >> the encapsulation be agnostic to the layer at which it is applied >> and >> >> the service that is being constructed. That is, the same >> >> encapsulation may be used on a service function path realized at >> the >> >> network layer or at any other layer, and the same encapsulation >> will >> >> apply for the construction of service function paths regardless >>of >> >> the actual service." >> >> >> >> The first sentance says "layer at which it is applied". That >> implies >> >> to me that the encapsulation header can be applied at different >> layers? >> >> Is that really the intent? To have encapsulation happen at >> different >> >> layers for different legs of the service path? >> >> >> >> From the second sentance, it seems like what we really want to say >> is >> >> "layer from which it is applied" (i.e., application layer service >> vs. >> >> L2 service that provides the information necessary for >> encapsulation)? >> > >> > The wording is not clear to me whether it means the encapsulation is >>at >> any >> > layer, or if the encapsulation is at a single layer, and it is the >> service >> > that can be at any layer, which influences encapsulation at a single >> layer. >> > >> > thanx. >> > >> > -- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore >> >> Sent: Tuesday, November 26, 2013 11:12 PM >> >> To: nsc@ietf.org >> >> Subject: Re: [nsc] Progress toward WG formation >> >> >> >> On 11/26/13 5:28 PM, Kevin J Ma wrote: >> >>> just to clarify, as an example, do we expect to be able to: >> >>> - use L2 encapsulation to get from the classifier to the firewall >> >>> - use L4 encapsulation to get from the firewall to the TLS offload >> >>> - use L5 encapsulation to get from the TLS offload to the load >> balancer >> >>> - use L3 encapsulation to get from the load balancer to AV scanner >> >>> etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... >> >>> (with all the necessary re-classification steps in between)? >> >> >> >> No. I'm also not sure what you mean by "reclassification" >> >> in this context. I don't see this mechanism as being significantly >> >> different from how everything from network stacks to filesystems >> >> are implemented - they have a demultiplexing element in the >> >> messages. What you're suggesting sounds unfortunately and >> >> unnecessarily complicated. >> >> >> >> Melinda >> >> >> >> _______________________________________________ >> >> nsc mailing list >> >> nsc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From lucy.yong@huawei.com Wed Nov 27 06:13:16 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C241ADFC0 for ; Wed, 27 Nov 2013 06:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 GbAE1hQtID24 for ; Wed, 27 Nov 2013 06:13:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F16A81ADFCD for ; Wed, 27 Nov 2013 06:13:02 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYJ41531; Wed, 27 Nov 2013 14:13:02 +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; Wed, 27 Nov 2013 14:12:31 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 27 Nov 2013 14:12:59 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.24]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 06:12:54 -0800 From: Lucy yong To: "Jim Guichard (jguichar)" , Kevin J Ma , "Joel M. Halpern" , "Melinda Shore" , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TAAFS4/gAAAtQ0AAABGogAAAP3EgAAQwI6AAA59NCA= Date: Wed, 27 Nov 2013 14:12:54 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D453026C1@dfweml509-mbx.china.huawei.com> References: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF2B@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.105] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 14:13:16 -0000 Agree with Jim.=20 -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, November 27, 2013 7:08 AM To: Kevin J Ma; Joel M. Halpern; Melinda Shore; nsc@ietf.org Subject: Re: [nsc] Progress toward WG formation Hi Kevin, The lower layer encapsulation (e.g. the "transport") needs some way of indi= cating that an SFC encapsulation follows. This will be addressed as part of= the SFC encapsulation work item. On 11/27/13 12:08 AM, "Kevin J Ma" wrote: >Hi Joel, > > I read "encapsulation" as the act of encapsulating, and therefore =20 > also the act of decapsulating, not as the header itself. > > It's not immediately clear to me how this could be made "agnostic". > The entity that decap's the lower layer needs some way to know that =20 > the next layer up is an SFC encap, and that seems like it would be =20 > lower-layer-protocol-specific? I can see making the parsing of the =20 > encap header: "agnostic", but not the recognition of the encap? > >thanx. > >-- Kevin J. Ma > >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Tuesday, November 26, 2013 11:40 PM >> To: Kevin J Ma; Melinda Shore; nsc@ietf.org >> Subject: Re: [nsc] Progress toward WG formation >>=20 >> The way I read the "agnostic" is that one transport might be MPLS,=20 >> while another might be VxLAN, and a third might be IP-in-IP. =20 >> However, they both carry the same common header so that logic which=20 >> needs to extract metadata or other related operations is always=20 >> working with the same constructs. >>=20 >> Yours, >> Joel >>=20 >> On 11/26/13 11:32 PM, Kevin J Ma wrote: >> > Hi Melinda, >> > >> >> What you're suggesting sounds unfortunately and unnecessarily=20 >> >> complicated. >> > >> > I'm not suggesting anything. I'm trying to understand what the >>charter >> says. >> > >> > As stated in my original email: >> > >> >> "It is intended that >> >> the encapsulation be agnostic to the layer at which it is=20 >> >> applied >> and >> >> the service that is being constructed. That is, the same >> >> encapsulation may be used on a service function path realized=20 >> >> at >> the >> >> network layer or at any other layer, and the same=20 >> >> encapsulation >> will >> >> apply for the construction of service function paths=20 >> >> regardless >>of >> >> the actual service." >> >> >> >> The first sentance says "layer at which it is applied". That >> implies >> >> to me that the encapsulation header can be applied at different >> layers? >> >> Is that really the intent? To have encapsulation happen at >> different >> >> layers for different legs of the service path? >> >> >> >> From the second sentance, it seems like what we really want to=20 >> >> say >> is >> >> "layer from which it is applied" (i.e., application layer=20 >> >> service >> vs. >> >> L2 service that provides the information necessary for >> encapsulation)? >> > >> > The wording is not clear to me whether it means the encapsulation=20 >> > is >>at >> any >> > layer, or if the encapsulation is at a single layer, and it is the >> service >> > that can be at any layer, which influences encapsulation at a=20 >> > single >> layer. >> > >> > thanx. >> > >> > -- Kevin J. Ma >> > >> >> -----Original Message----- >> >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore >> >> Sent: Tuesday, November 26, 2013 11:12 PM >> >> To: nsc@ietf.org >> >> Subject: Re: [nsc] Progress toward WG formation >> >> >> >> On 11/26/13 5:28 PM, Kevin J Ma wrote: >> >>> just to clarify, as an example, do we expect to be able to: >> >>> - use L2 encapsulation to get from the classifier to the firewall >> >>> - use L4 encapsulation to get from the firewall to the TLS=20 >> >>> offload >> >>> - use L5 encapsulation to get from the TLS offload to the load >> balancer >> >>> - use L3 encapsulation to get from the load balancer to AV=20 >> >>> scanner etc., for a chain that starts out FW -> TLS -> LB -> AV -> .= .. >> >>> (with all the necessary re-classification steps in between)? >> >> >> >> No. I'm also not sure what you mean by "reclassification" >> >> in this context. I don't see this mechanism as being=20 >> >> significantly different from how everything from network stacks to=20 >> >> filesystems are implemented - they have a demultiplexing element=20 >> >> in the messages. What you're suggesting sounds unfortunately and=20 >> >> unnecessarily complicated. >> >> >> >> Melinda >> >> >> >> _______________________________________________ >> >> nsc mailing list >> >> nsc@ietf.org >> >> https://www.ietf.org/mailman/listinfo/nsc >> > _______________________________________________ >> > nsc mailing list >> > nsc@ietf.org >> > https://www.ietf.org/mailman/listinfo/nsc >> > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Nov 27 06:19:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7F01ADFC7 for ; Wed, 27 Nov 2013 06:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Q9-mMrectn for ; Wed, 27 Nov 2013 06:19:16 -0800 (PST) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id AEDA91ADF8B for ; Wed, 27 Nov 2013 06:19:16 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 06:19:16 -0800 From: Ron Parker To: "Hongyu Li (Julio)" , "Surendra Kumar (smkumar)" , Lucy yong , Thomas Narten Thread-Topic: [nsc] Clarification RE: Progress toward WG formation Thread-Index: AQHO6vsqJxuRWCSjL02I672Kphv1iJo47ZQAgAAICgCAABFhAIAARBcA///Ty4A= Date: Wed, 27 Nov 2013 14:19:15 +0000 Message-ID: References: <6EB34CB5D82C4645B826C56144826EA97E99AC64@SZXEMA509-MBX.china.huawei.com> <6EB34CB5D82C4645B826C56144826EA97E99AD6F@SZXEMA509-MBX.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E99AD6F@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Clarification RE: Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 14:19:21 -0000 V2Ugc2FpZCBpbiBWYW5jb3V2ZXIgdGhhdCBzZXJ2aWNlIGZ1bmN0aW9uIGNoYWluaW5nIGFwcGxp ZXMgZXF1YWxseSB0byBwdXJlbHkgdHJhZGl0aW9uYWwgcGh5c2ljYWwgZGVwbG95bWVudHMsIHB1 cmVseSB2aXJ0dWFsaXplZCBkZXBsb3ltZW50cywgb3IgYW55IG1peCBvZiB0aGUgdHdvLiAgIA0K DQpJbiBlbWFpbCBleGNoYW5nZXMsIHdlJ3ZlIGFsc28gc2FpZCB0aGF0IHNlcnZpY2UgZnVuY3Rp b25zIGFyZSBsb2dpY2FsIGVudGl0aWVzLCBpbmRlcGVuZGVudCBvZiBwaHlzaWNhbCBvciB2aXJ0 dWFsLiAgIFRoYXQgaXMsIG1vcmUgdGhhbiBvbmUgY2FuIGJlIGxvY2F0ZWQgYXQgdGhlIHNhbWUg SVAgYWRkcmVzcy4NCg0KU0ROIHByb3ZpZGVzIGEgdXNlZnVsIGFic3RyYWN0aW9uIHRoYXQgSSB0 aGluayB3ZSBjYW4gYXBwbHkgdG8gU0ZDLiAgIFNETiBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIHRo ZSAib3ZlcmxheSIgYW5kIHRoZSAidW5kZXJsYXkiLiAgIFRoZSAib3ZlcmxheSIgaXMgd2hlcmUg dGhlIGFwcGxpY2F0aW9ucyByZXNpZGUgLS0gdGhleSBzZWUgSVAgYWRkcmVzc2VzIHRoYXQgbWF5 IG5vdCBjb3JyZXNwb25kIHRvIHRoZSBuZXR3b3JrIHRvcG9sb2d5LiAgIFRoZSAidW5kZXJsYXki IGlzIHRoZSB0b3Bsb2dpY2FsbHkgc2lnbmlmaWNhbnQgbmV0d29yayAoaS5lLiwgc29tZSBjb2xs ZWN0aW9uIG9mIHBoeXNpY2FsIG9yIHZpcnR1YWwgc3dpdGNoZXMgYW5kIHJvdXRlcnMpLiANCg0K SWYgd2UgdmlldyB0aGUgc2VydmljZSBmdW5jdGlvbnMgYXMgc2ltaWxhciB0byB0aGUgYXBwbGlj YXRpb25zIGluIGFuIFNETiBuZXR3b3JrICh0aGlzIGlzIGEgbG9vc2UgYW5hbG9neSBhbmQgSSdt IG5vdCBpbXBseWluZyBhbnl0aGluZyBhYm91dCB3aGljaCBJU08gbGF5ZXJzIHRoZSBzZXJ2aWNl IGZ1bmN0aW9uIG9wZXJhdGVzIGF0KSwgdGhlbiB3ZSBjYW4gc2F5IHRoZSBzZXJ2aWNlIGZ1bmN0 aW9ucyBhbmQgdGhlcmVmb3JlIHRoZSBTRkMgb3BlcmF0ZSBpbiB0aGUgb3ZlcmxheS4gICBXaGV0 aGVyIHRoZXJlIGlzIG9yIGlzIG5vdCBhbiB1bmRlcmxheSBhbmQgd2hhdCBmb3JtIGl0IHRha2Vz IGlzIHRoZXJlZm9yZSBoaWRkZW4gZnJvbSB0aGUgb3BlcmF0aW9uIG9mIHRoZSBTRkMuICAgDQoN ClRoaXMgd291bGQgYWxsb3cgdXMgdG8gZGlzY3VzcyBjaGFpbnMgb2Ygc2VydmljZSBmdW5jdGlv bnMgd2hlcmUgdGhlIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBsb2dpY2FsIGVudGl0aWVzIHRoYXQg YXJlIHRoZW4gbG9jYXRlZCB3aXRoaW4gYSBuZXR3b3JrIHVzaW5nIG5ldHdvcmsgYWRkcmVzc2Vz IChlLmcuLCBJUCwgRXRoZXJuZXQpLiAgIFdoZXRoZXIgdGhhdCBuZXR3b3JrIHNhdCBvbiB0b3Ag b2Ygc29tZSB1bmRlcmxheSBiZWNvbWVzIGlycmVsZXZhbnQuDQoNCiAgIFJvbg0KIA0KDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5zYyBbbWFpbHRvOm5zYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSG9uZ3l1IExpIChKdWxpbykNClNlbnQ6IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMjcsIDIwMTMgMzo0OSBBTQ0KVG86IFN1cmVuZHJhIEt1bWFyIChzbWt1bWFy KTsgTHVjeSB5b25nOyBUaG9tYXMgTmFydGVuDQpDYzogbnNjQGlldGYub3JnOyBhZHJpYW5Ab2xk ZG9nLmNvLnVrDQpTdWJqZWN0OiBSZTogW25zY10gQ2xhcmlmaWNhdGlvbiBSRTogUHJvZ3Jlc3Mg dG93YXJkIFdHIGZvcm1hdGlvbg0KDQpJIGFtIGFmcmFpZCAibmV0d29yayBub2RlIiBkb2Vzbid0 IGluY2x1ZGUgYSBzZXJ2ZXIgaW4gYSBEQywgd2hlcmUgdmlydHVhbCBTRnMgYXJlIHJ1bm5pbmcu IFRoYXQncyB3aHkgSSBwcm9wb3NlZCB0byByZW1vdmUgIm5ldHdvcmsgbm9kZSIgaW4gY2FzZSB3 ZSBkb27igJl0IGFkZCAic2VydmVyIiBleHBsaWNpdGx5IGhlcmUgYW5kIGFkZCBtb3JlIGNvbXBs ZXhpdHkuDQoNCkhvbmd5dQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3Vy ZW5kcmEgS3VtYXIgKHNta3VtYXIpIFttYWlsdG86c21rdW1hckBjaXNjby5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAyNywgMjAxMyAxMjo0NSBQTQ0KVG86IEhvbmd5dSBMaSAoSnVs aW8pOyBMdWN5IHlvbmc7IFRob21hcyBOYXJ0ZW4NCkNjOiBuc2NAaWV0Zi5vcmc7IGFkcmlhbkBv bGRkb2cuY28udWsNClN1YmplY3Q6IFJlOiBbbnNjXSBDbGFyaWZpY2F0aW9uIFJFOiBQcm9ncmVz cyB0b3dhcmQgV0cgZm9ybWF0aW9uDQoNCg0KSXJyZXNwZWN0aXZlIG9mIHRoZSBubyBvZiB2aXJ0 dWFsIGxheWVycywgeW91IG5lZWQgYSBwaHlzaWNhbCBub2RlIGFuZCB0aGF0IGJlaW5nIG9uIGEg bmV0d29yayBpcyBjb252ZXllZCBieSAibmV0d29yayBub2RlIi4gSSB3b3VsZCB0aGluayB0aGlz IHdob2xlIGVmZm9ydCBpcyBtb290IGlmIGVpdGhlciBvbmUgaXMgZXhjbHVkZWQuDQoNClN1cmVu ZHJhLg0KDQoNCk9uIDExLzI2LzEzIDc6NDIgUE0sICJIb25neXUgTGkgKEp1bGlvKSIgPGhvbmd5 dS5saUBodWF3ZWkuY29tPiB3cm90ZToNCg0KPkFjdHVhbGx5LCBJIGhhdmUgYSBzaW1pbGFyIHF1 ZXN0aW9uLiBTb2x1dGlvbiBhZGRyZXNzIGJ5IFNGQyBXRyAod2hlbiANCj5pdCBjb21lcyBpbnRv IHJlYWxpdHkpIHNob3VsZCBiZSBhcHBsaWNhYmxlIHRvIGJvdGggcGh5c2ljYWwgbm9kZXMgYW5k IA0KPnZpcnR1YWwgaW5zdGFuY2UsIG9yIGV2ZW4gYSBtaXggb2YgdGhlIHR3by4gSW4gb3RoZXIg d29yZHMsIGFuICJpbnN0YW5jZSINCj5tYXkgcmVzaWRlcyBpbiBhIG5ldHdvcmsgbm9kZSwgb3Ig aW4gYSBzZXJ2ZXIsIHdoZXJlIG1heSBjb250YWlucyANCj5tdWx0aXBsZSBpbnN0YW5jZXMuIEhh dmluZyB0aGF0IHNhaWQsIHRvIGNvdmVyIGFsbCBjYXNlcywgSSdkIHN1Z2dlc3QgDQo+Zm9sbG93 aW5nIHRleHQ6DQo+DQo+DQo+ICAgQW4gU0ZDIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIHNlbGVj dGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIA0KPmZ1bmN0aW9uIGluc3RhbmNlcywgdGhlcmVieSBm b3JtaW5nIGEgc2VydmljZSBncmFwaDogdGhpcyBpcyBjYWxsZWQgYSANCj5TZXJ2aWNlIEZ1bmN0 aW9uIFBhdGggKFNGUCkuIC1lbmQNCj4NCj5SZW1vdmluZyAib24gc3BlY2lmaWMgbmV0d29yayBu b2RlcyBvbiB3aGljaCB0aGV5IGFyZSBwcm92aWRlZCIuDQo+DQo+V291bGQgdGhpcyBiZSBPSz8N Cj4NCj5DaGVlcnMsDQo+SG9uZ3l1DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G cm9tOiBuc2MgW21haWx0bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEx1Y3kg eW9uZw0KPlNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcsIDIwMTMgMTE6MTQgQU0NCj5Ubzog VGhvbWFzIE5hcnRlbg0KPkNjOiBuc2NAaWV0Zi5vcmc7IGFkcmlhbkBvbGRkb2cuY28udWsNCj5T dWJqZWN0OiBSZTogW25zY10gQ2xhcmlmaWNhdGlvbiBSRTogUHJvZ3Jlc3MgdG93YXJkIFdHIGZv cm1hdGlvbg0KPg0KPkhpIFRob21hcywNCj4NCj5QbGVhc2Ugc2VlIGlubGluZSBiZWxvdy4NCj4N Cj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFRob21hcyBOYXJ0ZW4gW21haWx0 bzpuYXJ0ZW5AdXMuaWJtLmNvbV0NCj5TZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyNiwgMjAxMyA0 OjU5IFBNDQo+VG86IEx1Y3kgeW9uZw0KPkNjOiBhZHJpYW5Ab2xkZG9nLmNvLnVrOyBuc2NAaWV0 Zi5vcmcNCj5TdWJqZWN0OiBSZTogW25zY10gQ2xhcmlmaWNhdGlvbiBSRTogUHJvZ3Jlc3MgdG93 YXJkIFdHIGZvcm1hdGlvbg0KPg0KPkhpIEx1Y3kuDQo+DQo+PiBUZXh0Og0KPg0KPj4gQW4gU0ZD IGlzIGluc3RhbnRpYXRlZCB0aHJvdWdoIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1 bmN0aW9uIA0KPj4gaW5zdGFuY2VzIGFuZCB0aGUgbmV0d29yayBub2RlcyBvbiB3aGljaCB0aGV5 IGFyZSBwcm92aWRlZCwgdGhlcmVieSANCj4+IGZvcm1pbmcgYSBzZXJ2aWNlIGdyYXBoOiB0aGlz IGlzIGNhbGxlZCBhIFNlcnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKS4NCj4+IC1lbmQNCj4NCj4+ IERvZXMgaXQgbWVhbiB0byBzYXkgdGhpcz8NCj4NCj4+IEEgU0ZDIGlzIGluc3RhbnRpYXRlZCB0 aHJvdWdoIHNlbGVjdGlvbiBvZiBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIA0KPj4gaW5zdGFu Y2VzIGFuZC9vciB0aGUgbmV0d29yayBub2RlcyBvbiB3aGljaCB0aGV5IGFyZSBwcm92aWRlZCwg DQo+PiB0aGVyZWJ5IGZvcm1pbmcgYSBzZXJ2aWNlIGdyYXBoOiB0aGlzIGlzIGNhbGxlZCBhIFNl cnZpY2UgRnVuY3Rpb24gUGF0aCAoU0ZQKS4NCj4NCj4+ICJhbmQvb3IiIG1lYW5zIGRpZmZlcmVu dCBmcm9tICJhbmQiLg0KPg0KPlRvIGJlIGNsZWFyLCB5b3UgYXJlIGFza2luZyB0aGF0ICJhbmQi IGJlIGNoYW5nZWQgdG8gImFuZC9vciI/DQo+DQo+QWN0dWFsbHksIGJldHRlciB0ZXh0IHdvdWxk IHByb2JhYmx5IGJlIHNvbWV0aGluZyBsaWtlOg0KPg0KPiAgIEFuIFNGQyBpcyBpbnN0YW50aWF0 ZWQgdGhyb3VnaCBzZWxlY3Rpb24gb2Ygc3BlY2lmaWMgc2VydmljZQ0KPiAgIGZ1bmN0aW9uIGlu c3RhbmNlcyBvbiBzcGVjaWZpYyBuZXR3b3JrIG5vZGVzIG9uIHdoaWNoIHRoZXkgYXJlDQo+ICAg cHJvdmlkZWQsIHRoZXJlYnkgZm9ybWluZyBhIHNlcnZpY2UgZ3JhcGg6IHRoaXMgaXMgY2FsbGVk IGEgU2VydmljZQ0KPiAgIEZ1bmN0aW9uIFBhdGggKFNGUCkuIC1lbmQNCj4NCj5JLmUuLCBjaGFu Z2UgdGhlICJhbmQgdGhlIG5ldHdvcmsgbm9kZXMgLi4uIiB0byAib24gc3BlY2lmaWMgbmV0d29y ayANCj5ub2Rlcy4uLiINCj4NCj5Xb3VsZCB0aGF0IHdvcms/DQo+W0x1Y3ldIFRoaXMgaXMgYmV0 dGVyLiBUaGUgcG9pbnQgaXMgd2hhdCBpcyB1c2VkIHRvIGZvcm0gdGhlIHNlcnZpY2UgDQo+Z3Jh cGgsIHNlcnZpY2UgZnVuY3Rpb24gaW5zdGFuY2VzLCBub2Rlcywgb3IgYm90aC4gSWYgeW91IHRo aW5rIHRoYXQgDQo+c2hvdWxkIGJlIGRpc2N1c3NlZCBpbiB0aGUgc29sdXRpb24gZGV2ZWxvcG1l bnQsIEkgYW0gZmluZSB3aXRoIHRoZSB0ZXh0Lg0KPkJUVywgd2h5IHVzZSAiQW4gU0ZDIj8NCj4N Cj4+IFRleHQgaW4gR2VuZXJpYyBTRkMgRW5jYXBzdWxhdGlvbjoNCj4NCj4+IGEgc2luZ2xlIHNl cnZpY2UtbGV2ZWwgZGF0YSBwbGFuZSBlbmNhcHN1bGF0aW9uIGZvcm1hdCBmb3IgY29udmV5aW5n IA0KPj4gdGhlIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW4gYW5kIHRoZSBzZXJ2aWNlIGZ1bmN0aW9u IHBhdGgsIGFuZCBmb3IgDQo+PiBjb21tdW5pY2F0aW5nIGNvbnRleHQgaW5mb3JtYXRpb24gYmV0 d2VlbiBub2RlcyB0aGF0IGltcGxlbWVudCANCj4+IHNlcnZpY2UgZnVuY3Rpb25zIGFuZCBzZXJ2 aWNlIGZ1bmN0aW9uIGNoYWlucy4gLWVuZA0KPg0KPj4gRG8gdGhlc2UgbmVzdGVkICJhbmQiIG1l YW5zIHRoYXQgdGhlIGRhdGEgcGxhbmUgZW5jYXBzdWxhdGlvbiBmb3JtYXQgDQo+PiBoYXMgdG8g aGF2ZSB0aGUgZmllbGRzIGZvciBhbGwgb2YgdGhlc2U/IEkgdGhvdWdodCB0aGF0IG9ubHkgc2Vy dmljZSANCj4+IGZ1bmN0aW9uIGNoYWluIGlzIG1hbmRhdGVkIGluIGRhdGEgcGxhbmU7IG90aGVy IHR3byBhcmUgb3B0aW9uYWwgaW4gDQo+PiBkYXRhIHBsYW5lIGJlY2F1c2Ugc29tZSBzb2x1dGlv bnMgbWF5IHdhbnQgdG8gY29udmV5IHRoZW0gdmlhIG90aGVyIA0KPj4gbWVjaGFuaXNtIHN1Y2gg YXMgY29udHJvbCBwbGFuZSwgaXMgdGhhdCByaWdodD8NCj4NCj5JIHRoaW5rIHRoZSBhbnN3ZXIg aXMgYm90aCB5ZXMgYW5kIG5vLiBZZXMsIHRob3NlIGZpZWxkcyB3aWxsIGJlIA0KPm5lZWRlZCwg YnV0IHRoZXJlIG1heSBiZSBjYXNlcyB3aGVyZSBzb21lIGZpZWxkcyBjYW4gYmUgb21pdHRlZC4g QnV0IA0KPnRoYXQgc29ydCBvZiBkZXRhaWwgaXMgZm9yIHRoZSBXRyB0byBkZWNpZGUgbGF0ZXIu IEUuZy4sIGV2ZW4gaWYgdGhlIA0KPmZpZWxkcyBhcmVuJ3QgbmVlZGVkIGl0IG1heSBiZSBzaW1w bGVyIGp1c3QgdG8gYWx3YXlzIGhhdmUgdGhlbSB0byBrZWVwIA0KPnRoZSBoZWFkZXIgc2l6ZSBj b25zdGFudCBpbiBhbGwgcGFja2V0cy4gQnV0IGluIG5vIHdheSBzaG91bGQgdGhlIA0KPndvcmRp bmcgaW4gdGhlIGNoYXJ0ZXIgYmUgdGFrZW4gdG8gbWVhbiB0aGF0IHRoaXMgc29ydCBvZiAoZGV0 YWlsZWQpIA0KPmRlY2lzaW9uIGhhcyBhbHJlYWR5IGJlZW4gbWFkZS4gVGhlc2Ugc29ydHMgb2Yg ZGV0YWlscyBuZWVkIHRvIGJlIHdvcmtlZCBvdXQgaW4gdGhlIFdHLg0KPltMdWN5XSBHb29kLiBJ IGFtIGZpbmUgd2l0aCB0aGlzIGFwcHJvYWNoLg0KPg0KPlJlZ2FyZHMsDQo+THVjeQ0KPg0KPj4g SWYgdGhlIHRleHQgZG9lcyBub3QgaW1wbHkgdGhhdCB0aGUgbGFzdCB0d28gaGF2ZSB0byBiZSBw cmVzZW50LCB0aGVuIA0KPj4gSSBhbSBmaW5lIHdpdGggaXQuDQo+DQo+SSBkbyBub3QgYmVsaWV2 ZSB0aGUgY2hhcnRlciB0ZXh0IGltcGxpZXMgdGhhdC4NCj4NCj5UaG9tYXMgKHdpdGggY29uY3Vy cmVuY2UgZnJvbSBKaW0pDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj5uc2MgbWFpbGluZyBsaXN0DQo+bnNjQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5zYyBtYWlsaW5nIGxpc3QNCj5uc2NAaWV0Zi5v cmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbnNjIG1haWxpbmcgbGlz dA0KbnNjQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0K From jguichar@cisco.com Wed Nov 27 08:02:41 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77C1AD0F0 for ; Wed, 27 Nov 2013 08:02:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.501 X-Spam-Level: X-Spam-Status: No, score=-9.501 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.001, 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 x5807JeshCsF for ; Wed, 27 Nov 2013 08:02:38 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 297B01ACCE8 for ; Wed, 27 Nov 2013 08:02:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10642; q=dns/txt; s=iport; t=1385568157; x=1386777757; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Dcvsc9GNSV8WgRQyKGoR/cqOIrkSELoEvkeeLqXgZSI=; b=Y4I/noWcqmCgA8C0jr8YOGO4e094P2yLOqnnFurab9qSr+ccrI4DBJK8 E3JpTm/Bp3hvEyjhJo2LQQq0kZ9J0YH87/rW9CY4I0lV6lXs+MVHqLl2B n7YBPpSCiULfd4JB0qIYHYkmpCp4lGh4ttwlwzdM2QcZAcft664fSHyep 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEFALoWllKtJV2d/2dsb2JhbABZgkNEOFOFW7FTgWmBHhZ0giUBAQEEAQEBaxcGAQgRBAEBKC4LFAkIAQEEARKIAQ3ARQSOfgoBBoQtA5gUkhOBPYFsgio X-IronPort-AV: E=Sophos;i="4.93,782,1378857600"; d="scan'208,217";a="2684225" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 27 Nov 2013 16:02:37 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rARG2asD031559 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 16:02:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 10:02:36 -0600 From: "Jim Guichard (jguichar)" To: Kevin J Ma , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IA= Date: Wed, 27 Nov 2013 16:02:35 +0000 Message-ID: In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FAEBC@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_CEBB7F6711BFDjguicharciscocom_" MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 16:02:41 -0000 --_000_CEBB7F6711BFDjguicharciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kevin, I think that you make a valid point and the wording in the current charter = is perhaps misleading (or at least difficult to parse). The key point to pu= ll from this is that the SFC encapsulation could be processed by an SF runn= ing at the network layer or any higher layer. I think this is easily fixed = by an adjustment to the wording of work item #3. I would like to suggest th= e following text to replace the existing text (changes in bold): "It is intended that the encapsulation be agnostic to the layer at which it= is applied and the service that is being constructed. That is, the same en= capsulation may be used on a service function chain applied at the network = layer or at any other layer, and the same encapsulation will apply for the = construction of service function paths regardless of the actual service". If there are no objections to this wording I can track the change. On 11/26/13 5:46 PM, "Kevin J Ma" > wrote: Hi all, This may be a nit, but wrt the encapsulation spec: "It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." The first sentance says "layer at which it is applied". That implies to me that the encapsulation header can be applied at different layers? Is that really the intent? To have encapsulation happen at different layers for different legs of the service path? From the second sentance, it seems like what we really want to say is "layer from which it is applied" (i.e., application layer service vs. L2 service that provides the information necessary for encapsulation)? This then goes back to my previous questions related to cross-layer signalling of encapsulation information. Is the discussion of such requirements and/or mechanisms (API)s in or out of scope? Note: As previously stated, I dont believe this to be a control plane issue. thanx. -- Kevin J. Ma -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 26, 2013 4:27 PM To: nsc@ietf.org Subject: [nsc] Progress toward WG formation Hi SFC list (still pretending to be NSC), Jim and Thomas have collated the discussion on a proposed WG charter and I have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I have still two tasks: 1. Read the mailing list to make sure they have captured consensus 2. Read the charter to make sure I support it. You can help me by commenting (on the list is preferred) about any deficiencies in the charter text or proposed milestones. My plan is to put the charter before the IESG on Thursday December 5th, and if all goes well it should go out for IESG and external review before coming to the IESG again for final approval on the 19th. Just be aware that snafus are "normal". As soon as we know the WG is forming, I will get the Secretariat to migrate the list to sfc@ietf.org. They're pretty good at that and = you should feel no pain (mostly). Thanks, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CEBB7F6711BFDjguicharciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9FF177B883A7B043A6D9B307C075CC5B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Kevin,

I think that you make a valid point and the wording in the current cha= rter is perhaps misleading (or at least difficult to parse). The key point = to pull from this is that the SFC encapsulation could be processed by = an SF running at the network layer or any higher layer. I think this is easily fixed by an adjustment to th= e wording of work item #3. I would like to suggest the following text to re= place the existing text (changes in bold):

"It is intended that the encapsulation be agnostic to the layer a= t which it is applied and the service that is being constructed. That is, t= he same encapsulation may be used on a service function chain applied at the network layer or at any other layer, and the sa= me encapsulation will apply for the construction of service function paths&= nbsp;regardless of the actual service".

If there are no objections to this wording I can track the change.&nbs= p;


On 11/26/13 5:46 PM, "Kevin J Ma" <kevin.ma@azukisystems.com> wrote:

Hi all,

  This may be a nit, but wrt the encapsulation spec:

  "It is intended that
   the encapsulation be agnostic to the layer at which it is= applied and
   the service that is being constructed. That is, the same =
   encapsulation may be used on a service function path real= ized at the
   network layer or at any other layer, and the same encapsu= lation will
   apply for the construction of service function paths rega= rdless of
   the actual service."

  The first sentance says "layer at which it is applied= ".  That implies
  to me that the encapsulation header can be applied at diff= erent layers?
  Is that really the intent?  To have encapsulatio= n happen at different
  layers for different legs of the service path?

  From the second sentance, it seems like what we really wan= t to say is
  "layer from which it is applied" (i.e., applicat= ion layer service vs.
  L2 service that provides the information necessary for enc= apsulation)?

  This then goes back to my previous questions related to cr= oss-layer
  signalling of encapsulation information.  Is the= discussion of such
  requirements and/or mechanisms (API)s in or out of scope?&= nbsp; Note: As
  previously stated, I dont believe this to be a control pla= ne issue.

thanx.

--  Kevin J. Ma

-----Original Message-----
From: nsc [mailto:nsc-bounces@= ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, November 26, 2013 4:27 PM
Subject: [nsc] Progress toward WG formation
Hi SFC list (still pretending to be NSC),
Jim and Thomas have collated the discussion on a proposed WG charter a= nd I
have
I have still two tasks:
1. Read the mailing list to make sure they have captured consensus
2. Read the charter to make sure I support it.
You can help me by commenting (on the list is preferred) about any
deficiencies
in the charter text or proposed milestones.
My plan is to put the charter before the IESG on Thursday December 5th= ,
and if
all goes well it should go out for IESG and external review before com= ing
to the
IESG again for final approval on the 19th. Just be aware that snafus a= re
"normal".
As soon as we know the WG is forming, I will get the Secretariat to
migrate the
list to sfc@ietf.org. They're pret= ty good at that and you should feel no
pain
(mostly).
Thanks,
Adrian
_______________________________________________
nsc mailing list
_______________________________________________
nsc mailing list

--_000_CEBB7F6711BFDjguicharciscocom_-- From Ron_Parker@affirmednetworks.com Wed Nov 27 08:07:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EAA1A1F5D for ; Wed, 27 Nov 2013 08:07:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC3Z9VLn7UWK for ; Wed, 27 Nov 2013 08:07:14 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 27C001AE088 for ; Wed, 27 Nov 2013 08:07:08 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 08:07:07 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , Kevin J Ma , "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAAfOXIA== Date: Wed, 27 Nov 2013 16:07:06 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C6C2C79FAEBC@MAILR002.mail.lan> 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_CDF2F015F4429F458815ED2A6C2B6B0B1A755D1CMBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 16:07:23 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A755D1CMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Your proposed change sounds good to me. Ron From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, November 27, 2013 11:03 AM To: Kevin J Ma; adrian@olddog.co.uk; nsc@ietf.org Subject: Re: [nsc] Progress toward WG formation Hi Kevin, I think that you make a valid point and the wording in the current charter = is perhaps misleading (or at least difficult to parse). The key point to pu= ll from this is that the SFC encapsulation could be processed by an SF runn= ing at the network layer or any higher layer. I think this is easily fixed = by an adjustment to the wording of work item #3. I would like to suggest th= e following text to replace the existing text (changes in bold): "It is intended that the encapsulation be agnostic to the layer at which it= is applied and the service that is being constructed. That is, the same en= capsulation may be used on a service function chain applied at the network = layer or at any other layer, and the same encapsulation will apply for the = construction of service function paths regardless of the actual service". If there are no objections to this wording I can track the change. On 11/26/13 5:46 PM, "Kevin J Ma" > wrote: Hi all, This may be a nit, but wrt the encapsulation spec: "It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." The first sentance says "layer at which it is applied". That implies to me that the encapsulation header can be applied at different layers? Is that really the intent? To have encapsulation happen at different layers for different legs of the service path? From the second sentance, it seems like what we really want to say is "layer from which it is applied" (i.e., application layer service vs. L2 service that provides the information necessary for encapsulation)? This then goes back to my previous questions related to cross-layer signalling of encapsulation information. Is the discussion of such requirements and/or mechanisms (API)s in or out of scope? Note: As previously stated, I dont believe this to be a control plane issue. thanx. -- Kevin J. Ma -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 26, 2013 4:27 PM To: nsc@ietf.org Subject: [nsc] Progress toward WG formation Hi SFC list (still pretending to be NSC), Jim and Thomas have collated the discussion on a proposed WG charter and I have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I have still two tasks: 1. Read the mailing list to make sure they have captured consensus 2. Read the charter to make sure I support it. You can help me by commenting (on the list is preferred) about any deficiencies in the charter text or proposed milestones. My plan is to put the charter before the IESG on Thursday December 5th, and if all goes well it should go out for IESG and external review before coming to the IESG again for final approval on the 19th. Just be aware that snafus are "normal". As soon as we know the WG is forming, I will get the Secretariat to migrate the list to sfc@ietf.org. They're pretty good at that and = you should feel no pain (mostly). Thanks, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A755D1CMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

Your proposed change soun= ds good to me.

 <= /p>

   Ron

 <= /p>

From: nsc [m= ailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, November 27, 2013 11:03 AM
To: Kevin J Ma; adrian@olddog.co.uk; nsc@ietf.org
Subject: Re: [nsc] Progress toward WG formation

 

Hi Kevin,=

 

I think that you make a val= id point and the wording in the current charter is perhaps misleading (or a= t least difficult to parse). The key point to pull from this is that the SFC encapsulation could be processed by an SF runnin= g at the network layer or any higher layer. I think this is easily fix= ed by an adjustment to the wording of work item #3. I would like to suggest= the following text to replace the existing text (changes in bold):

 

"It is intended that t= he encapsulation be agnostic to the layer at which it is applied and the se= rvice that is being constructed. That is, the same encapsulation may be used on a service function chain applied at the network laye= r or at any other layer, and the same encapsulation will apply for the cons= truction of service function paths regardless of the actual service&qu= ot;.

 

If there are no objections = to this wording I can track the change. 

  

 

On 11/26/13 5:46 PM, "= Kevin J Ma" <kevin.ma@= azukisystems.com> wrote:

 

Hi all,

 

  This may be a n= it, but wrt the encapsulation spec:

 

  "It is int= ended that

   the encapsulat= ion be agnostic to the layer at which it is applied and

   the service th= at is being constructed. That is, the same

   encapsulation = may be used on a service function path realized at the

   network layer = or at any other layer, and the same encapsulation will

   apply for the = construction of service function paths regardless of

   the actual ser= vice."

 

  The first senta= nce says "layer at which it is applied".  That implies<= o:p>

  to me that the = encapsulation header can be applied at different layers?<= /p>

  Is that really = the intent?  To have encapsulation happen at different=

  layers for diff= erent legs of the service path?

 

  From the second= sentance, it seems like what we really want to say is

  "layer fro= m which it is applied" (i.e., application layer service vs.=

  L2 service that= provides the information necessary for encapsulation)?

 

  This then goes = back to my previous questions related to cross-layer

  signalling of e= ncapsulation information.  Is the discussion of such

  requirements an= d/or mechanisms (API)s in or out of scope?  Note: As

  previously stat= ed, I dont believe this to be a control plane issue.

 

thanx.

 

--  Kevin J. Ma

 

-----Original Message-----<= o:p>

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adria= n Farrel

Sent: Tuesday, November 26,= 2013 4:27 PM

Subject: [nsc] Progress tow= ard WG formation

Hi SFC list (still pretendi= ng to be NSC),

Jim and Thomas have collate= d the discussion on a proposed WG charter and I

have

I have still two tasks:

1. Read the mailing list to= make sure they have captured consensus

2. Read the charter to make= sure I support it.

You can help me by commenti= ng (on the list is preferred) about any

deficiencies

in the charter text or prop= osed milestones.

My plan is to put the chart= er before the IESG on Thursday December 5th,

and if

all goes well it should go = out for IESG and external review before coming

to the

IESG again for final approv= al on the 19th. Just be aware that snafus are

"normal".

As soon as we know the WG i= s forming, I will get the Secretariat to

migrate the

list to sfc@ietf.org. They're pretty good at th= at and you should feel no

pain

(mostly).=

Thanks,

Adrian

___________________________= ____________________

nsc mailing list=

___________________________= ____________________

nsc mailing list=

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A755D1CMBX021W3CA2exch_-- From kevin.ma@azukisystems.com Wed Nov 27 08:11:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2BA1AE07F for ; Wed, 27 Nov 2013 08:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 oKPEA6_M3h1G for ; Wed, 27 Nov 2013 08:11:23 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id D59321AD93D for ; Wed, 27 Nov 2013 08:11:21 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 2B7838BFFE0; Wed, 27 Nov 2013 11:11:21 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 9073B8BFF58; Wed, 27 Nov 2013 11:11:20 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 27 Nov 2013 11:11:20 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "Joel M. Halpern" , Melinda Shore , "nsc@ietf.org" Date: Wed, 27 Nov 2013 11:11:19 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAAAgA3TAAEP1dgAAAtQ0AAABGoQAAAP3FgAAGReYAAAOPBmA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB060@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C79FAF2B@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 16:11:37 -0000 Hi Jim, I agree. I assume that the WG would probably adopt additional items to, e.g., specify how to recognize SFC encap from individual lower level protocols, rather than try to combine an exhaustive list with the definition of the encapsulation format? I still have a question as to whether or not cross-layer signaling is in scope or not? Getting back to the charter, I took a shot at clarifying the text for the encapsulation deliverable, based on what I've gathered from this thread. Please see if my understanding is correct: "Generic SFC Encapsulation: This document will describe a single=20 service-level data plane encapsulation format for conveying the service function chain and the service function path, and for=20 communicating context information between nodes that implement=20 service functions and service function chains. It is intended that the encapsulation format be agnostic to the layer at which it is applied and that a service that is being constructed may indicate the need for encapsulation from any layer at or above the layer at which the encapsulation is requested to be applied for each leg of the service path." thanx. -- Kevin J. Ma > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, November 27, 2013 8:08 AM > To: Kevin J Ma; Joel M. Halpern; Melinda Shore; nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > Hi Kevin, >=20 > The lower layer encapsulation (e.g. the "transport") needs some way of > indicating that an SFC encapsulation follows. This will be addressed as > part of the SFC encapsulation work item. >=20 > On 11/27/13 12:08 AM, "Kevin J Ma" wrote: >=20 > >Hi Joel, > > > > I read "encapsulation" as the act of encapsulating, and therefore > > also the act of decapsulating, not as the header itself. > > > > It's not immediately clear to me how this could be made "agnostic". > > The entity that decap's the lower layer needs some way to know that > > the next layer up is an SFC encap, and that seems like it would be > > lower-layer-protocol-specific? I can see making the parsing of the > > encap header: "agnostic", but not the recognition of the encap? > > > >thanx. > > > >-- Kevin J. Ma > > > >> -----Original Message----- > >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > >> Sent: Tuesday, November 26, 2013 11:40 PM > >> To: Kevin J Ma; Melinda Shore; nsc@ietf.org > >> Subject: Re: [nsc] Progress toward WG formation > >> > >> The way I read the "agnostic" is that one transport might be MPLS, > while > >> another might be VxLAN, and a third might be IP-in-IP. However, they > >> both carry the same common header so that logic which needs to extract > >> metadata or other related operations is always working with the same > >> constructs. > >> > >> Yours, > >> Joel > >> > >> On 11/26/13 11:32 PM, Kevin J Ma wrote: > >> > Hi Melinda, > >> > > >> >> What you're suggesting sounds unfortunately and > >> >> unnecessarily complicated. > >> > > >> > I'm not suggesting anything. I'm trying to understand what the > >>charter > >> says. > >> > > >> > As stated in my original email: > >> > > >> >> "It is intended that > >> >> the encapsulation be agnostic to the layer at which it is > applied > >> and > >> >> the service that is being constructed. That is, the same > >> >> encapsulation may be used on a service function path realized a= t > >> the > >> >> network layer or at any other layer, and the same encapsulation > >> will > >> >> apply for the construction of service function paths regardless > >>of > >> >> the actual service." > >> >> > >> >> The first sentance says "layer at which it is applied". That > >> implies > >> >> to me that the encapsulation header can be applied at different > >> layers? > >> >> Is that really the intent? To have encapsulation happen at > >> different > >> >> layers for different legs of the service path? > >> >> > >> >> From the second sentance, it seems like what we really want to > say > >> is > >> >> "layer from which it is applied" (i.e., application layer servic= e > >> vs. > >> >> L2 service that provides the information necessary for > >> encapsulation)? > >> > > >> > The wording is not clear to me whether it means the encapsulation is > >>at > >> any > >> > layer, or if the encapsulation is at a single layer, and it is the > >> service > >> > that can be at any layer, which influences encapsulation at a single > >> layer. > >> > > >> > thanx. > >> > > >> > -- Kevin J. Ma > >> > > >> >> -----Original Message----- > >> >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > >> >> Sent: Tuesday, November 26, 2013 11:12 PM > >> >> To: nsc@ietf.org > >> >> Subject: Re: [nsc] Progress toward WG formation > >> >> > >> >> On 11/26/13 5:28 PM, Kevin J Ma wrote: > >> >>> just to clarify, as an example, do we expect to be able to: > >> >>> - use L2 encapsulation to get from the classifier to the firewall > >> >>> - use L4 encapsulation to get from the firewall to the TLS offload > >> >>> - use L5 encapsulation to get from the TLS offload to the load > >> balancer > >> >>> - use L3 encapsulation to get from the load balancer to AV scanner > >> >>> etc., for a chain that starts out FW -> TLS -> LB -> AV -> ... > >> >>> (with all the necessary re-classification steps in between)? > >> >> > >> >> No. I'm also not sure what you mean by "reclassification" > >> >> in this context. I don't see this mechanism as being significantly > >> >> different from how everything from network stacks to filesystems > >> >> are implemented - they have a demultiplexing element in the > >> >> messages. What you're suggesting sounds unfortunately and > >> >> unnecessarily complicated. > >> >> > >> >> Melinda > >> >> > >> >> _______________________________________________ > >> >> nsc mailing list > >> >> nsc@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/nsc > >> > _______________________________________________ > >> > nsc mailing list > >> > nsc@ietf.org > >> > https://www.ietf.org/mailman/listinfo/nsc > >> > > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Wed Nov 27 08:20:17 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7D81AD73E for ; Wed, 27 Nov 2013 08:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 peKtksLpHNjp for ; Wed, 27 Nov 2013 08:20:14 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 831541ACCE9 for ; Wed, 27 Nov 2013 08:20:11 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A5C3C416E02; Wed, 27 Nov 2013 11:19:04 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 96E5F416DA6; Wed, 27 Nov 2013 11:19:03 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 27 Nov 2013 11:19:03 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , "adrian@olddog.co.uk" , "nsc@ietf.org" Date: Wed, 27 Nov 2013 11:19:01 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAAcLzEA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB071@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C6C2C79FAEBC@MAILR002.mail.lan> 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_291CC3F9E50E7641901A54E85D0977C6C2C79FB071MAILR002maill_" MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 16:20:17 -0000 --_000_291CC3F9E50E7641901A54E85D0977C6C2C79FB071MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, I actually just sent some other text in response to your other email. ;) I think the change helps to clarify, but please see my other response. thanx. -- Kevin J. Ma From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Wednesday, November 27, 2013 11:03 AM To: Kevin J Ma; adrian@olddog.co.uk; nsc@ietf.org Subject: Re: [nsc] Progress toward WG formation Hi Kevin, I think that you make a valid point and the wording in the current charter = is perhaps misleading (or at least difficult to parse). The key point to pu= ll from this is that the SFC encapsulation could be processed by an SF runn= ing at the network layer or any higher layer. I think this is easily fixed = by an adjustment to the wording of work item #3. I would like to suggest th= e following text to replace the existing text (changes in bold): "It is intended that the encapsulation be agnostic to the layer at which it= is applied and the service that is being constructed. That is, the same en= capsulation may be used on a service function chain applied at the network = layer or at any other layer, and the same encapsulation will apply for the = construction of service function paths regardless of the actual service". If there are no objections to this wording I can track the change. On 11/26/13 5:46 PM, "Kevin J Ma" > wrote: Hi all, This may be a nit, but wrt the encapsulation spec: "It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed. That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." The first sentance says "layer at which it is applied". That implies to me that the encapsulation header can be applied at different layers? Is that really the intent? To have encapsulation happen at different layers for different legs of the service path? From the second sentance, it seems like what we really want to say is "layer from which it is applied" (i.e., application layer service vs. L2 service that provides the information necessary for encapsulation)? This then goes back to my previous questions related to cross-layer signalling of encapsulation information. Is the discussion of such requirements and/or mechanisms (API)s in or out of scope? Note: As previously stated, I dont believe this to be a control plane issue. thanx. -- Kevin J. Ma -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel Sent: Tuesday, November 26, 2013 4:27 PM To: nsc@ietf.org Subject: [nsc] Progress toward WG formation Hi SFC list (still pretending to be NSC), Jim and Thomas have collated the discussion on a proposed WG charter and I have updated this at https://datatracker.ietf.org/doc/charter-ietf-sfc/ I have still two tasks: 1. Read the mailing list to make sure they have captured consensus 2. Read the charter to make sure I support it. You can help me by commenting (on the list is preferred) about any deficiencies in the charter text or proposed milestones. My plan is to put the charter before the IESG on Thursday December 5th, and if all goes well it should go out for IESG and external review before coming to the IESG again for final approval on the 19th. Just be aware that snafus are "normal". As soon as we know the WG is forming, I will get the Secretariat to migrate the list to sfc@ietf.org. They're pretty good at that and = you should feel no pain (mostly). Thanks, Adrian _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_291CC3F9E50E7641901A54E85D0977C6C2C79FB071MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

  I actually just sent some other t= ext in response to your other email.  ;)

&nb= sp; I think the change helps to clarify, but please see my other response.<= o:p>

 

= thanx.

 

--  Kevin J. Ma=

 

From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of = Jim Guichard (jguichar)
Sent: Wednesday, November 27, 2013 11:03 = AM
To: Kevin J Ma; adrian@olddog.co.uk; nsc@ietf.org
Subjec= t: Re: [nsc] Progress toward WG formation

 

Hi Kevin,

=  

I think that yo= u make a valid point and the wording in the current charter is perhaps misl= eading (or at least difficult to parse). The key point to pull from this is= that the SFC encapsulation could be processed by an SF running at the= network layer or any higher layer. I think this is easily fixed by an= adjustment to the wording of work item #3. I would like to suggest the fol= lowing text to replace the existing text (changes in bold):

 

"It is intended that the encapsu= lation be agnostic to the layer at which it is applied and the service that= is being constructed. That is, the same encapsulation may be used on a ser= vice function chain applied at the network layer or at any other lay= er, and the same encapsulation will apply for the construction of service f= unction paths regardless of the actual service".

 

If there are no objections to this wo= rding I can track the change. 

 

 

On 11/26/13 5:46 PM, = "Kevin J Ma" <kev= in.ma@azukisystems.com> wrote:

 

=

Hi all,

 

  This may be a nit, but wrt the encapsulation spec:<= o:p>

 =

  "It is int= ended that

 =   the encapsulation be agnostic to the layer at which it is applied an= d

   th= e service that is being constructed. That is, the same

   encapsulation may be us= ed on a service function path realized at the

<= div>

   network layer or at any other la= yer, and the same encapsulation will

   apply for the construction of service func= tion paths regardless of

   the actual service."

<= div>

 

  The first sentance says "layer at whic= h it is applied".  That implies

<= div>

  to me that the encapsulation head= er can be applied at different layers?

  Is that really the intent?  To = have encapsulation happen at different

  layers for different legs of the service = path?

 = ;

  From the= second sentance, it seems like what we really want to say is

  "layer from w= hich it is applied" (i.e., application layer service vs.

  L2 service that pr= ovides the information necessary for encapsulation)?

<= /div>

 

=

  This then goes back to my previous qu= estions related to cross-layer

  signalling of encapsulation information. &nb= sp;Is the discussion of such

  requirements and/or mechanisms (API)s in or out of = scope?  Note: As

  previously stated, I dont believe this to be a contro= l plane issue.

 

thanx.<= /o:p>

 

--  Kevin J. Ma

 

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

Fro= m: nsc [mailto:nsc-bounces@ietf.org= ] On Behalf Of Adrian Farrel

Sent: Tuesday, November 26, 2013 4:27 PM

Subject: [nsc] Progress toward WG formation

<= div>

Hi SFC list (still pretending to be NSC),

Jim and Thomas have = collated the discussion on a proposed WG charter and I

have

I have= still two tasks:

1. Read the mailing list to make sure they have captured consensus

2. Read the charter to m= ake sure I support it.

You can help me by commenting (on the list is preferred) about any

deficiencies

in the charter text or = proposed milestones.

<= span style=3D'font-size:10.5pt;font-family:"Calibri","sans-serif";color:bla= ck'>My plan is to put the charter before the IESG on Thursday December 5th,=

and if

all goes well it should go= out for IESG and external review before coming

=

to the

IESG again for final approval on the 19th. Just be awa= re that snafus are

"normal".

= As soon as we know the WG is forming, I will get the Secretariat to

migrate the

list to sfc@ietf.org. They're pretty good at that and you shoul= d feel no

pain

(mostly).

Thanks,=

Adrian

=

____________________________________________= ___

nsc mailing l= ist

___________________________________= ____________

nsc = mailing list

https://www.ietf.org/mailman/listinfo/nsc

<= /div>

 

= --_000_291CC3F9E50E7641901A54E85D0977C6C2C79FB071MAILR002maill_-- From melinda.shore@gmail.com Wed Nov 27 08:59:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B5E1AD945 for ; Wed, 27 Nov 2013 08:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxXMDTpA2-wF for ; Wed, 27 Nov 2013 08:59:22 -0800 (PST) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DF1AD7C0 for ; Wed, 27 Nov 2013 08:59:22 -0800 (PST) Received: by mail-pd0-f169.google.com with SMTP id v10so10339121pde.0 for ; Wed, 27 Nov 2013 08:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=bCvg7kJBeDKyFzie2dXaqbu/9GeCsSZvVXJcr1ksDVc=; b=ax/mkFvYGAnfKemOPtTfSlOsV8Y7gN4xunUbvZIWNJAEUxy+FbDQ61d0/MjbEr/eyD 9BUAjuunohcDTBJGnnrR5LCj//TTyoO/GXjIMz1b/iDkSxX/bXVBl+JWLoLuY3AS5JoS 8IJz097G46TN3Xcxkw+QBXPgXk4JIpibpPmAEJFj9LYO2ZNw20AMJrG0Kd/3TjYpY9wg Hx7h5TzeLlZg/WmwoiHn/kNpTrpa12Dvz6Oud5vtXQpEzIx+Tvluv6fUuoYRRZo23D+q T23SOJVuS8HZ9sjeMI/Dpf1aarzSOg4QxhwU628W9rnAOoArcOpoJvGU7/Yl2oiirlsa 43NA== X-Received: by 10.68.232.37 with SMTP id tl5mr6153709pbc.86.1385571562404; Wed, 27 Nov 2013 08:59:22 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id gv10sm83340693pbd.0.2013.11.27.08.59.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 08:59:19 -0800 (PST) Message-ID: <529624E5.5090209@gmail.com> Date: Wed, 27 Nov 2013 07:59:17 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 16:59:24 -0000 On 11/27/13 7:02 AM, Jim Guichard (jguichar) wrote: > I think that you make a valid point and the wording in the current > charter is perhaps misleading (or at least difficult to parse). The key > point to pull from this is that the SFC encapsulation could be processed > by an SF running at the network layer or any higher layer. I think I see the source of the confusion. I think it's not so much that it's "running at" a given layer but that it's treating traffic at a given layer. I don't think the original language was at all unclear but maybe that's just me. I do think the "running at" language is both more confusing and confused than "layer at which it is applied." Melinda From jguichar@cisco.com Wed Nov 27 09:05:12 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5F61AE01A for ; Wed, 27 Nov 2013 09:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 Sj-JkKGEfKS8 for ; Wed, 27 Nov 2013 09:05:11 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id B701C1ADF91 for ; Wed, 27 Nov 2013 09:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=995; q=dns/txt; s=iport; t=1385571910; x=1386781510; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=sxDp7qhVBdP2Og7CK2v0L8ndpxdtGrAtP0TMrWO/Ks8=; b=a+PL4SoTnGiYrJ3yIGQPljuFOYfgx+mZrvFYnWOminMIOk4PjaBih3XD XBp1thV54+AiurETClbavt7Ct5fRhWOAAl1EkIWk9Qv2RTu6QCsQnxtWH vk13bpecML0z1aj14A7bXFBuKmCEjAub5cELDPbf4zrZ+wVjmT6pFWySB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAPclllKtJV2c/2dsb2JhbABZgwc4U7hCgR8WdIIlAQEBAwEBAQE3NBANAQgYHjEGCyUBAQQBEodvAwkGDbgPDYd7EwSMcYIYhDMDlimBa4xahTmDKYIq X-IronPort-AV: E=Sophos;i="4.93,783,1378857600"; d="scan'208";a="2703004" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 27 Nov 2013 17:05:10 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rARH5AhO007375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 17:05:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 11:05:09 -0600 From: "Jim Guichard (jguichar)" To: Melinda Shore , "nsc@ietf.org" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAADHVxgP//rc2A Date: Wed, 27 Nov 2013 17:05:09 +0000 Message-ID: In-Reply-To: <529624E5.5090209@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <29AC8A3E0C07954797B2EBE403E898E9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 17:05:12 -0000 Hi Melinda, On 11/27/13 11:59 AM, "Melinda Shore" wrote: >On 11/27/13 7:02 AM, Jim Guichard (jguichar) wrote: >> I think that you make a valid point and the wording in the current >> charter is perhaps misleading (or at least difficult to parse). The key >> point to pull from this is that the SFC encapsulation could be processed >> by an SF running at the network layer or any higher layer. > >I think I see the source of the confusion. I think it's not so much >that it's "running at" a given layer but that it's treating traffic >at a given layer.=20 Jim> yes precisely, but you knew what I meant ;-) > I don't think the original language was at all >unclear but maybe that's just me. I do think the "running at" language >is both more confusing and confused than "layer at which it is applied." > >Melinda > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Wed Nov 27 10:07:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C7F1ADF59 for ; Wed, 27 Nov 2013 10:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.399 X-Spam-Level: X-Spam-Status: No, score=0.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_OFF=2.3, 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 gI8Rvk_XJmqF for ; Wed, 27 Nov 2013 10:06:58 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id BA5211AD694 for ; Wed, 27 Nov 2013 10:06:58 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 467B5416D75; Wed, 27 Nov 2013 13:06:58 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D0B4D41690F; Wed, 27 Nov 2013 13:06:57 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 27 Nov 2013 13:06:57 -0500 From: Kevin J Ma To: "Jim Guichard (jguichar)" , Melinda Shore , "nsc@ietf.org" Date: Wed, 27 Nov 2013 13:06:56 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAADHVxgP//rc2AgAAGLlA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB15E@MAILR002.mail.lan> References: <529624E5.5090209@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 18:07:00 -0000 My current understanding is that: a) the service can be at any layer. b) the encapsulation can be at any layer. c) the encapsulation may be at a different (lower) layer than the service d) the service may be at a different layer on each leg of the chain e) the encapsulation may be at a different layer on each leg of the path f) the signaling from service layer to encapsulation layer is out-of-scope The encapsulation layer and the service layer are independent, and only related by c) above, with the caveat of f) above? If I reread the charter with these in mind, then I can see these as being a valid interpretation of: layer and service agnostic. However, I still find the last sentance confusing as I interpret it to preclude e) above. Is this sentance needed at all? Perhaps it can just be removed? =20 "That is, the same=20 encapsulation may be used on a service function path realized at the=20 network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." I would also change the prior sentance: "It is intended that the encapsulation be agnostic to the layer at which it is applied and the service that is being constructed." adding the word "format" to be consistent with the first sentance: "It is intended that the encapsulation format be agnostic to the layer at which it is applied= and the service that is being constructed." or see the alternate text in my other email. thanx. -- Kevin J. Ma > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard > (jguichar) > Sent: Wednesday, November 27, 2013 12:05 PM > To: Melinda Shore; nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > Hi Melinda, >=20 > On 11/27/13 11:59 AM, "Melinda Shore" wrote: >=20 > >On 11/27/13 7:02 AM, Jim Guichard (jguichar) wrote: > >> I think that you make a valid point and the wording in the current > >> charter is perhaps misleading (or at least difficult to parse). The ke= y > >> point to pull from this is that the SFC encapsulation could be > processed > >> by an SF running at the network layer or any higher layer. > > > >I think I see the source of the confusion. I think it's not so much > >that it's "running at" a given layer but that it's treating traffic > >at a given layer. >=20 > Jim> yes precisely, but you knew what I meant ;-) >=20 > > I don't think the original language was at all > >unclear but maybe that's just me. I do think the "running at" language > >is both more confusing and confused than "layer at which it is applied." > > > >Melinda > > > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Wed Nov 27 10:17:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137531ADDDA for ; Wed, 27 Nov 2013 10:17:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmIj0UmZfefJ for ; Wed, 27 Nov 2013 10:17:41 -0800 (PST) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 77C451ADDAC for ; Wed, 27 Nov 2013 10:17:41 -0800 (PST) Received: by mail-pd0-f182.google.com with SMTP id v10so10375782pde.41 for ; Wed, 27 Nov 2013 10:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Lm9T7JZbDU5UD+R5XoHcvEUtyzwS4967EZ30deLkWfk=; b=x2V4hT/pbS+0GqwRPugP0lxiCkW0gnSgmSBlpc7u/0PZWI/wqXDqoy8j6v6Hv4xZBe 69FRffWANZKQTDAoPGq6ZVX5wqmLnDyivQsNfwQ4SN5BavxyJBJZLkYGMbwlNlT8+pYP SjO0XtPsU1YbClW0dVXtVPRIseJARzYQya6Xbn3Pv0cvDdZNH8YmJg9jKsaMIhGR5I2s 9WlDajdZysU4JNIdCcEyAjLepFVQ50HqbCy7ULYgfqtijJ3lpyDY15CS91+NX4OuYPKd w0ZtxoEiiJhKQ6p+OK1rH/yfnqhO65cPs/C8rD0EPRN1Yeg4zIun0lU6KYWGnXqc+Iys vhMQ== X-Received: by 10.68.225.9 with SMTP id rg9mr6516177pbc.122.1385576260060; Wed, 27 Nov 2013 10:17:40 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id zq10sm101351018pab.6.2013.11.27.10.17.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 10:17:39 -0800 (PST) Message-ID: <52963740.5040304@gmail.com> Date: Wed, 27 Nov 2013 09:17:36 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Jim Guichard (jguichar)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 18:17:43 -0000 On 11/27/13 8:05 AM, Jim Guichard (jguichar) wrote: > On 11/27/13 11:59 AM, "Melinda Shore" wrote: >> I think I see the source of the confusion. I think it's not so much >> that it's "running at" a given layer but that it's treating traffic >> at a given layer. > > Jim> yes precisely, but you knew what I meant ;-) I did. I think if it were just me I'd drop any discussion of layering here as I don't think it's particularly helpful and I don't think it changes anything. On the other hand if enough people are confused, that's a problem, but on a third hand I think that if people are confused about this particular scenario then they're probably confused about layering more generally and I'm not sure it's nsc's job to fix that. (And I'll note that there seems to be a lot more confusion about network layering than there used to be). I'm wondering if there are other people who feel as if it's helpful to provide clarifying text around this. Melinda From kevin.ma@azukisystems.com Wed Nov 27 11:08:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83F1AD8F2 for ; Wed, 27 Nov 2013 11:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 C16bPoVHv7UB for ; Wed, 27 Nov 2013 11:07:55 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0961AD72A for ; Wed, 27 Nov 2013 11:07:55 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7134F7AF3BC; Wed, 27 Nov 2013 14:07:54 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E9B347AF6A0; Wed, 27 Nov 2013 14:07:53 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Wed, 27 Nov 2013 14:07:53 -0500 From: Kevin J Ma To: Melinda Shore , "Jim Guichard (jguichar)" Date: Wed, 27 Nov 2013 14:07:52 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rnPlmo79y+/fbRxaYH1Yt1N6AEQAAw7cw Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> References: <52963740.5040304@gmail.com> In-Reply-To: <52963740.5040304@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 19:08:01 -0000 > I think that if people are > confused about this particular scenario then they're probably > confused about layering more generally and I'm not sure it's nsc's > job to fix that.=20 If anyone was confused by my question, it has consistently been about the distinction between the layer at which the encapsulation occurs and the layer at which the service is operating, and the signaling between the two, should they be different [1]. In addition, I asked if the layer at which encapsulation could occur for a given service path could change on each leg of the=20 service path, which I believe Surendra confirmed [2]. Though I appreciate the concern for my possible general confusedness. -- Kevin J. Ma [1] http://www.ietf.org/mail-archive/web/nsc/current/msg00756.html [2] http://www.ietf.org/mail-archive/web/nsc/current/msg00770.html > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > Sent: Wednesday, November 27, 2013 1:18 PM > To: Jim Guichard (jguichar) > Cc: nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > On 11/27/13 8:05 AM, Jim Guichard (jguichar) wrote: > > On 11/27/13 11:59 AM, "Melinda Shore" wrote: > >> I think I see the source of the confusion. I think it's not so much > >> that it's "running at" a given layer but that it's treating traffic > >> at a given layer. > > > > Jim> yes precisely, but you knew what I meant ;-) >=20 > I did. I think if it were just me I'd drop any discussion of layering > here as I don't think it's particularly helpful and I don't think it > changes anything. On the other hand if enough people are confused, > that's a problem, but on a third hand I think that if people are > confused about this particular scenario then they're probably > confused about layering more generally and I'm not sure it's nsc's > job to fix that. (And I'll note that there seems to be a lot more > confusion about network layering than there used to be). >=20 > I'm wondering if there are other people who feel as if it's > helpful to provide clarifying text around this. >=20 > Melinda >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Wed Nov 27 11:38:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2CD1AE06C for ; Wed, 27 Nov 2013 11:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrmZvoYqhZNz for ; Wed, 27 Nov 2013 11:37:24 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 695DF1AD8DC for ; Wed, 27 Nov 2013 11:34:04 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so10999758pbb.4 for ; Wed, 27 Nov 2013 11:34:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tfDZ+iK0eyfq5Gg5uRag/GVF0QcemZF8klscfYXm+WE=; b=l25U0kID7gbdUF9klKeZyNWJ8pNeMIC/SND1lNpfArDqA6VSq9PZswMVE/VznSO5En kjUtIY3CaNe8d0IqU+T0Z1VXuXpfvtZdaJZkvI7uKTAA+UqS9/4tIIFicHcVSdrex/00 aKrPscIMoxgWn6KXMg17E5aL0pyJdgO1Z8bMI0maaMb9psDBf7bdRr+aVHTykCNppUdU XX3I5mk8dsJiun3550YotfvsoRTbOWcwAkTlJtambP4sb6ckhjLmyAnIOlOKg4BEHmk7 YN5XQ/116h1mrvMz/R7IPMvGhTbbfE4emUAtBtip5PEwK1yyT8DKVaX7o4xyCvRX528D H6Qw== X-Received: by 10.68.159.129 with SMTP id xc1mr4422797pbb.193.1385580843989; Wed, 27 Nov 2013 11:34:03 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id de1sm89836040pbc.7.2013.11.27.11.34.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 11:34:02 -0800 (PST) Message-ID: <52964928.50708@gmail.com> Date: Wed, 27 Nov 2013 10:34:00 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin J Ma References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 19:38:01 -0000 X-List-Received-Date: Wed, 27 Nov 2013 19:38:01 -0000 On 11/27/13 10:07 AM, Kevin J Ma wrote: > If anyone was confused by my question, it has consistently been about > the distinction between the layer at which the encapsulation occurs > and the layer at which the service is operating, and the signaling > between the two, should they be different [1]. Right, and I don't understand why this is a question. Aside from there not really being any sort of issue there, I think, I've been a bit concerned that being legalistic about layering has tended to lead to more confusion rather than less, and to more complicated protocols that are difficult to implement and deploy. When it comes right down to it, this could be done as a RESTful protocol, a radio/PHY protocol, and anything in-between. You could write the messages down on paper and carry them to some guy who'll manually configure a device, if it came down to it. Thinking about layers is a lot less useful than thinking about the transport (in its general sense, for heaven's sake) characteristics that you need to support the service whose messages you're carrying. It wasn't *that* long ago that it was a matter of faith that the IP stack doesn't have seven layers, etc. Not sure what happened but I think it's tended to lead to discussions like we're having here and that have taken place in nvo3. That is to say, a bunch of ratholing and unnecessary complexity. I don't think a discussion of layering in the nsc charter is clarifying or helps frame scope issues, although I'll grant that saying that nsc may be used to provision/manage/etc. services operating at any layer in the IP stack may help stave off confusion on the part of those who tend to ask that question in the first place. It seems tautological to me but I may be alone in that. Melinda Melinda From Ron_Parker@affirmednetworks.com Wed Nov 27 11:47:34 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650131AD8DA for ; Wed, 27 Nov 2013 11:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pZFxMiavEAH5 for ; Wed, 27 Nov 2013 11:47:31 -0800 (PST) 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 24B741AD83F for ; Wed, 27 Nov 2013 11:47:31 -0800 (PST) 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.0158.001; Wed, 27 Nov 2013 11:47:30 -0800 From: Ron Parker To: Kevin J Ma Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/ Date: Wed, 27 Nov 2013 19:47:30 +0000 Message-ID: <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 19:47:34 -0000 Hi, Kevin.=20 I'm not entirely clear on "the layer that the encapsulation occurs". Are y= ou thinking of this from an ISO 7 layer perspective or from a modular imple= mentation perspective? Perhaps, naively, I've always envisioned the sfc s= ervice header inserted before the original/modified/manufactured IP datagra= m that the layer 3 and above service function operates on. And a transpor= t encapsulation of some sort is inserted before the sfc service header. = =20 Although I haven't spent much time thinking about it, I suppose this could = be extended to insertion of the SFC header in front of an original/modified= /manufactured MAC frame that a layer 2 and above service function operates = on. And then the obligatory transport encapsulation in front of the inser= ted SFC header. =20 Is this consistent with your layering concepts? Ron On Nov 27, 2013, at 2:08 PM, "Kevin J Ma" wrote= : >> I think that if people are >> confused about this particular scenario then they're probably >> confused about layering more generally and I'm not sure it's nsc's >> job to fix that. >=20 > If anyone was confused by my question, it has consistently been about > the distinction between the layer at which the encapsulation occurs > and the layer at which the service is operating, and the signaling > between the two, should they be different [1]. >=20 > In addition, I asked if the layer at which encapsulation could > occur for a given service path could change on each leg of the=20 > service path, which I believe Surendra confirmed [2]. >=20 > Though I appreciate the concern for my possible general confusedness. >=20 > -- Kevin J. Ma >=20 > [1] http://www.ietf.org/mail-archive/web/nsc/current/msg00756.html >=20 > [2] http://www.ietf.org/mail-archive/web/nsc/current/msg00770.html >=20 >=20 >> -----Original Message----- >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore >> Sent: Wednesday, November 27, 2013 1:18 PM >> To: Jim Guichard (jguichar) >> Cc: nsc@ietf.org >> Subject: Re: [nsc] Progress toward WG formation >>=20 >>> On 11/27/13 8:05 AM, Jim Guichard (jguichar) wrote: >>>> On 11/27/13 11:59 AM, "Melinda Shore" wrote: >>>> I think I see the source of the confusion. I think it's not so much >>>> that it's "running at" a given layer but that it's treating traffic >>>> at a given layer. >>>=20 >>> Jim> yes precisely, but you knew what I meant ;-) >>=20 >> I did. I think if it were just me I'd drop any discussion of layering >> here as I don't think it's particularly helpful and I don't think it >> changes anything. On the other hand if enough people are confused, >> that's a problem, but on a third hand I think that if people are >> confused about this particular scenario then they're probably >> confused about layering more generally and I'm not sure it's nsc's >> job to fix that. (And I'll note that there seems to be a lot more >> confusion about network layering than there used to be). >>=20 >> I'm wondering if there are other people who feel as if it's >> helpful to provide clarifying text around this. >>=20 >> Melinda >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From kevin.ma@azukisystems.com Wed Nov 27 11:48:56 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861901ADF6C for ; Wed, 27 Nov 2013 11:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1eNYDHblCNMg for ; Wed, 27 Nov 2013 11:48:52 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id E222D1AD83F for ; Wed, 27 Nov 2013 11:48:51 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6AB777AFA31; Wed, 27 Nov 2013 14:48:05 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 05A437AF9C5; Wed, 27 Nov 2013 14:48:05 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Wed, 27 Nov 2013 14:48:04 -0500 From: Kevin J Ma To: Melinda Shore Date: Wed, 27 Nov 2013 14:48:03 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rp6KWQ+dxxyi2SgySsnV6OTp/SQAAIIag Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1ED@MAILR002.mail.lan> References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <52964928.50708@gmail.com> In-Reply-To: <52964928.50708@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 19:48:56 -0000 Hi Melinda, I agree that the layer discussion in the charter may be unnecessary. The original discussion stemmed from concerns that the initial set of documents only considered lower layer encapsulation, but did not consider the useability of such encapsulation by a higher layer service. Defining an encapsulation format that cannot be used by a large number of applications would be unfortunate. I don't feel that this is an unreasonable concern (though it may not be charter- worthy). thanx. -- Kevin J. Ma > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Wednesday, November 27, 2013 2:34 PM > To: Kevin J Ma > Cc: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > On 11/27/13 10:07 AM, Kevin J Ma wrote: > > If anyone was confused by my question, it has consistently been about > > the distinction between the layer at which the encapsulation occurs > > and the layer at which the service is operating, and the signaling > > between the two, should they be different [1]. >=20 > Right, and I don't understand why this is a question. > Aside from there not really being any sort of issue there, > I think, I've been a bit concerned that being legalistic > about layering has tended to lead to more confusion rather > than less, and to more complicated protocols that are > difficult to implement and deploy. >=20 > When it comes right down to it, this could be done as > a RESTful protocol, a radio/PHY protocol, and anything > in-between. You could write the messages down on > paper and carry them to some guy who'll manually > configure a device, if it came down to it. Thinking > about layers is a lot less useful than thinking about > the transport (in its general sense, for heaven's sake) > characteristics that you need to support the service > whose messages you're carrying. >=20 > It wasn't *that* long ago that it was a matter of faith > that the IP stack doesn't have seven layers, etc. Not > sure what happened but I think it's tended to lead to > discussions like we're having here and that have taken > place in nvo3. That is to say, a bunch of ratholing and > unnecessary complexity. I don't think a discussion of > layering in the nsc charter is clarifying or helps > frame scope issues, although I'll grant that saying that > nsc may be used to provision/manage/etc. services operating > at any layer in the IP stack may help stave off confusion > on the part of those who tend to ask that question in the > first place. It seems tautological to me but I may be > alone in that. >=20 > Melinda >=20 >=20 > Melinda From melinda.shore@gmail.com Wed Nov 27 11:57:54 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBC31ADFD7 for ; Wed, 27 Nov 2013 11:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSS68eeBMIvn for ; Wed, 27 Nov 2013 11:57:42 -0800 (PST) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 124EA1ADE86 for ; Wed, 27 Nov 2013 11:57:03 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id un15so11023012pbc.41 for ; Wed, 27 Nov 2013 11:57:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PmGcEu336KWz6Mz9r0LVNC6loomlYgtDeSi9lJhK9kE=; b=n36HXjdM7pP/8/+4wMyt7rVC12pgQ74fiB9MNZ97F0nXdT9yak3mkXyDjfiwRR5Qvc Y1yiUVxVplP7bjht8Zy2UL8tEjp/dzwyU2l5+2iCPvHrSLF5EaPcmM4eSwwsUin/MSEa I45i2XjrFNDZ0mBegt25kmfPsXkyWuwSguMF08WQQeCIBJdqDD8lfTIkN+BT+Fs05Wq/ joRBVMlW2m1+T7cf855vN0m0youS1lW9TE3oacruUADeHc13qTaQBxdz4waQjuMgjMLb Ai2pr37Bp68vmsBfwr+l2xua+T2jxHrUYt1Y3gBBFWxdbpBR8upt5uVp+frkcniHR5sR xr9g== X-Received: by 10.68.138.199 with SMTP id qs7mr3537562pbb.199.1385582222641; Wed, 27 Nov 2013 11:57:02 -0800 (PST) Received: from spandex.local (216-67-62-197-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.62.197]) by mx.google.com with ESMTPSA id zq10sm101790191pab.6.2013.11.27.11.57.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 11:57:01 -0800 (PST) Message-ID: <52964E8B.8060702@gmail.com> Date: Wed, 27 Nov 2013 10:56:59 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin J Ma References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <52964928.50708@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1ED@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1ED@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 19:57:54 -0000 X-List-Received-Date: Wed, 27 Nov 2013 19:57:54 -0000 On 11/27/13 10:48 AM, Kevin J Ma wrote: > The original discussion stemmed from concerns that the initial set > of documents only considered lower layer encapsulation, but did not > consider the useability of such encapsulation by a higher layer > service. Defining an encapsulation format that cannot be used by > a large number of applications would be unfortunate. I don't feel > that this is an unreasonable concern (though it may not be charter- > worthy). Can you give an example of the sort of thing you're concerned about? I'm having a very difficult time envisioning a "higher-layer" service even seeing the encapsulation. Melinda From kevin.ma@azukisystems.com Wed Nov 27 12:04:53 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78A1AE009 for ; Wed, 27 Nov 2013 12:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wfsvRcmGn-Qu for ; Wed, 27 Nov 2013 12:04:08 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA3C1ADE86 for ; Wed, 27 Nov 2013 12:03:27 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C8A5D8BF28E; Wed, 27 Nov 2013 15:03:26 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 1BE0B8BE475; Wed, 27 Nov 2013 15:03:26 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 27 Nov 2013 15:03:25 -0500 From: Kevin J Ma To: Ron Parker Date: Wed, 27 Nov 2013 15:03:24 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> In-Reply-To: <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 20:04:53 -0000 X-List-Received-Date: Wed, 27 Nov 2013 20:04:53 -0000 Hi Ron, > Perhaps, naively, I've always envisioned the > sfc service header inserted before the original/modified/manufactured IP > datagram that the layer 3 and above service function operates on. My question was partially about whether it would always be the IP datagram, or whether it could be an ethernet frame, or a TCP payload, or whether it might be just the HTTP entity body. Along with that, as one who develops applications that only care about the HTTP request, and might not have direct access to the code (layer, whatever= ) responsible for encap/decap of the sfc header, how the application layer would get access to the sfc information, if the encapsulation was not at the same layer as the service function. I don't really care where the sfc header is, as long as the information is available to the service, but it was/is not clear to me yet how the service would get that information, or if I missed something about the intended flexibility of the encapsulation. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Wednesday, November 27, 2013 2:48 PM > To: Kevin J Ma > Cc: Melinda Shore; Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > Hi, Kevin. >=20 > I'm not entirely clear on "the layer that the encapsulation occurs". Are > you thinking of this from an ISO 7 layer perspective or from a modular > implementation perspective? Perhaps, naively, I've always envisioned th= e > sfc service header inserted before the original/modified/manufactured IP > datagram that the layer 3 and above service function operates on. And a > transport encapsulation of some sort is inserted before the sfc service > header. >=20 > Although I haven't spent much time thinking about it, I suppose this coul= d > be extended to insertion of the SFC header in front of an > original/modified/manufactured MAC frame that a layer 2 and above service > function operates on. And then the obligatory transport encapsulation i= n > front of the inserted SFC header. >=20 > Is this consistent with your layering concepts? >=20 > Ron >=20 >=20 > On Nov 27, 2013, at 2:08 PM, "Kevin J Ma" > wrote: >=20 > >> I think that if people are > >> confused about this particular scenario then they're probably > >> confused about layering more generally and I'm not sure it's nsc's > >> job to fix that. > > > > If anyone was confused by my question, it has consistently been about > > the distinction between the layer at which the encapsulation occurs > > and the layer at which the service is operating, and the signaling > > between the two, should they be different [1]. > > > > In addition, I asked if the layer at which encapsulation could > > occur for a given service path could change on each leg of the > > service path, which I believe Surendra confirmed [2]. > > > > Though I appreciate the concern for my possible general confusedness. > > > > -- Kevin J. Ma > > > > [1] http://www.ietf.org/mail-archive/web/nsc/current/msg00756.html > > > > [2] http://www.ietf.org/mail-archive/web/nsc/current/msg00770.html > > > > > >> -----Original Message----- > >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > >> Sent: Wednesday, November 27, 2013 1:18 PM > >> To: Jim Guichard (jguichar) > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] Progress toward WG formation > >> > >>> On 11/27/13 8:05 AM, Jim Guichard (jguichar) wrote: > >>>> On 11/27/13 11:59 AM, "Melinda Shore" > wrote: > >>>> I think I see the source of the confusion. I think it's not so much > >>>> that it's "running at" a given layer but that it's treating traffic > >>>> at a given layer. > >>> > >>> Jim> yes precisely, but you knew what I meant ;-) > >> > >> I did. I think if it were just me I'd drop any discussion of layering > >> here as I don't think it's particularly helpful and I don't think it > >> changes anything. On the other hand if enough people are confused, > >> that's a problem, but on a third hand I think that if people are > >> confused about this particular scenario then they're probably > >> confused about layering more generally and I'm not sure it's nsc's > >> job to fix that. (And I'll note that there seems to be a lot more > >> confusion about network layering than there used to be). > >> > >> I'm wondering if there are other people who feel as if it's > >> helpful to provide clarifying text around this. > >> > >> Melinda > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From Ron_Parker@affirmednetworks.com Wed Nov 27 12:25:09 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 086C91ADF5F for ; Wed, 27 Nov 2013 12:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bLw4h-Vim3G for ; Wed, 27 Nov 2013 12:25:06 -0800 (PST) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id A675E1ADE86 for ; Wed, 27 Nov 2013 12:25:06 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Wed, 27 Nov 2013 12:25:05 -0800 From: Ron Parker To: Kevin J Ma Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmD///n5cA== Date: Wed, 27 Nov 2013 20:25:04 +0000 Message-ID: References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 27 Nov 2013 20:25:09 -0000 Kevin, As has been pointed out on the thread, "layer" can and does mean multiple t= hings. Let's consider the protocol stackup for your example --we have L2/L3/TCP/HT= TP as the thing that an HTTP-aware network element acts upon. Depending o= n the internal software design of that network element, it is certainly con= ceivable that some internal software module acts solely on the HTTP portion= . But whether or not it has access to particulars from L2/L3/TCP is a des= ign and implementation decision. Now with an SFC header, we might have (I'll pick IP/UDP as my exemplary tra= nsport for the SFC encapsulated packets) -- L2/IP/UDP/SFC/L3/TCP/HTTP. Le= t's also assume that the network element has been enhanced to understand th= is new SFC tunneling concept (whether that is in the kernel, in application= space, etc., is a design and implementation decision). Now the argument = can be extended that whether that software module that looks at HTTP, only,= has access to the outer IP/UDP and SFC data is a design and implementation= decision. Ron -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Wednesday, November 27, 2013 3:03 PM To: Ron Parker Cc: Melinda Shore; Jim Guichard (jguichar); nsc@ietf.org Subject: RE: [nsc] Progress toward WG formation Hi Ron, > Perhaps, naively, I've always envisioned the sfc service header=20 > inserted before the original/modified/manufactured IP datagram that=20 > the layer 3 and above service function operates on. My question was partially about whether it would always be the IP datagram,= or whether it could be an ethernet frame, or a TCP payload, or whether it = might be just the HTTP entity body. Along with that, as one who develops applications that only care about the = HTTP request, and might not have direct access to the code (layer, whatever= ) responsible for encap/decap of the sfc header, how the application layer = would get access to the sfc information, if the encapsulation was not at th= e same layer as the service function. I don't really care where the sfc header is, as long as the information is = available to the service, but it was/is not clear to me yet how the service= would get that information, or if I missed something about the intended fl= exibility of the encapsulation. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Wednesday, November 27, 2013 2:48 PM > To: Kevin J Ma > Cc: Melinda Shore; Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > Hi, Kevin. >=20 > I'm not entirely clear on "the layer that the encapsulation occurs". =20 > Are you thinking of this from an ISO 7 layer perspective or from a modula= r > implementation perspective? Perhaps, naively, I've always envisioned th= e > sfc service header inserted before the original/modified/manufactured IP > datagram that the layer 3 and above service function operates on. And a > transport encapsulation of some sort is inserted before the sfc=20 > service header. >=20 > Although I haven't spent much time thinking about it, I suppose this=20 > could be extended to insertion of the SFC header in front of an=20 > original/modified/manufactured MAC frame that a layer 2 and above service > function operates on. And then the obligatory transport encapsulation i= n > front of the inserted SFC header. >=20 > Is this consistent with your layering concepts? >=20 > Ron >=20 >=20 > On Nov 27, 2013, at 2:08 PM, "Kevin J Ma" > wrote: >=20 > >> I think that if people are > >> confused about this particular scenario then they're probably=20 > >> confused about layering more generally and I'm not sure it's nsc's=20 > >> job to fix that. > > > > If anyone was confused by my question, it has consistently been=20 > > about the distinction between the layer at which the encapsulation=20 > > occurs and the layer at which the service is operating, and the=20 > > signaling between the two, should they be different [1]. > > > > In addition, I asked if the layer at which encapsulation could occur=20 > > for a given service path could change on each leg of the service=20 > > path, which I believe Surendra confirmed [2]. > > > > Though I appreciate the concern for my possible general confusedness. > > > > -- Kevin J. Ma > > > > [1] http://www.ietf.org/mail-archive/web/nsc/current/msg00756.html > > > > [2] http://www.ietf.org/mail-archive/web/nsc/current/msg00770.html > > > > > >> -----Original Message----- > >> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Melinda Shore > >> Sent: Wednesday, November 27, 2013 1:18 PM > >> To: Jim Guichard (jguichar) > >> Cc: nsc@ietf.org > >> Subject: Re: [nsc] Progress toward WG formation > >> > >>> On 11/27/13 8:05 AM, Jim Guichard (jguichar) wrote: > >>>> On 11/27/13 11:59 AM, "Melinda Shore" > wrote: > >>>> I think I see the source of the confusion. I think it's not so=20 > >>>> much that it's "running at" a given layer but that it's treating=20 > >>>> traffic at a given layer. > >>> > >>> Jim> yes precisely, but you knew what I meant ;-) > >> > >> I did. I think if it were just me I'd drop any discussion of=20 > >> layering here as I don't think it's particularly helpful and I=20 > >> don't think it changes anything. On the other hand if enough=20 > >> people are confused, that's a problem, but on a third hand I think=20 > >> that if people are confused about this particular scenario then=20 > >> they're probably confused about layering more generally and I'm not=20 > >> sure it's nsc's job to fix that. (And I'll note that there seems=20 > >> to be a lot more confusion about network layering than there used to b= e). > >> > >> I'm wondering if there are other people who feel as if it's helpful=20 > >> to provide clarifying text around this. > >> > >> Melinda > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From melinda.shore@gmail.com Wed Nov 27 16:02:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0AD1ADFF2 for ; Wed, 27 Nov 2013 16:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZgDXdmscOxhX for ; Wed, 27 Nov 2013 16:02:54 -0800 (PST) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 68E601A1EF9 for ; Wed, 27 Nov 2013 16:02:54 -0800 (PST) Received: by mail-pb0-f50.google.com with SMTP id rr13so11330567pbb.23 for ; Wed, 27 Nov 2013 16:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3h1CveJ6nE/9oA1qOWxnoCECBVSp35Tmm+heU/DzJ5g=; b=DzPt/afTl8YVGHBxB2CRWCMCZyRlwChXPxI0/GolkFFezJLWWQA0BPi2Iw6rciTAHk U961T+d9TFM4toRDyCn6/1d7xUBRYD11fPL1NqJQOGxh9Q4z0TsZuZMhum77xGLS3DEu mKjq+UQQG99xiL26ao8siO/cbtdLgdLkkeRhoSWj4glTEhMgQBfiXF4mMSr9VIKidN8y 2lznWLYvP375Y9Lq2g1aUUo/O98AbUg3js/KEb3NX3jJzcqsm59vcZ8c3/ZkQMVrvfC1 Q6rwVsaXm+i+gja8KLl5eRz75DyL51mqUpPqMQeWYvgPccglpXaXY2RBlHDcmkix6dDb 4QpA== X-Received: by 10.66.197.135 with SMTP id iu7mr19464187pac.149.1385596973875; Wed, 27 Nov 2013 16:02:53 -0800 (PST) Received: from spandex.local (63-140-92-49.dynamic.dsl.acsalaska.net. [63.140.92.49]) by mx.google.com with ESMTPSA id ik1sm63911675pbc.9.2013.11.27.16.02.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 16:02:52 -0800 (PST) Message-ID: <5296882A.6090502@gmail.com> Date: Wed, 27 Nov 2013 15:02:50 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kevin J Ma References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Ron Parker Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 00:02:55 -0000 On 11/27/13 11:03 AM, Kevin J Ma wrote: > My question was partially about whether it would always be the IP datagram, > or whether it could be an ethernet frame, or a TCP payload, or whether it > might be just the HTTP entity body. Where I think you've wandered into the weeds is that you appear to believe that the nsc "application" is going to receive the entire datagram, from the Ethernet (or whatever) frame up. Unless someone's written something *extremely* funky, as a rule encapsulations/headers/ etc. are not available to the services "above" them. That's certainly true for all modern operating systems (TCP does not see the Ethernet frame [or the IP datagram], and so on). Melinda From kevin.ma@azukisystems.com Wed Nov 27 16:44:45 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6C61AE067 for ; Wed, 27 Nov 2013 16:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0BF0m6Cbi54s for ; Wed, 27 Nov 2013 16:44:43 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id A7A021AE060 for ; Wed, 27 Nov 2013 16:44:43 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 0EC8B41686C; Wed, 27 Nov 2013 19:44:43 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 95B3641685C; Wed, 27 Nov 2013 19:44:42 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Wed, 27 Nov 2013 19:44:42 -0500 From: Kevin J Ma To: Melinda Shore Date: Wed, 27 Nov 2013 19:44:41 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rqtiagqqFxABgQYG+oBBAp4SztAAGJ4Qw Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB260@MAILR002.mail.lan> References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <52964928.50708@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1ED@MAILR002.mail.lan> <52964E8B.8060702@gmail.com> In-Reply-To: <52964E8B.8060702@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 00:44:45 -0000 Hi Melinda, > Can you give an example of the sort of thing you're concerned about? Sure, but this is unrelated to the charter text discussion. Ron and I had an offline discussion about my previous example: > --> FE_TLS --> RR --> AV --> LB --> BE_TLS --> > / \ ^ \ > / \ / \ > ---------+ +------+ +----------> where it would be desirable to have a single front-end TLS termination paired with a single back-end TLS connection, but with the ability for individual application layer multiplexed objects (e.g., a particular HTTP entity) to follow different service paths from RR to LB (e.g., not everything needs to go through AV). There are certainly many ways to skin this: individual connections and SFC paths for each object between RR and LB, or a single SFC path that sends everything through AV, or a completely non-SFC path between RR and LB. There are also various amounts of metadata that could be shared, e.g., FE_TLS flow id, application object id, internal flow id, etc. The question was about whether or not the encapsulation is taking into account the fact that many of the services listed in the problem statemen= t and use cases are actually application layer functions that often involve TCP termination and application layer message parsing, and are not themse= lves packet oriented, even though they have packet-based transport below them. thanx. -- Kevin J. Ma > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Wednesday, November 27, 2013 2:57 PM > To: Kevin J Ma > Cc: Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > On 11/27/13 10:48 AM, Kevin J Ma wrote: > > The original discussion stemmed from concerns that the initial set > > of documents only considered lower layer encapsulation, but did not > > consider the useability of such encapsulation by a higher layer > > service. Defining an encapsulation format that cannot be used by > > a large number of applications would be unfortunate. I don't feel > > that this is an unreasonable concern (though it may not be charter- > > worthy). >=20 > Can you give an example of the sort of thing you're concerned about? > I'm having a very difficult time envisioning a "higher-layer" service > even seeing the encapsulation. >=20 > Melinda From kevin.ma@azukisystems.com Wed Nov 27 16:45:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22801AE06A for ; Wed, 27 Nov 2013 16:45:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IHPZJEmoaVWc for ; Wed, 27 Nov 2013 16:45:39 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 277961AE069 for ; Wed, 27 Nov 2013 16:45:39 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 35BE47AFC53; Wed, 27 Nov 2013 19:45:29 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A05ED7AFC79; Wed, 27 Nov 2013 19:45:28 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 27 Nov 2013 19:45:28 -0500 From: Kevin J Ma To: Melinda Shore Date: Wed, 27 Nov 2013 19:45:27 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7rzTDnWRFaK+a2SliAGnPWZfdlqQABNCmg Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> In-Reply-To: <5296882A.6090502@gmail.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Ron Parker Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 00:45:41 -0000 Hi Melinda, > Unless someone's written something > *extremely* funky, as a rule encapsulations/headers/ > etc. are not available to the services "above" them. =20 Indeed. That is precisely the problem. If I have a service that runs above that encapsulation layer, (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.) how does that service know what chain it's in, and how does it indicate to the lower encapsulation layer what chain to send it back out on if reclassification occurs? -- Kevin J. Ma > -----Original Message----- > From: Melinda Shore [mailto:melinda.shore@gmail.com] > Sent: Wednesday, November 27, 2013 7:03 PM > To: Kevin J Ma > Cc: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org > Subject: Re: [nsc] Progress toward WG formation >=20 > On 11/27/13 11:03 AM, Kevin J Ma wrote: > > My question was partially about whether it would always be the IP > datagram, > > or whether it could be an ethernet frame, or a TCP payload, or whether > it > > might be just the HTTP entity body. >=20 > Where I think you've wandered into the weeds is that you > appear to believe that the nsc "application" is going to > receive the entire datagram, from the Ethernet (or > whatever) frame up. Unless someone's written something > *extremely* funky, as a rule encapsulations/headers/ > etc. are not available to the services "above" them. That's > certainly true for all modern operating systems (TCP > does not see the Ethernet frame [or the IP datagram], and > so on). >=20 > Melinda From melinda.shore@gmail.com Wed Nov 27 17:01:17 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63871AE070 for ; Wed, 27 Nov 2013 17:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WonY0bVjf4d for ; Wed, 27 Nov 2013 17:01:16 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2141AE069 for ; Wed, 27 Nov 2013 17:01:16 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so11550900pbc.12 for ; Wed, 27 Nov 2013 17:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=yDuwMsenz0Qo6YwfI48MHI6lRGg5xxeoP0fXMdztlHQ=; b=AKtm7mwXcvYE9LNjpcVacdUGeUE/1lajSEWaivo6oCfbK64o3MQ/4XaCAIoI6n9cEh ExolJPG82euHbvpRUvO49vt3ib2/n50o7Mloc+2hdnC1PRyNtlELEyYmx3yAUgIIwN+R yCXtVu5yg4gAdZF0bFHP4/or9Y3+fhIowFtLJEg9iWqBbgvO0MkvNiNHDiE+O5nHkdY7 zgDzIMmtt65Mgsk5KT9WCEePQ+AQM+eFXEr2IfWSdUwqGfZsm0NZcSse3jccZ78SGAO8 cWI4qUZbX6IsD7LF/c9jyWJ41SdtHM90iOWlx8apUAcVBUwE3syfs/qwzPSu1BmUjThR wGsA== X-Received: by 10.68.240.36 with SMTP id vx4mr7927606pbc.140.1385600475939; Wed, 27 Nov 2013 17:01:15 -0800 (PST) Received: from spandex.local (63-140-92-49.dynamic.dsl.acsalaska.net. [63.140.92.49]) by mx.google.com with ESMTPSA id ja5sm90398418pbc.14.2013.11.27.17.01.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Nov 2013 17:01:14 -0800 (PST) Message-ID: <529695D7.4060006@gmail.com> Date: Wed, 27 Nov 2013 16:01:11 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: nsc@ietf.org References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 01:01:17 -0000 On 11/27/13 3:45 PM, Kevin J Ma wrote: > If I have a service that runs above that encapsulation layer, > (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.) > how does that service know what chain it's in, and how does > it indicate to the lower encapsulation layer what chain to > send it back out on if reclassification occurs? >From NSC control traffic. It's surely not going to learn those things from an IP header, etc. Melinda From Ron_Parker@affirmednetworks.com Wed Nov 27 18:58:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743101AE0DE for ; Wed, 27 Nov 2013 18:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAe0Odgn6cuX for ; Wed, 27 Nov 2013 18:57:59 -0800 (PST) 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 D5F821A82E2 for ; Wed, 27 Nov 2013 18:57:59 -0800 (PST) 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.0158.001; Wed, 27 Nov 2013 18:57:58 -0800 From: Ron Parker To: Kevin J Ma Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmCAAM3tAIAAC+iA//+e6/0= Date: Thu, 28 Nov 2013 02:57:58 +0000 Message-ID: References: <52963740.5040304@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com>, <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 02:58:01 -0000 I don't think there is a strict prohibition on seeing data from lower layer= s. Even in a traditional user space application implementation there is li= mited capability to get lower layer information via sockopt and recvmsg. =20 Ron > On Nov 27, 2013, at 7:45 PM, "Kevin J Ma" wro= te: >=20 > Hi Melinda, >=20 >> Unless someone's written something >> *extremely* funky, as a rule encapsulations/headers/ >> etc. are not available to the services "above" them. =20 >=20 > Indeed. That is precisely the problem. >=20 > If I have a service that runs above that encapsulation layer, > (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.) > how does that service know what chain it's in, and how does > it indicate to the lower encapsulation layer what chain to > send it back out on if reclassification occurs? >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Melinda Shore [mailto:melinda.shore@gmail.com] >> Sent: Wednesday, November 27, 2013 7:03 PM >> To: Kevin J Ma >> Cc: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org >> Subject: Re: [nsc] Progress toward WG formation >>=20 >>> On 11/27/13 11:03 AM, Kevin J Ma wrote: >>> My question was partially about whether it would always be the IP >> datagram, >>> or whether it could be an ethernet frame, or a TCP payload, or whether >> it >>> might be just the HTTP entity body. >>=20 >> Where I think you've wandered into the weeds is that you >> appear to believe that the nsc "application" is going to >> receive the entire datagram, from the Ethernet (or >> whatever) frame up. Unless someone's written something >> *extremely* funky, as a rule encapsulations/headers/ >> etc. are not available to the services "above" them. That's >> certainly true for all modern operating systems (TCP >> does not see the Ethernet frame [or the IP datagram], and >> so on). >>=20 >> Melinda >=20 From diego@tid.es Thu Nov 28 01:15:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC351ADBCC for ; Thu, 28 Nov 2013 01:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 SOb3GWhM0uNP for ; Thu, 28 Nov 2013 01:15:01 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABE1AD845 for ; Thu, 28 Nov 2013 01:15:00 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MWY0068AV0Y6E@tid.hi.inet> for nsc@ietf.org; Thu, 28 Nov 2013 10:14:58 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 5B.46.03197.29907925; Thu, 28 Nov 2013 10:14:58 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MWY00681V0Y6E@tid.hi.inet> for nsc@ietf.org; Thu, 28 Nov 2013 10:14:58 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.96]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 10:14:58 +0100 Date: Thu, 28 Nov 2013 09:14:57 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Ron Parker Message-id: Content-id: <1B17305943F65244978652414D87DE3D@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: [nsc] Progress toward WG formation Thread-index: AQHO65zyB1gAFw69SQygXsQ56slOfZo5X/MAgAALEwCAAARxAIAAQuYAgAAL6ICAACUGAIAAaVaA X-AuditID: 0a5f4068-b7f3e8e000000c7d-00-52970992e00e X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhinfg0p3EOT3IYNYnHYvj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/v9TcwFa5QrTs/YytTAuEOpi5GTQ0LARGLWxGusELaYxIV7 69m6GLk4hAQOMEp8ffSXCcL5yihxZ/drRghnA6PE3OV32UFaWARUJbZuWM8EYrMB2Y+af4PF hQX0JTZPuMnSxcjBwSngIbH9YjnEBgWJP+ces4DYIgIGEq8/n2IFmckssIxR4vPO72BzeAUs JR7OfAxmMwuYSWw41M8MEReU+DH5HthMZgF1iSlTciFKxCWaW2+yQNiKEtMWNTCC2IwCshLv 5s9nhdl1sGETlB0j8ab1OSPEPQISS/acZ4awRSVePv7HCvHjKmaJlsY1rBMYJWYhOWMWkjNm IZwxC8kZs5CcsYCRdRWjWHFSUWZ6RkluYmZOuoGhXkamXmZeaskmRkjcZexgXL5T5RCjAAej Eg/vBfNpQUKsiWXFlbmHGCU4mJVEeJs5pgcJ8aYkVlalFuXHF5XmpBYfYmTi4JRqYOSwZnr7 xn7afZbyE+H6m6ZFpz2zk2sz92FINst//zbhjNi32u7jh/OjZmptqjRfHrt+6+XctNrHuROX 7jq/cIZGTcONCNuwgiWbZIs/Nk9XSWCdl/9d2Ol/5ykJtrsx6azzxCSWpd7WW+W4TznnSJTQ 3+eXffIOTX65J7O3+p3j1I0lspdYdiuxFGckGmoxFxUnAgCYS+1HmQIAAA== References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 09:15:03 -0000 SW5kZWVkLiBJbiBhIHR5cGljYWwgSFRUUCBhcHBsaWNhdGlvbiBzY2VuYXJpbywgeW91IGhhdmUg YnkgZGVmYXVsdCBhY2Nlc3MgdG8gbG9jYWwgYW5kIHJlbW90ZSBJUCBhZGRyZXNzZXMsIFRDUCBw b3J0IG51bWJlcnMsIFRMUyBpZGVudGl0eSBwYXJhbWV0ZXJzLCBhbmQgcHJvY2VzcyBlbnZpcm9u bWVudCB2YXJpYWJsZXMsIHRvIG5hbWUgdGhlIGVzc2VudGlhbCBvbmVzLiBJIHRoaW5rIGl0IHdv dWxkIGJlIHJlYXNvbmFibGUgdG8gZXhwZWN0IHRoYXQgYSBTRkMgbW9kdWxlIChub3QgdG8gdXNl IHRoZSBhY2N1cnNlZCAibGF5ZXIiOiBJIGZ1bGx5IGFncmVlIHdpdGggTWVsaW5kYSdzIHByZXZp b3VzIHN0YXRlbWVudCBvbiB0aGUgbGF5ZXJpbmcgY29uZnVzaW9uKSB3b3VsZCBiZSBhYmxlIHRv IGV4cG9zZSBzb21lIGluZm9ybWF0aW9uIG9uIGl0cyBtZXRhZGF0YS4gQW55d2F5LCB0aGF0IHNo b3VsZCBiZSBhIGRlc2lnbiBkZWNpc2lvbiBhbmQgY2VydGFpbmx5IG91dCBvZiBzY29wZSBmb3Ig dGhpcyBncm91cC4NCg0KQmUgZ29vZGUsDQoNCk9uIDI4IE5vdiAyMDEzLCBhdCAwMzo1NyAsIFJv biBQYXJrZXIgd3JvdGU6DQoNCj4gSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHN0cmljdCBwcm9o aWJpdGlvbiBvbiBzZWVpbmcgZGF0YSBmcm9tIGxvd2VyIGxheWVycy4gIEV2ZW4gaW4gYSB0cmFk aXRpb25hbCB1c2VyIHNwYWNlIGFwcGxpY2F0aW9uIGltcGxlbWVudGF0aW9uIHRoZXJlIGlzIGxp bWl0ZWQgY2FwYWJpbGl0eSB0byBnZXQgbG93ZXIgbGF5ZXIgaW5mb3JtYXRpb24gdmlhIHNvY2tv cHQgYW5kIHJlY3Ztc2cuDQo+DQo+ICAgIFJvbg0KPg0KPg0KPj4gT24gTm92IDI3LCAyMDEzLCBh dCA3OjQ1IFBNLCAiS2V2aW4gSiBNYSIgPGtldmluLm1hQGF6dWtpc3lzdGVtcy5jb20+IHdyb3Rl Og0KPj4NCj4+IEhpIE1lbGluZGEsDQo+Pg0KPj4+IFVubGVzcyBzb21lb25lJ3Mgd3JpdHRlbiBz b21ldGhpbmcNCj4+PiAqZXh0cmVtZWx5KiBmdW5reSwgYXMgYSBydWxlIGVuY2Fwc3VsYXRpb25z L2hlYWRlcnMvDQo+Pj4gZXRjLiBhcmUgbm90IGF2YWlsYWJsZSB0byB0aGUgc2VydmljZXMgImFi b3ZlIiB0aGVtLg0KPj4NCj4+IEluZGVlZC4gIFRoYXQgaXMgcHJlY2lzZWx5IHRoZSBwcm9ibGVt Lg0KPj4NCj4+IElmIEkgaGF2ZSBhIHNlcnZpY2UgdGhhdCBydW5zIGFib3ZlIHRoYXQgZW5jYXBz dWxhdGlvbiBsYXllciwNCj4+IChlLmcuLCBhbiBIVFRQIGxvYWQgYmFsYW5jZXIsIEFWIFNjYW5u ZXIsIFZpZGVvIE9wdGltaXplciwgZXRjLikNCj4+IGhvdyBkb2VzIHRoYXQgc2VydmljZSBrbm93 IHdoYXQgY2hhaW4gaXQncyBpbiwgYW5kIGhvdyBkb2VzDQo+PiBpdCBpbmRpY2F0ZSB0byB0aGUg bG93ZXIgZW5jYXBzdWxhdGlvbiBsYXllciB3aGF0IGNoYWluIHRvDQo+PiBzZW5kIGl0IGJhY2sg b3V0IG9uIGlmIHJlY2xhc3NpZmljYXRpb24gb2NjdXJzPw0KPj4NCj4+IC0tICBLZXZpbiBKLiBN YQ0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+IEZyb206IE1lbGluZGEg U2hvcmUgW21haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbV0NCj4+PiBTZW50OiBXZWRuZXNk YXksIE5vdmVtYmVyIDI3LCAyMDEzIDc6MDMgUE0NCj4+PiBUbzogS2V2aW4gSiBNYQ0KPj4+IENj OiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWljaGFyKTsgbnNjQGlldGYub3JnDQo+Pj4g U3ViamVjdDogUmU6IFtuc2NdIFByb2dyZXNzIHRvd2FyZCBXRyBmb3JtYXRpb24NCj4+Pg0KPj4+ PiBPbiAxMS8yNy8xMyAxMTowMyBBTSwgS2V2aW4gSiBNYSB3cm90ZToNCj4+Pj4gTXkgcXVlc3Rp b24gd2FzIHBhcnRpYWxseSBhYm91dCB3aGV0aGVyIGl0IHdvdWxkIGFsd2F5cyBiZSB0aGUgSVAN Cj4+PiBkYXRhZ3JhbSwNCj4+Pj4gb3Igd2hldGhlciBpdCBjb3VsZCBiZSBhbiBldGhlcm5ldCBm cmFtZSwgb3IgYSBUQ1AgcGF5bG9hZCwgb3Igd2hldGhlcg0KPj4+IGl0DQo+Pj4+IG1pZ2h0IGJl IGp1c3QgdGhlIEhUVFAgZW50aXR5IGJvZHkuDQo+Pj4NCj4+PiBXaGVyZSBJIHRoaW5rIHlvdSd2 ZSB3YW5kZXJlZCBpbnRvIHRoZSB3ZWVkcyBpcyB0aGF0IHlvdQ0KPj4+IGFwcGVhciB0byBiZWxp ZXZlIHRoYXQgdGhlIG5zYyAiYXBwbGljYXRpb24iIGlzIGdvaW5nIHRvDQo+Pj4gcmVjZWl2ZSB0 aGUgZW50aXJlIGRhdGFncmFtLCBmcm9tIHRoZSBFdGhlcm5ldCAob3INCj4+PiB3aGF0ZXZlcikg ZnJhbWUgdXAuICBVbmxlc3Mgc29tZW9uZSdzIHdyaXR0ZW4gc29tZXRoaW5nDQo+Pj4gKmV4dHJl bWVseSogZnVua3ksIGFzIGEgcnVsZSBlbmNhcHN1bGF0aW9ucy9oZWFkZXJzLw0KPj4+IGV0Yy4g YXJlIG5vdCBhdmFpbGFibGUgdG8gdGhlIHNlcnZpY2VzICJhYm92ZSIgdGhlbS4gIFRoYXQncw0K Pj4+IGNlcnRhaW5seSB0cnVlIGZvciBhbGwgbW9kZXJuIG9wZXJhdGluZyBzeXN0ZW1zIChUQ1AN Cj4+PiBkb2VzIG5vdCBzZWUgdGhlIEV0aGVybmV0IGZyYW1lIFtvciB0aGUgSVAgZGF0YWdyYW1d LCBhbmQNCj4+PiBzbyBvbikuDQo+Pj4NCj4+PiBNZWxpbmRhDQo+Pg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2MgbWFpbGluZyBsaXN0DQo+ IG5zY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25z Yw0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpE ciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2Rp ZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAw NDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVz dGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1 ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRl IGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRo aXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ug b25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0 IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From kevin.ma@azukisystems.com Thu Nov 28 07:09:52 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5EE1AE16D for ; Thu, 28 Nov 2013 07:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 lU8cOrse2zPv for ; Thu, 28 Nov 2013 07:09:50 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id C91951AE169 for ; Thu, 28 Nov 2013 07:09:49 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 19A7855653C; Thu, 28 Nov 2013 10:08:46 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 28FEF556519; Thu, 28 Nov 2013 10:08:45 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Thu, 28 Nov 2013 10:08:44 -0500 From: Kevin J Ma To: "Diego R. Lopez" , Ron Parker Date: Thu, 28 Nov 2013 10:08:43 -0500 Thread-Topic: [nsc] Progress toward WG formation Thread-Index: AQHO65zyB1gAFw69SQygXsQ56slOfZo5X/MAgAALEwCAAARxAIAAQuYAgAAL6ICAACUGAIAAaVaAgABvvLA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 15:09:52 -0000 SGkgUm9uL0RpZWdvLA0KDQogIENlcnRhaW5seSB0aGVyZSBhcmUgd2F5cyB0byBpbXBsZW1lbnQg aXQsIGJ1dCBhZ2FpbiwgbXkgb3JpZ2luYWwgcXVlc3Rpb24NCiAgd2FzIHNpbXBseTogaXMgdGhp cyBkaXNjdXNzaW9uIGluIG9yIG91dCBvZiBzY29wZT8gIEFuZCBJIHRoaW5rIHRoZSBzaW1wbGUN CiAgYW5zd2VyIHdhcy9pcyBuby4NCg0KdGhhbnguDQoNCi0tICBLZXZpbiBKLiBNYQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERpZWdvIFIuIExvcGV6IFttYWlsdG86 ZGllZ29AdGlkLmVzXQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMjgsIDIwMTMgNDoxNSBB TQ0KPiBUbzogUm9uIFBhcmtlcg0KPiBDYzogS2V2aW4gSiBNYTsgbnNjQGlldGYub3JnOyBKaW0g R3VpY2hhcmQgKGpndWljaGFyKTsgTWVsaW5kYSBTaG9yZQ0KPiBTdWJqZWN0OiBSZTogW25zY10g UHJvZ3Jlc3MgdG93YXJkIFdHIGZvcm1hdGlvbg0KPiANCj4gSW5kZWVkLiBJbiBhIHR5cGljYWwg SFRUUCBhcHBsaWNhdGlvbiBzY2VuYXJpbywgeW91IGhhdmUgYnkgZGVmYXVsdCBhY2Nlc3MNCj4g dG8gbG9jYWwgYW5kIHJlbW90ZSBJUCBhZGRyZXNzZXMsIFRDUCBwb3J0IG51bWJlcnMsIFRMUyBp ZGVudGl0eQ0KPiBwYXJhbWV0ZXJzLCBhbmQgcHJvY2VzcyBlbnZpcm9ubWVudCB2YXJpYWJsZXMs IHRvIG5hbWUgdGhlIGVzc2VudGlhbCBvbmVzLg0KPiBJIHRoaW5rIGl0IHdvdWxkIGJlIHJlYXNv bmFibGUgdG8gZXhwZWN0IHRoYXQgYSBTRkMgbW9kdWxlIChub3QgdG8gdXNlIHRoZQ0KPiBhY2N1 cnNlZCAibGF5ZXIiOiBJIGZ1bGx5IGFncmVlIHdpdGggTWVsaW5kYSdzIHByZXZpb3VzIHN0YXRl bWVudCBvbiB0aGUNCj4gbGF5ZXJpbmcgY29uZnVzaW9uKSB3b3VsZCBiZSBhYmxlIHRvIGV4cG9z ZSBzb21lIGluZm9ybWF0aW9uIG9uIGl0cw0KPiBtZXRhZGF0YS4gQW55d2F5LCB0aGF0IHNob3Vs ZCBiZSBhIGRlc2lnbiBkZWNpc2lvbiBhbmQgY2VydGFpbmx5IG91dCBvZg0KPiBzY29wZSBmb3Ig dGhpcyBncm91cC4NCj4gDQo+IEJlIGdvb2RlLA0KPiANCj4gT24gMjggTm92IDIwMTMsIGF0IDAz OjU3ICwgUm9uIFBhcmtlciB3cm90ZToNCj4gDQo+ID4gSSBkb24ndCB0aGluayB0aGVyZSBpcyBh IHN0cmljdCBwcm9oaWJpdGlvbiBvbiBzZWVpbmcgZGF0YSBmcm9tIGxvd2VyDQo+IGxheWVycy4g IEV2ZW4gaW4gYSB0cmFkaXRpb25hbCB1c2VyIHNwYWNlIGFwcGxpY2F0aW9uIGltcGxlbWVudGF0 aW9uIHRoZXJlDQo+IGlzIGxpbWl0ZWQgY2FwYWJpbGl0eSB0byBnZXQgbG93ZXIgbGF5ZXIgaW5m b3JtYXRpb24gdmlhIHNvY2tvcHQgYW5kDQo+IHJlY3Ztc2cuDQo+ID4NCj4gPiAgICBSb24NCj4g Pg0KPiA+DQo+ID4+IE9uIE5vdiAyNywgMjAxMywgYXQgNzo0NSBQTSwgIktldmluIEogTWEiIDxr ZXZpbi5tYUBhenVraXN5c3RlbXMuY29tPg0KPiB3cm90ZToNCj4gPj4NCj4gPj4gSGkgTWVsaW5k YSwNCj4gPj4NCj4gPj4+IFVubGVzcyBzb21lb25lJ3Mgd3JpdHRlbiBzb21ldGhpbmcNCj4gPj4+ ICpleHRyZW1lbHkqIGZ1bmt5LCBhcyBhIHJ1bGUgZW5jYXBzdWxhdGlvbnMvaGVhZGVycy8NCj4g Pj4+IGV0Yy4gYXJlIG5vdCBhdmFpbGFibGUgdG8gdGhlIHNlcnZpY2VzICJhYm92ZSIgdGhlbS4N Cj4gPj4NCj4gPj4gSW5kZWVkLiAgVGhhdCBpcyBwcmVjaXNlbHkgdGhlIHByb2JsZW0uDQo+ID4+ DQo+ID4+IElmIEkgaGF2ZSBhIHNlcnZpY2UgdGhhdCBydW5zIGFib3ZlIHRoYXQgZW5jYXBzdWxh dGlvbiBsYXllciwNCj4gPj4gKGUuZy4sIGFuIEhUVFAgbG9hZCBiYWxhbmNlciwgQVYgU2Nhbm5l ciwgVmlkZW8gT3B0aW1pemVyLCBldGMuKQ0KPiA+PiBob3cgZG9lcyB0aGF0IHNlcnZpY2Uga25v dyB3aGF0IGNoYWluIGl0J3MgaW4sIGFuZCBob3cgZG9lcw0KPiA+PiBpdCBpbmRpY2F0ZSB0byB0 aGUgbG93ZXIgZW5jYXBzdWxhdGlvbiBsYXllciB3aGF0IGNoYWluIHRvDQo+ID4+IHNlbmQgaXQg YmFjayBvdXQgb24gaWYgcmVjbGFzc2lmaWNhdGlvbiBvY2N1cnM/DQo+ID4+DQo+ID4+IC0tICBL ZXZpbiBKLiBNYQ0KPiA+Pg0KPiA+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4+ IEZyb206IE1lbGluZGEgU2hvcmUgW21haWx0bzptZWxpbmRhLnNob3JlQGdtYWlsLmNvbV0NCj4g Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMjcsIDIwMTMgNzowMyBQTQ0KPiA+Pj4gVG86 IEtldmluIEogTWENCj4gPj4+IENjOiBSb24gUGFya2VyOyBKaW0gR3VpY2hhcmQgKGpndWljaGFy KTsgbnNjQGlldGYub3JnDQo+ID4+PiBTdWJqZWN0OiBSZTogW25zY10gUHJvZ3Jlc3MgdG93YXJk IFdHIGZvcm1hdGlvbg0KPiA+Pj4NCj4gPj4+PiBPbiAxMS8yNy8xMyAxMTowMyBBTSwgS2V2aW4g SiBNYSB3cm90ZToNCj4gPj4+PiBNeSBxdWVzdGlvbiB3YXMgcGFydGlhbGx5IGFib3V0IHdoZXRo ZXIgaXQgd291bGQgYWx3YXlzIGJlIHRoZSBJUA0KPiA+Pj4gZGF0YWdyYW0sDQo+ID4+Pj4gb3Ig d2hldGhlciBpdCBjb3VsZCBiZSBhbiBldGhlcm5ldCBmcmFtZSwgb3IgYSBUQ1AgcGF5bG9hZCwg b3INCj4gd2hldGhlcg0KPiA+Pj4gaXQNCj4gPj4+PiBtaWdodCBiZSBqdXN0IHRoZSBIVFRQIGVu dGl0eSBib2R5Lg0KPiA+Pj4NCj4gPj4+IFdoZXJlIEkgdGhpbmsgeW91J3ZlIHdhbmRlcmVkIGlu dG8gdGhlIHdlZWRzIGlzIHRoYXQgeW91DQo+ID4+PiBhcHBlYXIgdG8gYmVsaWV2ZSB0aGF0IHRo ZSBuc2MgImFwcGxpY2F0aW9uIiBpcyBnb2luZyB0bw0KPiA+Pj4gcmVjZWl2ZSB0aGUgZW50aXJl IGRhdGFncmFtLCBmcm9tIHRoZSBFdGhlcm5ldCAob3INCj4gPj4+IHdoYXRldmVyKSBmcmFtZSB1 cC4gIFVubGVzcyBzb21lb25lJ3Mgd3JpdHRlbiBzb21ldGhpbmcNCj4gPj4+ICpleHRyZW1lbHkq IGZ1bmt5LCBhcyBhIHJ1bGUgZW5jYXBzdWxhdGlvbnMvaGVhZGVycy8NCj4gPj4+IGV0Yy4gYXJl IG5vdCBhdmFpbGFibGUgdG8gdGhlIHNlcnZpY2VzICJhYm92ZSIgdGhlbS4gIFRoYXQncw0KPiA+ Pj4gY2VydGFpbmx5IHRydWUgZm9yIGFsbCBtb2Rlcm4gb3BlcmF0aW5nIHN5c3RlbXMgKFRDUA0K PiA+Pj4gZG9lcyBub3Qgc2VlIHRoZSBFdGhlcm5ldCBmcmFtZSBbb3IgdGhlIElQIGRhdGFncmFt XSwgYW5kDQo+ID4+PiBzbyBvbikuDQo+ID4+Pg0KPiA+Pj4gTWVsaW5kYQ0KPiA+Pg0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbnNjIG1h aWxpbmcgbGlzdA0KPiA+IG5zY0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbnNjDQo+IA0KPiANCj4gLS0NCj4gIkVzdGEgdmV6IG5vIGZhbGxhcmVt b3MsIERvY3RvciBJbmZpZXJubyINCj4gDQo+IERyIERpZWdvIFIuIExvcGV6DQo+IFRlbGVmb25p Y2EgSStEDQo+IGh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KPiANCj4gZS1tYWls OiBkaWVnb0B0aWQuZXMNCj4gVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCj4gTW9iaWxlOiArMzQg NjgyIDA1MSAwOTENCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gRXN0ZSBt ZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUg Y29uc3VsdGFyDQo+IG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUg Y29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2UNCj4gc2l0dWFkbyBtw6FzIGFiYWpvLg0K PiBUaGlzIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUu IFdlIG9ubHkgc2VuZCBhbmQNCj4gcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRl cm1zIHNldCBvdXQgYXQ6DQo+IGh0dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1l ci5hc3B4DQo= From diego@tid.es Thu Nov 28 07:21:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFC81AE155 for ; Thu, 28 Nov 2013 07:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kQj6f2J1cY-G for ; Thu, 28 Nov 2013 07:21:30 -0800 (PST) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 230601AE08E for ; Thu, 28 Nov 2013 07:21:30 -0800 (PST) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MWZ008AOBZS61@tid.hi.inet> for nsc@ietf.org; Thu, 28 Nov 2013 16:21:28 +0100 (MET) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id 25.83.03314.87F57925; Thu, 28 Nov 2013 16:21:28 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MWZ008AHBZS61@tid.hi.inet> for nsc@ietf.org; Thu, 28 Nov 2013 16:21:28 +0100 (MET) Received: from EX10-MB1-MAD.hi.inet ([169.254.1.96]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0158.001; Thu, 28 Nov 2013 16:21:28 +0100 Date: Thu, 28 Nov 2013 15:21:27 +0000 From: "Diego R. Lopez" In-reply-to: <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> X-Originating-IP: [10.95.64.115] To: Kevin J Ma Message-id: <9D68893D-2DC7-466A-9525-C444A54A0FD7@tid.es> Content-id: <31EED929F35A4B4C9AEEED2D1E0ADC61@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [nsc] Progress toward WG formation Thread-index: AQHO65zyB1gAFw69SQygXsQ56slOfZo5X/MAgAALEwCAAARxAIAAQuYAgAAL6ICAACUGAIAAaVaAgABvvLD///apAA== X-AuditID: 0a5f4068-b7fe58e000000cf2-7f-52975f7895f4 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhinfg0q2Inx5ksLpf1+L4vv1sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOL6pjbXggWrF7KWX2RoY98t1MXJwSAiYSEzebNDFyAlkiklc uLeerYuRi0NI4ACjxMK726Ccr4wS388tYoVwpjFKtLZNZwdpYRFQlVg/5Q8biM0GZD9q/g0W FxbQl9g84SYLyAZOAW+JVVt4IDYoSPw595gFxBYR0JJon7eYEWQms8AaRon1u6cwgyR4BSwl Xl2cCDaTWcBM4tSirWwQcUGJH5PvsUDEdSR6v39jhrDFJZpbb0LFtSWevLvACmIzCshKvJs/ nxVimYHEwYZNUHaOxOXfOxkhDhKQWLLnPDOELSrx8vE/qCdns0j0f97JOIFRYhaSO2YhuWMW kjtmIbljFpI7FjCyrmIUK04qykzPKMlNzMxJNzDUy8jUy8xLLdnECIm8jB2My3eqHGIU4GBU 4uG9YD4tSIg1say4MvcQowQHs5IIr0Xo9CAh3pTEyqrUovz4otKc1OJDjEwcnFINjKpxmxsd Jj6ubAp15l5/v1ytT8G9KufKxQobJf7O8EuTnR0Ur/um5dw+liQmIuFsesSFcX31jGdhnSr1 qkx/XZaX9b8Xm9aywaNy5d8TNxo35wWctK18c+Rp2j2Gg4/cdk9s/8EgHHd5QuTOt3ceqs2K W/vQ9ctc4e/9p/wdN+2pOFLge/VphRJLcUaioRZzUXEiANZQN7maAgAA References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore , Ron Parker Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 28 Nov 2013 15:21:32 -0000 Yes! I mean, I agree in that the simple answer is "no"... Be goode, On 28 Nov 2013, at 16:08 , Kevin J Ma wrote: > Hi Ron/Diego, > > Certainly there are ways to implement it, but again, my original questio= n > was simply: is this discussion in or out of scope? And I think the simp= le > answer was/is no. > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: Diego R. Lopez [mailto:diego@tid.es] >> Sent: Thursday, November 28, 2013 4:15 AM >> To: Ron Parker >> Cc: Kevin J Ma; nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore >> Subject: Re: [nsc] Progress toward WG formation >> >> Indeed. In a typical HTTP application scenario, you have by default acce= ss >> to local and remote IP addresses, TCP port numbers, TLS identity >> parameters, and process environment variables, to name the essential one= s. >> I think it would be reasonable to expect that a SFC module (not to use t= he >> accursed "layer": I fully agree with Melinda's previous statement on the >> layering confusion) would be able to expose some information on its >> metadata. Anyway, that should be a design decision and certainly out of >> scope for this group. >> >> Be goode, >> >> On 28 Nov 2013, at 03:57 , Ron Parker wrote: >> >>> I don't think there is a strict prohibition on seeing data from lower >> layers. Even in a traditional user space application implementation the= re >> is limited capability to get lower layer information via sockopt and >> recvmsg. >>> >>> Ron >>> >>> >>>> On Nov 27, 2013, at 7:45 PM, "Kevin J Ma" >> wrote: >>>> >>>> Hi Melinda, >>>> >>>>> Unless someone's written something >>>>> *extremely* funky, as a rule encapsulations/headers/ >>>>> etc. are not available to the services "above" them. >>>> >>>> Indeed. That is precisely the problem. >>>> >>>> If I have a service that runs above that encapsulation layer, >>>> (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.) >>>> how does that service know what chain it's in, and how does >>>> it indicate to the lower encapsulation layer what chain to >>>> send it back out on if reclassification occurs? >>>> >>>> -- Kevin J. Ma >>>> >>>>> -----Original Message----- >>>>> From: Melinda Shore [mailto:melinda.shore@gmail.com] >>>>> Sent: Wednesday, November 27, 2013 7:03 PM >>>>> To: Kevin J Ma >>>>> Cc: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org >>>>> Subject: Re: [nsc] Progress toward WG formation >>>>> >>>>>> On 11/27/13 11:03 AM, Kevin J Ma wrote: >>>>>> My question was partially about whether it would always be the IP >>>>> datagram, >>>>>> or whether it could be an ethernet frame, or a TCP payload, or >> whether >>>>> it >>>>>> might be just the HTTP entity body. >>>>> >>>>> Where I think you've wandered into the weeds is that you >>>>> appear to believe that the nsc "application" is going to >>>>> receive the entire datagram, from the Ethernet (or >>>>> whatever) frame up. Unless someone's written something >>>>> *extremely* funky, as a rule encapsulations/headers/ >>>>> etc. are not available to the services "above" them. That's >>>>> certainly true for all modern operating systems (TCP >>>>> does not see the Ethernet frame [or the IP datagram], and >>>>> so on). >>>>> >>>>> Melinda >>>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >> >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx -- "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 Ron_Parker@affirmednetworks.com Fri Nov 29 09:15:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CFA1ADDAF for ; Fri, 29 Nov 2013 09:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlfkVaBmewJc for ; Fri, 29 Nov 2013 09:14:58 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC3B1ACC8A for ; Fri, 29 Nov 2013 09:14:58 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 09:14:56 -0800 From: Ron Parker To: Kevin J Ma , "Diego R. Lopez" Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmCAAM3tAIAAC+iA//+e6/2AAO9wgIAAYteAgAEsV4E= Date: Fri, 29 Nov 2013 17:14:55 +0000 Message-ID: References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.174.120.126] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , Melinda Shore Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 17:15:00 -0000 As Kevin mentioned, he and I had an offline discussion on this topic and I'= d like to summarize for the group what we discussed. =0A= =0A= The issue at hand is whether the SFC architecture will include those servic= e functions that operate sub-5-tuple, at the transaction level. Take, for= example, HTTP2.0 where an HTTP2.0 aware service function/classifier may ch= oose to send some transactions on one chain and others on another. Since = these transactions were separated out from a common five-tuple, in practica= l terms, all of those transaction-level chains would need to return back to= the original service function (which perhaps is represented as two distrin= ct service functions -- front-half and back half. =0A= =0A= Kevin's basic question is whether the SFC architecture supports this type o= f functionality and my view is categorically, yes. In fact 5-tuple aware = and transaction aware decision making is one of the prime advantages over e= xisting physical or VLAN-based chaining.=0A= =0A= Clearly, there are additional complexities to do this (i.e., what is the fu= ll encapsulation stackup for those packets that represent a subset of the o= riginal 5-tuple?). As a group we would need to decide what, if any, of th= at complexity was pushed down into the SFC capability set or whether that c= omplexity remains solely within the domain of the affected service function= s (i.e., do those service functions that are chained after the HTTP2.0-awar= e classifier need to implicitly know that they are indeed participating in = such a scenario?).=0A= =0A= Ron=0A= =0A= =0A= ________________________________________=0A= From: Kevin J Ma [kevin.ma@azukisystems.com]=0A= Sent: Thursday, November 28, 2013 10:08 AM=0A= To: Diego R. Lopez; Ron Parker=0A= Cc: nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore=0A= Subject: RE: [nsc] Progress toward WG formation=0A= =0A= Hi Ron/Diego,=0A= =0A= Certainly there are ways to implement it, but again, my original question= =0A= was simply: is this discussion in or out of scope? And I think the simpl= e=0A= answer was/is no.=0A= =0A= thanx.=0A= =0A= -- Kevin J. Ma=0A= =0A= > -----Original Message-----=0A= > From: Diego R. Lopez [mailto:diego@tid.es]=0A= > Sent: Thursday, November 28, 2013 4:15 AM=0A= > To: Ron Parker=0A= > Cc: Kevin J Ma; nsc@ietf.org; Jim Guichard (jguichar); Melinda Shore=0A= > Subject: Re: [nsc] Progress toward WG formation=0A= >=0A= > Indeed. In a typical HTTP application scenario, you have by default acces= s=0A= > to local and remote IP addresses, TCP port numbers, TLS identity=0A= > parameters, and process environment variables, to name the essential ones= .=0A= > I think it would be reasonable to expect that a SFC module (not to use th= e=0A= > accursed "layer": I fully agree with Melinda's previous statement on the= =0A= > layering confusion) would be able to expose some information on its=0A= > metadata. Anyway, that should be a design decision and certainly out of= =0A= > scope for this group.=0A= >=0A= > Be goode,=0A= >=0A= > On 28 Nov 2013, at 03:57 , Ron Parker wrote:=0A= >=0A= > > I don't think there is a strict prohibition on seeing data from lower= =0A= > layers. Even in a traditional user space application implementation ther= e=0A= > is limited capability to get lower layer information via sockopt and=0A= > recvmsg.=0A= > >=0A= > > Ron=0A= > >=0A= > >=0A= > >> On Nov 27, 2013, at 7:45 PM, "Kevin J Ma" = =0A= > wrote:=0A= > >>=0A= > >> Hi Melinda,=0A= > >>=0A= > >>> Unless someone's written something=0A= > >>> *extremely* funky, as a rule encapsulations/headers/=0A= > >>> etc. are not available to the services "above" them.=0A= > >>=0A= > >> Indeed. That is precisely the problem.=0A= > >>=0A= > >> If I have a service that runs above that encapsulation layer,=0A= > >> (e.g., an HTTP load balancer, AV Scanner, Video Optimizer, etc.)=0A= > >> how does that service know what chain it's in, and how does=0A= > >> it indicate to the lower encapsulation layer what chain to=0A= > >> send it back out on if reclassification occurs?=0A= > >>=0A= > >> -- Kevin J. Ma=0A= > >>=0A= > >>> -----Original Message-----=0A= > >>> From: Melinda Shore [mailto:melinda.shore@gmail.com]=0A= > >>> Sent: Wednesday, November 27, 2013 7:03 PM=0A= > >>> To: Kevin J Ma=0A= > >>> Cc: Ron Parker; Jim Guichard (jguichar); nsc@ietf.org=0A= > >>> Subject: Re: [nsc] Progress toward WG formation=0A= > >>>=0A= > >>>> On 11/27/13 11:03 AM, Kevin J Ma wrote:=0A= > >>>> My question was partially about whether it would always be the IP=0A= > >>> datagram,=0A= > >>>> or whether it could be an ethernet frame, or a TCP payload, or=0A= > whether=0A= > >>> it=0A= > >>>> might be just the HTTP entity body.=0A= > >>>=0A= > >>> Where I think you've wandered into the weeds is that you=0A= > >>> appear to believe that the nsc "application" is going to=0A= > >>> receive the entire datagram, from the Ethernet (or=0A= > >>> whatever) frame up. Unless someone's written something=0A= > >>> *extremely* funky, as a rule encapsulations/headers/=0A= > >>> etc. are not available to the services "above" them. That's=0A= > >>> certainly true for all modern operating systems (TCP=0A= > >>> does not see the Ethernet frame [or the IP datagram], and=0A= > >>> so on).=0A= > >>>=0A= > >>> Melinda=0A= > >>=0A= > > _______________________________________________=0A= > > nsc mailing list=0A= > > nsc@ietf.org=0A= > > https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= >=0A= > --=0A= > "Esta vez no fallaremos, Doctor Infierno"=0A= >=0A= > Dr Diego R. Lopez=0A= > Telefonica I+D=0A= > http://people.tid.es/diego.lopez/=0A= >=0A= > e-mail: diego@tid.es=0A= > Tel: +34 913 129 041=0A= > Mobile: +34 682 051 091=0A= > -----------------------------------------=0A= >=0A= >=0A= > ________________________________=0A= >=0A= > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar= =0A= > nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el= enlace=0A= > situado m=E1s abajo.=0A= > This message is intended exclusively for its addressee. We only send and= =0A= > receive email on the basis of the terms set out at:=0A= > http://www.tid.es/ES/PAGINAS/disclaimer.aspx=0A= From melinda.shore@gmail.com Fri Nov 29 11:15:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D141ADE88 for ; Fri, 29 Nov 2013 11:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNPjPih0igVb for ; Fri, 29 Nov 2013 11:15:53 -0800 (PST) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C2B9E1ADD9D for ; Fri, 29 Nov 2013 11:15:53 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rp16so14973660pbb.32 for ; Fri, 29 Nov 2013 11:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qNTugX6UbtsdyW3njOhutxKWJ6cRR95d8QbtEURTOd8=; b=Ezz0wXLHZ2Fn6RI1BFitYsmmoWY+QitEfnL+MRwL3AxkSYeheBDE9KqfLjz+W4SHi8 EnpSyW8qkPqbmzQgEnNbjbA+C4If9EWKm2oPsUX//iVp9Nz/BxQMeAa1TUBlSFbDPYK9 McCBcWRd9aYKwCG3ce2h7pdN0XvmNRQKxTgmbGjboFVU6tuzDm7QJYxjwXiIyLwg1YiB hjYez5dDtYVL9ao7Eo2HT5KMteoMtzRwaZvCCqK5BDvGiSdOYf4L5/M0sIeQznDpreJe PzjzmZI5bokjQIoQcjph1W+hwoatpa9/qtne1wxI2h7CVM21DgYbQJlg8f19/uzONk0E BDZA== X-Received: by 10.67.14.67 with SMTP id fe3mr29548796pad.134.1385752552522; Fri, 29 Nov 2013 11:15:52 -0800 (PST) Received: from spandex.local (216-67-70-82-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.70.82]) by mx.google.com with ESMTPSA id jn12sm62496106pbd.37.2013.11.29.11.15.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 11:15:51 -0800 (PST) Message-ID: <5298E7E3.9020901@gmail.com> Date: Fri, 29 Nov 2013 10:15:47 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ron Parker References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Diego R. Lopez" , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 19:15:55 -0000 On 11/29/13 8:14 AM, Ron Parker wrote: > Kevin's basic question is whether the SFC architecture supports this > type of functionality and my view is categorically, yes. In fact > 5-tuple aware and transaction aware decision making is one of the > prime advantages over existing physical or VLAN-based chaining. I'd think long and hard about whether you're planning on using addresses as what might essentially be considered to be topology descriptors or as identifiers. As long as there's an assumption that there can be a NAT in a service chain you've got to accept the possibility that if you're using addresses this way you'll be getting things wrong, that you'll be using what's essentially a form of source routing that can lead to tromboning, and a number of other brokennesses. Melinda From adrian@olddog.co.uk Fri Nov 29 11:16:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3951ADD9D for ; Fri, 29 Nov 2013 11:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZMP_F5EQiUB for ; Fri, 29 Nov 2013 11:16:48 -0800 (PST) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 101061ADF69 for ; Fri, 29 Nov 2013 11:16:47 -0800 (PST) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATJGjfI004337 for ; Fri, 29 Nov 2013 19:16:45 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id rATJGi9p004316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 29 Nov 2013 19:16:45 GMT From: "Adrian Farrel" To: Date: Fri, 29 Nov 2013 19:16:44 -0000 Message-ID: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac7tN4Wn/P/bkpKXTmq+048ezaHoRg== Content-Language: en-gb Subject: [nsc] Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Nov 2013 19:16:50 -0000 Hi, I've been reading through the mailing list and have polished the charter text a little further. I picked up Kevin's suggestions as follows: Added the word "format" describing the layer independence of the encapsulation in point 3. In point 3, I did not delete... "That is, the same encapsulation may be used on a service function path realized at the network layer or at any other layer, and the same encapsulation will apply for the construction of service function paths regardless of the actual service." ...but I did insert "format" in that text as well. Still in the same point 3, I took Jim's s/path realized/function applied/ I did not make any change after Hongyu's discussion of "network node". I don't think that is a synonym for "Network Element (NE)", but does represent an addressable node on the graph. It *is* an interesting debate about whether a specific service function instance can move around, but if it changes identity and address when it does so then perhaps it is hard to know what to call it. But I did take Thomas's proposal for that paragraph and rework it to lead to.. An SFC is instantiated through selection of specific service function instances on specific network nodes to form a service graph: this is called a Service Function Path (SFP). This is the version that will go to the IESG on Thursday 5th. You can (of course) continue to discuss the text, but it feels like we are now tweaking the tweaks. Cheers, Adrian PS. If you could all try to remember to change the subject line when your conversation wanders on to new topics it would be nice. From Ron_Parker@affirmednetworks.com Fri Nov 29 11:31:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADCC71AD6B9 for ; Fri, 29 Nov 2013 11:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITzCyg-JKh01 for ; Fri, 29 Nov 2013 11:31:45 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97A1AC403 for ; Fri, 29 Nov 2013 11:31:45 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 11:31:44 -0800 From: Ron Parker To: Melinda Shore Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmCAAM3tAIAAC+iA//+e6/2AAO9wgIAAYteAgAEsV4GAAKsFgIAAglyA Date: Fri, 29 Nov 2013 19:31:43 +0000 Message-ID: References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> <5298E7E3.9020901@gmail.com> In-Reply-To: <5298E7E3.9020901@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.174.120.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Diego R. Lopez" , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 19:31:46 -0000 Hi, Melinda. >From your response, I don't think I conveyed my point adequately. I was t= rying to describe a service chaining scenario that could operate at the sub= -5-tuple level by splitting out subflows from a 5-tuple flow for differenti= ated treatment and then potentially reassembling them in some service-funct= ion-specific manner. The issue of locators (IP address or otherwise) does= n't enter into this, IMO. Ron -----Original Message----- From: Melinda Shore [mailto:melinda.shore@gmail.com]=20 Sent: Friday, November 29, 2013 2:16 PM To: Ron Parker Cc: Kevin J Ma; Diego R. Lopez; nsc@ietf.org; Jim Guichard (jguichar) Subject: Re: [nsc] Progress toward WG formation On 11/29/13 8:14 AM, Ron Parker wrote: > Kevin's basic question is whether the SFC architecture supports this > type of functionality and my view is categorically, yes. In fact > 5-tuple aware and transaction aware decision making is one of the=20 > prime advantages over existing physical or VLAN-based chaining. I'd think long and hard about whether you're planning on using addresses as= what might essentially be considered to be topology descriptors or as iden= tifiers. As long as there's an assumption that there can be a NAT in a ser= vice chain you've got to accept the possibility that if you're using addres= ses this way you'll be getting things wrong, that you'll be using what's es= sentially a form of source routing that can lead to tromboning, and a numbe= r of other brokennesses. Melinda From jguichar@cisco.com Fri Nov 29 11:59:35 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978BD1AD8F9 for ; Fri, 29 Nov 2013 11:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 VnLS9huj6GRn for ; Fri, 29 Nov 2013 11:59:34 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E01961ACC8A for ; Fri, 29 Nov 2013 11:59:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2030; q=dns/txt; s=iport; t=1385755173; x=1386964773; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=qxFLhl461SzxsHcAXFygYpBfXd4dzoSe5BVFqo2MIrU=; b=Zd03tWw9ZxRNR8wdAEN+5CMZzwhOFXFb27vtzMepy8hrxMr8pIWa7EmC DzjzF1gv5dFyN1UPHJJzbBZ6/yGBPz0MHSRL3fasw96DSNiawGRinhbXA NpXP24DH5KT3+2n2BnRjqFNCsw+5CskDzprhXuEAbxBrdHfaUD7uKh1th g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALvxmFKtJXG9/2dsb2JhbABZgweBC7hZgSEWdIIlAQEBBDo/DAYBCBEBAwEBAR4JKBEUAwYIAgQBDQWHbwMPuDUNhzQXjHeBZisHAgSELQOWKYFrjFqFOYMpgio X-IronPort-AV: E=Sophos;i="4.93,798,1378857600"; d="scan'208";a="285373345" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 29 Nov 2013 19:59:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rATJxWde010719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Nov 2013 19:59:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.30]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 29 Nov 2013 13:59:32 -0600 From: "Jim Guichard (jguichar)" To: Ron Parker , Melinda Shore Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAADHVxgP//rc2AgABoFACAAA4MAIAACxIAgAAEcgCAAELlAIAAC+iAgAAlBwCAAGlUgIAAYteAgAG1l4CAACHFgIAABHSA//+z7wA= Date: Fri, 29 Nov 2013 19:59:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <5959EB21773E1A489AA4B331188FC768@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Diego R. Lopez" , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 19:59:35 -0000 Seems to me Ron that what you describe is essentially a pipeline where the SFC encapsulation would need to carry enough information to successfully reassemble the original flow on exit from the service function. As you stated, such a service function would need an entry and exit process point and in between specific aspects of the "overall" service function would be applied to parts of the flow. On 11/29/13 2:31 PM, "Ron Parker" wrote: >Hi, Melinda. > >From your response, I don't think I conveyed my point adequately. I was >trying to describe a service chaining scenario that could operate at the >sub-5-tuple level by splitting out subflows from a 5-tuple flow for >differentiated treatment and then potentially reassembling them in some >service-function-specific manner. The issue of locators (IP address or >otherwise) doesn't enter into this, IMO. > > Ron > > >-----Original Message----- >From: Melinda Shore [mailto:melinda.shore@gmail.com] >Sent: Friday, November 29, 2013 2:16 PM >To: Ron Parker >Cc: Kevin J Ma; Diego R. Lopez; nsc@ietf.org; Jim Guichard (jguichar) >Subject: Re: [nsc] Progress toward WG formation > >On 11/29/13 8:14 AM, Ron Parker wrote: >> Kevin's basic question is whether the SFC architecture supports this >> type of functionality and my view is categorically, yes. In fact >> 5-tuple aware and transaction aware decision making is one of the >> prime advantages over existing physical or VLAN-based chaining. > >I'd think long and hard about whether you're planning on using addresses >as what might essentially be considered to be topology descriptors or as >identifiers. As long as there's an assumption that there can be a NAT in >a service chain you've got to accept the possibility that if you're using >addresses this way you'll be getting things wrong, that you'll be using >what's essentially a form of source routing that can lead to tromboning, >and a number of other brokennesses. > >Melinda From melinda.shore@gmail.com Fri Nov 29 12:10:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B5E1AE2DB for ; Fri, 29 Nov 2013 12:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLPHfDznbggA for ; Fri, 29 Nov 2013 12:10:22 -0800 (PST) Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 97D781AE2D8 for ; Fri, 29 Nov 2013 12:10:22 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id rq2so15052234pbb.30 for ; Fri, 29 Nov 2013 12:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+G1Sh+UyyGL7kTdb1lZNLJzRJzB+6pi+q7zWPEiDbKs=; b=PPpAQw8CbTsZhQoMkWGWysxXiVrWDhUpuPjzoF4L47IGj40MACp88CmQNyxHfYIvw0 3Qlrpwim17mK80Po+4SB60/iodBCdppwk7t9EugD2cPle3zekK0GYB48GSECWIUq8Qha e4dkwW5wLGNbwNtxxr4+SVVoGvrsbdF1AAkhWzSeGa5CWmSeIraMrWwAHxzp4D13z3D+ vccLw9xbpV7GjlDktsq8cwDLMLyJBBpqHrIsls1ZOYG/TYfm0JMdo8PeuWqlum1OVx5a OpsRfs+izr9s4P0fsdbRCizWyNxcS6KD96jic6JhK/jCk/ZYqvbWE6TrBvHjsoc0noHr bI5g== X-Received: by 10.66.162.136 with SMTP id ya8mr53587004pab.110.1385755821477; Fri, 29 Nov 2013 12:10:21 -0800 (PST) Received: from spandex.local (216-67-70-82-rb3.nwc.dsl.dynamic.acsalaska.net. [216.67.70.82]) by mx.google.com with ESMTPSA id ki1sm104058214pbd.1.2013.11.29.12.10.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Nov 2013 12:10:20 -0800 (PST) Message-ID: <5298F4A9.6000301@gmail.com> Date: Fri, 29 Nov 2013 11:10:17 -0900 From: Melinda Shore User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Ron Parker References: <52963740.5040304@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1A6@MAILR002.mail.lan> <14526E57-692B-45CD-96F5-FCDB8BC85277@affirmednetworks.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB1FE@MAILR002.mail.lan> <5296882A.6090502@gmail.com> <291CC3F9E50E7641901A54E85D0977C6C2C79FB261@MAILR002.mail.lan> , <291CC3F9E50E7641901A54E85D0977C6C2C79FB279@MAILR002.mail.lan> <5298E7E3.9020901@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Diego R. Lopez" , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 20:10:24 -0000 On 11/29/13 10:31 AM, Ron Parker wrote: > From your response, I don't think I conveyed my point adequately. I > was trying to describe a service chaining scenario that could operate > at the sub-5-tuple level by splitting out subflows from a 5-tuple > flow for differentiated treatment and then potentially reassembling > them in some service-function-specific manner. The issue of > locators (IP address or otherwise) doesn't enter into this, IMO. I think that if you're looking at using addresses for identifiers only, and aren't interested in leveraging them for some sort of understanding of topology, you're probably better off coming up with some sort of other identifier rather than reusing addresses. To be honest I'm not sure whether what you're discussing here would be considered control plane or data plane, which makes a difference. Melinda From Ron_Parker@affirmednetworks.com Fri Nov 29 12:32:12 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6CE1ADE8B for ; Fri, 29 Nov 2013 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drCRed7mm1r9 for ; Fri, 29 Nov 2013 12:32:10 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) by ietfa.amsl.com (Postfix) with ESMTP id AA1131ADDAC for ; Fri, 29 Nov 2013 12:32:10 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0158.001; Fri, 29 Nov 2013 12:32:09 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , Melinda Shore Thread-Topic: [nsc] Progress toward WG formation Thread-Index: Ac7q7kgqB1gAFw69SQygXsQ56slOfQABtcQAACdV4IAAEKZUgAAANHOAAAKHwQAAAcFrAP//hPZ/////hmCAAM3tAIAAC+iA//+e6/2AAO9wgIAAYteAgAEsV4GAAKsFgIAAglyA//+J3IAAEA1+QA== Date: Fri, 29 Nov 2013 20:32:07 +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: [71.174.120.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Diego R. Lopez" , Kevin J Ma Subject: Re: [nsc] Progress toward WG formation X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 29 Nov 2013 20:32:12 -0000 Exactly. This is a great use of metadata -- service-function-specific tag= s or handles that allow this type of disassociated service processing. In= fact, there was a use case presentation in Vancouver that gave a tangentia= lly similar example. Some service function added a discard eligibility ta= g that some downstream service function would examine in its intelligent ov= erload control processing.=20 In terms of separating SFC capabilities from service function capabilities,= I think we can consider for the SFC realm the connectionless or connection= -oriented manner of achieving SFC tunnels, where an SFC tunnel is the compo= sition of the SFC transport plus SFC service encapsulation (i.e., IP + UDP = + SFC header). Many service functions operate at the fully-qualified or f= iltered 5-tuple level. Thus, any reliability is end-to-end and connection= less tunnels between the classifier and service functions will suffice. I= f a packet is dropped between service functions, end-to-end reliability, if= applicable, will cause it to be resent. But, for service functions opera= ting sub-fully-qualified-5-tuple, the assumption is that the "front-half" s= ervice function terminated the end-to-end 5-tuple (i.e., TCP). This now c= reates the need to have reliable transport of the sub-flows between the cla= ssifier and service functions. Ron -----Original Message----- From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com]=20 Sent: Friday, November 29, 2013 3:00 PM To: Ron Parker; Melinda Shore Cc: Kevin J Ma; Diego R. Lopez; nsc@ietf.org Subject: Re: [nsc] Progress toward WG formation Seems to me Ron that what you describe is essentially a pipeline where the = SFC encapsulation would need to carry enough information to successfully re= assemble the original flow on exit from the service function. As you stated= , such a service function would need an entry and exit process point and in= between specific aspects of the "overall" service function would be applie= d to parts of the flow. On 11/29/13 2:31 PM, "Ron Parker" wrote: >Hi, Melinda. > >From your response, I don't think I conveyed my point adequately. I was >trying to describe a service chaining scenario that could operate at=20 >the sub-5-tuple level by splitting out subflows from a 5-tuple flow for=20 >differentiated treatment and then potentially reassembling them in some >service-function-specific manner. The issue of locators (IP address or >otherwise) doesn't enter into this, IMO. > > Ron > > >-----Original Message----- >From: Melinda Shore [mailto:melinda.shore@gmail.com] >Sent: Friday, November 29, 2013 2:16 PM >To: Ron Parker >Cc: Kevin J Ma; Diego R. Lopez; nsc@ietf.org; Jim Guichard (jguichar) >Subject: Re: [nsc] Progress toward WG formation > >On 11/29/13 8:14 AM, Ron Parker wrote: >> Kevin's basic question is whether the SFC architecture supports this >> type of functionality and my view is categorically, yes. In fact >> 5-tuple aware and transaction aware decision making is one of the=20 >> prime advantages over existing physical or VLAN-based chaining. > >I'd think long and hard about whether you're planning on using=20 >addresses as what might essentially be considered to be topology=20 >descriptors or as identifiers. As long as there's an assumption that=20 >there can be a NAT in a service chain you've got to accept the=20 >possibility that if you're using addresses this way you'll be getting=20 >things wrong, that you'll be using what's essentially a form of source=20 >routing that can lead to tromboning, and a number of other brokennesses. > >Melinda From hongyu.li@huawei.com Sat Nov 30 00:03:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4001AE3A3 for ; Sat, 30 Nov 2013 00:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 xpW1YWK8obVR for ; Sat, 30 Nov 2013 00:03:36 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75E891AE3A1 for ; Sat, 30 Nov 2013 00:03:35 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYM09408; Sat, 30 Nov 2013 08:03:32 +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, 30 Nov 2013 08:02:49 +0000 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 30 Nov 2013 08:03:28 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.188]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Sat, 30 Nov 2013 16:03:24 +0800 From: "Hongyu Li (Julio)" To: "adrian@olddog.co.uk" , "nsc@ietf.org" Thread-Topic: Node or not //RE: [nsc] Charter text updated Thread-Index: Ac7tN4Wn/P/bkpKXTmq+048ezaHoRgAab4xQ Date: Sat, 30 Nov 2013 08:03:24 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk> In-Reply-To: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk> 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 Subject: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 30 Nov 2013 08:03:38 -0000 SGkgYWxsLA0KDQpJIGFtIHN0aWxsIHN0cnVnZ2xpbmcgd2l0aCB0aGUgd29yZCAibm9kZSIgaW4g dXBkYXRlZCBjaGFydGVyLg0KDQoiIDMuIEdlbmVyaWMgU0ZDIEVuY2Fwc3VsYXRpb246IFRoaXMg ZG9jdW1lbnQgd2lsbCBkZXNjcmliZSBhIHNpbmdsZSANCiAgIHNlcnZpY2UtbGV2ZWwgZGF0YSBw bGFuZSBlbmNhcHN1bGF0aW9uIGZvcm1hdCBmb3IgY29udmV5aW5nIHRoZQ0KICAgc2VydmljZSBm dW5jdGlvbiBjaGFpbiBhbmQgdGhlIHNlcnZpY2UgZnVuY3Rpb24gcGF0aCwgYW5kIGZvciANCiAg IGNvbW11bmljYXRpbmcgY29udGV4dCBpbmZvcm1hdGlvbiBiZXR3ZWVuIG5vZGVzIHRoYXQgaW1w bGVtZW50IA0KICAgc2VydmljZSBmdW5jdGlvbnMgYW5kIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5z LiINCg0KSSBhbSBub3Qgc3VyZSB3aGVyZSBhcmUgIm5vZGVzIHRoYXQgaW1wbGVtZW50IiBpbiBh Ym92ZSB0ZXN0IGZpdHRpbmcgaW50byBmb2xsb3dpbmcgY2FzZToNCg0KVGhlcmUgYXJlIHNldmVy YWwgdmlydHVhbCBTZXJ2aWNlIEZ1bmN0aW9ucyBydW5uaW5nIGluIGEgc2FtZSBzZXJ2ZXIsIGFu ZCBlYWNoIFNlcnZpY2UgRnVuY3Rpb24gaXMgcnVubmluZyBpbiBhIHN0YW5kYWxvbmUgVmlydHVh bCBNYWNoaW5lLiBUaGVzZSBTRnMgZm9ybXMgYW4gU0ZDIGluIHRoZSBzZXJ2ZXIuIFRoaXMgaXMg YSB0eXBpY2FsIE5GViBjYXNlLCB3aGljaCBJIGJlbGlldmUgd2UgYWdyZWVkIHRvIHN1cHBvcnQg YWNjb3JkaW5nIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uLiBTbywgd2hlcmUgaXMgdGhlIG5vZGUg Zml0dGluZyBpbnRvPyBFcXVhbCB0byBWTXM/DQoNCkNoZWVycywNCkhvbmd5dQ0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBBZHJpYW4gRmFycmVsDQpTZW50OiBTYXR1cmRheSwgTm92ZW1iZXIg MzAsIDIwMTMgMzoxNyBBTQ0KVG86IG5zY0BpZXRmLm9yZw0KU3ViamVjdDogW25zY10gQ2hhcnRl ciB0ZXh0IHVwZGF0ZWQNCg0KSGksDQoNCkkndmUgYmVlbiByZWFkaW5nIHRocm91Z2ggdGhlIG1h aWxpbmcgbGlzdCBhbmQgaGF2ZSBwb2xpc2hlZCB0aGUgY2hhcnRlciB0ZXh0IGEgbGl0dGxlIGZ1 cnRoZXIuDQoNCkkgcGlja2VkIHVwIEtldmluJ3Mgc3VnZ2VzdGlvbnMgYXMgZm9sbG93czoNCg0K QWRkZWQgdGhlIHdvcmQgImZvcm1hdCIgZGVzY3JpYmluZyB0aGUgbGF5ZXIgaW5kZXBlbmRlbmNl IG9mIHRoZSBlbmNhcHN1bGF0aW9uIGluIHBvaW50IDMuDQoNCkluIHBvaW50IDMsIEkgZGlkIG5v dCBkZWxldGUuLi4gDQogICJUaGF0IGlzLCB0aGUgc2FtZSANCiAgIGVuY2Fwc3VsYXRpb24gbWF5 IGJlIHVzZWQgb24gYSBzZXJ2aWNlIGZ1bmN0aW9uIHBhdGggcmVhbGl6ZWQgYXQgdGhlIA0KICAg bmV0d29yayBsYXllciBvciBhdCBhbnkgb3RoZXIgbGF5ZXIsIGFuZCB0aGUgc2FtZSBlbmNhcHN1 bGF0aW9uIHdpbGwNCiAgIGFwcGx5IGZvciB0aGUgY29uc3RydWN0aW9uIG9mIHNlcnZpY2UgZnVu Y3Rpb24gcGF0aHMgcmVnYXJkbGVzcyBvZg0KICAgdGhlIGFjdHVhbCBzZXJ2aWNlLiINCi4uLmJ1 dCBJIGRpZCBpbnNlcnQgImZvcm1hdCIgaW4gdGhhdCB0ZXh0IGFzIHdlbGwuDQoNClN0aWxsIGlu IHRoZSBzYW1lIHBvaW50IDMsIEkgdG9vayBKaW0ncyBzL3BhdGggcmVhbGl6ZWQvZnVuY3Rpb24g YXBwbGllZC8NCg0KSSBkaWQgbm90IG1ha2UgYW55IGNoYW5nZSBhZnRlciBIb25neXUncyBkaXNj dXNzaW9uIG9mICJuZXR3b3JrIG5vZGUiLiBJIGRvbid0IHRoaW5rIHRoYXQgaXMgYSBzeW5vbnlt IGZvciAiTmV0d29yayBFbGVtZW50IChORSkiLCBidXQgZG9lcyByZXByZXNlbnQgYW4gYWRkcmVz c2FibGUgbm9kZSBvbiB0aGUgZ3JhcGguIEl0ICppcyogYW4gaW50ZXJlc3RpbmcgZGViYXRlIGFi b3V0IHdoZXRoZXIgYSBzcGVjaWZpYyBzZXJ2aWNlIGZ1bmN0aW9uIGluc3RhbmNlIGNhbiBtb3Zl IGFyb3VuZCwgYnV0IGlmIGl0IGNoYW5nZXMgaWRlbnRpdHkgYW5kIGFkZHJlc3Mgd2hlbiBpdCBk b2VzIHNvIHRoZW4gcGVyaGFwcyBpdCBpcyBoYXJkIHRvIGtub3cgd2hhdCB0byBjYWxsIGl0LiBC dXQgSSBkaWQgdGFrZSBUaG9tYXMncyBwcm9wb3NhbCBmb3IgdGhhdCBwYXJhZ3JhcGggYW5kIHJl d29yayBpdCB0byBsZWFkIHRvLi4NCg0KICAgQW4gU0ZDIGlzIGluc3RhbnRpYXRlZCB0aHJvdWdo IHNlbGVjdGlvbg0KICAgb2Ygc3BlY2lmaWMgc2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMgb24g c3BlY2lmaWMgbmV0d29yayBub2RlcyB0byBmb3JtDQogICBhIHNlcnZpY2UgZ3JhcGg6IHRoaXMg aXMgY2FsbGVkIGEgU2VydmljZSBGdW5jdGlvbiBQYXRoIChTRlApLiANCg0KVGhpcyBpcyB0aGUg dmVyc2lvbiB0aGF0IHdpbGwgZ28gdG8gdGhlIElFU0cgb24gVGh1cnNkYXkgNXRoLiBZb3UgY2Fu IChvZg0KY291cnNlKSBjb250aW51ZSB0byBkaXNjdXNzIHRoZSB0ZXh0LCBidXQgaXQgZmVlbHMg bGlrZSB3ZSBhcmUgbm93IHR3ZWFraW5nIHRoZSB0d2Vha3MuDQoNCkNoZWVycywNCkFkcmlhbg0K DQpQUy4gSWYgeW91IGNvdWxkIGFsbCB0cnkgdG8gcmVtZW1iZXIgdG8gY2hhbmdlIHRoZSBzdWJq ZWN0IGxpbmUgd2hlbiB5b3VyIGNvbnZlcnNhdGlvbiB3YW5kZXJzIG9uIHRvIG5ldyB0b3BpY3Mg aXQgd291bGQgYmUgbmljZS4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From stbryant@cisco.com Sat Nov 30 00:26:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377081AE23C for ; Sat, 30 Nov 2013 00:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 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.001, 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 CF6TgIYCfD7V for ; Sat, 30 Nov 2013 00:26:38 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 02C231AE152 for ; Sat, 30 Nov 2013 00:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3297; q=dns/txt; s=iport; t=1385799996; x=1387009596; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1Iv19bqxWxoi19rOXMohd+2FC2oIFBTpr4ZunldM7Ow=; b=G4+nABczTTUN1KRc73kfOg2vWqAT4QCyOnEF612smetFHlsUR8/zflFG LDPP+9TY9zUjQSRstwcCDv9z0zX45lQeXi/977wqF3AIXl6I26whaiNAu 1jc89VssxZq1RDE64Bh/bBWpBoNQFlr9g04dxBfDyn1Hh6kqvGXv5fVbQ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAFOgmVKtJXG//2dsb2JhbABQCYMHOLkvgR8WdIIlAQEBAwEBAQE3NAsFBwQCAQgRBAEBAR4JBycLFAkIAgQOBYd7Bg2/EhMEji0oMwcGgxqBEwOYFJITgyk X-IronPort-AV: E=Sophos;i="4.93,802,1378857600"; d="scan'208";a="3272189" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-6.cisco.com with ESMTP; 30 Nov 2013 08:26:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAU8QaU3006546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 30 Nov 2013 08:26:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.232]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Sat, 30 Nov 2013 02:26:35 -0600 From: "Stewart Bryant (stbryant)" To: "Hongyu Li (Julio)" Thread-Topic: [nsc] Node or not //RE: Charter text updated Thread-Index: AQHO7aKv7ZW/klt9bUSuSvNT0oXtwpo9cH0i Date: Sat, 30 Nov 2013 08:26:34 +0000 Message-ID: <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk>, <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> In-Reply-To: <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "adrian@olddog.co.uk" Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 30 Nov 2013 08:26:40 -0000 Would entities be better than nodes? S > On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" wrot= e: >=20 > Hi all, >=20 > I am still struggling with the word "node" in updated charter. >=20 > " 3. Generic SFC Encapsulation: This document will describe a single=20 > service-level data plane encapsulation format for conveying the > service function chain and the service function path, and for=20 > communicating context information between nodes that implement=20 > service functions and service function chains." >=20 > I am not sure where are "nodes that implement" in above test fitting into= following case: >=20 > There are several virtual Service Functions running in a same server, and= each Service Function is running in a standalone Virtual Machine. These SF= s forms an SFC in the server. This is a typical NFV case, which I believe w= e agreed to support according mailing list discussion. So, where is the nod= e fitting into? Equal to VMs? >=20 > Cheers, > Hongyu >=20 > -----Original Message----- > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Saturday, November 30, 2013 3:17 AM > To: nsc@ietf.org > Subject: [nsc] Charter text updated >=20 > Hi, >=20 > I've been reading through the mailing list and have polished the charter = text a little further. >=20 > I picked up Kevin's suggestions as follows: >=20 > Added the word "format" describing the layer independence of the encapsul= ation in point 3. >=20 > In point 3, I did not delete...=20 > "That is, the same=20 > encapsulation may be used on a service function path realized at the=20 > network layer or at any other layer, and the same encapsulation will > apply for the construction of service function paths regardless of > the actual service." > ...but I did insert "format" in that text as well. >=20 > Still in the same point 3, I took Jim's s/path realized/function applied/ >=20 > I did not make any change after Hongyu's discussion of "network node". I = don't think that is a synonym for "Network Element (NE)", but does represen= t an addressable node on the graph. It *is* an interesting debate about whe= ther a specific service function instance can move around, but if it change= s identity and address when it does so then perhaps it is hard to know what= to call it. But I did take Thomas's proposal for that paragraph and rework= it to lead to.. >=20 > An SFC is instantiated through selection > of specific service function instances on specific network nodes to for= m > a service graph: this is called a Service Function Path (SFP).=20 >=20 > This is the version that will go to the IESG on Thursday 5th. You can (of > course) continue to discuss the text, but it feels like we are now tweaki= ng the tweaks. >=20 > Cheers, > Adrian >=20 > PS. If you could all try to remember to change the subject line when your= conversation wanders on to new topics it would be nice. >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From adrian@olddog.co.uk Sat Nov 30 05:07:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB321AE42E for ; Sat, 30 Nov 2013 05:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_UKh6UjMRPt for ; Sat, 30 Nov 2013 05:07:27 -0800 (PST) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBCB1AE42F for ; Sat, 30 Nov 2013 05:07:27 -0800 (PST) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAUD7AvW024150; Sat, 30 Nov 2013 13:07:10 GMT Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id rAUD790M024144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 30 Nov 2013 13:07:10 GMT From: "Adrian Farrel" To: "'Hongyu Li \(Julio\)'" References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk>, <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> In-Reply-To: <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> Date: Sat, 30 Nov 2013 13:07:08 -0000 Message-ID: <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJMeIyybGx7Ooz+WueVTKnj5Td7oQKNgx12Aj30HQ2ZHEwHkA== Content-Language: en-gb Cc: nsc@ietf.org Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Nov 2013 13:07:30 -0000 I don't like to use "entity" because it is commonly shorthand for "Network Entity (NE)" which has a long association with a physical box. "Node" (for me) is a concept of graph theory equating to "vertex" and is a "point on the graph". That, I think, mans that it is uniquely addressable and identifiable, but may be logical or physical (indeed, when we want to make the distinction we say "logical node" or "physical node"). Hongyu, I appreciate you asking questions to find out what is and is not in scope for this text. But since we are having trouble reaching convergence, I wonder whether you could make a clear statement of what it is that you want to make sure is in scope for the WG. If you can say "I want the WG to be able to work on..." then we can pick an appropriate answer: - Ah, no, it is our intention that that is out of scope - Yes, and that is already in scope - Oh, we see what you mean - here is a text change. Thanks, Adrian > -----Original Message----- > From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] > Sent: 30 November 2013 08:27 > To: Hongyu Li (Julio) > Cc: adrian@olddog.co.uk; nsc@ietf.org > Subject: Re: [nsc] Node or not //RE: Charter text updated > > Would entities be better than nodes? > > S > > > > > On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" wrote: > > > > Hi all, > > > > I am still struggling with the word "node" in updated charter. > > > > " 3. Generic SFC Encapsulation: This document will describe a single > > service-level data plane encapsulation format for conveying the > > service function chain and the service function path, and for > > communicating context information between nodes that implement > > service functions and service function chains." > > > > I am not sure where are "nodes that implement" in above test fitting into > following case: > > > > There are several virtual Service Functions running in a same server, and each > Service Function is running in a standalone Virtual Machine. These SFs forms an > SFC in the server. This is a typical NFV case, which I believe we agreed to support > according mailing list discussion. So, where is the node fitting into? Equal to VMs? > > > > Cheers, > > Hongyu > > > > -----Original Message----- > > From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel > > Sent: Saturday, November 30, 2013 3:17 AM > > To: nsc@ietf.org > > Subject: [nsc] Charter text updated > > > > Hi, > > > > I've been reading through the mailing list and have polished the charter text a > little further. > > > > I picked up Kevin's suggestions as follows: > > > > Added the word "format" describing the layer independence of the > encapsulation in point 3. > > > > In point 3, I did not delete... > > "That is, the same > > encapsulation may be used on a service function path realized at the > > network layer or at any other layer, and the same encapsulation will > > apply for the construction of service function paths regardless of > > the actual service." > > ...but I did insert "format" in that text as well. > > > > Still in the same point 3, I took Jim's s/path realized/function applied/ > > > > I did not make any change after Hongyu's discussion of "network node". I don't > think that is a synonym for "Network Element (NE)", but does represent an > addressable node on the graph. It *is* an interesting debate about whether a > specific service function instance can move around, but if it changes identity and > address when it does so then perhaps it is hard to know what to call it. But I did > take Thomas's proposal for that paragraph and rework it to lead to.. > > > > An SFC is instantiated through selection > > of specific service function instances on specific network nodes to form > > a service graph: this is called a Service Function Path (SFP). > > > > This is the version that will go to the IESG on Thursday 5th. You can (of > > course) continue to discuss the text, but it feels like we are now tweaking the > tweaks. > > > > Cheers, > > Adrian > > > > PS. If you could all try to remember to change the subject line when your > conversation wanders on to new topics it would be nice. > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc From tnadeau@lucidvision.com Sat Nov 30 06:18:52 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0C21AE024 for ; Sat, 30 Nov 2013 06:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 BRJlPiY9To-1 for ; Sat, 30 Nov 2013 06:18:50 -0800 (PST) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE481ADEB7 for ; Sat, 30 Nov 2013 06:18:50 -0800 (PST) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 29DE626432BE; Sat, 30 Nov 2013 09:18:48 -0500 (EST) Content-Type: multipart/signed; boundary="Apple-Mail=_BB556011-4B0F-46CC-8803-E8D37A35B042"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Thomas Nadeau In-Reply-To: <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> Date: Sat, 30 Nov 2013 09:18:47 -0500 Message-Id: References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk>, <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> To: Farrel Adrian X-Mailer: Apple Mail (2.1822) Cc: nsc@ietf.org, "Hongyu Li \(Julio\)" Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 30 Nov 2013 14:18:52 -0000 --Apple-Mail=_BB556011-4B0F-46CC-8803-E8D37A35B042 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 30, 2013:8:07 AM, at 8:07 AM, Adrian Farrel = wrote: > I don't like to use "entity" because it is commonly shorthand for = "Network > Entity (NE)" which has a long association with a physical box. >=20 > "Node" (for me) is a concept of graph theory equating to "vertex" and = is a > "point on the graph". That, I think, mans that it is uniquely = addressable and > identifiable, but may be logical or physical (indeed, when we want to = make the > distinction we say "logical node" or "physical node"). I agree. In fact, we refined that a little more in = draft-quinn-sfc-arch=20 by using this definition: Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. --Tom >=20 > Hongyu, I appreciate you asking questions to find out what is and is = not in > scope for this text. But since we are having trouble reaching = convergence, I > wonder whether you could make a clear statement of what it is that you = want to > make sure is in scope for the WG. If you can say "I want the WG to be = able to > work on..." then we can pick an appropriate answer: > - Ah, no, it is our intention that that is out of scope > - Yes, and that is already in scope > - Oh, we see what you mean - here is a text change. >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] >> Sent: 30 November 2013 08:27 >> To: Hongyu Li (Julio) >> Cc: adrian@olddog.co.uk; nsc@ietf.org >> Subject: Re: [nsc] Node or not //RE: Charter text updated >>=20 >> Would entities be better than nodes? >>=20 >> S >>=20 >>=20 >>=20 >>> On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" = wrote: >>>=20 >>> Hi all, >>>=20 >>> I am still struggling with the word "node" in updated charter. >>>=20 >>> " 3. Generic SFC Encapsulation: This document will describe a single >>> service-level data plane encapsulation format for conveying the >>> service function chain and the service function path, and for >>> communicating context information between nodes that implement >>> service functions and service function chains." >>>=20 >>> I am not sure where are "nodes that implement" in above test fitting = into >> following case: >>>=20 >>> There are several virtual Service Functions running in a same = server, and > each >> Service Function is running in a standalone Virtual Machine. These = SFs forms > an >> SFC in the server. This is a typical NFV case, which I believe we = agreed to > support >> according mailing list discussion. So, where is the node fitting = into? Equal > to VMs? >>>=20 >>> Cheers, >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Saturday, November 30, 2013 3:17 AM >>> To: nsc@ietf.org >>> Subject: [nsc] Charter text updated >>>=20 >>> Hi, >>>=20 >>> I've been reading through the mailing list and have polished the = charter > text a >> little further. >>>=20 >>> I picked up Kevin's suggestions as follows: >>>=20 >>> Added the word "format" describing the layer independence of the >> encapsulation in point 3. >>>=20 >>> In point 3, I did not delete... >>> "That is, the same >>> encapsulation may be used on a service function path realized at = the >>> network layer or at any other layer, and the same encapsulation = will >>> apply for the construction of service function paths regardless of >>> the actual service." >>> ...but I did insert "format" in that text as well. >>>=20 >>> Still in the same point 3, I took Jim's s/path realized/function = applied/ >>>=20 >>> I did not make any change after Hongyu's discussion of "network = node". I > don't >> think that is a synonym for "Network Element (NE)", but does = represent an >> addressable node on the graph. It *is* an interesting debate about = whether a >> specific service function instance can move around, but if it changes = identity > and >> address when it does so then perhaps it is hard to know what to call = it. But I > did >> take Thomas's proposal for that paragraph and rework it to lead to.. >>>=20 >>> An SFC is instantiated through selection >>> of specific service function instances on specific network nodes to = form >>> a service graph: this is called a Service Function Path (SFP). >>>=20 >>> This is the version that will go to the IESG on Thursday 5th. You = can (of >>> course) continue to discuss the text, but it feels like we are now = tweaking > the >> tweaks. >>>=20 >>> Cheers, >>> Adrian >>>=20 >>> PS. If you could all try to remember to change the subject line when = your >> conversation wanders on to new topics it would be nice. >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_BB556011-4B0F-46CC-8803-E8D37A35B042 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 iQIcBAEBCgAGBQJSmfPHAAoJEPcO+I7eiUJZrEIP/Ro3cd51NWjtYIAYLczFFc+O kTIkCwxPk63rSYnYguOQjnKWmPnC5pMKiVSiD8pzdgGGdxetbDB5ICeuJ1feqyMD OB4I0xLMwXhXLTy8PJuR5fDHPJWrpjz9R/5tgqyQP7673ZNsuxx7LT0rEVIKWU1O ZNLbF4Rox6S/QeFJ8ZP235YgbD+UR7+xdUFWOZeMr9FpR2p1DnoC+FfPOZl9odVk 3aK7oGKkE71MBSWMwB3BaYPNF2scO+6Q133uiwuC4Vm2Ukb1SBQybfPXlpU+nnOu EZbLin4Kbzys4Pr6L8Wo7HDIIj3wp/I9My6VArqzPl/OMcIH4LlBvsrWExw9ZkkI 3ua9LiwL/A8EkcIaH9cBRpdTmyhSN4g05g7tiqNcm73cf41k1Btn+Jey9K3J+G+8 hO60tIKSoG7VvtHnU+HPGp3ZZMrwdPD3pWAb5x3D0/UAKht1VusulTmsSY6ZtOat ZPkeZQNGnqp2X+hukHqP7e3yNlbXTAxeOyV5pxKt3a0EVPdRBzBgeDJfO9gKvvuw zw/ol3ayWp/jcThMaApdVw/1uW2Iy5cvHJTl/GVWe+3XPLhtZW9phuASH6wCVLaj ceTTE1KbYicHzBAKYb5gEdZ6uW7kyE1FlQ56jIL53d1OEw8bVlZdq+RmTprQ/A+O tSUhTXRVk2jaiw7HEPFs =HAmQ -----END PGP SIGNATURE----- --Apple-Mail=_BB556011-4B0F-46CC-8803-E8D37A35B042-- From Ron_Parker@affirmednetworks.com Sat Nov 30 08:24:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79CD21AE450 for ; Sat, 30 Nov 2013 08:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0Jvfes6WrBx for ; Sat, 30 Nov 2013 08:24:24 -0800 (PST) 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 230AE1AE44F for ; Sat, 30 Nov 2013 08:24:24 -0800 (PST) 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.0158.001; Sat, 30 Nov 2013 08:24:22 -0800 From: Ron Parker To: Thomas Nadeau , Farrel Adrian Thread-Topic: [nsc] Node or not //RE: Charter text updated Thread-Index: AQHO7aKvEEDxwTpnPE+e0HcLMfeHZ5o99pgAgABOZACAABQFgP//nLwg Date: Sat, 30 Nov 2013 16:24:21 +0000 Message-ID: References: <09f201ceed37$8b554ad0$a1ffe070$@olddog.co.uk>, <6EB34CB5D82C4645B826C56144826EA97E99D8C1@SZXEMA509-MBS.china.huawei.com> <5C8E766A-1664-44E0-B3D4-FC686B2184A1@cisco.com> <0a6401ceedcd$13ce5150$3b6af3f0$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.174.120.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 30 Nov 2013 16:24:26 -0000 Tom, That definition covers all the necessary aspects, IMO. Ron -----Original Message----- From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Thomas Nadeau Sent: Saturday, November 30, 2013 9:19 AM To: Farrel Adrian Cc: nsc@ietf.org; Hongyu Li (Julio) Subject: Re: [nsc] Node or not //RE: Charter text updated On Nov 30, 2013:8:07 AM, at 8:07 AM, Adrian Farrel wr= ote: > I don't like to use "entity" because it is commonly shorthand for=20 > "Network Entity (NE)" which has a long association with a physical box. >=20 > "Node" (for me) is a concept of graph theory equating to "vertex" and=20 > is a "point on the graph". That, I think, mans that it is uniquely=20 > addressable and identifiable, but may be logical or physical (indeed,=20 > when we want to make the distinction we say "logical node" or "physical n= ode"). I agree. In fact, we refined that a little more in draft-quinn-sfc-arch by= using this definition: Service Node (SN): Physical or virtual element that hosts one or more service functions and has one or more network locators associated with it for reachability and service delivery. --Tom >=20 > Hongyu, I appreciate you asking questions to find out what is and is=20 > not in scope for this text. But since we are having trouble reaching=20 > convergence, I wonder whether you could make a clear statement of what=20 > it is that you want to make sure is in scope for the WG. If you can=20 > say "I want the WG to be able to work on..." then we can pick an appropri= ate answer: > - Ah, no, it is our intention that that is out of scope > - Yes, and that is already in scope > - Oh, we see what you mean - here is a text change. >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] >> Sent: 30 November 2013 08:27 >> To: Hongyu Li (Julio) >> Cc: adrian@olddog.co.uk; nsc@ietf.org >> Subject: Re: [nsc] Node or not //RE: Charter text updated >>=20 >> Would entities be better than nodes? >>=20 >> S >>=20 >>=20 >>=20 >>> On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" wr= ote: >>>=20 >>> Hi all, >>>=20 >>> I am still struggling with the word "node" in updated charter. >>>=20 >>> " 3. Generic SFC Encapsulation: This document will describe a single =20 >>> service-level data plane encapsulation format for conveying the =20 >>> service function chain and the service function path, and for =20 >>> communicating context information between nodes that implement =20 >>> service functions and service function chains." >>>=20 >>> I am not sure where are "nodes that implement" in above test fitting=20 >>> into >> following case: >>>=20 >>> There are several virtual Service Functions running in a same=20 >>> server, and > each >> Service Function is running in a standalone Virtual Machine. These=20 >> SFs forms > an >> SFC in the server. This is a typical NFV case, which I believe we=20 >> agreed to > support >> according mailing list discussion. So, where is the node fitting=20 >> into? Equal > to VMs? >>>=20 >>> Cheers, >>> Hongyu >>>=20 >>> -----Original Message----- >>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >>> Sent: Saturday, November 30, 2013 3:17 AM >>> To: nsc@ietf.org >>> Subject: [nsc] Charter text updated >>>=20 >>> Hi, >>>=20 >>> I've been reading through the mailing list and have polished the=20 >>> charter > text a >> little further. >>>=20 >>> I picked up Kevin's suggestions as follows: >>>=20 >>> Added the word "format" describing the layer independence of the >> encapsulation in point 3. >>>=20 >>> In point 3, I did not delete... >>> "That is, the same >>> encapsulation may be used on a service function path realized at=20 >>> the network layer or at any other layer, and the same encapsulation=20 >>> will apply for the construction of service function paths=20 >>> regardless of the actual service." >>> ...but I did insert "format" in that text as well. >>>=20 >>> Still in the same point 3, I took Jim's s/path realized/function=20 >>> applied/ >>>=20 >>> I did not make any change after Hongyu's discussion of "network=20 >>> node". I > don't >> think that is a synonym for "Network Element (NE)", but does=20 >> represent an addressable node on the graph. It *is* an interesting=20 >> debate about whether a specific service function instance can move=20 >> around, but if it changes identity > and >> address when it does so then perhaps it is hard to know what to call=20 >> it. But I > did >> take Thomas's proposal for that paragraph and rework it to lead to.. >>>=20 >>> An SFC is instantiated through selection of specific service=20 >>> function instances on specific network nodes to form a service=20 >>> graph: this is called a Service Function Path (SFP). >>>=20 >>> This is the version that will go to the IESG on Thursday 5th. You=20 >>> can (of >>> course) continue to discuss the text, but it feels like we are now=20 >>> tweaking > the >> tweaks. >>>=20 >>> Cheers, >>> Adrian >>>=20 >>> PS. If you could all try to remember to change the subject line when=20 >>> your >> conversation wanders on to new topics it would be nice. >>>=20 >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 From smkumar@cisco.com Sat Nov 30 19:32:43 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579671AE247 for ; Sat, 30 Nov 2013 19:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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.001, 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 N3XCkQmpKiZV for ; Sat, 30 Nov 2013 19:32:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 068841ACCEB for ; Sat, 30 Nov 2013 19:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5648; q=dns/txt; s=iport; t=1385868759; x=1387078359; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=+npb9kWMB8/qYEOQbcKvf4HYHWcxd2y/Gtxfm60RPK4=; b=mlpdWX5egnvFPc19mg78OwMteLpT/movNH72cBx0ajHIC4fvZjooYPOK 9Zta4W+mmSpHJZFGui9etyxTWPQPuKSEg87mR6NVqO4ExXsQK+GOHwfPE JI2wwKgZ/okwY/ws9xBv75fCwL2fcMqmqkfa0xAON+m9jmB443IZsAscR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFAAqtmlKtJV2b/2dsb2JhbABQCYMHOFO4XIEZFnSCJQEBAQQBAQE3NAsMBgEIDgMEAQEfCS4LFAkIAgQBDQWIAQ2+YRMEji1bBwaELQOYFJITgymCKg X-IronPort-AV: E=Sophos;i="4.93,804,1378857600"; d="scan'208";a="288542245" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 01 Dec 2013 03:32:39 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rB13WcAg020039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 1 Dec 2013 03:32:38 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.234]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Sat, 30 Nov 2013 21:32:38 -0600 From: "Surendra Kumar (smkumar)" To: Thomas Nadeau , Farrel Adrian Thread-Topic: [nsc] Node or not //RE: Charter text updated Thread-Index: AQHO7aKyFZmY6OcqJUKvh+NZmxc3kZo91REAgABOZACAABQFgIAAV7IA Date: Sun, 1 Dec 2013 03:32:37 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.21.93.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <6632A2D2AD741743A35775FFFAC90A7F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Hongyu Li \(Julio\)" Subject: Re: [nsc] Node or not //RE: Charter text updated X-BeenThere: nsc@ietf.org X-Mailman-Version: 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, 01 Dec 2013 03:32:43 -0000 +1, "node" makes perfect sense. Surendra. On 11/30/13 6:18 AM, "Thomas Nadeau" wrote: > >On Nov 30, 2013:8:07 AM, at 8:07 AM, Adrian Farrel >wrote: > >> I don't like to use "entity" because it is commonly shorthand for >>"Network >> Entity (NE)" which has a long association with a physical box. >>=20 >> "Node" (for me) is a concept of graph theory equating to "vertex" and >>is a >> "point on the graph". That, I think, mans that it is uniquely >>addressable and >> identifiable, but may be logical or physical (indeed, when we want to >>make the >> distinction we say "logical node" or "physical node"). > > I agree. In fact, we refined that a little more in draft-quinn-sfc-arch >by using this definition: > > Service Node (SN): Physical or virtual element that hosts one or > more service functions and has one or more network locators > associated with it for reachability and service delivery. > > --Tom > > >>=20 >> Hongyu, I appreciate you asking questions to find out what is and is >>not in >> scope for this text. But since we are having trouble reaching >>convergence, I >> wonder whether you could make a clear statement of what it is that you >>want to >> make sure is in scope for the WG. If you can say "I want the WG to be >>able to >> work on..." then we can pick an appropriate answer: >> - Ah, no, it is our intention that that is out of scope >> - Yes, and that is already in scope >> - Oh, we see what you mean - here is a text change. >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: Stewart Bryant (stbryant) [mailto:stbryant@cisco.com] >>> Sent: 30 November 2013 08:27 >>> To: Hongyu Li (Julio) >>> Cc: adrian@olddog.co.uk; nsc@ietf.org >>> Subject: Re: [nsc] Node or not //RE: Charter text updated >>>=20 >>> Would entities be better than nodes? >>>=20 >>> S >>>=20 >>>=20 >>>=20 >>>> On 30 Nov 2013, at 08:03, "Hongyu Li (Julio)" >>>>wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I am still struggling with the word "node" in updated charter. >>>>=20 >>>> " 3. Generic SFC Encapsulation: This document will describe a single >>>> service-level data plane encapsulation format for conveying the >>>> service function chain and the service function path, and for >>>> communicating context information between nodes that implement >>>> service functions and service function chains." >>>>=20 >>>> I am not sure where are "nodes that implement" in above test fitting >>>>into >>> following case: >>>>=20 >>>> There are several virtual Service Functions running in a same server, >>>>and >> each >>> Service Function is running in a standalone Virtual Machine. These SFs >>>forms >> an >>> SFC in the server. This is a typical NFV case, which I believe we >>>agreed to >> support >>> according mailing list discussion. So, where is the node fitting into? >>>Equal >> to VMs? >>>>=20 >>>> Cheers, >>>> Hongyu >>>>=20 >>>> -----Original Message----- >>>> From: nsc [mailto:nsc-bounces@ietf.org] On Behalf Of Adrian Farrel >>>> Sent: Saturday, November 30, 2013 3:17 AM >>>> To: nsc@ietf.org >>>> Subject: [nsc] Charter text updated >>>>=20 >>>> Hi, >>>>=20 >>>> I've been reading through the mailing list and have polished the >>>>charter >> text a >>> little further. >>>>=20 >>>> I picked up Kevin's suggestions as follows: >>>>=20 >>>> Added the word "format" describing the layer independence of the >>> encapsulation in point 3. >>>>=20 >>>> In point 3, I did not delete... >>>> "That is, the same >>>> encapsulation may be used on a service function path realized at the >>>> network layer or at any other layer, and the same encapsulation will >>>> apply for the construction of service function paths regardless of >>>> the actual service." >>>> ...but I did insert "format" in that text as well. >>>>=20 >>>> Still in the same point 3, I took Jim's s/path realized/function >>>>applied/ >>>>=20 >>>> I did not make any change after Hongyu's discussion of "network >>>>node". I >> don't >>> think that is a synonym for "Network Element (NE)", but does represent >>>an >>> addressable node on the graph. It *is* an interesting debate about >>>whether a >>> specific service function instance can move around, but if it changes >>>identity >> and >>> address when it does so then perhaps it is hard to know what to call >>>it. But I >> did >>> take Thomas's proposal for that paragraph and rework it to lead to.. >>>>=20 >>>> An SFC is instantiated through selection >>>> of specific service function instances on specific network nodes to >>>>form >>>> a service graph: this is called a Service Function Path (SFP). >>>>=20 >>>> This is the version that will go to the IESG on Thursday 5th. You can >>>>(of >>>> course) continue to discuss the text, but it feels like we are now >>>>tweaking >> the >>> tweaks. >>>>=20 >>>> Cheers, >>>> Adrian >>>>=20 >>>> PS. If you could all try to remember to change the subject line when >>>>your >>> conversation wanders on to new topics it would be nice. >>>>=20 >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>>> _______________________________________________ >>>> nsc mailing list >>>> nsc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/nsc >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >