From nobody Mon Jun 1 08:07:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FCD1A914B for ; Sat, 30 May 2015 11:27:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ARey3hMv1rs for ; Sat, 30 May 2015 11:27:50 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D611A9149 for ; Sat, 30 May 2015 11:27:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 239E7240865; Sat, 30 May 2015 11:27:50 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (75-146-28-117-Richmond.hfc.comcastbusiness.net [75.146.28.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id A0C4824079F; Sat, 30 May 2015 11:27:48 -0700 (PDT) Message-ID: <556A010E.3030901@joelhalpern.com> Date: Sat, 30 May 2015 14:27:26 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Dolson , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" , "Huangjing (A)" , Linda Dunbar References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 08:07:45 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 18:27:52 -0000 Clearly, there are cases where a service funtion will originate packets. I would strongly hope that the service function is not required to know the details of the service function path identification inorder to do so. My assumption has been that to support this need (both for bidirectional cases, and for others), there would be a classifier in place to apply the necessary headers. That classifier could be colocated with the SFF, or could be colocated with the service function itself. Thus, if one wants to deploy a service function and the ability to add path information, I would expect a service funciton with colocated classifier. Arguably this is only a descriptive difference. But that description keeps much clearer what functionality we are discussing, and where it may exist. Yours, Joel On 5/30/15 8:13 AM, Dave Dolson wrote: > I will review the document later, but I can quickly answer your question. >> I have question why not the SFC forwarding system handle the paired chain itself? > > Here is the very simple example that indicates the problem: > - An SF firewall has a policy to respond to not-permitted incoming connections with TCP RST > (rather than allowing the connection to reach the protected host). > - Therefore when a TCP SYN packet arrives at the SF firewall with NSH encapsulation > having path ID x and Path Index y, it must be able to insert the response into the path that is > the bidirectional complement, an NSH encapsulation having path ID x' and path index y' to send > the packet back to the source, following the reverse path. > > I hope that shows why the paths need to be paired? > > I believe that most flow-stateful devices will require the pairing information. > > -Dave > > > ________________________________ > From: Huangyong (Oliver) [oliver.huang@huawei.com] > Sent: Friday, May 29, 2015 9:06 PM > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > Hello Dave, > > Thank you for your detailed consideration on the draft. I agree that the SF should support the capability of bidirectional chains. For example, the NAT SF may provide the new allocated address/port to the controller. You mentioned the control plane should inform SF bidirectional chain (which path id are paired). I have question why not the SFC forwarding system handle the paired chain itself? > > Performance mornitoring is a basic capability which should exist in all interfaces C1,C2,C3. > > Mohamed have developed a new version of this draft and made a big promotion. In the new draft, C3,C4 are introduced for SF and SF proxy separately. I think it may cover the related scenario. I attached it in this email, please check it. > > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are representative of Huawei on this draft. Please contact more detail to them. Thank you very much! > > BR > Oliver > > --------------------------- > Huangyong (Oliver) > Network research, Huawei > > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Saturday, May 30, 2015 4:42 AM > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com > Subject: Comments on draft-ww-sfc-control-plane-04 > > Authors of draft-ww-sfc-control-plane, > > I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04 > > I have some very high-level suggestions: > > > 1. I believe the “F” interface should be split into two interfaces. One for performance monitoring (availability and workload were cited), and one for updating classification information. > > Call these F1 and F2, I suppose. My reasons are that (a) as a general principle, interfaces should not have multiple purposes and (b) F1 and F2 could be communicating to different control-plane managers. > > > > 2. A control interface is required to SF components. Call it C3. This interface is required to (a) inform the SF about bidirectional chains (i.e., which Path IDs are paired) and (b) inform the SF about semantics of types of meta-data. C3 should also be connected to the SFC Proxy. > > I propose: > > 4.5 C3 Interface > > A service function may need information about the service paths > passing through it, and may need information about specific meta-data > types attached to packets on the paths. > > Some types of SF might be agnostic about the paths traversing them, but > most transport-layer-flow-aware devices will require this configuration. > > When bidirectional chains are deployed, the C3 interface provisions > each SF with each path identifier/path index pair that will pass through. > Each such pair is associated with an opposite-direction pair of > identifier/index. > > Meta-data is for the benefit of SFs. The C3 interface informs the SF > about the semantics of the meta-data, which would otherwise have > opaque meaning. Meta-data attributes include "scope" (per-packet, per-flow > or per host), "mandatory" (must be understood), "bidirectional" (same > value may be used in both directions), "is_qualifier" (indicates a > distinct routing domain). > > > I think there is quite a bit to explore, but I believe this starts the discussion. > Thoughts? > > > David Dolson > Senior Software Architect, Sandvine Inc. > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jun 1 08:07:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAD81AC3FB for ; Sun, 31 May 2015 18:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0WVLF9lcMOGH for ; Sun, 31 May 2015 18:02:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A1B1AC3F6 for ; Sun, 31 May 2015 18:02:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BWS43856; Mon, 01 Jun 2015 01:02:46 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Jun 2015 02:02:46 +0100 Received: from SZXEMA506-MBX.china.huawei.com ([169.254.3.98]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Mon, 1 Jun 2015 09:02:34 +0800 From: "Huangyong (Oliver)" To: Dave Dolson , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAABf9ORQATQ+fIA== Date: Mon, 1 Jun 2015 01:02:33 +0000 Message-ID: <8172B566C79A4A4C8EB6C7B1F6529EFC61E2835F@szxema506-mbx.china.huawei.com> References: , <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-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.108.172] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 08:07:45 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 01:02:52 -0000 Dave, I think we all agree that the "paired/bidirectional path" requirement. = =20 My question is, it seems unclear that the "control plane inform the SF = about bidirectional chains" to achieve this goal. From my point of view, S= F provide the reverse path flow identifier via either control plane or data= plane to the classifier. It seems that the SF need not know which path ids= are paired.=20 Anyway, you have provided very useful information regarding the control= interface which may be described in the draft I think. Thank you Dave. BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Saturday, May 30, 2015 8:14 PM To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A= ); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 I will review the document later, but I can quickly answer your question. > I have question why not the SFC forwarding system handle the paired chain= itself? Here is the very simple example that indicates the problem: - An SF firewall has a policy to respond to not-permitted incoming connect= ions with TCP RST (rather than allowing the connection to reach the protect= ed host). - Therefore when a TCP SYN packet arrives at the SF firewall with NSH enca= psulation having path ID x and Path Index y, it must be able to insert the = response into the path that is the bidirectional complement, an NSH encapsu= lation having path ID x' and path index y' to send the packet back to the s= ource, following the reverse path. I hope that shows why the paths need to be paired? I believe that most flow-stateful devices will require the pairing informat= ion. -Dave ________________________________ From: Huangyong (Oliver) [oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair= @orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; = seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Lind= a Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong (Oliver); mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. On= e for performance monitoring (availability and workload were cited), and on= e for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. From nobody Mon Jun 1 09:20:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1141C1B2A64 for ; Mon, 1 Jun 2015 08:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT2Lj3Hqmk0F for ; Mon, 1 Jun 2015 08:29:46 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id A0CC61B2A72 for ; Mon, 1 Jun 2015 08:29:45 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 1 Jun 2015 11:29:44 -0400 From: Dave Dolson To: "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "ron_parker@affirmednetworks.com" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjA= Date: Mon, 1 Jun 2015 15:29:43 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> In-Reply-To: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830C1F4B8wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 09:20:38 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 15:29:50 -0000 --_000_E8355113905631478EFF04F5AA706E9830C1F4B8wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the 2nd paragraph in 2.1, 2.1. Generic Requirements For deployments that would require so, SFC forwarding must be allowed even if no control protocols are enabled. Static configuration must be allowed. A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions, even when control plane components are unavailable or unreachable for some reason. "Control Element must not be required" is contrary to how OpenFlow works (a= s I understand it). So the "must" wording seems to preclude the use of OpenFlow and similar pro= tocols. Was this intended? And it is probably a bad idea to allow an uncontrolled data-plane element t= o keep running indefinitely. Would you want a switch to run without MAC lea= rning? Would you want a router to run if it lost its BGP connection? No, an= d this is why loss of control plane should generally lead to shutting down = the data plane. I understand the sentiment to allow static configuration, which I think is = fine. But if the control-plane is dynamic, loss of controller should lead t= o shut-down. -Dave From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.boucadair= @orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; = seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Lind= a Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong= (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; w= alter.haeffner@vodafone.com; seungikle= e@etri.re.kr; ron_parker@affirmednetworks.com= Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. O= ne for performance monitoring (availability and workload were cited), and o= ne for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This= interface is required to (a) inform the SF about bidirectional chains (i.e= ., which Path IDs are paired) and (b) inform the SF about semantics of type= s of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. --_000_E8355113905631478EFF04F5AA706E9830C1F4B8wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding the 2nd para= graph in 2.1,

 

 

2.1.  Generic Requirements

 

   For deployments that would require so, SFC forwa= rding must be allowed

   even if no control protocols are enabled.  = Static configuration must

   be allowed.

 

   A permanent association between an SFC data plan= e element with a

   Control Element must not be required; specifical= ly, the SFC-enabled

   domain must keep on processing incoming packets = according to the SFC

   instructions, even when control plane components= are unavailable or

   unreachable for some reason.

 

 

“Control Element= must not be required” is contrary to how OpenFlow works (as I unders= tand it).

So the “mustR= 21; wording seems to preclude the use of OpenFlow and similar protocols. Wa= s this intended?

 

And it is probably a b= ad idea to allow an uncontrolled data-plane element to keep running indefin= itely. Would you want a switch to run without MAC learning? Would you want = a router to run if it lost its BGP connection? No, and this is why loss of control plane should generally lead to shuttin= g down the data plane.

 

 

I understand the senti= ment to allow static configuration, which I think is fine. But if the contr= ol-plane is dynamic, loss of controller should lead to shut-down.

 

 

 

-Dave

 

 

 

 

From: Huangyon= g (Oliver) [mailto:oliver.huang@huawei.com]
Sent: Friday, May 29, 2015 9:06 PM
To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; ron_parker@affirmednetworks.com; Huangjing (A= ); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

 

Hello= Dave,

=  

 = ;       Thank you for your detailed considera= tion on the draft.  I agree that the SF should support the capability = of bidirectional chains. For example, the NAT SF may provide the new alloca= ted address/port to the controller.  You mentioned the control plane shou= ld inform SF bidirectional chain (which path id are paired).  I have q= uestion why not the SFC forwarding system handle the paired chain itself?

=  

 = ;       Performance mornitoring is a basic ca= pability which should exist in all interfaces C1,C2,C3.

=  

 = ;       Mohamed have developed a new version = of this draft and made a big promotion. In the new draft, C3,C4 are introdu= ced for SF and SF proxy separately.  I think it may cover the related = scenario.  I attached it in this email,  please check it.

=  

 = ;       Now James.Huang(I add in this email),= Qin.Wu and Linda. Dunbar are representative of= Huawei on this draft. Please contact more detail to them.   Than= k you very much!

=  

BR

Olive= r

=  

------= ---------------------

Huangyong (Oliver)

Network research, Huawei

=  

 

Authors of draft-ww-sfc-control-plane,

 

I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

 

I have some very high-level suggestions:<= /p>

 

1.     &= nbsp; I believe the “F” interface should be s= plit into two interfaces. One for performance monitoring (availability and = workload were cited), and one for updating classification information.=

Call these F1 and F2, I suppose. My reasons a= re that (a) as a general principle, interfaces should not have multiple pur= poses and (b) F1 and F2 could be communicating to different control-plane m= anagers.

 

2.     &= nbsp; A control interface is required to SF components. C= all it C3. This interface is required to (a) inform the SF about bidirectio= nal chains (i.e., which Path IDs are paired) and (b) inform the SF about se= mantics of types of meta-data. C3 should also be connected to the SFC Proxy.

 

I propose:

 

= 4.5  C3 Interface

=  

=    A service function may need information about the service path= s

=    passing through it, and may need information about specific me= ta-data

=    types attached to packets on the paths.

=  

=    Some types of SF might be agnostic about the paths traversing = them, but

=    most transport-layer-flow-aware devices will require this conf= iguration.

=  

=    When bidirectional chains are deployed, the C3 interface provi= sions

=    each SF with each path identifier/path index pair that will pa= ss through.

=    Each such pair is associated with an opposite-direction pair o= f

=    identifier/index.

=  

=    Meta-data is for the benefit of SFs. The C3 interface informs = the SF

=    about the semantics of the meta-data, which would otherwise ha= ve

=    opaque meaning. Meta-data attributes include "scope"= (per-packet, per-flow

=    or per host), "mandatory" (must be understood), &quo= t;bidirectional" (same

=    value may be used in both directions), "is_qualifier"= ; (indicates a

=    distinct routing domain).

=  

 

I think there is quite a bit to explore, but I belie= ve this starts the discussion.

Thoughts?

 

 

David Dolson

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

 

--_000_E8355113905631478EFF04F5AA706E9830C1F4B8wtlexchp2sandvi_-- From nobody Mon Jun 1 09:20:44 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABA31B2B27 for ; Mon, 1 Jun 2015 08:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 yUJ7LieBIE7N for ; Mon, 1 Jun 2015 08:44:27 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03CBF1B2AF3 for ; Mon, 1 Jun 2015 08:43:05 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0224.002; Mon, 1 Jun 2015 08:43:04 -0700 From: Ron Parker To: Dave Dolson , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYA== Date: Mon, 1 Jun 2015 15:43:04 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8B2859MBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 09:20:37 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 15:44:33 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8B2859MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Dave. OpenFlow implementations locate the policy decision point in the controller= and hence per-flow policy analysis is supported via the control plane mess= aging. Assuming that the controller, after analyzing a flow, provides bot= h the action and the filter it used to define the flow, then we get to whet= her the filter is coarse-grained or fine-grained. If the filter is coarse= -grained (e.g., all TCP/80), then additional control plane activity is not = required for subsequent micro-flows that match the macro-flow's filter. B= ut, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, then= the control plane overhead becomes very large and perhaps impractical. = Many of the use cases we've talked about for SFC suggest micro-flow level p= olicy decisions. While I wouldn't suggest that we preclude centralized fine-grained policy a= s a design/implementation decision, I also feel there should be an alternat= ive to allow for distributed/fine-grained policy decisions. In that case,= the control plane's job would be to provide and maintain all of the data n= ecessary to those distributed policy decision points, but not necessarily h= andle per-micro-flow transactions. In summary, we could end up with any or all of the following operating poin= ts (as a fundamental capability or simply a deployment approach): * Centralized coarse-grained policy decision point * Centralized fine-grained policy decision point * Distributed coarse-grained policy decision point * Distributed fine-grained policy decision point Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, June 1, 2015 11:30 AM To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; Ron Parker; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Regarding the 2nd paragraph in 2.1, 2.1. Generic Requirements For deployments that would require so, SFC forwarding must be allowed even if no control protocols are enabled. Static configuration must be allowed. A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions, even when control plane components are unavailable or unreachable for some reason. "Control Element must not be required" is contrary to how OpenFlow works (a= s I understand it). So the "must" wording seems to preclude the use of OpenFlow and similar pro= tocols. Was this intended? And it is probably a bad idea to allow an uncontrolled data-plane element t= o keep running indefinitely. Would you want a switch to run without MAC lea= rning? Would you want a router to run if it lost its BGP connection? No, an= d this is why loss of control plane should generally lead to shutting down = the data plane. I understand the sentiment to allow static configuration, which I think is = fine. But if the control-plane is dynamic, loss of controller should lead t= o shut-down. -Dave From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin = Wu; mohamed.boucadair@orange.com; chri= stian.jacquenet@orange.com; walter.h= aeffner@vodafone.com; seungiklee@etri.= re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong= (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; w= alter.haeffner@vodafone.com; seungikle= e@etri.re.kr; ron_parker@affirmednetworks.com= Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. On= e for performance monitoring (availability and workload were cited), and on= e for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8B2859MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Dave.

 

OpenFlow implementatio= ns locate the policy decision point in the controller and hence per-flow po= licy analysis is supported via the control plane messaging.   Ass= uming that the controller, after analyzing a flow, provides both the action and the filter it used to define the flow, then w= e get to whether the filter is coarse-grained or fine-grained.   = If the filter is coarse-grained (e.g., all TCP/80), then additional control= plane activity is not required for subsequent micro-flows that match the macro-flow’s filter.   But, if = fine-grained (i.e., fully qualified 5-tuple) filtering is used, then the co= ntrol plane overhead becomes very large and perhaps impractical.  = ;  Many of the use cases we’ve talked about for SFC suggest micro-flow level policy decisions.  

 

While I wouldn’t= suggest that we preclude centralized fine-grained policy as a design/imple= mentation decision, I also feel there should be an alternative to allow for= distributed/fine-grained policy decisions.   In that case, the control plane’s job would be to provide and mainta= in all of the data necessary to those distributed policy decision points, b= ut not necessarily handle per-micro-flow transactions.

 

In summary, we could e= nd up with any or all of the following operating points (as a fundamental c= apability or simply a deployment approach):

·        Centralized co= arse-grained policy decision point

·        Centralized fi= ne-grained policy decision point

·        Distributed co= arse-grained policy decision point

·        Distributed fi= ne-grained policy decision point

 

   Ron<= /o:p>

 

 

From: Dave Dolson [mailto:ddolson@sandvine.co= m]
Sent: Monday, June 1, 2015 11:30 AM
To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; moh= amed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@= vodafone.com; seungiklee@etri.re.kr; Ron Parker; Huangjing (A); Linda Dunba= r
Subject: RE: Comments on draft-ww-sfc-control-plane-04

 

Regarding the 2nd para= graph in 2.1,

 

 

2.1.  Generic Requirements

 

   For deployments that would require so, SFC forwa= rding must be allowed

   even if no control protocols are enabled.  = Static configuration must

   be allowed.

 

   A permanent association between an SFC data plan= e element with a

   Control Element must not be required; specifical= ly, the SFC-enabled

   domain must keep on processing incoming packets = according to the SFC

   instructions, even when control plane components= are unavailable or

   unreachable for some reason.

 

 

“Control Element= must not be required” is contrary to how OpenFlow works (as I unders= tand it).

So the “mustR= 21; wording seems to preclude the use of OpenFlow and similar protocols. Wa= s this intended?

 

And it is probably a b= ad idea to allow an uncontrolled data-plane element to keep running indefin= itely. Would you want a switch to run without MAC learning? Would you want = a router to run if it lost its BGP connection? No, and this is why loss of control plane should generally lead to shuttin= g down the data plane.

 

 

I understand the senti= ment to allow static configuration, which I think is fine. But if the contr= ol-plane is dynamic, loss of controller should lead to shut-down.

 

 

 

-Dave

 

 

 

 

From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com]
Sent: Friday, May 29, 2015 9:06 PM
To: Dave Dolson; sfc@ietf.org; H= ongyu Li (Julio); Qin Wu; mohamed.boucadair@orange.co= m; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; = seungiklee@etri.re.kr; ron_parker@affirmednetwo= rks.com; Huangjing (A); Linda Dunbar
Subject: RE: Comments on draft-ww-sfc-control-plane-04

 

Hello= Dave,

=  

 = ;       Thank you for your detailed considera= tion on the draft.  I agree that the SF should support the capability = of bidirectional chains. For example, the NAT SF may provide the new alloca= ted address/port to the controller.  You mentioned the control plane shou= ld inform SF bidirectional chain (which path id are paired).  I have q= uestion why not the SFC forwarding system handle the paired chain itself?

=  

 = ;       Performance mornitoring is a basic ca= pability which should exist in all interfaces C1,C2,C3.

=  

 = ;       Mohamed have developed a new version = of this draft and made a big promotion. In the new draft, C3,C4 are introdu= ced for SF and SF proxy separately.  I think it may cover the related = scenario.  I attached it in this email,  please check it.

=  

 = ;       Now James.Huang(I add in this email),= Qin.Wu and Linda. Dunbar are representative of= Huawei on this draft. Please contact more detail to them.   Than= k you very much!

=  

BR

Olive= r

=  

------= ---------------------

Huangyong (Oliver)

Network research, Huawei

=  

From: Dave Dolson [mailto:ddolson@sandvine.com]
Sent: Saturday, May 30, 2015 4:42 AM
To: sfc@ietf.org; Hongyu Li (Jul= io); Qin Wu; Huangyong (Oliver); mohamed.boucadair@orange.co= m; christian.jacquenet@orange.com; walter.haeffner@vodafone.com; = seungiklee@etri.re.kr; ron_parker@affirmednetwo= rks.com
Subject: Comments on draft-ww-sfc-control-plane-04=

 

Authors of draft-ww-sfc-control-plane,

 

I’ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-plane-04

 

I have some very high-level suggestions:<= /p>

 

1.      I believe the “F” interface should be s= plit into two interfaces. One for performance monitoring (availability and = workload were cited), and one for updating classification information.=

Call these F1 and F2, I suppose. My reasons a= re that (a) as a general principle, interfaces should not have multiple pur= poses and (b) F1 and F2 could be communicating to different control-plane m= anagers.

 

2.      A control interface is required to SF components. C= all it C3. This interface is required to (a) inform the SF about bidirectio= nal chains (i.e., which Path IDs are paired) and (b) inform the SF about se= mantics of types of meta-data. C3 should also be connected to the SFC Proxy.

 

I propose:

 

= 4.5  C3 Interface

=  

=    A service function may need information about the service path= s

=    passing through it, and may need information about specific me= ta-data

=    types attached to packets on the paths.

=  

=    Some types of SF might be agnostic about the paths traversing = them, but

=    most transport-layer-flow-aware devices will require this conf= iguration.

=  

=    When bidirectional chains are deployed, the C3 interface provi= sions

=    each SF with each path identifier/path index pair that will pa= ss through.

=    Each such pair is associated with an opposite-direction pair o= f

=    identifier/index.

=  

=    Meta-data is for the benefit of SFs. The C3 interface informs = the SF

=    about the semantics of the meta-data, which would otherwise ha= ve

=    opaque meaning. Meta-data attributes include "scope"= (per-packet, per-flow

=    or per host), "mandatory" (must be understood), &quo= t;bidirectional" (same

=    value may be used in both directions), "is_qualifier"= ; (indicates a

=    distinct routing domain).

=  

 

I think there is quite a bit to explore, but I belie= ve this starts the discussion.

Thoughts?

 

 

David Dolson

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

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E8B2859MBX021W3CA2exch_-- From nobody Mon Jun 1 09:20:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999E91B2BD3 for ; Mon, 1 Jun 2015 08:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sbGAXwq17dF for ; Mon, 1 Jun 2015 08:56:52 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 059441B2BD4 for ; Mon, 1 Jun 2015 08:50:11 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Jun 2015 11:50:10 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 1 Jun 2015 11:50:10 -0400 From: Dave Dolson To: Ron Parker , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsO Date: Mon, 1 Jun 2015 15:50:08 +0000 Message-ID: <20150601155008.5374031.38326.16222@sandvine.com> References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 01 Jun 2015 09:20:38 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 15:56:54 -0000 I may not have explained my point we'll enough. I only have issue with the = case of the control plane being unreachable. David Dolson Senior Software Architect, Sandvine Inc. From: Ron Parker Sent: Monday, June 1, 2015 11:43 AM To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin W= u; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.hae= ffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hi, Dave. OpenFlow implementations locate the policy decision point in the controller= and hence per-flow policy analysis is supported via the control plane mess= aging. Assuming that the controller, after analyzing a flow, provides bot= h the action and the filter it used to define the flow, then we get to whet= her the filter is coarse-grained or fine-grained. If the filter is coarse= -grained (e.g., all TCP/80), then additional control plane activity is not = required for subsequent micro-flows that match the macro-flow=92s filter. = But, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, th= en the control plane overhead becomes very large and perhaps impractical. = Many of the use cases we=92ve talked about for SFC suggest micro-flow lev= el policy decisions. While I wouldn=92t suggest that we preclude centralized fine-grained policy= as a design/implementation decision, I also feel there should be an altern= ative to allow for distributed/fine-grained policy decisions. In that cas= e, the control plane=92s job would be to provide and maintain all of the da= ta necessary to those distributed policy decision points, but not necessari= ly handle per-micro-flow transactions. In summary, we could end up with any or all of the following operating poin= ts (as a fundamental capability or simply a deployment approach): =B7 Centralized coarse-grained policy decision point =B7 Centralized fine-grained policy decision point =B7 Distributed coarse-grained policy decision point =B7 Distributed fine-grained policy decision point Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, June 1, 2015 11:30 AM To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; Ron Parker; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Regarding the 2nd paragraph in 2.1, 2.1. Generic Requirements For deployments that would require so, SFC forwarding must be allowed even if no control protocols are enabled. Static configuration must be allowed. A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions, even when control plane components are unavailable or unreachable for some reason. =93Control Element must not be required=94 is contrary to how OpenFlow work= s (as I understand it). So the =93must=94 wording seems to preclude the use of OpenFlow and similar= protocols. Was this intended? And it is probably a bad idea to allow an uncontrolled data-plane element t= o keep running indefinitely. Would you want a switch to run without MAC lea= rning? Would you want a router to run if it lost its BGP connection? No, an= d this is why loss of control plane should generally lead to shutting down = the data plane. I understand the sentiment to allow static configuration, which I think is = fine. But if the control-plane is dynamic, loss of controller should lead t= o shut-down. -Dave From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin = Wu; mohamed.boucadair@orange.com; chri= stian.jacquenet@orange.com; walter.h= aeffner@vodafone.com; seungiklee@etri.= re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong= (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; w= alter.haeffner@vodafone.com; seungikle= e@etri.re.kr; ron_parker@affirmednetworks.com= Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I=92ve been reading over https://tools.ietf.org/html/draft-ww-sfc-control-p= lane-04 I have some very high-level suggestions: 1. I believe the =93F=94 interface should be split into two interfaces= . One for performance monitoring (availability and workload were cited), an= d one for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. From nobody Tue Jun 2 02:16:38 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828931B29C0 for ; Tue, 2 Jun 2015 02:16:36 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YXNc6qGduRqv for ; Tue, 2 Jun 2015 02:16:34 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E066E1B29BE for ; Tue, 2 Jun 2015 02:16:33 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1334A2DC14B for ; Tue, 2 Jun 2015 11:16:32 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id E97C2238081 for ; Tue, 2 Jun 2015 11:16:31 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0235.001; Tue, 2 Jun 2015 11:16:31 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-05.txt Thread-Index: AQHQnRIQkqFgwTGpF06i/GpJDc6B8Z2Y6mQg Date: Tue, 2 Jun 2015 09:16:31 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300531BD27@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150602085630.26166.36117.idtracker@ietfa.amsl.com> In-Reply-To: <20150602085630.26166.36117.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.75418 Archived-At: Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-05.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 09:16:36 -0000 Dear all, A new version of the SFC CP draft is available online. This new version was= completely re-written to address the comments we received so far and also = to align the draft with the SFC charter. FWIW, this draft targets this item= from the current wg charter: " Jan 2015 Informational document defining the control plane requirements fo= r conveying information between control or management elements and SFC impl= ementation points " We are seeking for feedback from the WG about this proposal, especially whe= ther the current scope is OK.=20 Please feel free to share any comments you may have on this version. Sugges= tions and text contributions are more than welcome. The plan is to ask for WG adoption.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 2 juin 2015 10:57 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-ww-sfc-control-plane-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Service Function Chaining (SFC) Control Plane > Components & Requirements > Authors : Hongyu Li > Qin Wu > Mohamed Boucadair > Christian Jacquenet > Walter Haeffner > Seungik Lee > Ron Parker > Linda Dunbar > Andrew Malis > Joel M. Halpern > Tirumaleswar Reddy > Prashanth Patil > Filename : draft-ww-sfc-control-plane-05.txt > Pages : 27 > Date : 2015-06-02 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements (including > management components) and SFC functional elements. Also, this > document identifies a set of control interfaces to interact with SFC- > aware elements to establish, maintain or recover service function > chains. This document does not specify protocols nor extensions to > existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ww-sfc-control-plane-05 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-05 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Jun 2 04:24:03 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBF01B2FE1 for ; Mon, 1 Jun 2015 10:41:39 -0700 (PDT) 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 vYbNsuA-rhKQ for ; Mon, 1 Jun 2015 10:41:37 -0700 (PDT) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5028D1B2FDD for ; Mon, 1 Jun 2015 10:41:31 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0224.002; Mon, 1 Jun 2015 10:41:30 -0700 From: Ron Parker To: Dave Dolson , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwA= Date: Mon, 1 Jun 2015 17:41:30 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> In-Reply-To: <20150601155008.5374031.38326.16222@sandvine.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 02 Jun 2015 04:24:00 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:41:40 -0000 Hi, Dave. I did catch that from your original message and I apologize for my comments= that weren't very direct wrt your point. So to complete the circle, my t= hinking is that if the policy decision point (PDP) is centralized, then you= live and die by the control plane availability. But, if the policy decis= ion points are distributed, there is a significantly increased tolerance to= temporary loss of the control plane. I'd like to retain within the archi= tecture the possibility for this distributed approach so that for any deplo= yment the relative strengths and weaknesses of centralized vs distributed c= an be weighed and decided upon. Based on which approach there is a profo= und impact on what the control plane is doing -- is it policy delivery or i= s it policy evaluation? Thanks. Ron -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Monday, June 1, 2015 11:50 AM To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu= ; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haef= fner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: Re: Comments on draft-ww-sfc-control-plane-04 I may not have explained my point we'll enough. I only have issue with the = case of the control plane being unreachable. David Dolson Senior Software Architect, Sandvine Inc. From: Ron Parker Sent: Monday, June 1, 2015 11:43 AM To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin W= u; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.hae= ffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hi, Dave. OpenFlow implementations locate the policy decision point in the controller= and hence per-flow policy analysis is supported via the control plane mess= aging. Assuming that the controller, after analyzing a flow, provides bot= h the action and the filter it used to define the flow, then we get to whet= her the filter is coarse-grained or fine-grained. If the filter is coarse= -grained (e.g., all TCP/80), then additional control plane activity is not = required for subsequent micro-flows that match the macro-flow's filter. B= ut, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, then= the control plane overhead becomes very large and perhaps impractical. = Many of the use cases we've talked about for SFC suggest micro-flow level p= olicy decisions. While I wouldn't suggest that we preclude centralized fine-grained policy a= s a design/implementation decision, I also feel there should be an alternat= ive to allow for distributed/fine-grained policy decisions. In that case,= the control plane's job would be to provide and maintain all of the data n= ecessary to those distributed policy decision points, but not necessarily h= andle per-micro-flow transactions. In summary, we could end up with any or all of the following operating poin= ts (as a fundamental capability or simply a deployment approach): * Centralized coarse-grained policy decision point * Centralized fine-grained policy decision point * Distributed coarse-grained policy decision point * Distributed fine-grained policy decision point Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, June 1, 2015 11:30 AM To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; Ron Parker; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Regarding the 2nd paragraph in 2.1, 2.1. Generic Requirements For deployments that would require so, SFC forwarding must be allowed even if no control protocols are enabled. Static configuration must be allowed. A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions, even when control plane components are unavailable or unreachable for some reason. "Control Element must not be required" is contrary to how OpenFlow works (a= s I understand it). So the "must" wording seems to preclude the use of OpenFlow and similar pro= tocols. Was this intended? And it is probably a bad idea to allow an uncontrolled data-plane element t= o keep running indefinitely. Would you want a switch to run without MAC lea= rning? Would you want a router to run if it lost its BGP connection? No, an= d this is why loss of control plane should generally lead to shutting down = the data plane. I understand the sentiment to allow static configuration, which I think is = fine. But if the control-plane is dynamic, loss of controller should lead t= o shut-down. -Dave From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin = Wu; mohamed.boucadair@orange.com; chri= stian.jacquenet@orange.com; walter.h= aeffner@vodafone.com; seungiklee@etri.= re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong= (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; w= alter.haeffner@vodafone.com; seungikle= e@etri.re.kr; ron_parker@affirmednetworks.com= Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. On= e for performance monitoring (availability and workload were cited), and on= e for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. From nobody Tue Jun 2 04:24:04 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07D091B30AA for ; Mon, 1 Jun 2015 11:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ1-EF6dQ4u8 for ; Mon, 1 Jun 2015 11:20:20 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id E40061B308E for ; Mon, 1 Jun 2015 11:20:19 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-3.sandvine.com (192.168.196.177) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 1 Jun 2015 14:20:19 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 1 Jun 2015 14:20:19 -0400 From: Dave Dolson To: Ron Parker , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "mohamed.boucadair@orange.com" , "christian.jacquenet@orange.com" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "Huangjing (A)" , Linda Dunbar Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwAAAGqEwA== Date: Mon, 1 Jun 2015 18:20:17 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Tue, 02 Jun 2015 04:24:01 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:20:23 -0000 Ron,=20 I don't disagree with those statements.=20 But I believe the wording in the text precludes OpenFlow "fail standalone m= ode". The wording is "... must keep on processing incoming packets according to t= he=20 SFC instructions, even when control plane components are unavailable or=20 unreachable for some reason". As I read it, this prohibits any special failure mode behavior, and hence i= s too strongly worded. There isn't even a time limit in the requirement. Must keep the SFC instruc= tions forever? Even after power cycle? As literally written, for example, C1 classification rules based on volatil= e identifiers such as IP addresses MUST be maintained forever. (Although lower-case "must" was used -- intenti= onally or in error?) Was this strong requirement really intended, or is the wording just incompl= ete? My feeling is that a more flexible approach would be valid.=20 E.g., an operator may wish to drop IP-address classification rules after a = few minutes if there is no control-plane connectivity. I think you *could* keep this wording if the classification rules themselve= s have timeouts.=20 But then the controller would always be refreshing them. -Dave -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Monday, June 01, 2015 1:42 PM To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin W= u; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.hae= ffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hi, Dave. I did catch that from your original message and I apologize for my comments= that weren't very direct wrt your point. So to complete the circle, my t= hinking is that if the policy decision point (PDP) is centralized, then you= live and die by the control plane availability. But, if the policy decis= ion points are distributed, there is a significantly increased tolerance to= temporary loss of the control plane. I'd like to retain within the archi= tecture the possibility for this distributed approach so that for any deplo= yment the relative strengths and weaknesses of centralized vs distributed c= an be weighed and decided upon. Based on which approach there is a profo= und impact on what the control plane is doing -- is it policy delivery or i= s it policy evaluation? Thanks. Ron -----Original Message----- From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Monday, June 1, 2015 11:50 AM To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu= ; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.haef= fner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: Re: Comments on draft-ww-sfc-control-plane-04 I may not have explained my point we'll enough. I only have issue with the = case of the control plane being unreachable. David Dolson Senior Software Architect, Sandvine Inc. From: Ron Parker Sent: Monday, June 1, 2015 11:43 AM To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin W= u; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; walter.hae= ffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hi, Dave. OpenFlow implementations locate the policy decision point in the controller= and hence per-flow policy analysis is supported via the control plane mess= aging. Assuming that the controller, after analyzing a flow, provides bot= h the action and the filter it used to define the flow, then we get to whet= her the filter is coarse-grained or fine-grained. If the filter is coarse= -grained (e.g., all TCP/80), then additional control plane activity is not = required for subsequent micro-flows that match the macro-flow's filter. B= ut, if fine-grained (i.e., fully qualified 5-tuple) filtering is used, then= the control plane overhead becomes very large and perhaps impractical. = Many of the use cases we've talked about for SFC suggest micro-flow level p= olicy decisions. While I wouldn't suggest that we preclude centralized fine-grained policy a= s a design/implementation decision, I also feel there should be an alternat= ive to allow for distributed/fine-grained policy decisions. In that case,= the control plane's job would be to provide and maintain all of the data n= ecessary to those distributed policy decision points, but not necessarily h= andle per-micro-flow transactions. In summary, we could end up with any or all of the following operating poin= ts (as a fundamental capability or simply a deployment approach): * Centralized coarse-grained policy decision point * Centralized fine-grained policy decision point * Distributed coarse-grained policy decision point * Distributed fine-grained policy decision point Ron From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Monday, June 1, 2015 11:30 AM To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; mohamed.bo= ucadair@orange.com; christian.jacquenet@orange.com; walter.haeffner@vodafon= e.com; seungiklee@etri.re.kr; Ron Parker; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Regarding the 2nd paragraph in 2.1, 2.1. Generic Requirements For deployments that would require so, SFC forwarding must be allowed even if no control protocols are enabled. Static configuration must be allowed. A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions, even when control plane components are unavailable or unreachable for some reason. "Control Element must not be required" is contrary to how OpenFlow works (a= s I understand it). So the "must" wording seems to preclude the use of OpenFlow and similar pro= tocols. Was this intended? And it is probably a bad idea to allow an uncontrolled data-plane element t= o keep running indefinitely. Would you want a switch to run without MAC lea= rning? Would you want a router to run if it lost its BGP connection? No, an= d this is why loss of control plane should generally lead to shutting down = the data plane. I understand the sentiment to allow static configuration, which I think is = fine. But if the control-plane is dynamic, loss of controller should lead t= o shut-down. -Dave From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] Sent: Friday, May 29, 2015 9:06 PM To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qin = Wu; mohamed.boucadair@orange.com; chri= stian.jacquenet@orange.com; walter.h= aeffner@vodafone.com; seungiklee@etri.= re.kr; ron_parker@affirmednetworks.com; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hello Dave, Thank you for your detailed consideration on the draft. I agree th= at the SF should support the capability of bidirectional chains. For exampl= e, the NAT SF may provide the new allocated address/port to the controller.= You mentioned the control plane should inform SF bidirectional chain (whi= ch path id are paired). I have question why not the SFC forwarding system = handle the paired chain itself? Performance mornitoring is a basic capability which should exist in= all interfaces C1,C2,C3. Mohamed have developed a new version of this draft and made a big p= romotion. In the new draft, C3,C4 are introduced for SF and SF proxy separa= tely. I think it may cover the related scenario. I attached it in this em= ail, please check it. Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar are = representative of Huawei on this draft. Please contact more detail to them.= Thank you very much! BR Oliver --------------------------- Huangyong (Oliver) Network research, Huawei From: Dave Dolson [mailto:ddolson@sandvine.com] Sent: Saturday, May 30, 2015 4:42 AM To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; Huangyong= (Oliver); mohamed.boucadair@orange.com; christian.jacquenet@orange.com; w= alter.haeffner@vodafone.com; seungikle= e@etri.re.kr; ron_parker@affirmednetworks.com= Subject: Comments on draft-ww-sfc-control-plane-04 Authors of draft-ww-sfc-control-plane, I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control-pla= ne-04 I have some very high-level suggestions: 1. I believe the "F" interface should be split into two interfaces. On= e for performance monitoring (availability and workload were cited), and on= e for updating classification information. Call these F1 and F2, I suppose. My reasons are that (a) as a general princ= iple, interfaces should not have multiple purposes and (b) F1 and F2 could = be communicating to different control-plane managers. 2. A control interface is required to SF components. Call it C3. This = interface is required to (a) inform the SF about bidirectional chains (i.e.= , which Path IDs are paired) and (b) inform the SF about semantics of types= of meta-data. C3 should also be connected to the SFC Proxy. I propose: 4.5 C3 Interface A service function may need information about the service paths passing through it, and may need information about specific meta-data types attached to packets on the paths. Some types of SF might be agnostic about the paths traversing them, but most transport-layer-flow-aware devices will require this configuration. When bidirectional chains are deployed, the C3 interface provisions each SF with each path identifier/path index pair that will pass through= . Each such pair is associated with an opposite-direction pair of identifier/index. Meta-data is for the benefit of SFs. The C3 interface informs the SF about the semantics of the meta-data, which would otherwise have opaque meaning. Meta-data attributes include "scope" (per-packet, per-fl= ow or per host), "mandatory" (must be understood), "bidirectional" (same value may be used in both directions), "is_qualifier" (indicates a distinct routing domain). I think there is quite a bit to explore, but I believe this starts the disc= ussion. Thoughts? David Dolson Senior Software Architect, Sandvine Inc. From nobody Tue Jun 2 04:24:06 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E380F1A90B0 for ; Tue, 2 Jun 2015 02:38:02 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YVs8datqZblg for ; Tue, 2 Jun 2015 02:37:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE161A90AA for ; Tue, 2 Jun 2015 02:37:58 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id B5A29264174; Tue, 2 Jun 2015 11:37:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7F773238055; Tue, 2 Jun 2015 11:37:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0235.001; Tue, 2 Jun 2015 11:37:50 +0200 From: To: Dave Dolson , Ron Parker , "Huangyong (Oliver)" , "sfc@ietf.org" , "Hongyu Li (Julio)" , Qin Wu , "JACQUENET Christian IMT/OLN" , "walter.haeffner@vodafone.com" , "seungiklee@etri.re.kr" , "Huangjing (A)" , "Linda Dunbar" Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwAAAGqEwAAgjFww Date: Tue, 2 Jun 2015 09:37:49 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.2.75418 Archived-At: X-Mailman-Approved-At: Tue, 02 Jun 2015 04:24:00 -0700 Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 09:38:03 -0000 Hi Dave, -05 includes this text inspired by your first message in this thread:=20 Also, this interface informs the SFC-aware SF about the semantics of a context information, which would otherwise have opaque meaning. Several attributes may be associated with a context information such as (but not limited to) the "scope" (e.g., per-packet, per-flow or per host), whether it is "mandatory" or "optional" to process flows bound to a given chain, etc. Note that a context may be mandatory for "chain 1", but optional for "chain 2". Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: lundi 1 juin 2015 20:20 > =C0=A0: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); = Qin > Wu; BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Objet=A0: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Ron, >=20 > I don't disagree with those statements. > But I believe the wording in the text precludes OpenFlow "fail standalone > mode". >=20 > The wording is "... must keep on processing incoming packets according to > the > SFC instructions, even when control plane components are unavailable or > unreachable for some reason". >=20 > As I read it, this prohibits any special failure mode behavior, and hence > is too strongly worded. >=20 > There isn't even a time limit in the requirement. Must keep the SFC > instructions forever? Even after power cycle? > As literally written, for example, C1 classification rules based on > volatile identifiers such as IP addresses > MUST be maintained forever. (Although lower-case "must" was used -- > intentionally or in error?) >=20 > Was this strong requirement really intended, or is the wording just > incomplete? [Med] -05 includes the following text:=20 A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions even during unavailability events of control plane components. SFC implementations that do not meet this requirement will suffer from another flavor of the constrained high availability issue, discussed in Section 2.3 of [RFC7498], supposed to be solved by SFC designs. The point is to encourage SFC mechanisms that do not degrade the serviceabi= lity of an SFC-enabled domain. If such requirement is not met, then service= disruption is likely...which is not desired. If activating SFC solution wi= ll lead to more unavailability events, then I do think we are not addressin= g correctly the SFC problem space (RFC7498). Does this make sense? > My feeling is that a more flexible approach would be valid. > E.g., an operator may wish to drop IP-address classification rules after = a > few minutes if there is no control-plane connectivity. [Med] Which means no service, no? Why not relying on "stale" information ma= intained by SFC data plane elements to process packets? >=20 > I think you *could* keep this wording if the classification rules > themselves have timeouts. [Med] The point about timeouts is a good point. I do personally think that = associating timeouts with classification entries will ease the management o= f classification entries (especially the removal of obsolete entries by loc= al decisions at the classifier). =20 > But then the controller would always be refreshing them. [Med] This depends on the timeout (that can be expressed in days, months, e= tc.) or be set to infinite (for entries that are supposed to last for too t= oo long periods).=20 >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, June 01, 2015 1:42 PM > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hi, Dave. >=20 > I did catch that from your original message and I apologize for my > comments that weren't very direct wrt your point. So to complete the > circle, my thinking is that if the policy decision point (PDP) is > centralized, then you live and die by the control plane availability. > But, if the policy decision points are distributed, there is a > significantly increased tolerance to temporary loss of the control plane. > I'd like to retain within the architecture the possibility for this > distributed approach so that for any deployment the relative strengths an= d > weaknesses of centralized vs distributed can be weighed and decided upon. > Based on which approach there is a profound impact on what the control > plane is doing -- is it policy delivery or is it policy evaluation? >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Monday, June 1, 2015 11:50 AM > To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: Re: Comments on draft-ww-sfc-control-plane-04 >=20 > I may not have explained my point we'll enough. I only have issue with th= e > case of the control plane being unreachable. >=20 > David Dolson > Senior Software Architect, Sandvine Inc. > From: Ron Parker > Sent: Monday, June 1, 2015 11:43 AM > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 >=20 > Hi, Dave. >=20 > OpenFlow implementations locate the policy decision point in the > controller and hence per-flow policy analysis is supported via the contro= l > plane messaging. Assuming that the controller, after analyzing a flow, > provides both the action and the filter it used to define the flow, then > we get to whether the filter is coarse-grained or fine-grained. If the > filter is coarse-grained (e.g., all TCP/80), then additional control plan= e > activity is not required for subsequent micro-flows that match the macro- > flow's filter. But, if fine-grained (i.e., fully qualified 5-tuple) > filtering is used, then the control plane overhead becomes very large and > perhaps impractical. Many of the use cases we've talked about for SFC > suggest micro-flow level policy decisions. >=20 > While I wouldn't suggest that we preclude centralized fine-grained policy > as a design/implementation decision, I also feel there should be an > alternative to allow for distributed/fine-grained policy decisions. In > that case, the control plane's job would be to provide and maintain all o= f > the data necessary to those distributed policy decision points, but not > necessarily handle per-micro-flow transactions. >=20 > In summary, we could end up with any or all of the following operating > points (as a fundamental capability or simply a deployment approach): >=20 > * Centralized coarse-grained policy decision point >=20 > * Centralized fine-grained policy decision point >=20 > * Distributed coarse-grained policy decision point >=20 > * Distributed fine-grained policy decision point >=20 > Ron >=20 >=20 > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Monday, June 1, 2015 11:30 AM > To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Ron Parker; Huangjin= g > (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Regarding the 2nd paragraph in 2.1, >=20 >=20 > 2.1. Generic Requirements >=20 > For deployments that would require so, SFC forwarding must be allowed > even if no control protocols are enabled. Static configuration must > be allowed. >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions, even when control plane components are unavailable or > unreachable for some reason. >=20 >=20 > "Control Element must not be required" is contrary to how OpenFlow works > (as I understand it). > So the "must" wording seems to preclude the use of OpenFlow and similar > protocols. Was this intended? >=20 > And it is probably a bad idea to allow an uncontrolled data-plane element > to keep running indefinitely. Would you want a switch to run without MAC > learning? Would you want a router to run if it lost its BGP connection? > No, and this is why loss of control plane should generally lead to > shutting down the data plane. >=20 >=20 > I understand the sentiment to allow static configuration, which I think i= s > fine. But if the control-plane is dynamic, loss of controller should lead > to shut-down. >=20 >=20 >=20 > -Dave >=20 >=20 >=20 >=20 > From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] > Sent: Friday, May 29, 2015 9:06 PM > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qi= n > Wu; mohamed.boucadair@orange.com; > christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; > seungiklee@etri.re.kr; > ron_parker@affirmednetworks.com; > Huangjing (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hello Dave, >=20 > Thank you for your detailed consideration on the draft. I agree > that the SF should support the capability of bidirectional chains. For > example, the NAT SF may provide the new allocated address/port to the > controller. You mentioned the control plane should inform SF > bidirectional chain (which path id are paired). I have question why not > the SFC forwarding system handle the paired chain itself? >=20 > Performance mornitoring is a basic capability which should exist > in all interfaces C1,C2,C3. >=20 > Mohamed have developed a new version of this draft and made a big > promotion. In the new draft, C3,C4 are introduced for SF and SF proxy > separately. I think it may cover the related scenario. I attached it in > this email, please check it. >=20 > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar ar= e > representative of Huawei on this draft. Please contact more detail to > them. Thank you very much! >=20 > BR > Oliver >=20 > --------------------------- > Huangyong (Oliver) > Network research, Huawei >=20 > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Saturday, May 30, 2015 4:42 AM > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > Huangyong (Oliver); > mohamed.boucadair@orange.com; > christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; > seungiklee@etri.re.kr; > ron_parker@affirmednetworks.com > Subject: Comments on draft-ww-sfc-control-plane-04 >=20 > Authors of draft-ww-sfc-control-plane, >=20 > I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control- > plane-04 >=20 > I have some very high-level suggestions: >=20 >=20 > 1. I believe the "F" interface should be split into two interfaces. > One for performance monitoring (availability and workload were cited), an= d > one for updating classification information. >=20 > Call these F1 and F2, I suppose. My reasons are that (a) as a general > principle, interfaces should not have multiple purposes and (b) F1 and F2 > could be communicating to different control-plane managers. >=20 >=20 >=20 > 2. A control interface is required to SF components. Call it C3. Thi= s > interface is required to (a) inform the SF about bidirectional chains > (i.e., which Path IDs are paired) and (b) inform the SF about semantics o= f > types of meta-data. C3 should also be connected to the SFC Proxy. >=20 > I propose: >=20 > 4.5 C3 Interface >=20 > A service function may need information about the service paths > passing through it, and may need information about specific meta-data > types attached to packets on the paths. >=20 > Some types of SF might be agnostic about the paths traversing them, bu= t > most transport-layer-flow-aware devices will require this > configuration. >=20 > When bidirectional chains are deployed, the C3 interface provisions > each SF with each path identifier/path index pair that will pass > through. > Each such pair is associated with an opposite-direction pair of > identifier/index. >=20 > Meta-data is for the benefit of SFs. The C3 interface informs the SF > about the semantics of the meta-data, which would otherwise have > opaque meaning. Meta-data attributes include "scope" (per-packet, per- > flow > or per host), "mandatory" (must be understood), "bidirectional" (same > value may be used in both directions), "is_qualifier" (indicates a > distinct routing domain). >=20 >=20 > I think there is quite a bit to explore, but I believe this starts the > discussion. > Thoughts? >=20 >=20 > David Dolson > Senior Software Architect, Sandvine Inc. From nobody Tue Jun 2 09:13:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9939C1B2A89 for ; Tue, 2 Jun 2015 09:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3s_oebhz2Xek for ; Tue, 2 Jun 2015 09:13:48 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 081CB1B2A6A for ; Tue, 2 Jun 2015 09:13:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 12:13:47 -0400 From: Dave Dolson To: "mohamed.boucadair@orange.com" , Ron Parker , "Huangyong (Oliver)" , "sfc@ietf.org" Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwAAAGqEwAAgjFwwAAkfLzA= Date: Tue, 2 Jun 2015 16:13:46 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:13:51 -0000 [trimmed the list a bit to avoid the mailing list holding up the message] Med, Thanks for including changes in the document. You asked me a question: I wrote: > My feeling is that a more flexible approach would be valid. > E.g., an operator may wish to drop IP-address classification rules after = a > few minutes if there is no control-plane connectivity. [Med] Which means no service, no? Why not relying on "stale" information ma= intained by SFC data plane elements to process packets? What is "no service"? I think this could mean passing packets without apply= ing any SF functions, or applying a default set of SF functions. It could mean falling back to a CLI-provisioned forwarding policy. The question of "stale" information is exactly the point. If the control plane is not available, any volatile data might be stale. Concrete example: using IP addresses to classify subscriber policy, when IP= address assignment is dynamic. Which is a more valid way to think of stale state? (a) assume previous state is still the current state? The wrong chaining mi= ght be applied. (b) assume current state is unknowable? A default chaining should be applie= d. I don't know the answer. Neither is correct. I think operators must make th= e decision, based on failure analysis and=20 choosing the lesser evil of applying a default policy or possibly the wrong= policy. I think a pragmatic approach is to assume the previous state is valid for s= ome period of time, and only after the time expires, fall back to a default forwarding configur= ation. This would allow temporary network interruption or reboot of a controller w= ithout any down-side. I can think of two ways to implement this: 1. In a global sense, revert to a default rule set after a period of contro= ller interruption 2. On a per-rule sense, allowing timeouts on each rule. Controller can put = shorter timeouts on more volatile rules. I'm mainly thinking of classifier state, but I think similar concepts apply= to SFFs. A cohesive failure mode should be designed for the entire network. No operator wants to ever experience this, but... How do you feel about adding the word "temporary" ?=20 A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions even during temporary unavailability events of control plan= e ^^^^^^^^^ components. SFC implementations that do not meet this requirement will suffer from another flavor of the constrained high availability issue, discussed in Section 2.3 of [RFC7498], supposed to be solved by SFC designs. -Dave -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Tuesday, June 02, 2015 5:38 AM To: Dave Dolson; Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (J= ulio); Qin Wu; JACQUENET Christian IMT/OLN; walter.haeffner@vodafone.com; s= eungiklee@etri.re.kr; Huangjing (A); Linda Dunbar Subject: RE: Comments on draft-ww-sfc-control-plane-04 Hi Dave, -05 includes this text inspired by your first message in this thread:=20 Also, this interface informs the SFC-aware SF about the semantics of a context information, which would otherwise have opaque meaning. Several attributes may be associated with a context information such as (but not limited to) the "scope" (e.g., per-packet, per-flow or per host), whether it is "mandatory" or "optional" to process flows bound to a given chain, etc. Note that a context may be mandatory for "chain 1", but optional for "chain 2". Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: lundi 1 juin 2015 20:20 > =C0=A0: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); = Qin > Wu; BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Objet=A0: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Ron, >=20 > I don't disagree with those statements. > But I believe the wording in the text precludes OpenFlow "fail standalone > mode". >=20 > The wording is "... must keep on processing incoming packets according to > the > SFC instructions, even when control plane components are unavailable or > unreachable for some reason". >=20 > As I read it, this prohibits any special failure mode behavior, and hence > is too strongly worded. >=20 > There isn't even a time limit in the requirement. Must keep the SFC > instructions forever? Even after power cycle? > As literally written, for example, C1 classification rules based on > volatile identifiers such as IP addresses > MUST be maintained forever. (Although lower-case "must" was used -- > intentionally or in error?) >=20 > Was this strong requirement really intended, or is the wording just > incomplete? [Med] -05 includes the following text:=20 A permanent association between an SFC data plane element with a Control Element must not be required; specifically, the SFC-enabled domain must keep on processing incoming packets according to the SFC instructions even during unavailability events of control plane components. SFC implementations that do not meet this requirement will suffer from another flavor of the constrained high availability issue, discussed in Section 2.3 of [RFC7498], supposed to be solved by SFC designs. The point is to encourage SFC mechanisms that do not degrade the serviceabi= lity of an SFC-enabled domain. If such requirement is not met, then service= disruption is likely...which is not desired. If activating SFC solution wi= ll lead to more unavailability events, then I do think we are not addressin= g correctly the SFC problem space (RFC7498). Does this make sense? > My feeling is that a more flexible approach would be valid. > E.g., an operator may wish to drop IP-address classification rules after = a > few minutes if there is no control-plane connectivity. [Med] Which means no service, no? Why not relying on "stale" information ma= intained by SFC data plane elements to process packets? >=20 > I think you *could* keep this wording if the classification rules > themselves have timeouts. [Med] The point about timeouts is a good point. I do personally think that = associating timeouts with classification entries will ease the management o= f classification entries (especially the removal of obsolete entries by loc= al decisions at the classifier). =20 > But then the controller would always be refreshing them. [Med] This depends on the timeout (that can be expressed in days, months, e= tc.) or be set to infinite (for entries that are supposed to last for too t= oo long periods).=20 >=20 >=20 > -Dave >=20 >=20 >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Monday, June 01, 2015 1:42 PM > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hi, Dave. >=20 > I did catch that from your original message and I apologize for my > comments that weren't very direct wrt your point. So to complete the > circle, my thinking is that if the policy decision point (PDP) is > centralized, then you live and die by the control plane availability. > But, if the policy decision points are distributed, there is a > significantly increased tolerance to temporary loss of the control plane. > I'd like to retain within the architecture the possibility for this > distributed approach so that for any deployment the relative strengths an= d > weaknesses of centralized vs distributed can be weighed and decided upon. > Based on which approach there is a profound impact on what the control > plane is doing -- is it policy delivery or is it policy evaluation? >=20 > Thanks. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Monday, June 1, 2015 11:50 AM > To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: Re: Comments on draft-ww-sfc-control-plane-04 >=20 > I may not have explained my point we'll enough. I only have issue with th= e > case of the control plane being unreachable. >=20 > David Dolson > Senior Software Architect, Sandvine Inc. > From: Ron Parker > Sent: Monday, June 1, 2015 11:43 AM > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 >=20 > Hi, Dave. >=20 > OpenFlow implementations locate the policy decision point in the > controller and hence per-flow policy analysis is supported via the contro= l > plane messaging. Assuming that the controller, after analyzing a flow, > provides both the action and the filter it used to define the flow, then > we get to whether the filter is coarse-grained or fine-grained. If the > filter is coarse-grained (e.g., all TCP/80), then additional control plan= e > activity is not required for subsequent micro-flows that match the macro- > flow's filter. But, if fine-grained (i.e., fully qualified 5-tuple) > filtering is used, then the control plane overhead becomes very large and > perhaps impractical. Many of the use cases we've talked about for SFC > suggest micro-flow level policy decisions. >=20 > While I wouldn't suggest that we preclude centralized fine-grained policy > as a design/implementation decision, I also feel there should be an > alternative to allow for distributed/fine-grained policy decisions. In > that case, the control plane's job would be to provide and maintain all o= f > the data necessary to those distributed policy decision points, but not > necessarily handle per-micro-flow transactions. >=20 > In summary, we could end up with any or all of the following operating > points (as a fundamental capability or simply a deployment approach): >=20 > * Centralized coarse-grained policy decision point >=20 > * Centralized fine-grained policy decision point >=20 > * Distributed coarse-grained policy decision point >=20 > * Distributed fine-grained policy decision point >=20 > Ron >=20 >=20 > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Monday, June 1, 2015 11:30 AM > To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Ron Parker; Huangjin= g > (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Regarding the 2nd paragraph in 2.1, >=20 >=20 > 2.1. Generic Requirements >=20 > For deployments that would require so, SFC forwarding must be allowed > even if no control protocols are enabled. Static configuration must > be allowed. >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions, even when control plane components are unavailable or > unreachable for some reason. >=20 >=20 > "Control Element must not be required" is contrary to how OpenFlow works > (as I understand it). > So the "must" wording seems to preclude the use of OpenFlow and similar > protocols. Was this intended? >=20 > And it is probably a bad idea to allow an uncontrolled data-plane element > to keep running indefinitely. Would you want a switch to run without MAC > learning? Would you want a router to run if it lost its BGP connection? > No, and this is why loss of control plane should generally lead to > shutting down the data plane. >=20 >=20 > I understand the sentiment to allow static configuration, which I think i= s > fine. But if the control-plane is dynamic, loss of controller should lead > to shut-down. >=20 >=20 >=20 > -Dave >=20 >=20 >=20 >=20 > From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] > Sent: Friday, May 29, 2015 9:06 PM > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Qi= n > Wu; mohamed.boucadair@orange.com; > christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; > seungiklee@etri.re.kr; > ron_parker@affirmednetworks.com; > Huangjing (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hello Dave, >=20 > Thank you for your detailed consideration on the draft. I agree > that the SF should support the capability of bidirectional chains. For > example, the NAT SF may provide the new allocated address/port to the > controller. You mentioned the control plane should inform SF > bidirectional chain (which path id are paired). I have question why not > the SFC forwarding system handle the paired chain itself? >=20 > Performance mornitoring is a basic capability which should exist > in all interfaces C1,C2,C3. >=20 > Mohamed have developed a new version of this draft and made a big > promotion. In the new draft, C3,C4 are introduced for SF and SF proxy > separately. I think it may cover the related scenario. I attached it in > this email, please check it. >=20 > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar ar= e > representative of Huawei on this draft. Please contact more detail to > them. Thank you very much! >=20 > BR > Oliver >=20 > --------------------------- > Huangyong (Oliver) > Network research, Huawei >=20 > From: Dave Dolson [mailto:ddolson@sandvine.com] > Sent: Saturday, May 30, 2015 4:42 AM > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > Huangyong (Oliver); > mohamed.boucadair@orange.com; > christian.jacquenet@orange.com; > walter.haeffner@vodafone.com; > seungiklee@etri.re.kr; > ron_parker@affirmednetworks.com > Subject: Comments on draft-ww-sfc-control-plane-04 >=20 > Authors of draft-ww-sfc-control-plane, >=20 > I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control- > plane-04 >=20 > I have some very high-level suggestions: >=20 >=20 > 1. I believe the "F" interface should be split into two interfaces. > One for performance monitoring (availability and workload were cited), an= d > one for updating classification information. >=20 > Call these F1 and F2, I suppose. My reasons are that (a) as a general > principle, interfaces should not have multiple purposes and (b) F1 and F2 > could be communicating to different control-plane managers. >=20 >=20 >=20 > 2. A control interface is required to SF components. Call it C3. Thi= s > interface is required to (a) inform the SF about bidirectional chains > (i.e., which Path IDs are paired) and (b) inform the SF about semantics o= f > types of meta-data. C3 should also be connected to the SFC Proxy. >=20 > I propose: >=20 > 4.5 C3 Interface >=20 > A service function may need information about the service paths > passing through it, and may need information about specific meta-data > types attached to packets on the paths. >=20 > Some types of SF might be agnostic about the paths traversing them, bu= t > most transport-layer-flow-aware devices will require this > configuration. >=20 > When bidirectional chains are deployed, the C3 interface provisions > each SF with each path identifier/path index pair that will pass > through. > Each such pair is associated with an opposite-direction pair of > identifier/index. >=20 > Meta-data is for the benefit of SFs. The C3 interface informs the SF > about the semantics of the meta-data, which would otherwise have > opaque meaning. Meta-data attributes include "scope" (per-packet, per- > flow > or per host), "mandatory" (must be understood), "bidirectional" (same > value may be used in both directions), "is_qualifier" (indicates a > distinct routing domain). >=20 >=20 > I think there is quite a bit to explore, but I believe this starts the > discussion. > Thoughts? >=20 >=20 > David Dolson > Senior Software Architect, Sandvine Inc. From nobody Tue Jun 2 09:27:57 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37481B2B03 for ; Tue, 2 Jun 2015 09:27:55 -0700 (PDT) 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 LY1OcYfUummh for ; Tue, 2 Jun 2015 09:27:52 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB561B2ACE for ; Tue, 2 Jun 2015 09:27:52 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0224.002; Tue, 2 Jun 2015 09:27:51 -0700 From: Ron Parker To: Dave Dolson Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwAAAGqEwAAgjFwwAAkfLzAABeRJDw== Date: Tue, 2 Jun 2015 16:27:51 +0000 Message-ID: References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mohamed.boucadair@orange.com" , "Huangyong \(Oliver\)" , "sfc@ietf.org" Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 16:27:56 -0000 I agree that a likely pragmatic approach is to hold the last known policy/s= tate as received from CP for some time and then fall back to a default poli= cy after some timeout.=20 Ron > On Jun 2, 2015, at 12:13 PM, Dave Dolson wrote: >=20 > [trimmed the list a bit to avoid the mailing list holding up the message] > Med, > Thanks for including changes in the document. >=20 > You asked me a question: >=20 > I wrote: >> My feeling is that a more flexible approach would be valid. >> E.g., an operator may wish to drop IP-address classification rules after= a >> few minutes if there is no control-plane connectivity. >=20 > [Med] Which means no service, no? Why not relying on "stale" information = maintained by SFC data plane elements to process packets? >=20 > What is "no service"? I think this could mean passing packets without app= lying any SF functions, > or applying a default set of SF functions. > It could mean falling back to a CLI-provisioned forwarding policy. >=20 > The question of "stale" information is exactly the point. > If the control plane is not available, any volatile data might be stale. > Concrete example: using IP addresses to classify subscriber policy, when = IP address assignment is dynamic. >=20 > Which is a more valid way to think of stale state? > (a) assume previous state is still the current state? The wrong chaining = might be applied. > (b) assume current state is unknowable? A default chaining should be appl= ied. >=20 > I don't know the answer. Neither is correct. I think operators must make = the decision, based on failure analysis and=20 > choosing the lesser evil of applying a default policy or possibly the wro= ng policy. >=20 > I think a pragmatic approach is to assume the previous state is valid for= some period of time, > and only after the time expires, fall back to a default forwarding config= uration. > This would allow temporary network interruption or reboot of a controller= without any down-side. >=20 > I can think of two ways to implement this: > 1. In a global sense, revert to a default rule set after a period of cont= roller interruption > 2. On a per-rule sense, allowing timeouts on each rule. Controller can pu= t shorter timeouts on more volatile rules. >=20 > I'm mainly thinking of classifier state, but I think similar concepts app= ly to SFFs. > A cohesive failure mode should be designed for the entire network. > No operator wants to ever experience this, but... >=20 > How do you feel about adding the word "temporary" ?=20 >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions even during temporary unavailability events of control pla= ne > ^^^^^^^^^ > components. SFC implementations that do not meet this requirement > will suffer from another flavor of the constrained high availability > issue, discussed in Section 2.3 of [RFC7498], supposed to be solved > by SFC designs. >=20 >=20 > -Dave >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]= =20 > Sent: Tuesday, June 02, 2015 5:38 AM > To: Dave Dolson; Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li = (Julio); Qin Wu; JACQUENET Christian IMT/OLN; walter.haeffner@vodafone.com;= seungiklee@etri.re.kr; Huangjing (A); Linda Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hi Dave, >=20 > -05 includes this text inspired by your first message in this thread:=20 >=20 > Also, this interface informs the SFC-aware SF about the semantics of > a context information, which would otherwise have opaque meaning. > Several attributes may be associated with a context information such > as (but not limited to) the "scope" (e.g., per-packet, per-flow or > per host), whether it is "mandatory" or "optional" to process flows > bound to a given chain, etc. Note that a context may be mandatory > for "chain 1", but optional for "chain 2". >=20 > Please see inline. >=20 > Cheers, > Med >=20 >> -----Message d'origine----- >> De : Dave Dolson [mailto:ddolson@sandvine.com] >> Envoy=E9 : lundi 1 juin 2015 20:20 >> =C0 : Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Q= in >> Wu; BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; >> walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Lind= a >> Dunbar >> Objet : RE: Comments on draft-ww-sfc-control-plane-04 >>=20 >> Ron, >>=20 >> I don't disagree with those statements. >> But I believe the wording in the text precludes OpenFlow "fail standalon= e >> mode". >>=20 >> The wording is "... must keep on processing incoming packets according t= o >> the >> SFC instructions, even when control plane components are unavailable or >> unreachable for some reason". >>=20 >> As I read it, this prohibits any special failure mode behavior, and henc= e >> is too strongly worded. >>=20 >> There isn't even a time limit in the requirement. Must keep the SFC >> instructions forever? Even after power cycle? >> As literally written, for example, C1 classification rules based on >> volatile identifiers such as IP addresses >> MUST be maintained forever. (Although lower-case "must" was used -- >> intentionally or in error?) >>=20 >> Was this strong requirement really intended, or is the wording just >> incomplete? >=20 > [Med] -05 includes the following text:=20 >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions even during unavailability events of control plane > components. SFC implementations that do not meet this requirement > will suffer from another flavor of the constrained high availability > issue, discussed in Section 2.3 of [RFC7498], supposed to be solved > by SFC designs. >=20 > The point is to encourage SFC mechanisms that do not degrade the servicea= bility of an SFC-enabled domain. If such requirement is not met, then servi= ce disruption is likely...which is not desired. If activating SFC solution = will lead to more unavailability events, then I do think we are not address= ing correctly the SFC problem space (RFC7498). >=20 > Does this make sense? >=20 >> My feeling is that a more flexible approach would be valid. >> E.g., an operator may wish to drop IP-address classification rules after= a >> few minutes if there is no control-plane connectivity. >=20 > [Med] Which means no service, no? Why not relying on "stale" information = maintained by SFC data plane elements to process packets? >=20 >>=20 >> I think you *could* keep this wording if the classification rules >> themselves have timeouts. >=20 > [Med] The point about timeouts is a good point. I do personally think tha= t associating timeouts with classification entries will ease the management= of classification entries (especially the removal of obsolete entries by l= ocal decisions at the classifier). =20 >=20 >> But then the controller would always be refreshing them. >=20 > [Med] This depends on the timeout (that can be expressed in days, months,= etc.) or be set to infinite (for entries that are supposed to last for too= too long periods).=20 >=20 >>=20 >>=20 >> -Dave >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >> Sent: Monday, June 01, 2015 1:42 PM >> To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qi= n >> Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Lind= a >> Dunbar >> Subject: RE: Comments on draft-ww-sfc-control-plane-04 >>=20 >> Hi, Dave. >>=20 >> I did catch that from your original message and I apologize for my >> comments that weren't very direct wrt your point. So to complete the >> circle, my thinking is that if the policy decision point (PDP) is >> centralized, then you live and die by the control plane availability. >> But, if the policy decision points are distributed, there is a >> significantly increased tolerance to temporary loss of the control plane= . >> I'd like to retain within the architecture the possibility for this >> distributed approach so that for any deployment the relative strengths a= nd >> weaknesses of centralized vs distributed can be weighed and decided upon= . >> Based on which approach there is a profound impact on what the control >> plane is doing -- is it policy delivery or is it policy evaluation? >>=20 >> Thanks. >>=20 >> Ron >>=20 >>=20 >> -----Original Message----- >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Monday, June 1, 2015 11:50 AM >> To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin >> Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Lind= a >> Dunbar >> Subject: Re: Comments on draft-ww-sfc-control-plane-04 >>=20 >> I may not have explained my point we'll enough. I only have issue with t= he >> case of the control plane being unreachable. >>=20 >> David Dolson >> Senior Software Architect, Sandvine Inc. >> From: Ron Parker >> Sent: Monday, June 1, 2015 11:43 AM >> To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qi= n >> Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Lind= a >> Dunbar >> Subject: RE: Comments on draft-ww-sfc-control-plane-04 >>=20 >>=20 >> Hi, Dave. >>=20 >> OpenFlow implementations locate the policy decision point in the >> controller and hence per-flow policy analysis is supported via the contr= ol >> plane messaging. Assuming that the controller, after analyzing a flow, >> provides both the action and the filter it used to define the flow, then >> we get to whether the filter is coarse-grained or fine-grained. If the >> filter is coarse-grained (e.g., all TCP/80), then additional control pla= ne >> activity is not required for subsequent micro-flows that match the macro= - >> flow's filter. But, if fine-grained (i.e., fully qualified 5-tuple) >> filtering is used, then the control plane overhead becomes very large an= d >> perhaps impractical. Many of the use cases we've talked about for SFC >> suggest micro-flow level policy decisions. >>=20 >> While I wouldn't suggest that we preclude centralized fine-grained polic= y >> as a design/implementation decision, I also feel there should be an >> alternative to allow for distributed/fine-grained policy decisions. In >> that case, the control plane's job would be to provide and maintain all = of >> the data necessary to those distributed policy decision points, but not >> necessarily handle per-micro-flow transactions. >>=20 >> In summary, we could end up with any or all of the following operating >> points (as a fundamental capability or simply a deployment approach): >>=20 >> * Centralized coarse-grained policy decision point >>=20 >> * Centralized fine-grained policy decision point >>=20 >> * Distributed coarse-grained policy decision point >>=20 >> * Distributed fine-grained policy decision point >>=20 >> Ron >>=20 >>=20 >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Monday, June 1, 2015 11:30 AM >> To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; >> mohamed.boucadair@orange.com; christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Ron Parker; Huangji= ng >> (A); Linda Dunbar >> Subject: RE: Comments on draft-ww-sfc-control-plane-04 >>=20 >> Regarding the 2nd paragraph in 2.1, >>=20 >>=20 >> 2.1. Generic Requirements >>=20 >> For deployments that would require so, SFC forwarding must be allowed >> even if no control protocols are enabled. Static configuration must >> be allowed. >>=20 >> A permanent association between an SFC data plane element with a >> Control Element must not be required; specifically, the SFC-enabled >> domain must keep on processing incoming packets according to the SFC >> instructions, even when control plane components are unavailable or >> unreachable for some reason. >>=20 >>=20 >> "Control Element must not be required" is contrary to how OpenFlow works >> (as I understand it). >> So the "must" wording seems to preclude the use of OpenFlow and similar >> protocols. Was this intended? >>=20 >> And it is probably a bad idea to allow an uncontrolled data-plane elemen= t >> to keep running indefinitely. Would you want a switch to run without MAC >> learning? Would you want a router to run if it lost its BGP connection? >> No, and this is why loss of control plane should generally lead to >> shutting down the data plane. >>=20 >>=20 >> I understand the sentiment to allow static configuration, which I think = is >> fine. But if the control-plane is dynamic, loss of controller should lea= d >> to shut-down. >>=20 >>=20 >>=20 >> -Dave >>=20 >>=20 >>=20 >>=20 >> From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] >> Sent: Friday, May 29, 2015 9:06 PM >> To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); Q= in >> Wu; mohamed.boucadair@orange.com; >> christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; >> seungiklee@etri.re.kr; >> ron_parker@affirmednetworks.com; >> Huangjing (A); Linda Dunbar >> Subject: RE: Comments on draft-ww-sfc-control-plane-04 >>=20 >> Hello Dave, >>=20 >> Thank you for your detailed consideration on the draft. I agree >> that the SF should support the capability of bidirectional chains. For >> example, the NAT SF may provide the new allocated address/port to the >> controller. You mentioned the control plane should inform SF >> bidirectional chain (which path id are paired). I have question why not >> the SFC forwarding system handle the paired chain itself? >>=20 >> Performance mornitoring is a basic capability which should exist >> in all interfaces C1,C2,C3. >>=20 >> Mohamed have developed a new version of this draft and made a big >> promotion. In the new draft, C3,C4 are introduced for SF and SF proxy >> separately. I think it may cover the related scenario. I attached it i= n >> this email, please check it. >>=20 >> Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar ar= e >> representative of Huawei on this draft. Please contact more detail to >> them. Thank you very much! >>=20 >> BR >> Oliver >>=20 >> --------------------------- >> Huangyong (Oliver) >> Network research, Huawei >>=20 >> From: Dave Dolson [mailto:ddolson@sandvine.com] >> Sent: Saturday, May 30, 2015 4:42 AM >> To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; >> Huangyong (Oliver); >> mohamed.boucadair@orange.com; >> christian.jacquenet@orange.com; >> walter.haeffner@vodafone.com; >> seungiklee@etri.re.kr; >> ron_parker@affirmednetworks.com >> Subject: Comments on draft-ww-sfc-control-plane-04 >>=20 >> Authors of draft-ww-sfc-control-plane, >>=20 >> I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control- >> plane-04 >>=20 >> I have some very high-level suggestions: >>=20 >>=20 >> 1. I believe the "F" interface should be split into two interfaces. >> One for performance monitoring (availability and workload were cited), a= nd >> one for updating classification information. >>=20 >> Call these F1 and F2, I suppose. My reasons are that (a) as a general >> principle, interfaces should not have multiple purposes and (b) F1 and F= 2 >> could be communicating to different control-plane managers. >>=20 >>=20 >>=20 >> 2. A control interface is required to SF components. Call it C3. Th= is >> interface is required to (a) inform the SF about bidirectional chains >> (i.e., which Path IDs are paired) and (b) inform the SF about semantics = of >> types of meta-data. C3 should also be connected to the SFC Proxy. >>=20 >> I propose: >>=20 >> 4.5 C3 Interface >>=20 >> A service function may need information about the service paths >> passing through it, and may need information about specific meta-data >> types attached to packets on the paths. >>=20 >> Some types of SF might be agnostic about the paths traversing them, bu= t >> most transport-layer-flow-aware devices will require this >> configuration. >>=20 >> When bidirectional chains are deployed, the C3 interface provisions >> each SF with each path identifier/path index pair that will pass >> through. >> Each such pair is associated with an opposite-direction pair of >> identifier/index. >>=20 >> Meta-data is for the benefit of SFs. The C3 interface informs the SF >> about the semantics of the meta-data, which would otherwise have >> opaque meaning. Meta-data attributes include "scope" (per-packet, per- >> flow >> or per host), "mandatory" (must be understood), "bidirectional" (same >> value may be used in both directions), "is_qualifier" (indicates a >> distinct routing domain). >>=20 >>=20 >> I think there is quite a bit to explore, but I believe this starts the >> discussion. >> Thoughts? >>=20 >>=20 >> David Dolson >> Senior Software Architect, Sandvine Inc. >=20 From nobody Tue Jun 2 12:57:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78DB31ACE69; Tue, 2 Jun 2015 12:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcYaeWQ2Qftf; Tue, 2 Jun 2015 12:57:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5F71A1B86; Tue, 2 Jun 2015 12:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8350; q=dns/txt; s=iport; t=1433275025; x=1434484625; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gm+OwZ8pONIgcZoG/y+DSMxi4moV2EotNxAOZ4fQ0QA=; b=UcklwIw/CdkLYi5akGZhdmam0uFTWkQDhHmAEnPwMf/PzZUULLfZbrGK icggTb55Va9XrFcag3QWMKzbASYBa/WSNYIloNgnkzocDois9PjjBrrMK PgW6yCngSuFd7WvQ7d/YmmqpYKqdq4KuzQRzci5LDku+gabuhA2GiX1FA I=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BrBQAxCW5V/4ENJK1bgkVLgTIGgxi6bYhAAoFDTAEBAQEBAYELhCIBAQEDASNWBQsCAQgSBioCAiERFw4CBA4FDogKAwoItlKeXQ2FLQEBAQEBAQEBAQEBAQEBAQEBAQEBAReLQ4JNgjkHgmgvgRYFkxCCEoFDhWWBXIErjwiDLINZI2GBWoE9bwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,541,1427760000"; d="asc'?scan'208,217";a="16918063" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 02 Jun 2015 19:57:04 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t52Jv4QZ004831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 19:57:04 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 14:57:03 -0500 From: "Carlos Pignataro (cpignata)" To: Kathleen Moriarty Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmVFPkEdW80Ovx0KvMcwtrOuud52RxuAAgAAkHYCAAEDsgIAABQWAgAAImYCAB8Q/AA== Date: Tue, 2 Jun 2015 19:57:03 +0000 Message-ID: References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> <55677F7D.1070807@joelhalpern.com> <2F403ACA-D45B-4184-9E39-9DE527DC7A35@gmail.com> In-Reply-To: <2F403ACA-D45B-4184-9E39-9DE527DC7A35@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.26] Content-Type: multipart/signed; boundary="Apple-Mail=_2DF3E372-1BA0-4870-B22D-F67724CE3E74"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , Alia Atlas , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 02 Jun 2015 19:57:07 -0000 --Apple-Mail=_2DF3E372-1BA0-4870-B22D-F67724CE3E74 Content-Type: multipart/alternative; boundary="Apple-Mail=_82AE1CC6-72C9-44B9-949D-7FEC9AA6D59F" --Apple-Mail=_82AE1CC6-72C9-44B9-949D-7FEC9AA6D59F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Kathleen, We iterated with Alia in trying to get a more condensed and to-the-point = version of the text. Here=E2=80=99s a proposal that we believe can help address your concern: "A classifier may have privileged access to information about a packet = that is then communicated in the metadata. The threat of leaking this = private data needs to be considered [RFC 6973]. As one example, if = private data is represented by an identifier, then a new identifier can = be allocated, such that the mapping from the private data to the new = identifier is not broadly shared.=E2=80=9D With [RFC 6973] as an Informational reference. Does this help? Thanks, =E2=80=94 Carlos. > On May 28, 2015, at 5:20 PM, Kathleen Moriarty = wrote: >=20 > I can see your point of view, but that does not mean that a warning is = not needed. Someone may not be aware that their plain text traffic = could be used in the ways that are possible. Alia's suggested text = addresses this possible concern and is much appreciated to remove my = discuss. >=20 > Let me know if/when this text is incorporated. >=20 > Best regards, > Kathleen --Apple-Mail=_82AE1CC6-72C9-44B9-949D-7FEC9AA6D59F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Kathleen,

We iterated with Alia in trying to get a more condensed and = to-the-point version of the text.

Here=E2=80=99s a proposal that we = believe can help address your concern:

"A classifier may have privileged = access to information about a packet that is then communicated in the = metadata.   The threat of leaking this private data needs to = be considered [RFC 6973]. As one example, if private data is = represented by an identifier, then a new identifier can be allocated, = such that the mapping from the private data to the new identifier = is not broadly shared.=E2=80=9D

With [RFC 6973] as an Informational reference.

Does this = help?

Thanks,

=E2=80=94 Carlos.

On = May 28, 2015, at 5:20 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I can see your point of view, but that does not = mean that a warning is not needed.  Someone may not be aware that = their plain text traffic could be used in the ways that are possible. =  Alia's suggested text addresses this possible concern and is much = appreciated to remove my discuss.

Let me know if/when this text is = incorporated.

Best regards,
Kathleen

= --Apple-Mail=_82AE1CC6-72C9-44B9-949D-7FEC9AA6D59F-- --Apple-Mail=_2DF3E372-1BA0-4870-B22D-F67724CE3E74 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 iQIcBAEBCAAGBQJVbgqQAAoJEIXgpQGOZny9BQMP/18BYeLaCI3QjUszNQ1bgtOL Ytg0MbJQ39oJmN2lIF0/384K4vwA5u0VOtncFDitZ4pU0Q4DqE8MR0kQCI9AFKoo jj+z3veOvAkYda5A2ib5/S1Pib3ytbGU+hy27nz8yd/Fcf2S5UTLupnPKmYU1QE2 OlYAPsR6n7lOFsAG68CVVUt55Kz9OBPKUfa/TZ2VXdRu+ls04oN86l8WkpMF4XJ6 pWfHZmSAHVmlDHOLZwnr3w+eHtDjma+1oVPQwCzTRe87O4dSNOYKGuKmNO9KHjuE qfcjqoJHwEKrzv7jJEF0tpzYI7k0dr/OCeW8ncXoA1zBTJS4EEiaXIm7Pf73osMl o0Z9qhUyom+qINHJBZX3sg646fDWVg63Wv+7kfqrX/Kovm4QGRPbp/UkH+hew3ST A6+5ym9Fk01f5xK8TWblyGQrqxRoEdINQWBOpi9jIKdjTBCy8MQsINGwxwJfY+vZ gxbwMhqbxj7dvQnRJoWnixLJ2Q3xY8jzIlQe+HJYwixJKgmTNBV7ewMc5Asy2zKG UWkvnjnGltfHZHKa0fYj+xXpaCsUKgIIk1OBuyMU3s/0JOlv14kF0hbXpeFKPFQA 1EnPz3jsgTjRzZDNfAND/038oeoatumb/2pSdH4RUE5/lr5me9G3UbHlQl0HEPjo qnw8u/fGNqEl8evYsnid =8hA5 -----END PGP SIGNATURE----- --Apple-Mail=_2DF3E372-1BA0-4870-B22D-F67724CE3E74-- From nobody Tue Jun 2 12:59:06 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125C1B2AAF; Tue, 2 Jun 2015 12:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmj1vFKOfDCZ; Tue, 2 Jun 2015 12:59:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2BBD1B2F18; Tue, 2 Jun 2015 12:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32065; q=dns/txt; s=iport; t=1433275079; x=1434484679; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=t9sZai20NCPu68jo8IMpOLpbfWVlmIsgw0ugT68jN90=; b=F4Ii3wGWq4bpoOcoTvq67EJfH8cplx+nuLhJW/IbAwk8EprbaTGQ6hOx VwLi6nVufOpfFVZpiRHzmbkK6WVDeJysOB7SJ0jJHNJMj2HcNRRVy/isx 56XzZyeOhS31jzsJF/86tb62Ya1H3jnfJgr6jKZKxo1mlpbot0iAUdZ4V s=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B2BADrCW5V/4UNJK1bgkVLVF4Ggxi6bWYJgVqFLUoCgUM4FAEBAQEBAQGBCoQiAQEBAwEjRBIFCwIBCBIGIAEJAgIyFw4CBA4FCQUNiAoIDbZCpBYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXi0OENAEBTAQHgmgvgRYFhmuJZ4I+ghKBQ4dBgSuSNINZI2GBWoE9bwGBCzqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,541,1427760000"; d="asc'?scan'208,217";a="219939" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-5.cisco.com with ESMTP; 02 Jun 2015 19:57:57 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t52Jvv3I032642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Jun 2015 19:57:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 2 Jun 2015 14:57:57 -0500 From: "Carlos Pignataro (cpignata)" To: Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Z/h6A Date: Tue, 2 Jun 2015 19:57:56 +0000 Message-ID: <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> In-Reply-To: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.26] Content-Type: multipart/signed; boundary="Apple-Mail=_9E6545A8-AB83-45E1-9A3E-A4270DEF0AC5"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "draft-ietf-sfc-architecture.ad@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.shepherd@ietf.org" , "draft-ietf-sfc-architecture@ietf.org" , The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 02 Jun 2015 19:59:03 -0000 --Apple-Mail=_9E6545A8-AB83-45E1-9A3E-A4270DEF0AC5 Content-Type: multipart/alternative; boundary="Apple-Mail=_E709387D-A68E-4653-A471-4F92AF39E360" --Apple-Mail=_E709387D-A68E-4653-A471-4F92AF39E360 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Stephen, Let me reset the conversation, focusing specifically on the two = DISCUSSes you have: > On May 28, 2015, at 8:52 AM, Stephen Farrell = wrote: >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 >=20 > (1) I note the charter calls for this deliverable to "provide > a description of... security models" The charter also > generally notes that "The SFC WG will closely consider and > address the management and security implications when > documenting these deliverables." My conclusion is that this > deliverable needs to reflect the results of a security > analysis that the wg are suppoed to have carried out but that > it's currently too vague only saying that solutions need to > consider this. (Essentially this is a continuation of the > mail threads from the secdir review [1] and a satisfactory > resolution of that will probably resolve this.) >=20 > [1] > https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html = Regarding (1), you say: Essentially this is a continuation of the mail threads from the secdir review [1] and a satisfactory resolution of that will probably resolve this" And it seems from [2] there is a satisfactory resolution: Thanks for all these updates; I think they go a long way to addressing = the concerns that were raised during the secdir review. -Ben [2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html >=20 > (2) Metadata that contains information that is protected in > the data plane SHOULD be equally well protected when passed > about by SFC. I hope that's acceptable and documented. I'm > not sure myself if "passed about" ought also include within a > device but maybe it should really. But at minimum, I do > think you need to define confidentiality and origin > authentication services for SFC metadata and/or for the SFC > encapsulation as a whole. And I think this architecture > document needs to say that those services have to be > well-defined as part of any solution. (And I am not > saying that this draft needs to define how to do those.) >=20 >=20 Regarding (2), you say: Metadata that contains information that is protected in the data plane SHOULD be equally well protected when passed about by SFC. I hope that's acceptable and documented. For this we have proposed adding the following text: Protocols addressing this architecture must include adjunct mechanisms to provide confidentiality and integrity of metadata carried by the protocol, although implementation of such mechanisms may be optional. Would all these additions address your DISCUSS? Thanks, =E2=80=94 Carlos. --Apple-Mail=_E709387D-A68E-4653-A471-4F92AF39E360 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Stephen,

Let me reset the conversation, focusing specifically on the = two DISCUSSes you have:

On = May 28, 2015, at 8:52 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------


(1) I note the charter = calls for this deliverable to "provide
a description of... security models" The charter = also
generally notes that "The = SFC WG will closely consider and
address the management and security implications = when
documenting these = deliverables." My conclusion is that this
deliverable needs to reflect the results of a = security
analysis that the wg are = suppoed to have carried out but that
it's currently too vague only saying that = solutions need to
consider this. = (Essentially this is a continuation of the
mail threads from the secdir review [1] and a = satisfactory
resolution of that will = probably resolve this.)

  [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg05701.h= tml


Regarding (1), you = say:
Essentially this = is a continuation of the
mail threads from the = secdir review [1] and a satisfactory
resolution of that will probably resolve = this"

And it seems from [2] there is a satisfactory = resolution:
Thanks for = all these updates; I think they go a long way to addressing = the
concerns that were raised = during the secdir review.
-Ben

[2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.ht= ml



(2) Metadata that contains information that is = protected in
the data plane SHOULD be = equally well protected when passed
about by SFC. I hope that's acceptable and = documented. I'm
not sure myself if "passed = about" ought also include within a
device but maybe it should really.  But at = minimum, I do
think you need to define = confidentiality and origin
authentication services = for SFC metadata and/or for the SFC
encapsulation as a whole. And I think this = architecture
document needs to say that = those services have to be
well-defined as part of = any solution. (And I am not
saying that this draft = needs to define how to do those.)




Regarding = (2), you say:
Metadata that contains information that is protected = in
the data plane SHOULD be = equally well protected when passed
about by SFC. I hope that's acceptable and = documented.

For this we have proposed adding the = following text:
Protocols addressing this architecture must = include adjunct 
mechanisms = to provide confidentiality and integrity of metadata 
carried by the protocol, although = implementation of such 
mechanisms may be = optional.

Would all these = additions address your DISCUSS?

Thanks,

=E2=80=94 Carlos.


= --Apple-Mail=_E709387D-A68E-4653-A471-4F92AF39E360-- --Apple-Mail=_9E6545A8-AB83-45E1-9A3E-A4270DEF0AC5 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 iQIcBAEBCAAGBQJVbgrFAAoJEIXgpQGOZny9g6AP/RMXxlGhrUC3PAE2uY7L0kPy F3MFC7yCjW5hVwT/Ze4tQCJLjKehVfZ4bSh+wXPZAp7T5WEvgfUGRV2fqmsc7Ot7 TPjz9GOgasPiPNqkp9cGmdpbjiuKjMVAaegikhxgFGHHdjqWcScfH8REo0I9OMD9 o/Xgld8jSsgxIo8Lcv7xlj9R+zXdiur82nGt0h8YINbDQOGh3v0eYdTFY2tcaomR ibrSW24gm2dEn+rDACQRaWQhUjZA3zmbUCQucPVntiSnvwpfqgyh14A/dqQ3Hozu ltALXUbmaKre6WGpI/55o3bNfmo+ruFKLF0S4qXtLF4QNguRSswLqEx7lVOtpobs TfMHSzO8FGsZvDNa+ZAC7iWrt7AXtuhb3OAc85whSKcKkRJ9DXTlykKIbiE1VYY3 xdifluCu6jYsnZzrDreY6KuC74WqP6VjksOupvu+uDsJ3TdwRVYFx/Nq7CSpcTXB I/9nTHZ9K0iKalHlgOdR1SxEhnx0PGtscmXuZ1L/wJqy0RAhBEmNnC1oo4lEl45X dCBwE/gzzQW0l3PnC+PSikcCM+X8seERn6H0zmbH0teyS4I0ynqe7bY/9sMT/yER ULcgsr9Vzy6RxD6mod9uLDT+A9TU0CM3Vm3RrRNq1axJEpHIG8iO00NJrCqjmeQ7 PLJncjVMQq3b6mrPCjQQ =H7NW -----END PGP SIGNATURE----- --Apple-Mail=_9E6545A8-AB83-45E1-9A3E-A4270DEF0AC5-- From nobody Tue Jun 2 22:57:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9411A1BB5 for ; Tue, 2 Jun 2015 22:57:32 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LFpFiGMYpVCZ for ; Tue, 2 Jun 2015 22:57:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18131B3564 for ; Tue, 2 Jun 2015 22:57:24 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 0622B37429E; Wed, 3 Jun 2015 07:57:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id D842238404A; Wed, 3 Jun 2015 07:57:22 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0235.001; Wed, 3 Jun 2015 07:57:22 +0200 From: To: Dave Dolson , Ron Parker , "Huangyong (Oliver)" , "sfc@ietf.org" Thread-Topic: Comments on draft-ww-sfc-control-plane-04 Thread-Index: AdCaT/m1mDOWpHwMTiCAntP3ait8eAAIP1XAAIFxZjAAAmgRYAAAkYsOAAOhTwAAAGqEwAAgjFwwAAkfLzAAIRgjYA== Date: Wed, 3 Jun 2015 05:57:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300531C5D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <8172B566C79A4A4C8EB6C7B1F6529EFC61E28160@szxema506-mbx.china.huawei.com> , <20150601155008.5374031.38326.16222@sandvine.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.3.45416 Archived-At: Subject: Re: [sfc] Comments on draft-ww-sfc-control-plane-04 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 05:57:32 -0000 Hi Dave, Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > Envoy=E9=A0: mardi 2 juin 2015 18:14 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; Ron Parker; Huangyong (Oliver); > sfc@ietf.org > Objet=A0: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > [trimmed the list a bit to avoid the mailing list holding up the message] > Med, > Thanks for including changes in the document. >=20 > You asked me a question: >=20 > I wrote: > > My feeling is that a more flexible approach would be valid. > > E.g., an operator may wish to drop IP-address classification rules afte= r > a > > few minutes if there is no control-plane connectivity. >=20 > [Med] Which means no service, no? Why not relying on "stale" information > maintained by SFC data plane elements to process packets? >=20 > What is "no service"? I think this could mean passing packets without > applying any SF functions, > or applying a default set of SF functions. > It could mean falling back to a CLI-provisioned forwarding policy. [Med] Those are options that can be indeed envisaged. Applying a stale poli= cy or a default policy when failure is much better (from a service availabi= lity standpoint) than dropping/stopping treating packets entering an SFC-en= abled domain during CP failure events. The question is which strategy would= better ensure a service (relying on service chains) will still be delivere= d even during CP failure events. This can be left to the taste of operators= . >=20 > The question of "stale" information is exactly the point. > If the control plane is not available, any volatile data might be stale. > Concrete example: using IP addresses to classify subscriber policy, when > IP address assignment is dynamic. [Med] I see your point. FWIW, we already have this text: o Adjust classification rules when rules are based on volatile identifiers (e.g., an IPv4 address, IPv6 prefix). >=20 > Which is a more valid way to think of stale state? > (a) assume previous state is still the current state? The wrong chaining > might be applied. > (b) assume current state is unknowable? A default chaining should be > applied. >=20 > I don't know the answer. Neither is correct. I think operators must make > the decision, based on failure analysis and > choosing the lesser evil of applying a default policy or possibly the > wrong policy. >=20 > I think a pragmatic approach is to assume the previous state is valid for > some period of time, > and only after the time expires, fall back to a default forwarding > configuration. > This would allow temporary network interruption or reboot of a controller > without any down-side. >=20 > I can think of two ways to implement this: > 1. In a global sense, revert to a default rule set after a period of > controller interruption > 2. On a per-rule sense, allowing timeouts on each rule. Controller can pu= t > shorter timeouts on more volatile rules. [Med] The value I see in assigning timeouts is that, in addition to self-cl= earing entries, long-lived entries may be serviced during long failure peri= ods compared to short-lived entries. =20 >=20 > I'm mainly thinking of classifier state, but I think similar concepts > apply to SFFs. > A cohesive failure mode should be designed for the entire network. > No operator wants to ever experience this, but... >=20 > How do you feel about adding the word "temporary" ? >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions even during temporary unavailability events of control > plane > ^^^^^^^^^ > components. SFC implementations that do not meet this requirement > will suffer from another flavor of the constrained high availability > issue, discussed in Section 2.3 of [RFC7498], supposed to be solved > by SFC designs. >=20 [Med] Works for me. I implemented this change in my local copy. Thank you. >=20 > -Dave >=20 > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, June 02, 2015 5:38 AM > To: Dave Dolson; Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li > (Julio); Qin Wu; JACQUENET Christian IMT/OLN; > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); Linda > Dunbar > Subject: RE: Comments on draft-ww-sfc-control-plane-04 >=20 > Hi Dave, >=20 > -05 includes this text inspired by your first message in this thread: >=20 > Also, this interface informs the SFC-aware SF about the semantics of > a context information, which would otherwise have opaque meaning. > Several attributes may be associated with a context information such > as (but not limited to) the "scope" (e.g., per-packet, per-flow or > per host), whether it is "mandatory" or "optional" to process flows > bound to a given chain, etc. Note that a context may be mandatory > for "chain 1", but optional for "chain 2". >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Dave Dolson [mailto:ddolson@sandvine.com] > > Envoy=E9=A0: lundi 1 juin 2015 20:20 > > =C0=A0: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio)= ; Qin > > Wu; BOUCADAIR Mohamed IMT/OLN; JACQUENET Christian IMT/OLN; > > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); > Linda > > Dunbar > > Objet=A0: RE: Comments on draft-ww-sfc-control-plane-04 > > > > Ron, > > > > I don't disagree with those statements. > > But I believe the wording in the text precludes OpenFlow "fail > standalone > > mode". > > > > The wording is "... must keep on processing incoming packets according > to > > the > > SFC instructions, even when control plane components are unavailable or > > unreachable for some reason". > > > > As I read it, this prohibits any special failure mode behavior, and > hence > > is too strongly worded. > > > > There isn't even a time limit in the requirement. Must keep the SFC > > instructions forever? Even after power cycle? > > As literally written, for example, C1 classification rules based on > > volatile identifiers such as IP addresses > > MUST be maintained forever. (Although lower-case "must" was used -- > > intentionally or in error?) > > > > Was this strong requirement really intended, or is the wording just > > incomplete? >=20 > [Med] -05 includes the following text: >=20 > A permanent association between an SFC data plane element with a > Control Element must not be required; specifically, the SFC-enabled > domain must keep on processing incoming packets according to the SFC > instructions even during unavailability events of control plane > components. SFC implementations that do not meet this requirement > will suffer from another flavor of the constrained high availability > issue, discussed in Section 2.3 of [RFC7498], supposed to be solved > by SFC designs. >=20 > The point is to encourage SFC mechanisms that do not degrade the > serviceability of an SFC-enabled domain. If such requirement is not met, > then service disruption is likely...which is not desired. If activating > SFC solution will lead to more unavailability events, then I do think we > are not addressing correctly the SFC problem space (RFC7498). >=20 > Does this make sense? >=20 > > My feeling is that a more flexible approach would be valid. > > E.g., an operator may wish to drop IP-address classification rules afte= r > a > > few minutes if there is no control-plane connectivity. >=20 > [Med] Which means no service, no? Why not relying on "stale" information > maintained by SFC data plane elements to process packets? >=20 > > > > I think you *could* keep this wording if the classification rules > > themselves have timeouts. >=20 > [Med] The point about timeouts is a good point. I do personally think tha= t > associating timeouts with classification entries will ease the management > of classification entries (especially the removal of obsolete entries by > local decisions at the classifier). >=20 > > But then the controller would always be refreshing them. >=20 > [Med] This depends on the timeout (that can be expressed in days, months, > etc.) or be set to infinite (for entries that are supposed to last for to= o > too long periods). >=20 > > > > > > -Dave > > > > > > > > -----Original Message----- > > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > > Sent: Monday, June 01, 2015 1:42 PM > > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); > Qin > > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); > Linda > > Dunbar > > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > > > Hi, Dave. > > > > I did catch that from your original message and I apologize for my > > comments that weren't very direct wrt your point. So to complete the > > circle, my thinking is that if the policy decision point (PDP) is > > centralized, then you live and die by the control plane availability. > > But, if the policy decision points are distributed, there is a > > significantly increased tolerance to temporary loss of the control > plane. > > I'd like to retain within the architecture the possibility for this > > distributed approach so that for any deployment the relative strengths > and > > weaknesses of centralized vs distributed can be weighed and decided > upon. > > Based on which approach there is a profound impact on what the control > > plane is doing -- is it policy delivery or is it policy evaluation? > > > > Thanks. > > > > Ron > > > > > > -----Original Message----- > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Monday, June 1, 2015 11:50 AM > > To: Ron Parker; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qi= n > > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); > Linda > > Dunbar > > Subject: Re: Comments on draft-ww-sfc-control-plane-04 > > > > I may not have explained my point we'll enough. I only have issue with > the > > case of the control plane being unreachable. > > > > David Dolson > > Senior Software Architect, Sandvine Inc. > > From: Ron Parker > > Sent: Monday, June 1, 2015 11:43 AM > > To: Dave Dolson; Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); > Qin > > Wu; mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Huangjing (A); > Linda > > Dunbar > > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > > > > > Hi, Dave. > > > > OpenFlow implementations locate the policy decision point in the > > controller and hence per-flow policy analysis is supported via the > control > > plane messaging. Assuming that the controller, after analyzing a flow= , > > provides both the action and the filter it used to define the flow, the= n > > we get to whether the filter is coarse-grained or fine-grained. If th= e > > filter is coarse-grained (e.g., all TCP/80), then additional control > plane > > activity is not required for subsequent micro-flows that match the > macro- > > flow's filter. But, if fine-grained (i.e., fully qualified 5-tuple) > > filtering is used, then the control plane overhead becomes very large > and > > perhaps impractical. Many of the use cases we've talked about for SF= C > > suggest micro-flow level policy decisions. > > > > While I wouldn't suggest that we preclude centralized fine-grained > policy > > as a design/implementation decision, I also feel there should be an > > alternative to allow for distributed/fine-grained policy decisions. I= n > > that case, the control plane's job would be to provide and maintain all > of > > the data necessary to those distributed policy decision points, but not > > necessarily handle per-micro-flow transactions. > > > > In summary, we could end up with any or all of the following operating > > points (as a fundamental capability or simply a deployment approach): > > > > * Centralized coarse-grained policy decision point > > > > * Centralized fine-grained policy decision point > > > > * Distributed coarse-grained policy decision point > > > > * Distributed fine-grained policy decision point > > > > Ron > > > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Monday, June 1, 2015 11:30 AM > > To: Huangyong (Oliver); sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > > mohamed.boucadair@orange.com; christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; seungiklee@etri.re.kr; Ron Parker; > Huangjing > > (A); Linda Dunbar > > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > > > Regarding the 2nd paragraph in 2.1, > > > > > > 2.1. Generic Requirements > > > > For deployments that would require so, SFC forwarding must be allowe= d > > even if no control protocols are enabled. Static configuration must > > be allowed. > > > > A permanent association between an SFC data plane element with a > > Control Element must not be required; specifically, the SFC-enabled > > domain must keep on processing incoming packets according to the SFC > > instructions, even when control plane components are unavailable or > > unreachable for some reason. > > > > > > "Control Element must not be required" is contrary to how OpenFlow work= s > > (as I understand it). > > So the "must" wording seems to preclude the use of OpenFlow and similar > > protocols. Was this intended? > > > > And it is probably a bad idea to allow an uncontrolled data-plane > element > > to keep running indefinitely. Would you want a switch to run without MA= C > > learning? Would you want a router to run if it lost its BGP connection? > > No, and this is why loss of control plane should generally lead to > > shutting down the data plane. > > > > > > I understand the sentiment to allow static configuration, which I think > is > > fine. But if the control-plane is dynamic, loss of controller should > lead > > to shut-down. > > > > > > > > -Dave > > > > > > > > > > From: Huangyong (Oliver) [mailto:oliver.huang@huawei.com] > > Sent: Friday, May 29, 2015 9:06 PM > > To: Dave Dolson; sfc@ietf.org; Hongyu Li (Julio); > Qin > > Wu; mohamed.boucadair@orange.com; > > christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; > > seungiklee@etri.re.kr; > > ron_parker@affirmednetworks.com= ; > > Huangjing (A); Linda Dunbar > > Subject: RE: Comments on draft-ww-sfc-control-plane-04 > > > > Hello Dave, > > > > Thank you for your detailed consideration on the draft. I agre= e > > that the SF should support the capability of bidirectional chains. For > > example, the NAT SF may provide the new allocated address/port to the > > controller. You mentioned the control plane should inform SF > > bidirectional chain (which path id are paired). I have question why no= t > > the SFC forwarding system handle the paired chain itself? > > > > Performance mornitoring is a basic capability which should exis= t > > in all interfaces C1,C2,C3. > > > > Mohamed have developed a new version of this draft and made a > big > > promotion. In the new draft, C3,C4 are introduced for SF and SF proxy > > separately. I think it may cover the related scenario. I attached it > in > > this email, please check it. > > > > Now James.Huang(I add in this email), Qin.Wu and Linda. Dunbar > are > > representative of Huawei on this draft. Please contact more detail to > > them. Thank you very much! > > > > BR > > Oliver > > > > --------------------------- > > Huangyong (Oliver) > > Network research, Huawei > > > > From: Dave Dolson [mailto:ddolson@sandvine.com] > > Sent: Saturday, May 30, 2015 4:42 AM > > To: sfc@ietf.org; Hongyu Li (Julio); Qin Wu; > > Huangyong (Oliver); > > mohamed.boucadair@orange.com; > > christian.jacquenet@orange.com; > > walter.haeffner@vodafone.com; > > seungiklee@etri.re.kr; > > ron_parker@affirmednetworks.com > > Subject: Comments on draft-ww-sfc-control-plane-04 > > > > Authors of draft-ww-sfc-control-plane, > > > > I've been reading over https://tools.ietf.org/html/draft-ww-sfc-control= - > > plane-04 > > > > I have some very high-level suggestions: > > > > > > 1. I believe the "F" interface should be split into two interfaces= . > > One for performance monitoring (availability and workload were cited), > and > > one for updating classification information. > > > > Call these F1 and F2, I suppose. My reasons are that (a) as a general > > principle, interfaces should not have multiple purposes and (b) F1 and > F2 > > could be communicating to different control-plane managers. > > > > > > > > 2. A control interface is required to SF components. Call it C3. > This > > interface is required to (a) inform the SF about bidirectional chains > > (i.e., which Path IDs are paired) and (b) inform the SF about semantics > of > > types of meta-data. C3 should also be connected to the SFC Proxy. > > > > I propose: > > > > 4.5 C3 Interface > > > > A service function may need information about the service paths > > passing through it, and may need information about specific meta-dat= a > > types attached to packets on the paths. > > > > Some types of SF might be agnostic about the paths traversing them, > but > > most transport-layer-flow-aware devices will require this > > configuration. > > > > When bidirectional chains are deployed, the C3 interface provisions > > each SF with each path identifier/path index pair that will pass > > through. > > Each such pair is associated with an opposite-direction pair of > > identifier/index. > > > > Meta-data is for the benefit of SFs. The C3 interface informs the SF > > about the semantics of the meta-data, which would otherwise have > > opaque meaning. Meta-data attributes include "scope" (per-packet, > per- > > flow > > or per host), "mandatory" (must be understood), "bidirectional" (sam= e > > value may be used in both directions), "is_qualifier" (indicates a > > distinct routing domain). > > > > > > I think there is quite a bit to explore, but I believe this starts the > > discussion. > > Thoughts? > > > > > > David Dolson > > Senior Software Architect, Sandvine Inc. From nobody Fri Jun 5 09:24:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5B11A8781; Fri, 5 Jun 2015 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnLOzZcReAHO; Fri, 5 Jun 2015 09:23:55 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C97FD1A1BEF; Fri, 5 Jun 2015 09:23:55 -0700 (PDT) Received: by obcej4 with SMTP id ej4so6828376obc.0; Fri, 05 Jun 2015 09:23:55 -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=j1LI72e0rouaNveVijsM8jFTtlIIrOYX+AMPCbGtI/Q=; b=MWeQcEk8O3OOxPoq+gHXndfNMyrbbQUkRwy0Ln92BAQpmYNkKGGYv/7ozadDNDIv80 qlPGvfighoMHXqBGxx/Xrz65zRrQpkIE6UZczvnTPththtCMZHSv6kEJfOgHlvNG2J/G gsiHLbcJzbngGcBvedQsAypQkQMNECpYlfRgMVtcI7c5ZpwdULHdrp17sqYD0+DI1C1t K6f6Z/bnbwvLxUFogMxkwmMa4XBWeCcGxtnpQcOPIZ1DfyIkiYpUEU/xyGMMeivcnPE4 yw3/M+6i3Rzkgx4C8MprD9N7hbmFVUeJIt66VW5FKGOCJwP9UoPg0qKWjcVo5/Xa6k2F 0p+w== MIME-Version: 1.0 X-Received: by 10.182.68.13 with SMTP id r13mr3697757obt.20.1433521435267; Fri, 05 Jun 2015 09:23:55 -0700 (PDT) Received: by 10.60.33.167 with HTTP; Fri, 5 Jun 2015 09:23:55 -0700 (PDT) In-Reply-To: References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> <55677F7D.1070807@joelhalpern.com> <2F403ACA-D45B-4184-9E39-9DE527DC7A35@gmail.com> Date: Fri, 5 Jun 2015 12:23:55 -0400 Message-ID: From: Alia Atlas To: "Carlos Pignataro (cpignata)" Content-Type: multipart/alternative; boundary=e89a8fb1f60eed597a0517c7b7b4 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 05 Jun 2015 16:23:57 -0000 --e89a8fb1f60eed597a0517c7b7b4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Carlos & Joel, On Tue, Jun 2, 2015 at 3:57 PM, Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Kathleen, > > We iterated with Alia in trying to get a more condensed and to-the-point > version of the text. > > Here=E2=80=99s a proposal that we believe can help address your concern: > > "A classifier may have privileged access to information about a packet > that is then communicated in the metadata. The threat of leaking this > private data needs to be considered [RFC 6973]. As one example, if privat= e > data is represented by an identifier, then a new identifier can be > allocated, such that the mapping from the private data to the new > identifier is not broadly shared.=E2=80=9D > > With [RFC 6973] as an Informational reference. > > Does this help? > Kathleen and I discussed the proposed text and have a slight modification as follows: "A classifier may have privileged access to information about a packet or inside a packet (See bullet 4 in Sec. 3 and Sec 4.9) that is then communicated in the metadata. The threat of leaking this private data needs to be mitigated [RFC 6937]. As one example, if private data is represented by an identifier, then a new identifier can be allocated, such that the mapping from the private data to the new identifier is not broadly shared." Thanks, Alia Thanks, > > =E2=80=94 Carlos. > > On May 28, 2015, at 5:20 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > I can see your point of view, but that does not mean that a warning is no= t > needed. Someone may not be aware that their plain text traffic could be > used in the ways that are possible. Alia's suggested text addresses this > possible concern and is much appreciated to remove my discuss. > > Let me know if/when this text is incorporated. > > Best regards, > Kathleen > > > --e89a8fb1f60eed597a0517c7b7b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Carlos & Joel,


On Tue, Jun 2, 2015 at 3:57 = PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:=
Hi, Kathleen,
=
We iterated with Alia in trying to get a more condensed and = to-the-point version of the text.

Here=E2=80=99s a= proposal that we believe can help address your concern:

"A classifier may have privileged access to information about a packe= t that is then communicated in the metadata. =C2=A0 The threat of leaking t= his private data needs to be=C2=A0considered [RFC 6973]. As one example, if= private data is represented by an identifier, then a new identifier can be= allocated, such that the mapping from the private data to the=C2=A0new ide= ntifier is not broadly shared.=E2=80=9D

With [RFC 6973] a= s an=C2=A0Informational reference.

Does this help?=

=C2=A0Kathleen and I dis= cussed the proposed text and have a slight modification as follows:
"A clas= sifier may have privileged access to information about a packet or inside a= packet=C2=A0(See bullet 4 in Sec. 3 and Sec 4.9)=C2=A0that is then communicated in= the metadata. =C2=A0 The threat of leaking this private data needs to be= =C2=A0mitigated [RFC 6937]. As one example, if private data is represented = by an identifier, then a new identifier can be allocated, such that the map= ping from the private data to the new identifier is not broadly shared.&quo= t;

Thanks,
Alia=C2=A0

Thanks,

=E2=80=94 Carlos.

On May 28, 2015, at = 5:20 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
I can see y= our point of view, but that does not mean that a warning is not needed.=C2= =A0 Someone may not be aware that their plain text traffic could be used in= the ways that are possible.=C2=A0 Alia's suggested text addresses this= possible concern and is much appreciated to remove my discuss.

Let= me know if/when this text is incorporated.

Best regards,Kathleen

<= br> --e89a8fb1f60eed597a0517c7b7b4-- From nobody Sun Jun 7 13:15:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 961531ACD8C; Sun, 7 Jun 2015 13:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4djdK46sF7Y; Sun, 7 Jun 2015 13:15:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE27B1ACD9B; Sun, 7 Jun 2015 13:15:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9333CBE5D; Sun, 7 Jun 2015 21:15:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiFZXTwgbFIu; Sun, 7 Jun 2015 21:15:39 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 052ECBE5C; Sun, 7 Jun 2015 21:15:39 +0100 (IST) Message-ID: <5574A665.3080604@cs.tcd.ie> Date: Sun, 07 Jun 2015 21:15:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> In-Reply-To: <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kbLMDufMkBr2IAOdCET90T68FG1af4TeE" Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.ad@ietf.org" , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 20:15:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kbLMDufMkBr2IAOdCET90T68FG1af4TeE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Sorry for the delayed response - some more travel ensued;-( On 02/06/15 20:57, Carlos Pignataro (cpignata) wrote: > Hi, Stephen, >=20 > Let me reset the conversation, focusing specifically on the two DISCUSS= es you have: >=20 >> On May 28, 2015, at 8:52 AM, Stephen Farrell wrote: >> >> ----------------------------------------------------------------------= >> DISCUSS: >> ----------------------------------------------------------------------= >> >> >> (1) I note the charter calls for this deliverable to "provide >> a description of... security models" The charter also >> generally notes that "The SFC WG will closely consider and >> address the management and security implications when >> documenting these deliverables." My conclusion is that this >> deliverable needs to reflect the results of a security >> analysis that the wg are suppoed to have carried out but that >> it's currently too vague only saying that solutions need to >> consider this. (Essentially this is a continuation of the >> mail threads from the secdir review [1] and a satisfactory >> resolution of that will probably resolve this.) >> >> [1] >> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html >=20 >=20 > Regarding (1), you say: > Essentially this is a continuation of the > mail threads from the secdir review [1] and a satisfactory > resolution of that will probably resolve this" >=20 > And it seems from [2] there is a satisfactory resolution: > Thanks for all these updates; I think they go a long way to addressing = the > concerns that were raised during the secdir review. > -Ben >=20 > [2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html Yes, I think the secdir review discussions seem to be reaching or have reached closure. I'd say an updated draft could be a good idea as I've lost track of those changes. I'm therefore also not sure if the results there are enough to clear this point but that'll be much easier to determine with a revision. I don't believe that those discussions have resulted in anything that's a recognisable "security model" though have they (as is called for by the charter). Can you speak to how that aspect of the WG charter is met by the changes proposed or why that isn't needed? >> (2) Metadata that contains information that is protected in >> the data plane SHOULD be equally well protected when passed >> about by SFC. I hope that's acceptable and documented. I'm >> not sure myself if "passed about" ought also include within a >> device but maybe it should really. But at minimum, I do >> think you need to define confidentiality and origin >> authentication services for SFC metadata and/or for the SFC >> encapsulation as a whole. And I think this architecture >> document needs to say that those services have to be >> well-defined as part of any solution. (And I am not >> saying that this draft needs to define how to do those.) >> >> >=20 >=20 > Regarding (2), you say: > Metadata that contains information that is protected in > the data plane SHOULD be equally well protected when passed > about by SFC. I hope that's acceptable and documented. >=20 > For this we have proposed adding the following text: > Protocols addressing this architecture must include adjunct > mechanisms to provide confidentiality and integrity of metadata > carried by the protocol, although implementation of such > mechanisms may be optional. >=20 > Would all these additions address your DISCUSS? No, sorry. For one minor and two major reasons. The first is that I want to ensure we do not end up in the various bad situations that happened in the roll and karp WGs, so a simple addition like that without any idea what is likely to really happen isn't a good plan I think. The second is that I am entirely unconvinced that any security mechanisms can be an "adjunct" or optional to implement. The minor reason is that I don't think we have gotten to the bottom of whether data integrity of data in transit is sufficient or whether data origin authentication is really needed here. (That could easily be something to be addressed later in the WG but is not something to determine now unless we do the analysis now, or describe that analysis if it has been done but not written down so far which may be the case.) Cheers, S. PS: I'm starting on vacation on Thursday so will try to be responsive on this in the meantime. However, we really ought keep in mind that getting the right outcome at this stage could save a lot of effort later, so I wouldn't be too focused on trying to get this document done in the next few days and I think we ought be much more focused on doing our best with ensuring that SFC doesn't hit security speedbumps later on. >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >=20 >=20 --kbLMDufMkBr2IAOdCET90T68FG1af4TeE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdKZpAAoJEC88hzaAX42iKucH+gMQvQ4vbT7VSPAoNYUw3vBa LeYtP2W0gQ5D/ST0MpyICS2iGulyRgDYgj2HwoY4/IL9y0XgcWywD6SNOQaZetvH Edo4JGPhEEyy8jNktYDmUOA1kcluwvmIrHpO8PJ0T5HrOv4e91DCBl950NxQP2fG SG6dmKzcLbwEWzpuUqZ5Jz5/LAC16SdOtxk0cTtolguKvVhRkmJtAxRjTMcBN+Mk xuUQMZ3vzTcErpHQI9Uu7OgJRRY78XBthzCMrBUaBpQu8rUK8/5NIFgWwDsV7m61 EOJmrLmpkDSgmWpw/HhC3av1KPvBe3YXBHqWpEYAvaAlqQtkwg2x0A/Yc374+AA= =9ac5 -----END PGP SIGNATURE----- --kbLMDufMkBr2IAOdCET90T68FG1af4TeE-- From nobody Sun Jun 7 13:32:01 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E270F1ACDCE; Sun, 7 Jun 2015 13:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 RhkaSXIQIUhB; Sun, 7 Jun 2015 13:31:55 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D4D51ACDCB; Sun, 7 Jun 2015 13:31:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 364D2240C4E; Sun, 7 Jun 2015 13:31:55 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id ADB7D2404A3; Sun, 7 Jun 2015 13:31:54 -0700 (PDT) Message-ID: <5574AA33.5070609@joelhalpern.com> Date: Sun, 07 Jun 2015 16:31:47 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> In-Reply-To: <5574A665.3080604@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 20:31:57 -0000 I am not sure how to usefully respond to your concern that you are not convinced that security mechanisms can be adjunct or optional. That seems to border on opinion, rather than factual basis for a discuss. Further, I really do not want to end up in a situation where the majority of implementations are not conformant to the architecture and protocol spec. And it is very clear that most of the environments at least for the initial, single domain, case that we are targeting will not need any form of authentication or data integrity in the SFC mechanism. Also, I realized looking at your comments and the charter, that I do not know know what would constitute a "security model" as you understand it. Yours, Joel On 6/7/15 4:15 PM, Stephen Farrell wrote: > > Hi Carlos, > > Sorry for the delayed response - some more travel ensued;-( > ... > No, sorry. For one minor and two major reasons. > > The first is that I want to ensure we do not end up in the > various bad situations that happened in the roll and karp > WGs, so a simple addition like that without any idea what is > likely to really happen isn't a good plan I think. > > The second is that I am entirely unconvinced that any > security mechanisms can be an "adjunct" or optional to > implement. > > The minor reason is that I don't think we have gotten to > the bottom of whether data integrity of data in transit > is sufficient or whether data origin authentication is > really needed here. (That could easily be something to be > addressed later in the WG but is not something to determine > now unless we do the analysis now, or describe that analysis > if it has been done but not written down so far which may > be the case.) > > Cheers, > S. > > PS: I'm starting on vacation on Thursday so will try to be > responsive on this in the meantime. However, we really ought > keep in mind that getting the right outcome at this stage > could save a lot of effort later, so I wouldn't be too focused > on trying to get this document done in the next few days and > I think we ought be much more focused on doing our best with > ensuring that SFC doesn't hit security speedbumps later on. > > >> >> Thanks, >> >> — Carlos. >> >> >> > From nobody Sun Jun 7 13:34:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6EFB1ACDE0; Sun, 7 Jun 2015 13:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGR-xim_0oft; Sun, 7 Jun 2015 13:34:37 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E43C1ACDDF; Sun, 7 Jun 2015 13:34:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26CFCBE79; Sun, 7 Jun 2015 21:34:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMa9WUGgt8xE; Sun, 7 Jun 2015 21:34:34 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CCDCCBE5C; Sun, 7 Jun 2015 21:34:34 +0100 (IST) Message-ID: <5574AADA.8080606@cs.tcd.ie> Date: Sun, 07 Jun 2015 21:34:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> In-Reply-To: <5574AA33.5070609@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 20:34:38 -0000 On 07/06/15 21:31, Joel M. Halpern wrote: > I am not sure how to usefully respond to your concern that you are not > convinced that security mechanisms can be adjunct or optional. That > seems to border on opinion, rather than factual basis for a discuss. > Further, I really do not want to end up in a situation where the > majority of implementations are not conformant to the architecture and > protocol spec. > And it is very clear that most of the environments at least for the > initial, single domain, case that we are targeting will not need any > form of authentication or data integrity in the SFC mechanism. Hmm. Doesn't BCP61 directly address the above? > > Also, I realized looking at your comments and the charter, that I do not > know know what would constitute a "security model" as you understand it. Ok - what is a security model as you understand what the charter says about this deliverable? Since you're an author and the charter calls for that can you point me at where in the draft I find it or why it is no longer needed/relevant/whatever? Ta, S. > > Yours, > Joel > > On 6/7/15 4:15 PM, Stephen Farrell wrote: >> >> Hi Carlos, >> >> Sorry for the delayed response - some more travel ensued;-( >> > ... >> No, sorry. For one minor and two major reasons. >> >> The first is that I want to ensure we do not end up in the >> various bad situations that happened in the roll and karp >> WGs, so a simple addition like that without any idea what is >> likely to really happen isn't a good plan I think. >> >> The second is that I am entirely unconvinced that any >> security mechanisms can be an "adjunct" or optional to >> implement. >> >> The minor reason is that I don't think we have gotten to >> the bottom of whether data integrity of data in transit >> is sufficient or whether data origin authentication is >> really needed here. (That could easily be something to be >> addressed later in the WG but is not something to determine >> now unless we do the analysis now, or describe that analysis >> if it has been done but not written down so far which may >> be the case.) >> >> Cheers, >> S. >> >> PS: I'm starting on vacation on Thursday so will try to be >> responsive on this in the meantime. However, we really ought >> keep in mind that getting the right outcome at this stage >> could save a lot of effort later, so I wouldn't be too focused >> on trying to get this document done in the next few days and >> I think we ought be much more focused on doing our best with >> ensuring that SFC doesn't hit security speedbumps later on. >> >> >>> >>> Thanks, >>> >>> — Carlos. >>> >>> >>> >> > From nobody Sun Jun 7 13:40:36 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24C71ACDF3; Sun, 7 Jun 2015 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qyZyZqHMwuxD; Sun, 7 Jun 2015 13:40:31 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 672D01ACDD4; Sun, 7 Jun 2015 13:40:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 459ED240D79; Sun, 7 Jun 2015 13:40:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id B2B38240C1B; Sun, 7 Jun 2015 13:40:30 -0700 (PDT) Message-ID: <5574AC37.5010009@joelhalpern.com> Date: Sun, 07 Jun 2015 16:40:23 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> In-Reply-To: <5574AADA.8080606@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 20:40:32 -0000 The escurity considerations section addresses, as far as we understand them, the issues that a "security model" needs to cover. It is not done as an explicit model. We could recast the section as such a model, but it would end up saying the same things. We could write more explicitly some of the other assumptions we make, for example that the services to which user packets are delivered are trusted by the operator to examine the packets and associated metadata. We could note that the service functions are further trusted to modify the packet contents and metadata. We could add text that in most single-domain cases, the underlying infrastructure is trusted by the operator. Would adding text like that help? It would seem instead to provoke the BCP61 comment that you are now making. Yours, Joel On 6/7/15 4:34 PM, Stephen Farrell wrote: > > > On 07/06/15 21:31, Joel M. Halpern wrote: >> I am not sure how to usefully respond to your concern that you are not >> convinced that security mechanisms can be adjunct or optional. That >> seems to border on opinion, rather than factual basis for a discuss. >> Further, I really do not want to end up in a situation where the >> majority of implementations are not conformant to the architecture and >> protocol spec. >> And it is very clear that most of the environments at least for the >> initial, single domain, case that we are targeting will not need any >> form of authentication or data integrity in the SFC mechanism. > > Hmm. Doesn't BCP61 directly address the above? > >> >> Also, I realized looking at your comments and the charter, that I do not >> know know what would constitute a "security model" as you understand it. > > Ok - what is a security model as you understand what the charter > says about this deliverable? Since you're an author and the charter > calls for that can you point me at where in the draft I find it > or why it is no longer needed/relevant/whatever? > > Ta, > S. > > >> >> Yours, >> Joel >> >> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>> >>> Hi Carlos, >>> >>> Sorry for the delayed response - some more travel ensued;-( >>> >> ... >>> No, sorry. For one minor and two major reasons. >>> >>> The first is that I want to ensure we do not end up in the >>> various bad situations that happened in the roll and karp >>> WGs, so a simple addition like that without any idea what is >>> likely to really happen isn't a good plan I think. >>> >>> The second is that I am entirely unconvinced that any >>> security mechanisms can be an "adjunct" or optional to >>> implement. >>> >>> The minor reason is that I don't think we have gotten to >>> the bottom of whether data integrity of data in transit >>> is sufficient or whether data origin authentication is >>> really needed here. (That could easily be something to be >>> addressed later in the WG but is not something to determine >>> now unless we do the analysis now, or describe that analysis >>> if it has been done but not written down so far which may >>> be the case.) >>> >>> Cheers, >>> S. >>> >>> PS: I'm starting on vacation on Thursday so will try to be >>> responsive on this in the meantime. However, we really ought >>> keep in mind that getting the right outcome at this stage >>> could save a lot of effort later, so I wouldn't be too focused >>> on trying to get this document done in the next few days and >>> I think we ought be much more focused on doing our best with >>> ensuring that SFC doesn't hit security speedbumps later on. >>> >>> >>>> >>>> Thanks, >>>> >>>> — Carlos. >>>> >>>> >>>> >>> >> > From nobody Sun Jun 7 14:05:09 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAA81ACE45; Sun, 7 Jun 2015 14:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZX1TMqGQxC4; Sun, 7 Jun 2015 14:05:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9842A1ACE41; Sun, 7 Jun 2015 14:05:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7F83CBE79; Sun, 7 Jun 2015 22:05:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG9FLJ01jupq; Sun, 7 Jun 2015 22:05:00 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DCD21BE5C; Sun, 7 Jun 2015 22:04:59 +0100 (IST) Message-ID: <5574B1FB.5020706@cs.tcd.ie> Date: Sun, 07 Jun 2015 22:04:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> In-Reply-To: <5574AC37.5010009@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 21:05:07 -0000 On 07/06/15 21:40, Joel M. Halpern wrote: > The escurity considerations section addresses, as far as we understand > them, the issues that a "security model" needs to cover. It is not done > as an explicit model. We could recast the section as such a model, but > it would end up saying the same things. Well, let's see what a revised ID looks like and then haggle about that maybe. I think that'll be easier. (I note you did not say that the charter text on this is OBE btw.) > We could write more explicitly some of the other assumptions we make, > for example that the services to which user packets are delivered are > trusted by the operator to examine the packets and associated metadata. > We could note that the service functions are further trusted to modify > the packet contents and metadata. > We could add text that in most single-domain cases, the underlying > infrastructure is trusted by the operator. If your goal as authors/WG is to not have mandatory to implement security then yes you would I think need to explicitly justify that in a convincing manner. Isn't it perhaps telling us something if you chose to not explicitly say things like "trusted by the operator so no security needed" in the draft? (Seems so to me tbh.) > > Would adding text like that help? It would seem instead to provoke the > BCP61 comment that you are now making. The BCP61 comment resulted from your proposed text ("adjunct" etc) which seems to me to run counter to that BCP. Are you arguing that such text would be consistent with BCP61? If not, then what is your argument for BCP61 not applying or being unwise in this case? Cheers, S. > > Yours, > Joel > > On 6/7/15 4:34 PM, Stephen Farrell wrote: >> >> >> On 07/06/15 21:31, Joel M. Halpern wrote: >>> I am not sure how to usefully respond to your concern that you are not >>> convinced that security mechanisms can be adjunct or optional. That >>> seems to border on opinion, rather than factual basis for a discuss. >>> Further, I really do not want to end up in a situation where the >>> majority of implementations are not conformant to the architecture and >>> protocol spec. >>> And it is very clear that most of the environments at least for the >>> initial, single domain, case that we are targeting will not need any >>> form of authentication or data integrity in the SFC mechanism. >> >> Hmm. Doesn't BCP61 directly address the above? >> >>> >>> Also, I realized looking at your comments and the charter, that I do not >>> know know what would constitute a "security model" as you understand it. >> >> Ok - what is a security model as you understand what the charter >> says about this deliverable? Since you're an author and the charter >> calls for that can you point me at where in the draft I find it >> or why it is no longer needed/relevant/whatever? >> >> Ta, >> S. >> >> >>> >>> Yours, >>> Joel >>> >>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>> >>>> Hi Carlos, >>>> >>>> Sorry for the delayed response - some more travel ensued;-( >>>> >>> ... >>>> No, sorry. For one minor and two major reasons. >>>> >>>> The first is that I want to ensure we do not end up in the >>>> various bad situations that happened in the roll and karp >>>> WGs, so a simple addition like that without any idea what is >>>> likely to really happen isn't a good plan I think. >>>> >>>> The second is that I am entirely unconvinced that any >>>> security mechanisms can be an "adjunct" or optional to >>>> implement. >>>> >>>> The minor reason is that I don't think we have gotten to >>>> the bottom of whether data integrity of data in transit >>>> is sufficient or whether data origin authentication is >>>> really needed here. (That could easily be something to be >>>> addressed later in the WG but is not something to determine >>>> now unless we do the analysis now, or describe that analysis >>>> if it has been done but not written down so far which may >>>> be the case.) >>>> >>>> Cheers, >>>> S. >>>> >>>> PS: I'm starting on vacation on Thursday so will try to be >>>> responsive on this in the meantime. However, we really ought >>>> keep in mind that getting the right outcome at this stage >>>> could save a lot of effort later, so I wouldn't be too focused >>>> on trying to get this document done in the next few days and >>>> I think we ought be much more focused on doing our best with >>>> ensuring that SFC doesn't hit security speedbumps later on. >>>> >>>> >>>>> >>>>> Thanks, >>>>> >>>>> — Carlos. >>>>> >>>>> >>>>> >>>> >>> >> > From nobody Sun Jun 7 14:39:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B87DD1A014D; Sun, 7 Jun 2015 14:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21oy8dtrkwYf; Sun, 7 Jun 2015 14:39:03 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EEE31A0145; Sun, 7 Jun 2015 14:39:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id DA75E2401AE; Sun, 7 Jun 2015 14:39:02 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 3C15A2404A3; Sun, 7 Jun 2015 14:39:02 -0700 (PDT) Message-ID: <5574B9EE.2070002@joelhalpern.com> Date: Sun, 07 Jun 2015 17:38:54 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> In-Reply-To: <5574B1FB.5020706@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Jun 2015 21:39:04 -0000 This sounds like something Carlos and I can try to address in conjunction with the revisions. Sorry if I was slow to understand the quesiton. Yours, Joel On 6/7/15 5:04 PM, Stephen Farrell wrote: > > > On 07/06/15 21:40, Joel M. Halpern wrote: >> The escurity considerations section addresses, as far as we understand >> them, the issues that a "security model" needs to cover. It is not done >> as an explicit model. We could recast the section as such a model, but >> it would end up saying the same things. > > Well, let's see what a revised ID looks like and then haggle about > that maybe. I think that'll be easier. (I note you did not say that > the charter text on this is OBE btw.) > >> We could write more explicitly some of the other assumptions we make, >> for example that the services to which user packets are delivered are >> trusted by the operator to examine the packets and associated metadata. >> We could note that the service functions are further trusted to modify >> the packet contents and metadata. >> We could add text that in most single-domain cases, the underlying >> infrastructure is trusted by the operator. > > If your goal as authors/WG is to not have mandatory to implement > security then yes you would I think need to explicitly justify that > in a convincing manner. Isn't it perhaps telling us something if you > chose to not explicitly say things like "trusted by the operator so > no security needed" in the draft? (Seems so to me tbh.) > >> >> Would adding text like that help? It would seem instead to provoke the >> BCP61 comment that you are now making. > > The BCP61 comment resulted from your proposed text ("adjunct" etc) which > seems to me to run counter to that BCP. Are you arguing that such text > would be consistent with BCP61? If not, then what is your argument for > BCP61 not applying or being unwise in this case? > > Cheers, > S. > > >> >> Yours, >> Joel >> >> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>> >>> >>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>> I am not sure how to usefully respond to your concern that you are not >>>> convinced that security mechanisms can be adjunct or optional. That >>>> seems to border on opinion, rather than factual basis for a discuss. >>>> Further, I really do not want to end up in a situation where the >>>> majority of implementations are not conformant to the architecture and >>>> protocol spec. >>>> And it is very clear that most of the environments at least for the >>>> initial, single domain, case that we are targeting will not need any >>>> form of authentication or data integrity in the SFC mechanism. >>> >>> Hmm. Doesn't BCP61 directly address the above? >>> >>>> >>>> Also, I realized looking at your comments and the charter, that I do not >>>> know know what would constitute a "security model" as you understand it. >>> >>> Ok - what is a security model as you understand what the charter >>> says about this deliverable? Since you're an author and the charter >>> calls for that can you point me at where in the draft I find it >>> or why it is no longer needed/relevant/whatever? >>> >>> Ta, >>> S. >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>> >>>>> Hi Carlos, >>>>> >>>>> Sorry for the delayed response - some more travel ensued;-( >>>>> >>>> ... >>>>> No, sorry. For one minor and two major reasons. >>>>> >>>>> The first is that I want to ensure we do not end up in the >>>>> various bad situations that happened in the roll and karp >>>>> WGs, so a simple addition like that without any idea what is >>>>> likely to really happen isn't a good plan I think. >>>>> >>>>> The second is that I am entirely unconvinced that any >>>>> security mechanisms can be an "adjunct" or optional to >>>>> implement. >>>>> >>>>> The minor reason is that I don't think we have gotten to >>>>> the bottom of whether data integrity of data in transit >>>>> is sufficient or whether data origin authentication is >>>>> really needed here. (That could easily be something to be >>>>> addressed later in the WG but is not something to determine >>>>> now unless we do the analysis now, or describe that analysis >>>>> if it has been done but not written down so far which may >>>>> be the case.) >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>> responsive on this in the meantime. However, we really ought >>>>> keep in mind that getting the right outcome at this stage >>>>> could save a lot of effort later, so I wouldn't be too focused >>>>> on trying to get this document done in the next few days and >>>>> I think we ought be much more focused on doing our best with >>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>> >>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> — Carlos. >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From nobody Sun Jun 7 17:54:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC511A19E4; Sun, 7 Jun 2015 17:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CFZ7vqbiygK; Sun, 7 Jun 2015 17:54:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 715BA1A1A02; Sun, 7 Jun 2015 17:54:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608005437.9522.19047.idtracker@ietfa.amsl.com> Date: Sun, 07 Jun 2015 17:54:37 -0700 Archived-At: Cc: sfc@ietf.org Subject: [sfc] I-D Action: draft-ietf-sfc-architecture-09.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 00:54:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Service Function Chaining Working Group of the IETF. Title : Service Function Chaining (SFC) Architecture Authors : Joel Halpern Carlos Pignataro Filename : draft-ietf-sfc-architecture-09.txt Pages : 29 Date : 2015-06-07 Abstract: This document describes an architecture for the specification, creation, and ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components used in the construction of composite services through deployment of SFCs, with a focus on those to be standardized in the IETF. This document does not propose solutions, protocols, or extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sfc-architecture-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-architecture-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 7 17:59:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FEA31A19E4; Sun, 7 Jun 2015 17:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhDzW2EI8Bj0; Sun, 7 Jun 2015 17:59:42 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1C71A19E3; Sun, 7 Jun 2015 17:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13086; q=dns/txt; s=iport; t=1433725182; x=1434934782; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BIYn9ulKxHFxtyjPnjC1E2H0rMFycEOCtK3DaoUMeYk=; b=Kv0vAv91YkJ56Oohf/G/BOgszK2gmOGPUXoM780odI+6FJtOP/fYq4hC t49rQZ0AGUJifg3rWJQZtKwLcrR6ae3SuBakVzr6QODeRmHxUvKa8wmjX pNCyrXfXs7Ysw9NZur5kAIJCJC/3dqKBqmXZl7zNalQz8aDmXm29swOFT o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BcBABp6HRV/4sNJK1cgkVLVF4Ggxi6a2YJgWCFeQKBGjgUAQEBAQEBAYEKhCIBAQEDASNWBQsCAQgOBAYnAwICIREUAw4CBA4FDogKAwoIDasEnXINhSUBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItDgk2CNQQHgmgvgRYFkGSCSoIYgUdhhQqBYIEvjySDMYNZJGGBWYE9bwGBRYEBAQEB X-IronPort-AV: E=Sophos;i="5.13,570,1427760000"; d="asc'?scan'208,217";a="157147858" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 08 Jun 2015 00:59:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t580xfUR014348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 00:59:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Sun, 7 Jun 2015 19:59:40 -0500 From: "Carlos Pignataro (cpignata)" To: Alia Atlas Thread-Topic: Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmVFPkEdW80Ovx0KvMcwtrOuud52RxuAAgAAkHYCAAEDsgIAABQWAgAAImYCAB8Q/AIAEe3GAgAO0xgA= Date: Mon, 8 Jun 2015 00:59:39 +0000 Message-ID: <60085C9B-4350-4D24-9AEC-74385C492683@cisco.com> References: <20150528132429.13861.98021.idtracker@ietfa.amsl.com> <556720DA.30306@joelhalpern.com> <556723E0.5040603@joelhalpern.com> <4C97F2B0-7AAE-49A4-9D63-65B5494AABBE@cisco.com> <55677F7D.1070807@joelhalpern.com> <2F403ACA-D45B-4184-9E39-9DE527DC7A35@gmail.com> 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.252.250] Content-Type: multipart/signed; boundary="Apple-Mail=_E93F4413-B6AC-41BF-B15B-D3CC51A7C8A3"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "Joel M. Halpern" , "sfc-chairs@ietf.org" , "sfc@ietf.org" , Kathleen Moriarty , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Kathleen Moriarty's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jun 2015 00:59:44 -0000 --Apple-Mail=_E93F4413-B6AC-41BF-B15B-D3CC51A7C8A3 Content-Type: multipart/alternative; boundary="Apple-Mail=_0061A1D9-7ED2-44F6-A3F2-67562B202C74" --Apple-Mail=_0061A1D9-7ED2-44F6-A3F2-67562B202C74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kathleen, Alia, We just posted a new revision incorporating this text below. URL: = https://www.ietf.org/internet-drafts/draft-ietf-sfc-architecture-09.txt = Status: = https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ = Htmlized: = https://tools.ietf.org/html/draft-ietf-sfc-architecture-09 = Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture-09 = Thanks! =E2=80=94 Carlos. > On Jun 5, 2015, at 12:23 PM, Alia Atlas wrote: >=20 > Hi Carlos & Joel, >=20 >=20 > On Tue, Jun 2, 2015 at 3:57 PM, Carlos Pignataro (cpignata) = > wrote: > Hi, Kathleen, >=20 > We iterated with Alia in trying to get a more condensed and = to-the-point version of the text. >=20 > Here=E2=80=99s a proposal that we believe can help address your = concern: >=20 > "A classifier may have privileged access to information about a packet = that is then communicated in the metadata. The threat of leaking this = private data needs to be considered [RFC 6973]. As one example, if = private data is represented by an identifier, then a new identifier can = be allocated, such that the mapping from the private data to the new = identifier is not broadly shared.=E2=80=9D >=20 > With [RFC 6973] as an Informational reference. >=20 > Does this help? >=20 > Kathleen and I discussed the proposed text and have a slight = modification as follows: > "A classifier may have privileged access to information about a packet = or inside a packet (See bullet 4 in Sec. 3 and Sec 4.9) that is then = communicated in the metadata. The threat of leaking this private data = needs to be mitigated [RFC 6937]. As one example, if private data is = represented by an identifier, then a new identifier can be allocated, = such that the mapping from the private data to the new identifier is not = broadly shared." >=20 > Thanks, > Alia >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On May 28, 2015, at 5:20 PM, Kathleen Moriarty = > wrote: >>=20 >> I can see your point of view, but that does not mean that a warning = is not needed. Someone may not be aware that their plain text traffic = could be used in the ways that are possible. Alia's suggested text = addresses this possible concern and is much appreciated to remove my = discuss. >>=20 >> Let me know if/when this text is incorporated. >>=20 >> Best regards, >> Kathleen >=20 >=20 --Apple-Mail=_0061A1D9-7ED2-44F6-A3F2-67562B202C74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Kathleen, Alia,

We just posted a new revision incorporating this text = below.

URL: =            https://www.ietf.org/internet-drafts/draft-ietf-sfc-architectur= e-09.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/
Htmlized:       https://tools.ietf.org/html/draft-ietf-sfc-architecture-09<= br class=3D"">Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture= -09

Thanks!

=E2=80=94 Carlos.

On = Jun 5, 2015, at 12:23 PM, Alia Atlas <akatlas@gmail.com> = wrote:

Hi Carlos & Joel,


On Tue, Jun 2, 2015 at = 3:57 PM, Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi, Kathleen,

We iterated with Alia in trying to get a more condensed and = to-the-point version of the text.

Here=E2=80=99s a proposal that we = believe can help address your concern:

"A classifier may have privileged = access to information about a packet that is then communicated in the = metadata.   The threat of leaking this private data needs to = be considered [RFC 6973]. As one example, if private data is = represented by an identifier, then a new identifier can be allocated, = such that the mapping from the private data to the new identifier = is not broadly shared.=E2=80=9D

With [RFC 6973] as an Informational reference.

Does this = help?

 Kathleen and I discussed the = proposed text and have a slight modification as follows:
"A = classifier may have privileged access to information about a packet or = inside a packet (See = bullet 4 in Sec. 3 and Sec 4.9) that is then communicated in the metadata.   The = threat of leaking this private data needs to be mitigated [RFC = 6937]. As one example, if private data is represented by an identifier, = then a new identifier can be allocated, such that the mapping from the = private data to the new identifier is not broadly shared."

Thanks,
Alia 

Thanks,

=E2=80=94 Carlos.

On May 28, 2015, at 5:20 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

I can see = your point of view, but that does not mean that a warning is not = needed.  Someone may not be aware that their plain text traffic = could be used in the ways that are possible.  Alia's suggested text = addresses this possible concern and is much appreciated to remove my = discuss.

Let me know = if/when this text is incorporated.

Best = regards,
Kathleen



= --Apple-Mail=_0061A1D9-7ED2-44F6-A3F2-67562B202C74-- --Apple-Mail=_E93F4413-B6AC-41BF-B15B-D3CC51A7C8A3 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 iQIcBAEBCAAGBQJVdOj+AAoJEIXgpQGOZny96g8P/2aByvqycfkDOzGO/FO8Lc6I nmqdVzbQNqfBEUkfWcLvet/869T4hdxf40gQk0b9xPwVI3iRulGZSN3mbkv0UFZY K1ttOMc0Ei+ifqzcOVXHDvYTec9su0wzGvYcFtYMTlQ6or2dAPTV4QwcJun0HGxJ XTCMOFs1JJ8cAuHhsrTay1FH5aPTkDWPBFJPI2XjEpMd2hlFGkANJOhKMksIVosZ yjvm0DACkiJQkq7JgJKLWLJ5jLMXZTCketlyZDrqOn96SYyg5/vDGqH4f5yz8BOq 7ziGQPGHuMI9WwpMIe7t0OaC3Ng/4VvV2OP6/rgX0FEMKQSlmsoL/2W7mppeUHOZ uYhkBw4OSG7vsOBsg9Lgz+riuXSCbohxP81RcNSXYc4PSFhHGPCg01g/KLXl9yhg iRbChwI+uhZOy59CfynWolM4tKQvs1OsYBwqe2MH7yO8NZKlo1bEYgnWLy7/VdhR QT3i43Of4gY+cWEUZ6SU+cixoQlrQ3fTiKim0nu264TpqyzJHBLDOjBK0kr51hkd 2Ol+vSRQAccX/x5uRCNl6/ao6gx18UoW9pQ/kSaOsKC4zjvj35+Ntc2fxPHJjv4e XyNXVrrjNTYDTC3BcWSiSzRUJ6hVZ/ekNPHN5fVjylKMDQMi2rGGtvxd8kuLN4Xf Fz3DE6un2AJCpDzl7hSb =wfqW -----END PGP SIGNATURE----- --Apple-Mail=_E93F4413-B6AC-41BF-B15B-D3CC51A7C8A3-- From nobody Sun Jun 7 18:16:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F15CB1A1AB6; Sun, 7 Jun 2015 18:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VfA9YaWL2e8z; Sun, 7 Jun 2015 18:16:35 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FB31A0199; Sun, 7 Jun 2015 18:16:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54104; q=dns/txt; s=iport; t=1433726194; x=1434935794; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8BITGWz2kUqeDIWRyHHl9AxV4mDK9/ZnWO9gceludSE=; b=EQFAHiB7szPjlSzsTj/7pvwpw3jRHF3eH/hPUNfMexz0YKs6wsH+Z0iN McTBP4RPAX4PrzRNd9KEMzN7xTuzhzNBKrOOPvUzYuupeOHONwckM71ej DK5gB5+2oDW1ysYel7FU7w2yv1pCes8wbhmNWw7r4IbwExYJNzFdTOwoa Y=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeBACB63RV/5BdJa1cgkVLVF4Ggxi6aWYJgWCFL0oCgRo4FAEBAQEBAQGBCoQiAQEBAwEjRA0FBQsCAQgSBiABCQICMhcOAgQOBQkFDYgKCA2rB6MkAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tDhDQBAUwEB4JoL4EWBYUOgWCMQIIYgUeFMIIbgS+SVYNZJGGBWYE9bwGBCzqBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,570,1427760000"; d="asc'?scan'208,217";a="157150820" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 08 Jun 2015 01:16:33 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t581GXlR002369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 01:16:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Sun, 7 Jun 2015 20:16:32 -0500 From: "Carlos Pignataro (cpignata)" To: Stephen Farrell Thread-Topic: Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Z/h6AgAfgk4CAAFQaAA== Date: Mon, 8 Jun 2015 01:16:32 +0000 Message-ID: References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> In-Reply-To: <5574A665.3080604@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.250] Content-Type: multipart/signed; boundary="Apple-Mail=_6F37C859-809D-4173-BFFC-482B017DEF40"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "sfc-chairs@ietf.org" , "sfc@ietf.org" , "Jim Guichard \(jguichar\)" , "draft-ietf-sfc-architecture.ad@ietf.org" , The IESG , "draft-ietf-sfc-architecture@ietf.org" , "draft-ietf-sfc-architecture.shepherd@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jun 2015 01:16:39 -0000 --Apple-Mail=_6F37C859-809D-4173-BFFC-482B017DEF40 Content-Type: multipart/alternative; boundary="Apple-Mail=_73B3D3C5-B670-4F31-AB1F-5287A176B5BC" --Apple-Mail=_73B3D3C5-B670-4F31-AB1F-5287A176B5BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stephen, > On Jun 7, 2015, at 4:15 PM, Stephen Farrell = wrote: >=20 >=20 > Hi Carlos, >=20 > Sorry for the delayed response - some more travel ensued;-( >=20 > On 02/06/15 20:57, Carlos Pignataro (cpignata) wrote: >> Hi, Stephen, >>=20 >> Let me reset the conversation, focusing specifically on the two = DISCUSSes you have: >>=20 >>> On May 28, 2015, at 8:52 AM, Stephen Farrell = wrote: >>>=20 >>> = ---------------------------------------------------------------------- >>> DISCUSS: >>> = ---------------------------------------------------------------------- >>>=20 >>>=20 >>> (1) I note the charter calls for this deliverable to "provide >>> a description of... security models" The charter also >>> generally notes that "The SFC WG will closely consider and >>> address the management and security implications when >>> documenting these deliverables." My conclusion is that this >>> deliverable needs to reflect the results of a security >>> analysis that the wg are suppoed to have carried out but that >>> it's currently too vague only saying that solutions need to >>> consider this. (Essentially this is a continuation of the >>> mail threads from the secdir review [1] and a satisfactory >>> resolution of that will probably resolve this.) >>>=20 >>> [1] >>> https://www.ietf.org/mail-archive/web/secdir/current/msg05701.html = = > >>=20 >>=20 >> Regarding (1), you say: >> Essentially this is a continuation of the >> mail threads from the secdir review [1] and a satisfactory >> resolution of that will probably resolve this" >>=20 >> And it seems from [2] there is a satisfactory resolution: >> Thanks for all these updates; I think they go a long way to = addressing the >> concerns that were raised during the secdir review. >> -Ben >>=20 >> [2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.html = >=20 > Yes, I think the secdir review discussions seem to be reaching > or have reached closure. I'd say an updated draft could be a > good idea as I've lost track of those changes. I'm therefore > also not sure if the results there are enough to clear this > point but that'll be much easier to determine with a revision. >=20 We just posted a new rev to clear Kathleen=E2=80=99s discuss and bring = up all comments from Benoit and others. There are good updates to the security considerations, as per secdir = thread as well. You can check those diffs. > I don't believe that those discussions have resulted in anything > that's a recognisable "security model" though have they (as is > called for by the charter). Can you speak to how that aspect of > the WG charter is met by the changes proposed or why that isn't > needed? >=20 The =E2=80=9Csecurity model=E2=80=9D is basically the analysis and = details in each of the four areas called out in the Security = Considerations. I do wonder if this might make it more clear. Additionally, see below. OLD: Security considerations apply to the realization of this architecture, in particular to the documents that will define protocols. Such realization ought to provide means to protect against security and privacy attacks in the areas hereby described. Building from the categorization of [RFC7498], we can largely divide | the security considerations in four areas: NEW: Security considerations apply to the realization of this architecture, in particular to the documents that will define protocols. Such realization ought to provide means to protect against security and privacy attacks in the areas hereby described. Building from the categorization of [RFC7498], we can largely divide | the security model in four areas, each of which is described = detailing | its security considerations: >>> (2) Metadata that contains information that is protected in >>> the data plane SHOULD be equally well protected when passed >>> about by SFC. I hope that's acceptable and documented. I'm >>> not sure myself if "passed about" ought also include within a >>> device but maybe it should really. But at minimum, I do >>> think you need to define confidentiality and origin >>> authentication services for SFC metadata and/or for the SFC >>> encapsulation as a whole. And I think this architecture >>> document needs to say that those services have to be >>> well-defined as part of any solution. (And I am not >>> saying that this draft needs to define how to do those.) >>>=20 >>>=20 >>=20 >>=20 >> Regarding (2), you say: >> Metadata that contains information that is protected in >> the data plane SHOULD be equally well protected when passed >> about by SFC. I hope that's acceptable and documented. >>=20 >> For this we have proposed adding the following text: >> Protocols addressing this architecture must include adjunct >> mechanisms to provide confidentiality and integrity of metadata >> carried by the protocol, although implementation of such >> mechanisms may be optional. >>=20 >> Would all these additions address your DISCUSS? >=20 > No, sorry. For one minor and two major reasons. >=20 > The first is that I want to ensure we do not end up in the > various bad situations that happened in the roll and karp > WGs, so a simple addition like that without any idea what is > likely to really happen isn't a good plan I think. >=20 > The second is that I am entirely unconvinced that any > security mechanisms can be an "adjunct" or optional to > implement. >=20 > The minor reason is that I don't think we have gotten to > the bottom of whether data integrity of data in transit > is sufficient or whether data origin authentication is > really needed here. (That could easily be something to be > addressed later in the WG but is not something to determine > now unless we do the analysis now, or describe that analysis > if it has been done but not written down so far which may > be the case.) As Joel mentioned, we can work on this. Text proposal will follow. >=20 > Cheers, > S. >=20 > PS: I'm starting on vacation on Thursday so will try to be > responsive on this in the meantime. However, we really ought > keep in mind that getting the right outcome at this stage > could save a lot of effort later, so I wouldn't be too focused > on trying to get this document done in the next few days and > I think we ought be much more focused on doing our best with > ensuring that SFC doesn't hit security speedbumps later on. Let=E2=80=99s not make delaying (as a self-fulfilling prophecy) an = objective in itself, however. I am not implying that=E2=80=99s what=E2=80=99= s happening, nor that that=E2=80=99s what you are doing right now =E2=80=94= but merely pointing out that kicking the can too far down the road does = not ensure quality. We have the attention on this now. I agree with you that the focus is getting to the right outcome (and = text) =E2=80=94 let=E2=80=99s not focus on not getting this done in the = next couple days either. Thanks, =E2=80=94 Carlos. >=20 >=20 >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. --Apple-Mail=_73B3D3C5-B670-4F31-AB1F-5287A176B5BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Stephen,

On = Jun 7, 2015, at 4:15 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hi Carlos,

Sorry for the delayed response - some more = travel ensued;-(

On 02/06/15 20:57, Carlos = Pignataro (cpignata) wrote:
Hi, Stephen,
Let me reset the conversation, focusing specifically on the = two DISCUSSes you have:

On May 28, 2015, at 8:52 AM, Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:

---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------


(1) I note the = charter calls for this deliverable to "provide
a = description of... security models" The charter also
generally notes that "The SFC WG will closely consider and
address the management and security implications when
documenting these deliverables." My conclusion is that = this
deliverable needs to reflect the results of a = security
analysis that the wg are suppoed to have carried = out but that
it's currently too vague only saying that = solutions need to
consider this. (Essentially this is a = continuation of the
mail threads from the secdir review = [1] and a satisfactory
resolution of that will probably = resolve this.)

 [1]
https://www.ietf.org/mail-archive/web/secdir/current/msg05701.h= tml <https://www.ietf.org/mail-archive/web/secdir/current/msg05701.h= tml>


Regarding (1), you say:
Essentially this is a = continuation of the
mail threads from the secdir review = [1] and a satisfactory
resolution of that will probably = resolve this"

And it seems from [2] there = is a satisfactory resolution:
Thanks for all these = updates; I think they go a long way to addressing the
concerns that were raised during the secdir review.
-Ben

[2] http://www.ietf.org/mail-archive/web/secdir/current/msg05740.ht= ml

Yes, I think the secdir = review discussions seem to be reaching
or have reached closure. I'd say an updated = draft could be a
good idea as I've lost = track of those changes. I'm therefore
also not sure if the results there are enough to = clear this
point but that'll be much = easier to determine with a revision.


We just posted a new rev to clear Kathleen=E2=80=99s= discuss and bring up all comments from Benoit and = others. 

There are good updates = to the security considerations, as per secdir thread as well. You can = check those diffs.

I don't believe = that those discussions have resulted in anything
that's a recognisable "security model" though = have they (as is
called for by the = charter). Can you speak to how that aspect of
the WG charter is met by the changes proposed or = why that isn't
needed?


The =E2=80=9Csecurity model=E2=80=9D is basically = the analysis and details in each of the four areas called out in the = Security Considerations.

I do wonder = if this might make it more clear.

Additionally, see below.

OLD:
  =  Security considerations apply to the realization of this
   architecture, in particular to the documents = that will define
   protocols.  Such = realization ought to provide means to protect
  =  against security and privacy attacks in the areas hereby = described.

   Building from the categorization of [RFC7498], = we can largely divide
|  the security = considerations in four areas:

NEW:
  =  Security considerations apply to the realization of this
   architecture, in particular to the documents = that will define
   protocols.  Such = realization ought to provide means to protect
  =  against security and privacy attacks in the areas hereby = described.

   Building from the categorization of [RFC7498], = we can largely divide
|  the security model in = four areas, each of which is described detailing
| =  its security considerations:


(2) Metadata that contains information that is protected = in
the data plane SHOULD be equally well protected when = passed
about by SFC. I hope that's acceptable and = documented. I'm
not sure myself if "passed about" ought = also include within a
device but maybe it should really. =  But at minimum, I do
think you need to define = confidentiality and origin
authentication services for SFC = metadata and/or for the SFC
encapsulation as a whole. And = I think this architecture
document needs to say that those = services have to be
well-defined as part of any solution. = (And I am not
saying that this draft needs to define how = to do those.)



Regarding (2), you say:
Metadata = that contains information that is protected in
the data = plane SHOULD be equally well protected when passed
about = by SFC. I hope that's acceptable and documented.

For this we have proposed adding the following text:
Protocols addressing this architecture must include = adjunct
mechanisms to provide confidentiality and = integrity of metadata
carried by the protocol, although = implementation of such
mechanisms may be optional.

Would all these additions address your = DISCUSS?

No, sorry. For one minor = and two major reasons.

The first is that I want = to ensure we do not end up in the
various bad situations that happened in the roll = and karp
WGs, so a simple addition = like that without any idea what is
likely to really happen isn't a good plan I = think.

The second is that I am = entirely unconvinced that any
security mechanisms can be = an "adjunct" or optional to
implement.

The minor reason is that I don't think we have = gotten to
the bottom of whether data = integrity of data in transit
is sufficient or whether = data origin authentication is
really needed here. (That = could easily be something to be
addressed later in the WG but is not something = to determine
now unless we do the = analysis now, or describe that analysis
if it has been done but not written down so far = which may
be the case.)

As Joel = mentioned, we can work on this. Text proposal will follow.


Cheers,
S.

PS: I'm starting on = vacation on Thursday so will try to be
responsive on this in the meantime. However, we = really ought
keep in mind that getting = the right outcome at this stage
could save a lot of effort later, so I wouldn't = be too focused
on trying to get this = document done in the next few days and
I think we ought be much more focused on doing = our best with
ensuring that SFC doesn't = hit security speedbumps later on.

Let=E2=80=99s not make delaying (as a = self-fulfilling prophecy) an objective in itself, however. I am not = implying that=E2=80=99s what=E2=80=99s happening, nor that that=E2=80=99s = what you are doing right now =E2=80=94 but merely pointing out that = kicking the can too far down the road does not ensure quality. We have = the attention on this now.

I agree = with you that the focus is getting to the right outcome (and text) =E2=80=94= let=E2=80=99s not focus on not getting this done in the next couple = days either.

Thanks,

=E2=80=94 Carlos.




Thanks,
=E2=80=94 = Carlos.

= --Apple-Mail=_73B3D3C5-B670-4F31-AB1F-5287A176B5BC-- --Apple-Mail=_6F37C859-809D-4173-BFFC-482B017DEF40 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 iQIcBAEBCAAGBQJVdOzyAAoJEIXgpQGOZny9/N4P/0341GL8pQulmoCwQuITc4Eo ObaJ49VqWEPAU5xQvfqMtleq/emauXauUlOZ4WcjoaTRi6mcMjXGGxdUE2MIxWN6 El4ZZPFuioNBjQZXHmK/J1zc9OiL5eIdrebEozmGgbeu17ODX30CU6p0rDBNjuj1 IC3kDlLpo11mpBdO2Nl5mw8RGkNCApZpA2lIG1d81h4hTz4u9zivGflFWSePE3zX D8uzB6SvZ5cMcS1PRgyTdDeWnsvL2GPib68Q1zKYJy9gwnOURAZO4XCsr9BLdZpU lTaDBdr+pcsxa+pEWjmxXU7urUVGmUP6GtocTHoxYhbHaFhehzCtYEUwpRBSZwQ2 TmNhPtYzh6iNvTz0k7or6QH8AgMEMXdVpAH305FYKMM7itT7FJGKe6eT8fvDo/xc kPMBlaeahqZmlAb+sALh82+raeevBP6fGBg3HrBxKenLoftM9GCnkY1DRJVgggkZ Z9UiyY2DSFBLY4BBHVreilH6TghE1Z/Ea3zD+kJ44PFtU3KJBq6rjFP+svSzFfyM 01esqVJZ8WJV0yVyzzFiX/LqPzAvwn7t5Vrz9zB/5Q5/UOaIPZh5lYgwdkKSZc6F yqHlHYv18WVAZrrhj0aF2yGHkXdoADXaXDAGdRuA4AtCuT7R+9RjWuZ2Mj2SbImS KZYIt+wx8aogYiedHAkW =Knge -----END PGP SIGNATURE----- --Apple-Mail=_6F37C859-809D-4173-BFFC-482B017DEF40-- From nobody Sun Jun 7 18:29:08 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1571A1B7C; Sun, 7 Jun 2015 18:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 g38JJVp1NpUA; Sun, 7 Jun 2015 18:29:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDAA1A1B78; Sun, 7 Jun 2015 18:29:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150608012904.18463.63314.idtracker@ietfa.amsl.com> Date: Sun, 07 Jun 2015 18:29:04 -0700 Archived-At: Cc: sfc-chairs@ietf.org, sfc@ietf.org, jguichar@cisco.com, draft-ietf-sfc-architecture.ad@ietf.org, draft-ietf-sfc-architecture@ietf.org, draft-ietf-sfc-architecture.shepherd@ietf.org Subject: [sfc] Kathleen Moriarty's No Objection on draft-ietf-sfc-architecture-09: (with COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 01:29:05 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-sfc-architecture-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for adding text to address my previous discuss: 1. The Security Considerations section only talks about privacy of the SFC information for classification. The more important point may be the privacy of any data gathered from a payload used for the classification and this needs to be mentioned. Comments: 1. For the Service Functions, I would think you would want to leave out "Lawful Intercept" as a device type since it's not a universal requirement on networks and immediately raises privacy concerns. 2. Section 3, #3 Classification on part of the packet payload will become increasingly more difficult as encryption is rolled out. The IETF and IAB both support the increased use of encryption for privacy and security purposes and are looking to have it end-to-end where possible. With the work out of TCPInc, encryption will be even more prevalent. From nobody Sun Jun 7 18:35:30 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED541B2A1D; Sun, 7 Jun 2015 18:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svp4e8_Gq9Hw; Sun, 7 Jun 2015 18:35:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98621A3B9B; Sun, 7 Jun 2015 18:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9391; q=dns/txt; s=iport; t=1433727327; x=1434936927; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9JPf2XEEn17/ADcWb+5nmy8XQmC4aK1hzRv8QOO83JQ=; b=gaILdRtsdAbGa79bs+4yutlugwhdnuUX/UeTxI4wfjS9zsLInH5iwkf4 0+9gS8iVq4MxxwUNPt563bRgd0P58dlfyVUfhDXK8j2PFNdc3TeA3ABZP FQSKswL6Vtvnxp3QETt9j5r6fMaRz9Jyhc81h99yRkYyWJDarKXMDQ3uA o=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BNBQCn8HRV/5pdJa1WBoMQVF4Ggxi6aW+BVgqFeQKBGjkTAQEBAQEBAYEKhCIBAQEDAQEBASBEBwYFBQsCAQgSBioCAicLFw4CBA4FDogXCA2rDqMlAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4RDQweCaC+BFgWTLoIYgUeHS4Evg3qOW4NZJGGBKBwVgT1vgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,570,1427760000"; d="asc'?scan'208";a="157285627" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 08 Jun 2015 01:35:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t581ZPBJ001884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Jun 2015 01:35:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Sun, 7 Jun 2015 20:35:25 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Z/h6AgAfgk4CAAASJgIAAAMcAgAABoICAAAbggIAACXkAgABCGIA= Date: Mon, 8 Jun 2015 01:35:24 +0000 Message-ID: References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> In-Reply-To: <5574B9EE.2070002@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.252.250] Content-Type: multipart/signed; boundary="Apple-Mail=_EFA434CA-F7F9-4721-8BB2-5FEA3C99252B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "sfc@ietf.org" , Stephen Farrell Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jun 2015 01:35:29 -0000 --Apple-Mail=_EFA434CA-F7F9-4721-8BB2-5FEA3C99252B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, Please find some concrete text, with a sufficiently detailed = explanation, to anchor the discussion. Feedback? =E2=80=94>8=E2=80=94 6.1. SFC Data Plane Security One of the aspects to consider as part of the SFC security model is = whether to mandate the implementation of, and strongly recommend the use = of authentication and encryption technology within the SFC data plane. = This architecture mandates the definition of mechanisms to provide = confidentiality and integrity of metadata carried by the protocol, but = makes not further recommendations. This is based on the unusual = operating constraints. Rather than being an end-to-end protocol, or = even a relayed protocol with a desire to reduce the number of relays, = the goal of this protocol is to deliver data packets to a series of = service functions. These functions are selected and provided by a = combination of user and operator decisions. They are, in most cases, = granted access to the data packet contents and the metadata. Securing = the packets from the service functions would be counter-productive. One could argue for securing the packets as they traverse the underlying = network. Provisions for this are already included under the =E2=80=9CServ= ice Overlay=E2=80=9D title in this Security Considerations. In the = general case where every hop between service functions is over untrusted = media, that may be necessary and appropriate. However, the initial = target is for a single administrative domain, where if there are any = untrustued segments they will be few and well-recognized. Even in the = general case, most transport connections will be sufficiently trusted so = as not to warrant the cost of hop-wise security mechanisms over a = multi-hop transport. Given the operator focus on internal use of this tool, even demanding = implementation of such mechanisms is likely to place a cost on delivery = that will interfere with the use of this technology. It should be = understood that this architecture is a new model replacement for a = multiplicity of widely used techniques, most of which do not even have = the option of security mechanisms. This analysis leads to an expectation of a need for optional security = techniques well-integrated with the protocol so that they can be used = where needed, without mandating that all implementations include such = capabilities. =E2=80=94>8=E2=80=94 Thanks, =E2=80=94 Carlos. > On Jun 7, 2015, at 5:38 PM, Joel M. Halpern = wrote: >=20 > This sounds like something Carlos and I can try to address in = conjunction with the revisions. Sorry if I was slow to understand the = quesiton. >=20 > Yours, > Joel >=20 > On 6/7/15 5:04 PM, Stephen Farrell wrote: >>=20 >>=20 >> On 07/06/15 21:40, Joel M. Halpern wrote: >>> The escurity considerations section addresses, as far as we = understand >>> them, the issues that a "security model" needs to cover. It is not = done >>> as an explicit model. We could recast the section as such a model, = but >>> it would end up saying the same things. >>=20 >> Well, let's see what a revised ID looks like and then haggle about >> that maybe. I think that'll be easier. (I note you did not say that >> the charter text on this is OBE btw.) >>=20 >>> We could write more explicitly some of the other assumptions we = make, >>> for example that the services to which user packets are delivered = are >>> trusted by the operator to examine the packets and associated = metadata. >>> We could note that the service functions are further trusted to = modify >>> the packet contents and metadata. >>> We could add text that in most single-domain cases, the underlying >>> infrastructure is trusted by the operator. >>=20 >> If your goal as authors/WG is to not have mandatory to implement >> security then yes you would I think need to explicitly justify that >> in a convincing manner. Isn't it perhaps telling us something if you >> chose to not explicitly say things like "trusted by the operator so >> no security needed" in the draft? (Seems so to me tbh.) >>=20 >>>=20 >>> Would adding text like that help? It would seem instead to provoke = the >>> BCP61 comment that you are now making. >>=20 >> The BCP61 comment resulted from your proposed text ("adjunct" etc) = which >> seems to me to run counter to that BCP. Are you arguing that such = text >> would be consistent with BCP61? If not, then what is your argument = for >> BCP61 not applying or being unwise in this case? >>=20 >> Cheers, >> S. >>=20 >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>=20 >>>>=20 >>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>> I am not sure how to usefully respond to your concern that you are = not >>>>> convinced that security mechanisms can be adjunct or optional. = That >>>>> seems to border on opinion, rather than factual basis for a = discuss. >>>>> Further, I really do not want to end up in a situation where the >>>>> majority of implementations are not conformant to the architecture = and >>>>> protocol spec. >>>>> And it is very clear that most of the environments at least for = the >>>>> initial, single domain, case that we are targeting will not need = any >>>>> form of authentication or data integrity in the SFC mechanism. >>>>=20 >>>> Hmm. Doesn't BCP61 directly address the above? >>>>=20 >>>>>=20 >>>>> Also, I realized looking at your comments and the charter, that I = do not >>>>> know know what would constitute a "security model" as you = understand it. >>>>=20 >>>> Ok - what is a security model as you understand what the charter >>>> says about this deliverable? Since you're an author and the charter >>>> calls for that can you point me at where in the draft I find it >>>> or why it is no longer needed/relevant/whatever? >>>>=20 >>>> Ta, >>>> S. >>>>=20 >>>>=20 >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>=20 >>>>>> Hi Carlos, >>>>>>=20 >>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>=20 >>>>> ... >>>>>> No, sorry. For one minor and two major reasons. >>>>>>=20 >>>>>> The first is that I want to ensure we do not end up in the >>>>>> various bad situations that happened in the roll and karp >>>>>> WGs, so a simple addition like that without any idea what is >>>>>> likely to really happen isn't a good plan I think. >>>>>>=20 >>>>>> The second is that I am entirely unconvinced that any >>>>>> security mechanisms can be an "adjunct" or optional to >>>>>> implement. >>>>>>=20 >>>>>> The minor reason is that I don't think we have gotten to >>>>>> the bottom of whether data integrity of data in transit >>>>>> is sufficient or whether data origin authentication is >>>>>> really needed here. (That could easily be something to be >>>>>> addressed later in the WG but is not something to determine >>>>>> now unless we do the analysis now, or describe that analysis >>>>>> if it has been done but not written down so far which may >>>>>> be the case.) >>>>>>=20 >>>>>> Cheers, >>>>>> S. >>>>>>=20 >>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>> responsive on this in the meantime. However, we really ought >>>>>> keep in mind that getting the right outcome at this stage >>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>> on trying to get this document done in the next few days and >>>>>> I think we ought be much more focused on doing our best with >>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks, >>>>>>>=20 >>>>>>> =E2=80=94 Carlos. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_EFA434CA-F7F9-4721-8BB2-5FEA3C99252B 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 iQIcBAEBCAAGBQJVdPFeAAoJEIXgpQGOZny9s/wQAKx3tQrE0OhHG7kDCtjO69CK QVSCGoKBo0gT6EIbsyThh9NcY6CDldSuwqMCidTp/Q5tYbSG9zx7kl8hFNfiOd9I sY6z0A+u1EtSndxFzwai/suWsMrHY8rjmrZPe4bc/JH0qRuIRqoRSdTCAhhtarwn 1AQYVNq7qNkzY7XRVXfbde+jRUNU9faWHs4V7O4HcjOpT5AY2PYllwj24FNAbkLZ eCvwyUU4AtP3kND7Dd0ySBMzzNeaSHe4hzfFX8wk6bJKS0jFZdqkLGu064HJ6kZh zXrOHZ4rheJCva5kGbTkIIj3qbUBr7n+drJMK8WKJB6xirLqQg3gPgpr/g7AsE/Y u511MAv/mdPz1Rr73uvbUkTB7Vs1ua0jjAyLGeQzJ8F+Piihkp2p6E3sALEcx8hD l4EebNv2Iirz/eHn1uNib99Uwphre29/wNJmsvf+PZsUG0N/G8ZxMphJMBETIiBs OCmvfLhSo+li3EKLf0ndRSJ8q8+UZJ4zbhBqCmtkr3KyM4cBcYnmkoHlh/4rQUOX mMvII8C4+VQq/fTXMHujWEHkYoJHAYBfdMQ5HJ2pDKUwErBzk4rygLVyC0sbBfGj I/aGh6wUh/rktrFvyWovbC/7GFWkD2iIM8dyUB96QPbdmOT8JLm4O54EutujvfEv Yugsxhq0pE+JgUM9VvDL =C5MF -----END PGP SIGNATURE----- --Apple-Mail=_EFA434CA-F7F9-4721-8BB2-5FEA3C99252B-- From nobody Mon Jun 8 02:41:05 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3041B2DF0 for ; Mon, 8 Jun 2015 02:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.103 X-Spam-Level: X-Spam-Status: No, score=-0.103 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 191QqsooVsBn for ; Mon, 8 Jun 2015 02:41:03 -0700 (PDT) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 668331B2DF5 for ; Mon, 8 Jun 2015 02:41:03 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t589f21q021499 for ; Mon, 8 Jun 2015 18:41:02 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id ACA4B5F63F for ; Mon, 8 Jun 2015 18:41:01 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 9F14D5F611 for ; Mon, 8 Jun 2015 18:41:01 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t589esQt000369 for ; Mon, 8 Jun 2015 18:41:02 +0900 Message-ID: <5575637F.1010305@lab.ntt.co.jp> Date: Mon, 08 Jun 2015 18:42:23 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 References: <20150608093057.1730.81194.idtracker@ietfa.amsl.com> In-Reply-To: <20150608093057.1730.81194.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150608093057.1730.81194.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: sfc@ietf.org X-TM-AS-MML: disable Archived-At: Subject: [sfc] Fwd: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-02.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:41:05 -0000 Hi all, We have updated the draft, which describes analysis on forwarding methods for service chaining, based on opinions which we got at Dallas or from emails. The main changed points of this revision are as follows: - Two new authors participated - Separated the analysis into data and control plane aspects - Added a case study with actual measurement for method 1 - Sorted the network conditions in section 4.3 - Added some concrete use cases in mobile networks into section 4.3.2 If you have any opinions or comments, please let us know. We will welcome new suggestions! Best regards, Shunsuke -------- Forwarded Message -------- Subject: New Version Notification for draft-homma-sfc-forwarding-methods-analysis-02.txt Date: Mon, 08 Jun 2015 02:30:57 -0700 From: internet-drafts@ietf.org To: Alexey Gorbunov , Kengo , Shunsuke Homma , Alexey Gorbunov , Nicolai Leymann , Diego R. Lopez , David Dolson , Diego Lopez , Kengo Naito , David Dolson , Nicolai Leymann , Shunsuke Homma A new version of I-D, draft-homma-sfc-forwarding-methods-analysis-02.txt has been successfully submitted by Shunsuke Homma and posted to the IETF repository. Name: draft-homma-sfc-forwarding-methods-analysis Revision: 02 Title: Analysis on Forwarding Methods for Service Chaining Document date: 2015-06-08 Group: Individual Submission Pages: 31 URL: https://www.ietf.org/internet-drafts/draft-homma-sfc-forwarding-methods-analysis-02.txt Status: https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/ Htmlized: https://tools.ietf.org/html/draft-homma-sfc-forwarding-methods-analysis-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-homma-sfc-forwarding-methods-analysis-02 Abstract: Some working groups of the IETF and other Standards Developing Organizations are now discussing use cases of a technology that enables data packets to traverse appropriate service functions located remotely through networks. This is called Service Chaining in this document. (Also, in Network Functions Virtualisation (NFV), a subject that forwarding packets to required service functions in appropriate order is called VNF Forwarding Graph.) This draft does not focus only on SFC method, and thus, use the term "Service Chaining." SFC may be one of approaches to realize Service Chaining. There are several Service Chaining methods to forward data packets to service functions, and the applicable methods will vary depending on the service requirements of individual networks. This document presents the results of analyzing packet forwarding methods and path selection patterns for achieving Service Chaining. For forwarding data packets to the appropriate service functions, distribution of route information and steering data packets following the route information, are required. Examples of route information are packet identifier and the routing configurations based on the identifier. Also, forwarding functions are required to decide the path according to the route information. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Jun 8 16:53:47 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436DC1ACD60; Mon, 8 Jun 2015 16:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_5kWItssB5T; Mon, 8 Jun 2015 16:53:43 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663FB1ACDB1; Mon, 8 Jun 2015 16:53:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0A324BED6; Tue, 9 Jun 2015 00:53:41 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1jymdAXIpoJ; Tue, 9 Jun 2015 00:53:35 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 38052BEBC; Tue, 9 Jun 2015 00:53:35 +0100 (IST) Message-ID: <55762AFE.2080604@cs.tcd.ie> Date: Tue, 09 Jun 2015 00:53:34 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "Joel M. Halpern" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="q4kJD5eTaLjfLWQTp2L36EoLsUUmWeB4b" Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Jun 2015 23:53:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --q4kJD5eTaLjfLWQTp2L36EoLsUUmWeB4b Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, Thanks for that text, which I think seems to match well with what you and Joel have been saying. I have to say though that I don't find it at all convincing given that we have bcp61. Having some mti security so that it can be turned on when needed despite buying kit from multiple vendors is what bcp61 calls for and I really don't see why sfc is an exception. A question for you - is it useful for me to try de-construct the text below (on the above basis) or not? It may be a waste of time and we may be better off getting additional viewpoints on this instead. And in case it helps, I think the main (not the only) counter to what you propose below is the consideration that while sfc may only be well-defined for intradomain use now, intradomain use can in various ways span what are now clearly important trust boundaries, see tempora/belgacom/gemalto for examples. Cheers, S. On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: > Stephen, >=20 > Please find some concrete text, with a sufficiently detailed explanatio= n, to anchor the discussion. >=20 > Feedback? >=20 > =E2=80=94>8=E2=80=94 > 6.1. SFC Data Plane Security >=20 > One of the aspects to consider as part of the SFC security model is whe= ther to mandate the implementation of, and strongly recommend the use of = authentication and encryption technology within the SFC data plane. This= architecture mandates the definition of mechanisms to provide confidenti= ality and integrity of metadata carried by the protocol, but makes not fu= rther recommendations. This is based on the unusual operating constraints= =2E Rather than being an end-to-end protocol, or even a relayed protocol= with a desire to reduce the number of relays, the goal of this protocol = is to deliver data packets to a series of service functions. These funct= ions are selected and provided by a combination of user and operator deci= sions. They are, in most cases, granted access to the data packet content= s and the metadata. Securing the packets from the service functions woul= d be counter-productive. >=20 > One could argue for securing the packets as they traverse the underlyin= g network. Provisions for this are already included under the =E2=80=9CS= ervice Overlay=E2=80=9D title in this Security Considerations. In the gen= eral case where every hop between service functions is over untrusted med= ia, that may be necessary and appropriate. However, the initial target is= for a single administrative domain, where if there are any untrustued se= gments they will be few and well-recognized. Even in the general case, m= ost transport connections will be sufficiently trusted so as not to warra= nt the cost of hop-wise security mechanisms over a multi-hop transport. >=20 > Given the operator focus on internal use of this tool, even demanding i= mplementation of such mechanisms is likely to place a cost on delivery th= at will interfere with the use of this technology. It should be understo= od that this architecture is a new model replacement for a multiplicity o= f widely used techniques, most of which do not even have the option of se= curity mechanisms. >=20 > This analysis leads to an expectation of a need for optional security t= echniques well-integrated with the protocol so that they can be used wher= e needed, without mandating that all implementations include such capabil= ities. > =E2=80=94>8=E2=80=94 >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern wrot= e: >> >> This sounds like something Carlos and I can try to address in conjunct= ion with the revisions. Sorry if I was slow to understand the quesiton. >> >> Yours, >> Joel >> >> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>> >>> >>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>> The escurity considerations section addresses, as far as we understa= nd >>>> them, the issues that a "security model" needs to cover. It is not = done >>>> as an explicit model. We could recast the section as such a model, = but >>>> it would end up saying the same things. >>> >>> Well, let's see what a revised ID looks like and then haggle about >>> that maybe. I think that'll be easier. (I note you did not say that >>> the charter text on this is OBE btw.) >>> >>>> We could write more explicitly some of the other assumptions we make= , >>>> for example that the services to which user packets are delivered ar= e >>>> trusted by the operator to examine the packets and associated metada= ta. >>>> We could note that the service functions are further trusted to mod= ify >>>> the packet contents and metadata. >>>> We could add text that in most single-domain cases, the underlying >>>> infrastructure is trusted by the operator. >>> >>> If your goal as authors/WG is to not have mandatory to implement >>> security then yes you would I think need to explicitly justify that >>> in a convincing manner. Isn't it perhaps telling us something if you >>> chose to not explicitly say things like "trusted by the operator so >>> no security needed" in the draft? (Seems so to me tbh.) >>> >>>> >>>> Would adding text like that help? It would seem instead to provoke = the >>>> BCP61 comment that you are now making. >>> >>> The BCP61 comment resulted from your proposed text ("adjunct" etc) wh= ich >>> seems to me to run counter to that BCP. Are you arguing that such tex= t >>> would be consistent with BCP61? If not, then what is your argument fo= r >>> BCP61 not applying or being unwise in this case? >>> >>> Cheers, >>> S. >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>> >>>>> >>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>> I am not sure how to usefully respond to your concern that you are= not >>>>>> convinced that security mechanisms can be adjunct or optional. Th= at >>>>>> seems to border on opinion, rather than factual basis for a discus= s. >>>>>> Further, I really do not want to end up in a situation where the >>>>>> majority of implementations are not conformant to the architecture= and >>>>>> protocol spec. >>>>>> And it is very clear that most of the environments at least for th= e >>>>>> initial, single domain, case that we are targeting will not need a= ny >>>>>> form of authentication or data integrity in the SFC mechanism. >>>>> >>>>> Hmm. Doesn't BCP61 directly address the above? >>>>> >>>>>> >>>>>> Also, I realized looking at your comments and the charter, that I = do not >>>>>> know know what would constitute a "security model" as you understa= nd it. >>>>> >>>>> Ok - what is a security model as you understand what the charter >>>>> says about this deliverable? Since you're an author and the charter= >>>>> calls for that can you point me at where in the draft I find it >>>>> or why it is no longer needed/relevant/whatever? >>>>> >>>>> Ta, >>>>> S. >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> Hi Carlos, >>>>>>> >>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>> >>>>>> ... >>>>>>> No, sorry. For one minor and two major reasons. >>>>>>> >>>>>>> The first is that I want to ensure we do not end up in the >>>>>>> various bad situations that happened in the roll and karp >>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>> likely to really happen isn't a good plan I think. >>>>>>> >>>>>>> The second is that I am entirely unconvinced that any >>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>> implement. >>>>>>> >>>>>>> The minor reason is that I don't think we have gotten to >>>>>>> the bottom of whether data integrity of data in transit >>>>>>> is sufficient or whether data origin authentication is >>>>>>> really needed here. (That could easily be something to be >>>>>>> addressed later in the WG but is not something to determine >>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>> if it has been done but not written down so far which may >>>>>>> be the case.) >>>>>>> >>>>>>> Cheers, >>>>>>> S. >>>>>>> >>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>> responsive on this in the meantime. However, we really ought >>>>>>> keep in mind that getting the right outcome at this stage >>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>> on trying to get this document done in the next few days and >>>>>>> I think we ought be much more focused on doing our best with >>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> =E2=80=94 Carlos. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --q4kJD5eTaLjfLWQTp2L36EoLsUUmWeB4b Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdir+AAoJEC88hzaAX42ilzMH/jqbiYcpwjQvLTn2tR/Rwzns F/A1IwOqWZBfJzxzYK8xJDwjOK8dn1Rj85MBsKSM9wMYJlqwTwWlpTj3ghNPit1e nvfH9anPkQ3lrFkH7fUqx7ne844iLjMUy0KVHHlfXd1xowPJgaCAGGYxRmoyYuDx 2FlZxmUcAs0POC89aepBX+t3zz/lHC/p4nzT28UZvpqkdK8kJ77a0BzazJGkd6jN tWQLI3LwU556Yc0N0XxibCXilXoUg8wuXN1nfIJV/xqR3MTqvmTuAPK/UA4hbsYX Lg44ljCWZt1BmQbP2c05eTRqUA17sK1MQmP/2/Y/A/3shZF46xoA+pgY8dOGpIw= =H0Oq -----END PGP SIGNATURE----- --q4kJD5eTaLjfLWQTp2L36EoLsUUmWeB4b-- From nobody Mon Jun 8 17:12:18 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714031ACDF5; Mon, 8 Jun 2015 17:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KD5ZxiwlPUMJ; Mon, 8 Jun 2015 17:12:13 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57301ACDF4; Mon, 8 Jun 2015 17:12:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id C3B77240E1E; Mon, 8 Jun 2015 17:12:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id F0BC9240840; Mon, 8 Jun 2015 17:12:12 -0700 (PDT) Message-ID: <55762F4D.6070400@joelhalpern.com> Date: Mon, 08 Jun 2015 20:11:57 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> In-Reply-To: <55762AFE.2080604@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 00:12:16 -0000 Given that we do clearly recognize that there are cases where securing the communication is necessary this comes down, from what you are saying now, to the simple question of whether we have justified the absence of an MTI security mechanism. You are saying "no". We are saying "the working group did not ask for it, and here the reasons we think that is defensible." BCP61 does recognize that it does not apply to all cases. I am very concerned that if we write an MTI security mechanism into this, almost no implementations will be compliant with the specifications. That does not do us any good at all. You asked for us to be explicit, and to state our reasons. We have done so. Yes, we could have a working group hum on whether we want an MTI security mechanism in all solutions which comply with the architecture. I think we already have clarity on that issue from the WG. And I doubt such a hum would change your mind if it went against you. Yours, Joel On 6/8/15 7:53 PM, Stephen Farrell wrote: > > Hi Carlos, > > Thanks for that text, which I think seems to match well with what > you and Joel have been saying. > > I have to say though that I don't find it at all convincing given > that we have bcp61. Having some mti security so that it can be > turned on when needed despite buying kit from multiple vendors is > what bcp61 calls for and I really don't see why sfc is an exception. > > A question for you - is it useful for me to try de-construct the > text below (on the above basis) or not? It may be a waste of time > and we may be better off getting additional viewpoints on this > instead. > > And in case it helps, I think the main (not the only) counter to what > you propose below is the consideration that while sfc may only be > well-defined for intradomain use now, intradomain use can in > various ways span what are now clearly important trust boundaries, > see tempora/belgacom/gemalto for examples. > > Cheers, > S. > > > On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >> Stephen, >> >> Please find some concrete text, with a sufficiently detailed explanation, to anchor the discussion. >> >> Feedback? >> >> —>8— >> 6.1. SFC Data Plane Security >> >> One of the aspects to consider as part of the SFC security model is whether to mandate the implementation of, and strongly recommend the use of authentication and encryption technology within the SFC data plane. This architecture mandates the definition of mechanisms to provide confidentiality and integrity of metadata carried by the protocol, but makes not further recommendations. This is based on the unusual operating constraints. Rather than being an end-to-end protocol, or even a relayed protocol with a desire to reduce the number of relays, the goal of this protocol is to deliver data packets to a series of service functions. These functions are selected and provided by a combination of user and operator decisions. They are, in most cases, granted access to the data packet contents and the metadata. Securing the packets from the service functions would be counter-productive. >> >> One could argue for securing the packets as they traverse the underlying network. Provisions for this are already included under the “Service Overlay†title in this Security Considerations. In the general case where every hop between service functions is over untrusted media, that may be necessary and appropriate. However, the initial target is for a single administrative domain, where if there are any untrustued segments they will be few and well-recognized. Even in the general case, most transport connections will be sufficiently trusted so as not to warrant the cost of hop-wise security mechanisms over a multi-hop transport. >> >> Given the operator focus on internal use of this tool, even demanding implementation of such mechanisms is likely to place a cost on delivery that will interfere with the use of this technology. It should be understood that this architecture is a new model replacement for a multiplicity of widely used techniques, most of which do not even have the option of security mechanisms. >> >> This analysis leads to an expectation of a need for optional security techniques well-integrated with the protocol so that they can be used where needed, without mandating that all implementations include such capabilities. >> —>8— >> >> Thanks, >> >> — Carlos. >> >>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern wrote: >>> >>> This sounds like something Carlos and I can try to address in conjunction with the revisions. Sorry if I was slow to understand the quesiton. >>> >>> Yours, >>> Joel >>> >>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>> >>>> >>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>> The escurity considerations section addresses, as far as we understand >>>>> them, the issues that a "security model" needs to cover. It is not done >>>>> as an explicit model. We could recast the section as such a model, but >>>>> it would end up saying the same things. >>>> >>>> Well, let's see what a revised ID looks like and then haggle about >>>> that maybe. I think that'll be easier. (I note you did not say that >>>> the charter text on this is OBE btw.) >>>> >>>>> We could write more explicitly some of the other assumptions we make, >>>>> for example that the services to which user packets are delivered are >>>>> trusted by the operator to examine the packets and associated metadata. >>>>> We could note that the service functions are further trusted to modify >>>>> the packet contents and metadata. >>>>> We could add text that in most single-domain cases, the underlying >>>>> infrastructure is trusted by the operator. >>>> >>>> If your goal as authors/WG is to not have mandatory to implement >>>> security then yes you would I think need to explicitly justify that >>>> in a convincing manner. Isn't it perhaps telling us something if you >>>> chose to not explicitly say things like "trusted by the operator so >>>> no security needed" in the draft? (Seems so to me tbh.) >>>> >>>>> >>>>> Would adding text like that help? It would seem instead to provoke the >>>>> BCP61 comment that you are now making. >>>> >>>> The BCP61 comment resulted from your proposed text ("adjunct" etc) which >>>> seems to me to run counter to that BCP. Are you arguing that such text >>>> would be consistent with BCP61? If not, then what is your argument for >>>> BCP61 not applying or being unwise in this case? >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>> >>>>>> >>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>> I am not sure how to usefully respond to your concern that you are not >>>>>>> convinced that security mechanisms can be adjunct or optional. That >>>>>>> seems to border on opinion, rather than factual basis for a discuss. >>>>>>> Further, I really do not want to end up in a situation where the >>>>>>> majority of implementations are not conformant to the architecture and >>>>>>> protocol spec. >>>>>>> And it is very clear that most of the environments at least for the >>>>>>> initial, single domain, case that we are targeting will not need any >>>>>>> form of authentication or data integrity in the SFC mechanism. >>>>>> >>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>> >>>>>>> >>>>>>> Also, I realized looking at your comments and the charter, that I do not >>>>>>> know know what would constitute a "security model" as you understand it. >>>>>> >>>>>> Ok - what is a security model as you understand what the charter >>>>>> says about this deliverable? Since you're an author and the charter >>>>>> calls for that can you point me at where in the draft I find it >>>>>> or why it is no longer needed/relevant/whatever? >>>>>> >>>>>> Ta, >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> Hi Carlos, >>>>>>>> >>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>> >>>>>>> ... >>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>> >>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>> various bad situations that happened in the roll and karp >>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>> >>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>> implement. >>>>>>>> >>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>> is sufficient or whether data origin authentication is >>>>>>>> really needed here. (That could easily be something to be >>>>>>>> addressed later in the WG but is not something to determine >>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>> if it has been done but not written down so far which may >>>>>>>> be the case.) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> S. >>>>>>>> >>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>>> on trying to get this document done in the next few days and >>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> — Carlos. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> > From nobody Mon Jun 8 17:32:20 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89DF1ACE51; Mon, 8 Jun 2015 17:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOSFNAgk7waf; Mon, 8 Jun 2015 17:32:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CD91ACE4D; Mon, 8 Jun 2015 17:32:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7BC9DBECA; Tue, 9 Jun 2015 01:32:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LuyDyvil5L7; Tue, 9 Jun 2015 01:32:05 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.23.15]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 935EEBE35; Tue, 9 Jun 2015 01:32:05 +0100 (IST) Message-ID: <55763405.2000804@cs.tcd.ie> Date: Tue, 09 Jun 2015 01:32:05 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> In-Reply-To: <55762F4D.6070400@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 00:32:16 -0000 Hiya, On 09/06/15 01:11, Joel M. Halpern wrote: > Given that we do clearly recognize that there are cases where securing > the communication is necessary this comes down, from what you are saying > now, to the simple question of whether we have justified the absence of > an MTI security mechanism. If the question were simple, it'd be easier I guess:-) > > You are saying "no". We are saying "the working group did not ask for > it, and here the reasons we think that is defensible." Can you show me where the WG discussed this? (In the archive.) Seeing that discussion would help. If it has not happened, then seeing that discussion will help. > > BCP61 does recognize that it does not apply to all cases. I'm not sure what part(s) of bcp61 you mean, can you point me at that/those? > I am very concerned that if we write an MTI security mechanism into > this, almost no implementations will be compliant with the > specifications. That does not do us any good at all. Yes. Mythical security is no security I fully agree. But Carlos' text did not speak to unwillingness to implement, nor to any inability to define a usable/sufficiently-useful mechanism. > > You asked for us to be explicit, and to state our reasons. We have done > so. Carlos' recent text omitted some points mentioned above. > Yes, we could have a working group hum on whether we want an MTI > security mechanism in all solutions which comply with the architecture. > I think we already have clarity on that issue from the WG. And I doubt > such a hum would change your mind if it went against you. I am not asking for a hum. I am asking to see the (archive of the) discussion demonstrating that clarity. Please send a URL. Thanks, S. > > Yours, > Joel > > On 6/8/15 7:53 PM, Stephen Farrell wrote: >> >> Hi Carlos, >> >> Thanks for that text, which I think seems to match well with what >> you and Joel have been saying. >> >> I have to say though that I don't find it at all convincing given >> that we have bcp61. Having some mti security so that it can be >> turned on when needed despite buying kit from multiple vendors is >> what bcp61 calls for and I really don't see why sfc is an exception. >> >> A question for you - is it useful for me to try de-construct the >> text below (on the above basis) or not? It may be a waste of time >> and we may be better off getting additional viewpoints on this >> instead. >> >> And in case it helps, I think the main (not the only) counter to what >> you propose below is the consideration that while sfc may only be >> well-defined for intradomain use now, intradomain use can in >> various ways span what are now clearly important trust boundaries, >> see tempora/belgacom/gemalto for examples. >> >> Cheers, >> S. >> >> >> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>> Stephen, >>> >>> Please find some concrete text, with a sufficiently detailed >>> explanation, to anchor the discussion. >>> >>> Feedback? >>> >>> —>8— >>> 6.1. SFC Data Plane Security >>> >>> One of the aspects to consider as part of the SFC security model is >>> whether to mandate the implementation of, and strongly recommend the >>> use of authentication and encryption technology within the SFC data >>> plane. This architecture mandates the definition of mechanisms to >>> provide confidentiality and integrity of metadata carried by the >>> protocol, but makes not further recommendations. This is based on the >>> unusual operating constraints. Rather than being an end-to-end >>> protocol, or even a relayed protocol with a desire to reduce the >>> number of relays, the goal of this protocol is to deliver data >>> packets to a series of service functions. These functions are >>> selected and provided by a combination of user and operator >>> decisions. They are, in most cases, granted access to the data packet >>> contents and the metadata. Securing the packets from the service >>> functions would be counter-productive. >>> >>> One could argue for securing the packets as they traverse the >>> underlying network. Provisions for this are already included under >>> the “Service Overlay†title in this Security Considerations. In the >>> general case where every hop between service functions is over >>> untrusted media, that may be necessary and appropriate. However, the >>> initial target is for a single administrative domain, where if there >>> are any untrustued segments they will be few and well-recognized. >>> Even in the general case, most transport connections will be >>> sufficiently trusted so as not to warrant the cost of hop-wise >>> security mechanisms over a multi-hop transport. >>> >>> Given the operator focus on internal use of this tool, even demanding >>> implementation of such mechanisms is likely to place a cost on >>> delivery that will interfere with the use of this technology. It >>> should be understood that this architecture is a new model >>> replacement for a multiplicity of widely used techniques, most of >>> which do not even have the option of security mechanisms. >>> >>> This analysis leads to an expectation of a need for optional security >>> techniques well-integrated with the protocol so that they can be used >>> where needed, without mandating that all implementations include such >>> capabilities. >>> —>8— >>> >>> Thanks, >>> >>> — Carlos. >>> >>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>> wrote: >>>> >>>> This sounds like something Carlos and I can try to address in >>>> conjunction with the revisions. Sorry if I was slow to understand >>>> the quesiton. >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>> >>>>> >>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>> The escurity considerations section addresses, as far as we >>>>>> understand >>>>>> them, the issues that a "security model" needs to cover. It is >>>>>> not done >>>>>> as an explicit model. We could recast the section as such a >>>>>> model, but >>>>>> it would end up saying the same things. >>>>> >>>>> Well, let's see what a revised ID looks like and then haggle about >>>>> that maybe. I think that'll be easier. (I note you did not say that >>>>> the charter text on this is OBE btw.) >>>>> >>>>>> We could write more explicitly some of the other assumptions we make, >>>>>> for example that the services to which user packets are delivered are >>>>>> trusted by the operator to examine the packets and associated >>>>>> metadata. >>>>>> We could note that the service functions are further trusted to >>>>>> modify >>>>>> the packet contents and metadata. >>>>>> We could add text that in most single-domain cases, the underlying >>>>>> infrastructure is trusted by the operator. >>>>> >>>>> If your goal as authors/WG is to not have mandatory to implement >>>>> security then yes you would I think need to explicitly justify that >>>>> in a convincing manner. Isn't it perhaps telling us something if you >>>>> chose to not explicitly say things like "trusted by the operator so >>>>> no security needed" in the draft? (Seems so to me tbh.) >>>>> >>>>>> >>>>>> Would adding text like that help? It would seem instead to >>>>>> provoke the >>>>>> BCP61 comment that you are now making. >>>>> >>>>> The BCP61 comment resulted from your proposed text ("adjunct" etc) >>>>> which >>>>> seems to me to run counter to that BCP. Are you arguing that such text >>>>> would be consistent with BCP61? If not, then what is your argument for >>>>> BCP61 not applying or being unwise in this case? >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> >>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>> I am not sure how to usefully respond to your concern that you >>>>>>>> are not >>>>>>>> convinced that security mechanisms can be adjunct or optional. >>>>>>>> That >>>>>>>> seems to border on opinion, rather than factual basis for a >>>>>>>> discuss. >>>>>>>> Further, I really do not want to end up in a situation where the >>>>>>>> majority of implementations are not conformant to the >>>>>>>> architecture and >>>>>>>> protocol spec. >>>>>>>> And it is very clear that most of the environments at least for the >>>>>>>> initial, single domain, case that we are targeting will not need >>>>>>>> any >>>>>>>> form of authentication or data integrity in the SFC mechanism. >>>>>>> >>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>> >>>>>>>> >>>>>>>> Also, I realized looking at your comments and the charter, that >>>>>>>> I do not >>>>>>>> know know what would constitute a "security model" as you >>>>>>>> understand it. >>>>>>> >>>>>>> Ok - what is a security model as you understand what the charter >>>>>>> says about this deliverable? Since you're an author and the charter >>>>>>> calls for that can you point me at where in the draft I find it >>>>>>> or why it is no longer needed/relevant/whatever? >>>>>>> >>>>>>> Ta, >>>>>>> S. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> Hi Carlos, >>>>>>>>> >>>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>>> >>>>>>>> ... >>>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>>> >>>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>>> various bad situations that happened in the roll and karp >>>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>>> >>>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>>> implement. >>>>>>>>> >>>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>>> is sufficient or whether data origin authentication is >>>>>>>>> really needed here. (That could easily be something to be >>>>>>>>> addressed later in the WG but is not something to determine >>>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>>> if it has been done but not written down so far which may >>>>>>>>> be the case.) >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> S. >>>>>>>>> >>>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>>>> on trying to get this document done in the next few days and >>>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> — Carlos. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>> >> > From nobody Mon Jun 8 17:48:46 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBCB1A0058; Mon, 8 Jun 2015 17:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHD_upJ6hy9X; Mon, 8 Jun 2015 17:48:42 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BCC1A0056; Mon, 8 Jun 2015 17:48:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 0DFB224FD76; Mon, 8 Jun 2015 17:48:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 1E9132407EE; Mon, 8 Jun 2015 17:48:41 -0700 (PDT) Message-ID: <557637D9.3080202@joelhalpern.com> Date: Mon, 08 Jun 2015 20:48:25 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> <55763405.2000804@cs.tcd.ie> In-Reply-To: <55763405.2000804@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 00:48:45 -0000 There was no formal discussion of this topic by the working group. Carlos and I are reflecting what we understand from the passing references and the very lack of interest in the topic from the working group. I really do not think, in an architecture, that it makes sense to get into a discussion of what we think will be implemented. After all, while I can cite my expectations, we can't prove it until we get down the road. I tried to focus the text on substantive technical matters. On the other hand, you seem to be trying to force the issue. While section 6 of BCP61 is focused on the question of whether encryption is needed, it ends with the statement that cryptographic techniques are likely to be needed, with an implication form context of authentication and integrity. But even then, it does not go so far as to say that cryptographic means for authentication and integrity are mandatory, merely likely. So it seems very clear to me that even BCP 61 allows for cases where such tools may not be mandatory to implement. We are working on a control requirements document, and there I expect we will call for mandatory strong authentication, integrity, and encryption capabilities. The threats are much clearer, the responses are well-defined, and the value is demonstrable. But we are talking here about the data plane packets. Packets being passed through a chain of services on their way from a source to a destination. I am sure that you could phrase the question to the working group in such a way as to prompt extended discussion and disagreement. I am equally sure that the question could be phrased in a way that would result in a confirmation of Carlos' and my understanding of the working groups intent, desire, and understanding. Yours, Joel On 6/8/15 8:32 PM, Stephen Farrell wrote: > > Hiya, > > On 09/06/15 01:11, Joel M. Halpern wrote: >> Given that we do clearly recognize that there are cases where securing >> the communication is necessary this comes down, from what you are saying >> now, to the simple question of whether we have justified the absence of >> an MTI security mechanism. > > If the question were simple, it'd be easier I guess:-) > >> >> You are saying "no". We are saying "the working group did not ask for >> it, and here the reasons we think that is defensible." > > Can you show me where the WG discussed this? (In the archive.) > Seeing that discussion would help. If it has not happened, then > seeing that discussion will help. > >> >> BCP61 does recognize that it does not apply to all cases. > > I'm not sure what part(s) of bcp61 you mean, can you point me > at that/those? > > >> I am very concerned that if we write an MTI security mechanism into >> this, almost no implementations will be compliant with the >> specifications. That does not do us any good at all. > > Yes. Mythical security is no security I fully agree. But Carlos' > text did not speak to unwillingness to implement, nor to any > inability to define a usable/sufficiently-useful mechanism. > >> >> You asked for us to be explicit, and to state our reasons. We have done >> so. > > Carlos' recent text omitted some points mentioned above. > >> Yes, we could have a working group hum on whether we want an MTI >> security mechanism in all solutions which comply with the architecture. >> I think we already have clarity on that issue from the WG. And I doubt >> such a hum would change your mind if it went against you. > > I am not asking for a hum. I am asking to see the (archive of > the) discussion demonstrating that clarity. Please send a URL. > > Thanks, > S. > > >> >> Yours, >> Joel >> >> On 6/8/15 7:53 PM, Stephen Farrell wrote: >>> >>> Hi Carlos, >>> >>> Thanks for that text, which I think seems to match well with what >>> you and Joel have been saying. >>> >>> I have to say though that I don't find it at all convincing given >>> that we have bcp61. Having some mti security so that it can be >>> turned on when needed despite buying kit from multiple vendors is >>> what bcp61 calls for and I really don't see why sfc is an exception. >>> >>> A question for you - is it useful for me to try de-construct the >>> text below (on the above basis) or not? It may be a waste of time >>> and we may be better off getting additional viewpoints on this >>> instead. >>> >>> And in case it helps, I think the main (not the only) counter to what >>> you propose below is the consideration that while sfc may only be >>> well-defined for intradomain use now, intradomain use can in >>> various ways span what are now clearly important trust boundaries, >>> see tempora/belgacom/gemalto for examples. >>> >>> Cheers, >>> S. >>> >>> >>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>>> Stephen, >>>> >>>> Please find some concrete text, with a sufficiently detailed >>>> explanation, to anchor the discussion. >>>> >>>> Feedback? >>>> >>>> —>8— >>>> 6.1. SFC Data Plane Security >>>> >>>> One of the aspects to consider as part of the SFC security model is >>>> whether to mandate the implementation of, and strongly recommend the >>>> use of authentication and encryption technology within the SFC data >>>> plane. This architecture mandates the definition of mechanisms to >>>> provide confidentiality and integrity of metadata carried by the >>>> protocol, but makes not further recommendations. This is based on the >>>> unusual operating constraints. Rather than being an end-to-end >>>> protocol, or even a relayed protocol with a desire to reduce the >>>> number of relays, the goal of this protocol is to deliver data >>>> packets to a series of service functions. These functions are >>>> selected and provided by a combination of user and operator >>>> decisions. They are, in most cases, granted access to the data packet >>>> contents and the metadata. Securing the packets from the service >>>> functions would be counter-productive. >>>> >>>> One could argue for securing the packets as they traverse the >>>> underlying network. Provisions for this are already included under >>>> the “Service Overlay†title in this Security Considerations. In the >>>> general case where every hop between service functions is over >>>> untrusted media, that may be necessary and appropriate. However, the >>>> initial target is for a single administrative domain, where if there >>>> are any untrustued segments they will be few and well-recognized. >>>> Even in the general case, most transport connections will be >>>> sufficiently trusted so as not to warrant the cost of hop-wise >>>> security mechanisms over a multi-hop transport. >>>> >>>> Given the operator focus on internal use of this tool, even demanding >>>> implementation of such mechanisms is likely to place a cost on >>>> delivery that will interfere with the use of this technology. It >>>> should be understood that this architecture is a new model >>>> replacement for a multiplicity of widely used techniques, most of >>>> which do not even have the option of security mechanisms. >>>> >>>> This analysis leads to an expectation of a need for optional security >>>> techniques well-integrated with the protocol so that they can be used >>>> where needed, without mandating that all implementations include such >>>> capabilities. >>>> —>8— >>>> >>>> Thanks, >>>> >>>> — Carlos. >>>> >>>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>>> wrote: >>>>> >>>>> This sounds like something Carlos and I can try to address in >>>>> conjunction with the revisions. Sorry if I was slow to understand >>>>> the quesiton. >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>>> >>>>>> >>>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>>> The escurity considerations section addresses, as far as we >>>>>>> understand >>>>>>> them, the issues that a "security model" needs to cover. It is >>>>>>> not done >>>>>>> as an explicit model. We could recast the section as such a >>>>>>> model, but >>>>>>> it would end up saying the same things. >>>>>> >>>>>> Well, let's see what a revised ID looks like and then haggle about >>>>>> that maybe. I think that'll be easier. (I note you did not say that >>>>>> the charter text on this is OBE btw.) >>>>>> >>>>>>> We could write more explicitly some of the other assumptions we make, >>>>>>> for example that the services to which user packets are delivered are >>>>>>> trusted by the operator to examine the packets and associated >>>>>>> metadata. >>>>>>> We could note that the service functions are further trusted to >>>>>>> modify >>>>>>> the packet contents and metadata. >>>>>>> We could add text that in most single-domain cases, the underlying >>>>>>> infrastructure is trusted by the operator. >>>>>> >>>>>> If your goal as authors/WG is to not have mandatory to implement >>>>>> security then yes you would I think need to explicitly justify that >>>>>> in a convincing manner. Isn't it perhaps telling us something if you >>>>>> chose to not explicitly say things like "trusted by the operator so >>>>>> no security needed" in the draft? (Seems so to me tbh.) >>>>>> >>>>>>> >>>>>>> Would adding text like that help? It would seem instead to >>>>>>> provoke the >>>>>>> BCP61 comment that you are now making. >>>>>> >>>>>> The BCP61 comment resulted from your proposed text ("adjunct" etc) >>>>>> which >>>>>> seems to me to run counter to that BCP. Are you arguing that such text >>>>>> would be consistent with BCP61? If not, then what is your argument for >>>>>> BCP61 not applying or being unwise in this case? >>>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>>> >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>>> I am not sure how to usefully respond to your concern that you >>>>>>>>> are not >>>>>>>>> convinced that security mechanisms can be adjunct or optional. >>>>>>>>> That >>>>>>>>> seems to border on opinion, rather than factual basis for a >>>>>>>>> discuss. >>>>>>>>> Further, I really do not want to end up in a situation where the >>>>>>>>> majority of implementations are not conformant to the >>>>>>>>> architecture and >>>>>>>>> protocol spec. >>>>>>>>> And it is very clear that most of the environments at least for the >>>>>>>>> initial, single domain, case that we are targeting will not need >>>>>>>>> any >>>>>>>>> form of authentication or data integrity in the SFC mechanism. >>>>>>>> >>>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>>> >>>>>>>>> >>>>>>>>> Also, I realized looking at your comments and the charter, that >>>>>>>>> I do not >>>>>>>>> know know what would constitute a "security model" as you >>>>>>>>> understand it. >>>>>>>> >>>>>>>> Ok - what is a security model as you understand what the charter >>>>>>>> says about this deliverable? Since you're an author and the charter >>>>>>>> calls for that can you point me at where in the draft I find it >>>>>>>> or why it is no longer needed/relevant/whatever? >>>>>>>> >>>>>>>> Ta, >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> Hi Carlos, >>>>>>>>>> >>>>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>>>> >>>>>>>>> ... >>>>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>>>> >>>>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>>>> various bad situations that happened in the roll and karp >>>>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>>>> >>>>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>>>> implement. >>>>>>>>>> >>>>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>>>> is sufficient or whether data origin authentication is >>>>>>>>>> really needed here. (That could easily be something to be >>>>>>>>>> addressed later in the WG but is not something to determine >>>>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>>>> if it has been done but not written down so far which may >>>>>>>>>> be the case.) >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>>>>> on trying to get this document done in the next few days and >>>>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> — Carlos. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>> >>> >> From nobody Mon Jun 8 18:45:45 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB111A0248; Mon, 8 Jun 2015 18:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6sCNg8fZIzm; Mon, 8 Jun 2015 18:45:35 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 650101A011F; Mon, 8 Jun 2015 18:45:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42607; q=dns/txt; s=iport; t=1433814335; x=1435023935; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=32nLASFkctDOE5L5scDwbBVU/lR+BqLaZ1QLTl+bMeo=; b=V7dlrhnCobIYyDBWGT6NPepIBtRw928Wk2E1iwIev/GJuWXbBrEzKpf9 g7dalmevzGoorkBGRWJZLHaZgXS3StpAEzAVcpzuERriKlBDNPt1DXeIS XXRucZn79zjXnalgj05OfgfKXZlY3RyHLakIeKVC1wRThRW//M3hxPp1w E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BZCADDRHZV/5ldJa1WBoMQVF4Ggxi6ejwzgTwCGQENhXUCgTQ6EgEBAQEBAQGBCoQiAQEBAQEBAQEBARcBAgZEBwYFBQsCAQYCEgYgAQkCAicLFw4CBA4FCQUNiAsIDYxynRmkEgEBAQEBAQEBAQEBAQEBAQEBAQEBAReKQYEChCMQAgENPwQHgmgvgRYFkzyCGIFJYYZugTBAgzuOYYNZERNigSgcFYE9bwEBgUSBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,577,1427760000"; d="asc'?scan'208,217";a="157461344" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP; 09 Jun 2015 01:45:33 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t591jXet022104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jun 2015 01:45:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Mon, 8 Jun 2015 20:45:33 -0500 From: "Carlos Pignataro (cpignata)" To: "Joel M. Halpern" Thread-Topic: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQmUU9UNzRkq1wJU2Wvlf+qhp5bp2Z/h6AgAfgk4CAAASJgIAAAMcAgAABoICAAAbggIAACXkAgABCGICAAXXdAIAABSOAgAAFoICAAASRgIAAD/SA Date: Tue, 9 Jun 2015 01:45:32 +0000 Message-ID: <2A5EFB0C-6FCA-455A-83D1-E7395DF82E22@cisco.com> References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> <55763405.2000804@cs.tcd.ie> <557637D9.3080202@joelhalpern.com> In-Reply-To: <557637D9.3080202@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.250.82] Content-Type: multipart/signed; boundary="Apple-Mail=_871970C7-F482-4E26-B641-7555342E9537"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "sfc@ietf.org" , Stephen Farrell Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 01:45:41 -0000 --Apple-Mail=_871970C7-F482-4E26-B641-7555342E9537 Content-Type: multipart/alternative; boundary="Apple-Mail=_847E4A6B-11E4-40C1-A995-96B9783069B0" --Apple-Mail=_847E4A6B-11E4-40C1-A995-96B9783069B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Stephen, To add to what Joel articulated, please find a three key points: First, what we are taking about here is mandatory SFC encapsulation = encryption. That is really one piece of the security puzzle. But the = Service Overlay satisfy the security requirements of the specific SFC = deployment. At the tunnel, we can turn on "authenticity and integrity = checking, and/or confidentiality provisions=E2=80=9D (the text is = already there), and that would cover headers and payloads. It is not = fully clear (to me) why the fixation on mandating encrypting this = particular piece (more in the 3rd point). The second point, when you say =E2=80=9CPlease send a URL=E2=80=9D, it = seems as if you are hoping to find all security discussions consolidated = into a single convenient email thread. Truth is, the topic was discussed = in various occasions, on the list, with off-list comments, in meetings, = and in multiple threads. I expect that this is better than =E2=80=9Ca = URL=E2=80=9D frankly. So, a couple of relevant breadcrumbs FYI: All the WG discussions are = what drove the shaping of the security considerations from the initial = one-sentence that it was: " This document does not define a new protocol and therefore creates = no new security issues." to today=E2=80=99s: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture-09.txt&ur= l1=3Ddraft-merged-sfc-architecture-01.txt#diff0127 = That did not happen in a single mega-discussion =E2=80=94 the more meaty = security discussions started at this comment = http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html = , and we = had a milestone at = http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html = . Then the goal was to get to Hawaii with an even strengthened section. = Slide 4 at https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf = . And = really the list archives show this discussion sprinkled throughout = multiple times. The third point, regarding BCP61. BCP61 speaks about strong security = requirements for IETF =E2=80=9CStandard Protocols=E2=80=9D. However, = this document does not define protocols. I did mention to you already a couple of times that there is concrete = clear WG interest in working on these solutions, as per = https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00 = . You will = find that draft-reddy-sfc-nsh-encrypt-00 is not a quick = placeholder-draft, but energy wants to be placed here. This does not = mean or imply that this architecture needs to cast MTI encryption. That = question can be answered when the protocol and the encryption methods = are defined. Further, BCP61 says =E2=80=9Censure that IETF standard protocols have = the necessary features to provide appropriate security for the = application as it may be used across the Internet=E2=80=9D =E2=80=94 and = this architecture is not defining an application that is used across the = Internet. Thanks, =E2=80=94 Carlos. > On Jun 8, 2015, at 8:48 PM, Joel M. Halpern = wrote: >=20 > There was no formal discussion of this topic by the working group. = Carlos and I are reflecting what we understand from the passing = references and the very lack of interest in the topic from the working = group. >=20 > I really do not think, in an architecture, that it makes sense to get = into a discussion of what we think will be implemented. After all, = while I can cite my expectations, we can't prove it until we get down = the road. I tried to focus the text on substantive technical matters. = On the other hand, you seem to be trying to force the issue. >=20 > While section 6 of BCP61 is focused on the question of whether = encryption is needed, it ends with the statement that cryptographic = techniques are likely to be needed, with an implication form context of = authentication and integrity. But even then, it does not go so far as = to say that cryptographic means for authentication and integrity are = mandatory, merely likely. So it seems very clear to me that even BCP = 61 allows for cases where such tools may not be mandatory to implement. >=20 > We are working on a control requirements document, and there I expect = we will call for mandatory strong authentication, integrity, and = encryption capabilities. The threats are much clearer, the responses = are well-defined, and the value is demonstrable. >=20 > But we are talking here about the data plane packets. Packets being = passed through a chain of services on their way from a source to a = destination. >=20 > I am sure that you could phrase the question to the working group in = such a way as to prompt extended discussion and disagreement. I am = equally sure that the question could be phrased in a way that would = result in a confirmation of Carlos' and my understanding of the working = groups intent, desire, and understanding. >=20 > Yours, > Joel >=20 > On 6/8/15 8:32 PM, Stephen Farrell wrote: >>=20 >> Hiya, >>=20 >> On 09/06/15 01:11, Joel M. Halpern wrote: >>> Given that we do clearly recognize that there are cases where = securing >>> the communication is necessary this comes down, from what you are = saying >>> now, to the simple question of whether we have justified the absence = of >>> an MTI security mechanism. >>=20 >> If the question were simple, it'd be easier I guess:-) >>=20 >>>=20 >>> You are saying "no". We are saying "the working group did not ask = for >>> it, and here the reasons we think that is defensible." >>=20 >> Can you show me where the WG discussed this? (In the archive.) >> Seeing that discussion would help. If it has not happened, then >> seeing that discussion will help. >>=20 >>>=20 >>> BCP61 does recognize that it does not apply to all cases. >>=20 >> I'm not sure what part(s) of bcp61 you mean, can you point me >> at that/those? >>=20 >>=20 >>> I am very concerned that if we write an MTI security mechanism into >>> this, almost no implementations will be compliant with the >>> specifications. That does not do us any good at all. >>=20 >> Yes. Mythical security is no security I fully agree. But Carlos' >> text did not speak to unwillingness to implement, nor to any >> inability to define a usable/sufficiently-useful mechanism. >>=20 >>>=20 >>> You asked for us to be explicit, and to state our reasons. We have = done >>> so. >>=20 >> Carlos' recent text omitted some points mentioned above. >>=20 >>> Yes, we could have a working group hum on whether we want an MTI >>> security mechanism in all solutions which comply with the = architecture. >>> I think we already have clarity on that issue from the WG. And I = doubt >>> such a hum would change your mind if it went against you. >>=20 >> I am not asking for a hum. I am asking to see the (archive of >> the) discussion demonstrating that clarity. Please send a URL. >>=20 >> Thanks, >> S. >>=20 >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 6/8/15 7:53 PM, Stephen Farrell wrote: >>>>=20 >>>> Hi Carlos, >>>>=20 >>>> Thanks for that text, which I think seems to match well with what >>>> you and Joel have been saying. >>>>=20 >>>> I have to say though that I don't find it at all convincing given >>>> that we have bcp61. Having some mti security so that it can be >>>> turned on when needed despite buying kit from multiple vendors is >>>> what bcp61 calls for and I really don't see why sfc is an = exception. >>>>=20 >>>> A question for you - is it useful for me to try de-construct the >>>> text below (on the above basis) or not? It may be a waste of time >>>> and we may be better off getting additional viewpoints on this >>>> instead. >>>>=20 >>>> And in case it helps, I think the main (not the only) counter to = what >>>> you propose below is the consideration that while sfc may only be >>>> well-defined for intradomain use now, intradomain use can in >>>> various ways span what are now clearly important trust boundaries, >>>> see tempora/belgacom/gemalto for examples. >>>>=20 >>>> Cheers, >>>> S. >>>>=20 >>>>=20 >>>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>>>> Stephen, >>>>>=20 >>>>> Please find some concrete text, with a sufficiently detailed >>>>> explanation, to anchor the discussion. >>>>>=20 >>>>> Feedback? >>>>>=20 >>>>> =E2=80=94>8=E2=80=94 >>>>> 6.1. SFC Data Plane Security >>>>>=20 >>>>> One of the aspects to consider as part of the SFC security model = is >>>>> whether to mandate the implementation of, and strongly recommend = the >>>>> use of authentication and encryption technology within the SFC = data >>>>> plane. This architecture mandates the definition of mechanisms to >>>>> provide confidentiality and integrity of metadata carried by the >>>>> protocol, but makes not further recommendations. This is based on = the >>>>> unusual operating constraints. Rather than being an end-to-end >>>>> protocol, or even a relayed protocol with a desire to reduce the >>>>> number of relays, the goal of this protocol is to deliver data >>>>> packets to a series of service functions. These functions are >>>>> selected and provided by a combination of user and operator >>>>> decisions. They are, in most cases, granted access to the data = packet >>>>> contents and the metadata. Securing the packets from the service >>>>> functions would be counter-productive. >>>>>=20 >>>>> One could argue for securing the packets as they traverse the >>>>> underlying network. Provisions for this are already included = under >>>>> the =E2=80=9CService Overlay=E2=80=9D title in this Security = Considerations. In the >>>>> general case where every hop between service functions is over >>>>> untrusted media, that may be necessary and appropriate. However, = the >>>>> initial target is for a single administrative domain, where if = there >>>>> are any untrustued segments they will be few and well-recognized. >>>>> Even in the general case, most transport connections will be >>>>> sufficiently trusted so as not to warrant the cost of hop-wise >>>>> security mechanisms over a multi-hop transport. >>>>>=20 >>>>> Given the operator focus on internal use of this tool, even = demanding >>>>> implementation of such mechanisms is likely to place a cost on >>>>> delivery that will interfere with the use of this technology. It >>>>> should be understood that this architecture is a new model >>>>> replacement for a multiplicity of widely used techniques, most of >>>>> which do not even have the option of security mechanisms. >>>>>=20 >>>>> This analysis leads to an expectation of a need for optional = security >>>>> techniques well-integrated with the protocol so that they can be = used >>>>> where needed, without mandating that all implementations include = such >>>>> capabilities. >>>>> =E2=80=94>8=E2=80=94 >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> =E2=80=94 Carlos. >>>>>=20 >>>>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>>>> wrote: >>>>>>=20 >>>>>> This sounds like something Carlos and I can try to address in >>>>>> conjunction with the revisions. Sorry if I was slow to = understand >>>>>> the quesiton. >>>>>>=20 >>>>>> Yours, >>>>>> Joel >>>>>>=20 >>>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>>>>=20 >>>>>>>=20 >>>>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>>>> The escurity considerations section addresses, as far as we >>>>>>>> understand >>>>>>>> them, the issues that a "security model" needs to cover. It is >>>>>>>> not done >>>>>>>> as an explicit model. We could recast the section as such a >>>>>>>> model, but >>>>>>>> it would end up saying the same things. >>>>>>>=20 >>>>>>> Well, let's see what a revised ID looks like and then haggle = about >>>>>>> that maybe. I think that'll be easier. (I note you did not say = that >>>>>>> the charter text on this is OBE btw.) >>>>>>>=20 >>>>>>>> We could write more explicitly some of the other assumptions we = make, >>>>>>>> for example that the services to which user packets are = delivered are >>>>>>>> trusted by the operator to examine the packets and associated >>>>>>>> metadata. >>>>>>>> We could note that the service functions are further trusted = to >>>>>>>> modify >>>>>>>> the packet contents and metadata. >>>>>>>> We could add text that in most single-domain cases, the = underlying >>>>>>>> infrastructure is trusted by the operator. >>>>>>>=20 >>>>>>> If your goal as authors/WG is to not have mandatory to implement >>>>>>> security then yes you would I think need to explicitly justify = that >>>>>>> in a convincing manner. Isn't it perhaps telling us something if = you >>>>>>> chose to not explicitly say things like "trusted by the operator = so >>>>>>> no security needed" in the draft? (Seems so to me tbh.) >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Would adding text like that help? It would seem instead to >>>>>>>> provoke the >>>>>>>> BCP61 comment that you are now making. >>>>>>>=20 >>>>>>> The BCP61 comment resulted from your proposed text ("adjunct" = etc) >>>>>>> which >>>>>>> seems to me to run counter to that BCP. Are you arguing that = such text >>>>>>> would be consistent with BCP61? If not, then what is your = argument for >>>>>>> BCP61 not applying or being unwise in this case? >>>>>>>=20 >>>>>>> Cheers, >>>>>>> S. >>>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>>=20 >>>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>>>> I am not sure how to usefully respond to your concern that = you >>>>>>>>>> are not >>>>>>>>>> convinced that security mechanisms can be adjunct or = optional. >>>>>>>>>> That >>>>>>>>>> seems to border on opinion, rather than factual basis for a >>>>>>>>>> discuss. >>>>>>>>>> Further, I really do not want to end up in a situation where = the >>>>>>>>>> majority of implementations are not conformant to the >>>>>>>>>> architecture and >>>>>>>>>> protocol spec. >>>>>>>>>> And it is very clear that most of the environments at least = for the >>>>>>>>>> initial, single domain, case that we are targeting will not = need >>>>>>>>>> any >>>>>>>>>> form of authentication or data integrity in the SFC = mechanism. >>>>>>>>>=20 >>>>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Also, I realized looking at your comments and the charter, = that >>>>>>>>>> I do not >>>>>>>>>> know know what would constitute a "security model" as you >>>>>>>>>> understand it. >>>>>>>>>=20 >>>>>>>>> Ok - what is a security model as you understand what the = charter >>>>>>>>> says about this deliverable? Since you're an author and the = charter >>>>>>>>> calls for that can you point me at where in the draft I find = it >>>>>>>>> or why it is no longer needed/relevant/whatever? >>>>>>>>>=20 >>>>>>>>> Ta, >>>>>>>>> S. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>>=20 >>>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi Carlos, >>>>>>>>>>>=20 >>>>>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>>>>>=20 >>>>>>>>>> ... >>>>>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>>>>>=20 >>>>>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>>>>> various bad situations that happened in the roll and karp >>>>>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>>>>>=20 >>>>>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>>>>> implement. >>>>>>>>>>>=20 >>>>>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>>>>> is sufficient or whether data origin authentication is >>>>>>>>>>> really needed here. (That could easily be something to be >>>>>>>>>>> addressed later in the WG but is not something to determine >>>>>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>>>>> if it has been done but not written down so far which may >>>>>>>>>>> be the case.) >>>>>>>>>>>=20 >>>>>>>>>>> Cheers, >>>>>>>>>>> S. >>>>>>>>>>>=20 >>>>>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>>>>> could save a lot of effort later, so I wouldn't be too = focused >>>>>>>>>>> on trying to get this document done in the next few days and >>>>>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Thanks, >>>>>>>>>>>>=20 >>>>>>>>>>>> =E2=80=94 Carlos. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>=20 >>>=20 --Apple-Mail=_847E4A6B-11E4-40C1-A995-96B9783069B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Stephen,

To= add to what Joel articulated, please find a three key points:

First, what we are = taking about here is mandatory SFC encapsulation encryption. That is = really one piece of the security puzzle. But the Service Overlay = satisfy the security requirements of the specific SFC deployment. At the = tunnel, we can turn on "authenticity and integrity checking, and/or = confidentiality provisions=E2=80=9D (the text is already there), and = that would cover headers and payloads. It is not fully clear (to me) why = the fixation on mandating encrypting this particular piece (more in the = 3rd point).

The = second point, when you say =E2=80=9CPlease send a URL=E2=80=9D, it seems = as if you are hoping to find all security discussions consolidated into = a single convenient email thread. Truth is, the topic was discussed in = various occasions, on the list, with off-list comments, in meetings, and = in multiple threads. I expect that this is better than =E2=80=9Ca URL=E2=80= =9D frankly.

So,= a couple of relevant breadcrumbs FYI: All the WG discussions are what = drove the shaping of the security considerations from the initial = one-sentence that it was:
"   = This document does not define a new protocol and therefore creates = no
    new security = issues."

to today=E2=80=99s:
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architectur= e-09.txt&url1=3Ddraft-merged-sfc-architecture-01.txt#diff0127

That did not = happen in a single mega-discussion =E2=80=94 the more meaty security = discussions started at this comment http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html<= /a>, and we had a milestone at http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html<= /a>. 

Then = the goal was to get to Hawaii with an even strengthened section. Slide 4 = at https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf= . And really the list archives show this discussion sprinkled throughout = multiple times.

The third point, regarding BCP61. BCP61 speaks about strong = security requirements for IETF =E2=80=9CStandard Protocols=E2=80=9D. = However, this document does not define protocols. 

I did mention to you = already a couple of times that there is concrete clear WG interest in = working on these solutions, as per https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00.= You will find that draft-reddy-sfc-nsh-encrypt-00 is not a quick = placeholder-draft, but energy wants to be placed here. This does not = mean or imply that this architecture needs to cast MTI encryption. That = question can be answered when the protocol and the encryption methods = are defined.

Further, BCP61 says =E2=80=9Censure that IETF standard = protocols have the necessary features to provide appropriate security = for the application as it may be used across the Internet=E2=80=9D =E2=80=94= and this architecture is not defining an application that is used = across the Internet.

Thanks,

=E2=80=94 Carlos.

On Jun 8, 2015, at 8:48 PM, Joel M. Halpern = <jmh@joelhalpern.com> wrote:

There was no formal = discussion of this topic by the working group. Carlos and I are = reflecting what we understand from the passing references and the very = lack of interest in the topic from the working group.

I really do not think, in an architecture, that it makes = sense to get into a discussion of what we think will be implemented. =  After all, while I can cite my expectations, we can't prove it = until we get down the road.  I tried to focus the text on = substantive technical matters. On the other hand, you seem to be trying = to force the issue.

While section 6 of = BCP61 is focused on the question of whether encryption is needed, it = ends with the statement that cryptographic techniques are likely to be = needed, with an implication form context of authentication and = integrity.  But even then, it does not go so far as to say that = cryptographic means for authentication and integrity are mandatory, = merely likely.   So it seems very clear to me that even BCP 61 = allows for cases where such tools may not be mandatory to implement.

We are working on a control requirements = document, and there I expect we will call for mandatory strong = authentication, integrity, and encryption capabilities.  The = threats are much clearer, the responses are well-defined, and the value = is demonstrable.

But we are talking here = about the data plane packets.  Packets being passed through a chain = of services on their way from a source to a destination.
I am sure that you could phrase the question to the working = group in such a way as to prompt extended discussion and disagreement. =  I am equally sure that the question could be phrased in a way that = would result in a confirmation of Carlos' and my understanding of the = working groups intent, desire, and understanding.

Yours,
Joel

On = 6/8/15 8:32 PM, Stephen Farrell wrote:

Hiya,

On 09/06/15 01:11, Joel M. Halpern wrote:
Given that we do clearly = recognize that there are cases where securing
the = communication is necessary this comes down, from what you are saying
now, to the simple question of whether we have justified the = absence of
an MTI security mechanism.

If the question were simple, it'd = be easier I guess:-)


You are saying "no".  We = are saying "the working group did not ask for
it, and here = the reasons we think that is defensible."

Can you show me where the WG discussed this? (In the = archive.)
Seeing that discussion would help. If it has not = happened, then
seeing that discussion will help.


BCP61 does recognize that it does not apply to all cases.

I'm not sure what part(s) of = bcp61 you mean, can you point me
at that/those?


I am very concerned that if we write an MTI security = mechanism into
this, almost no implementations will be = compliant with the
specifications.  That does not do = us any good at all.

Yes. = Mythical security is no security I fully agree. But Carlos'
text did not speak to unwillingness to implement, nor to = any
inability to define a usable/sufficiently-useful = mechanism.


You asked for us to be explicit, and to state = our reasons.  We have done
so.

Carlos' recent text omitted some = points mentioned above.

Yes, we could have a working group hum on = whether we want an MTI
security mechanism in all solutions = which comply with the architecture.
 I think we = already have clarity on that issue from the WG.  And I doubt
such a hum would change your mind if it went against you.

I am not asking for a hum. I am = asking to see the (archive of
the) discussion = demonstrating that clarity. Please send a URL.

Thanks,
S.



Yours,
Joel

On 6/8/15 7:53 PM, Stephen = Farrell wrote:

Hi Carlos,

Thanks for that text, = which I think seems to match well with what
you and Joel = have been saying.

I have to say though that = I don't find it at all convincing given
that we have = bcp61. Having some mti security so that it can be
turned = on when needed despite buying kit from multiple vendors is
what bcp61 calls for and I really don't see why sfc is an = exception.

A question for you - is it = useful for me to try de-construct the
text below (on the = above basis) or not? It may be a waste of time
and we may = be better off getting additional viewpoints on this
instead.

And in case it helps, I = think the main (not the only) counter to what
you propose = below is the consideration that while sfc may only be
well-defined for intradomain use now, intradomain use can = in
various ways span what are now clearly important trust = boundaries,
see tempora/belgacom/gemalto for examples.

Cheers,
S.


On 08/06/15 02:35, Carlos Pignataro (cpignata) = wrote:
Stephen,

Please find some concrete text, with a = sufficiently detailed
explanation, to anchor the = discussion.

Feedback?

=E2=80=94>8=E2=80=94
6.1. SFC Data Plane = Security

One of the aspects to consider as = part of the SFC security model is
whether to mandate the = implementation of, and strongly recommend the
use of = authentication and encryption technology within the SFC data
plane.  This architecture mandates the definition of = mechanisms to
provide confidentiality and integrity of = metadata carried by the
protocol, but makes not further = recommendations. This is based on the
unusual operating = constraints.  Rather than being an end-to-end
protocol,= or even a relayed protocol with a desire to reduce the
number of relays, the goal of this protocol is to deliver = data
packets to a series of service functions.  These = functions are
selected and provided by a combination of = user and operator
decisions. They are, in most cases, = granted access to the data packet
contents and the = metadata.  Securing the packets from the service
functions would be counter-productive.

One could argue for securing the packets as they traverse = the
underlying network.  Provisions for this are = already included under
the =E2=80=9CService Overlay=E2=80=9D= title in this Security Considerations. In the
general = case where every hop between service functions is over
untrusted media, that may be necessary and appropriate. = However, the
initial target is for a single administrative = domain, where if there
are any untrustued segments they = will be few and well-recognized.
Even in the general case, = most transport connections will be
sufficiently trusted so = as not to warrant the cost of hop-wise
security mechanisms = over a multi-hop transport.

Given the = operator focus on internal use of this tool, even demanding
implementation of such mechanisms is likely to place a cost = on
delivery that will interfere with the use of this = technology.  It
should be understood that this = architecture is a new model
replacement for a multiplicity = of widely used techniques, most of
which do not even have = the option of security mechanisms.

This = analysis leads to an expectation of a need for optional security
techniques well-integrated with the protocol so that they can = be used
where needed, without mandating that all = implementations include such
capabilities.
=E2=80=94>8=E2=80=94

Thanks,
=E2=80=94 Carlos.

On Jun 7, 2015, at 5:38 = PM, Joel M. Halpern <jmh@joelhalpern.com>
wrote:

This sounds like something Carlos and I can = try to address in
conjunction with the revisions. =  Sorry if I was slow to understand
the quesiton.

Yours,
Joel

On 6/7/15 5:04 PM, Stephen Farrell wrote:


On 07/06/15 21:40, Joel M. Halpern wrote:
The escurity = considerations section addresses, as far as we
understandthem, the issues that a "security model" needs to cover. =  It is
not done
as an explicit model. =  We could recast the section as such a
model, but
it would end up saying the same things.

Well, let's see what a revised ID = looks like and then haggle about
that maybe. I think = that'll be easier. (I note you did not say that
the = charter text on this is OBE btw.)

We could write more explicitly some of the = other assumptions we make,
for example that the services = to which user packets are delivered are
trusted by the = operator to examine the packets and associated
metadata.
  We could note that the service functions are = further trusted to
modify
the packet = contents and metadata.
We could add text that in most = single-domain cases, the underlying
infrastructure is = trusted by the operator.

If = your goal as authors/WG is to not have mandatory to implement
security then yes you would I think need to explicitly = justify that
in a convincing manner. Isn't it perhaps = telling us something if you
chose to not explicitly say = things like "trusted by the operator so
no security = needed" in the draft? (Seems so to me tbh.)


Would = adding text like that help?  It would seem instead to
provoke the
BCP61 comment that you are now = making.

The BCP61 comment = resulted from your proposed text ("adjunct" etc)
which
seems to me to run counter to that BCP. Are you arguing that = such text
would be consistent with BCP61? If not, then = what is your argument for
BCP61 not applying or being = unwise in this case?

Cheers,
S.



Yours,
Joel

On 6/7/15 4:34 PM, Stephen Farrell wrote:


On 07/06/15 21:31, Joel M. Halpern wrote:
I am not sure how to = usefully respond to your concern that you
are not
convinced that security mechanisms can be adjunct or = optional.
That
seems to border on opinion, = rather than factual basis for a
discuss.
Further, I really do not want to end up in a situation where = the
majority of implementations are not conformant to = the
architecture and
protocol spec.
And it is very clear that most of the environments at least = for the
initial, single domain, case that we are targeting = will not need
any
form of authentication or = data integrity in the SFC mechanism.

Hmm. Doesn't BCP61 directly address the above?


Also, I realized looking at your comments and the charter, = that
I do not
know know what would = constitute a "security model" as you
understand it.

Ok - what is a security model as = you understand what the charter
says about this = deliverable? Since you're an author and the charter
calls = for that can you point me at where in the draft I find it
or= why it is no longer needed/relevant/whatever?

Ta,
S.



Yours,
Joel

On 6/7/15 4:15 PM, Stephen = Farrell wrote:

Hi Carlos,

Sorry for the delayed = response - some more travel ensued;-(

...
No, sorry. For one minor and two major reasons.

The first is that I want to ensure we do not = end up in the
various bad situations that happened in the = roll and karp
WGs, so a simple addition like that without = any idea what is
likely to really happen isn't a good plan = I think.

The second is that I am entirely = unconvinced that any
security mechanisms can be an = "adjunct" or optional to
implement.

The minor reason is that I don't think we have gotten to
the bottom of whether data integrity of data in transit
is sufficient or whether data origin authentication is
really needed here. (That could easily be something to be
addressed later in the WG but is not something to = determine
now unless we do the analysis now, or describe = that analysis
if it has been done but not written down so = far which may
be the case.)

Cheers,
S.

PS: I'm = starting on vacation on Thursday so will try to be
responsive on this in the meantime. However, we really = ought
keep in mind that getting the right outcome at this = stage
could save a lot of effort later, so I wouldn't be = too focused
on trying to get this document done in the = next few days and
I think we ought be much more focused on = doing our best with
ensuring that SFC doesn't hit security = speedbumps later on.



Thanks,

=E2=80=94 Carlos.









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




= --Apple-Mail=_847E4A6B-11E4-40C1-A995-96B9783069B0-- --Apple-Mail=_871970C7-F482-4E26-B641-7555342E9537 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 iQIcBAEBCAAGBQJVdkU7AAoJEIXgpQGOZny94bQP+wfeZczqn+v8Wa4ZNT6fKXth 0rLEpkWeGTtFCT3TbQ6Sfzf+9xsNL5p/FM/M6Ul8OaAuJJk9Z5Gw7F6BhLPy0BcK OQpjdfU0ce6tPHjSUpL5c3ZzGfIwoLiENQNUUrUYKY8c7Yrc/YH13BQ9GRs3P7t+ WvS/2sRK/GphcVvSdTqHiHcfeatN4JXOZC1m3Dp/DmtJyETJLe5ljjA7Fu5TWA3L Q0pwiNxh7PUGvmVH7vBpYfSb33YsAi7qIY3hYTBc139myo6bVROT9GO1Ey7OlqSI 63TNPUhM/9KYHK/AyxDCSTMFJO/Ss8TJ1LeavKTwNAEcMReVbtihpW+agiYROCh7 6qXUMZwYIWz6rzyr90efEsawk2jPum5SqGgrtOqoyFDx+dGqZAI+VxdhRqYxU6J0 H3iVvrCgmfPjUhW3SBMC7cR8p7stjq1rjfSa/ouG88ROLFHJyCfBhPCnOs7iQrU6 ANYiqYeOj2lRmeDGLo0tMyWT14guavkEGKM3x4WDcRBvCki1l6ij8EzUsQvft6f6 95EAf6q7/eZkqf598eBRiyhhSFgAZwTBuSsITpkiHL60dyvK6YJnVXsChoDHmXNk nMRbvIMuYlFnUT+0f4UwfjtWPhm8OxjAY7R3Fhw+48aHf9xdsHmdNjjbm7P9tgUv pew3/ZdZRQZbziCBK3kj =/UsN -----END PGP SIGNATURE----- --Apple-Mail=_871970C7-F482-4E26-B641-7555342E9537-- From nobody Mon Jun 8 22:02:38 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D881ACEF0; Mon, 8 Jun 2015 22:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 D-dSPmLzKGwW; Mon, 8 Jun 2015 22:02:33 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id DDCDA1ACEEF; Mon, 8 Jun 2015 22:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=pitFFhelqUYamVWp/ziv8qBB+V7teCpavvb7UA2Cvajv8Pn8DmegXwBJpdTEK8vP; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.52] (helo=mswamui-valley.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Z2BgF-0002KQ-TY; Tue, 09 Jun 2015 01:02:31 -0400 Received: from 76.254.48.4 by webmail.earthlink.net with HTTP; Tue, 9 Jun 2015 01:02:31 -0400 Message-ID: <16519348.1433826151912.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Date: Mon, 8 Jun 2015 22:02:31 -0700 (GMT-07:00) From: Randy Presuhn To: "sfc@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888ff8848a73c44bba07e9dbfa57a16f148e8457ef596a10080350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.52 Archived-At: Cc: The IESG Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 05:02:34 -0000 Hi - >From: "Carlos Pignataro (cpignata)" >Sent: Jun 8, 2015 6:45 PM >To: "Joel M. Halpern" >Cc: The IESG , "sfc@ietf.org" , Stephen Farre= ll >Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architectur= e-08: (with DISCUSS and COMMENT) ... >Further, BCP61 says =E2=80=9Censure that IETF standard protocols have >the necessary features to provide appropriate security for the >application as it may be used across the Internet=E2=80=9D =E2=80=94 and t= his >architecture is not defining an application that is used across >the Internet. Are you arguing that in the context of BCP61, this architecture should be understood as an implicit applicability statement, effectively mandating that SFC should not be used across the Internet or across networks where eavesdropping / monitoring is a possibility? Randy From nobody Mon Jun 8 22:40:43 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC9CC1AD0AD for ; Mon, 8 Jun 2015 22:40:41 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 v0UhDOPJQ79y for ; Mon, 8 Jun 2015 22:40:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646141AD0AF for ; Mon, 8 Jun 2015 22:40:39 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 833012AC19E for ; Tue, 9 Jun 2015 07:40:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6A6CA384061 for ; Tue, 9 Jun 2015 07:40:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0235.001; Tue, 9 Jun 2015 07:40:37 +0200 From: To: "sfc@ietf.org" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-06.txt Thread-Index: AQHQonZMwSPNk8u+uUmltok+dB54Lp2jp9cg Date: Tue, 9 Jun 2015 05:40:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> In-Reply-To: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.9.45715 Archived-At: Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 05:40:42 -0000 Dear all, This new version integrates the comments received from the list.=20 I do think the document is ready for a WG call for adoption. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: mardi 9 juin 2015 07:37 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-ww-sfc-control-plane-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : Service Function Chaining (SFC) Control Plane > Components & Requirements > Authors : Hongyu Li > Qin Wu > Mohamed Boucadair > Christian Jacquenet > Walter Haeffner > Seungik Lee > Ron Parker > Linda Dunbar > Andrew Malis > Joel M. Halpern > Tirumaleswar Reddy > Prashanth Patil > Filename : draft-ww-sfc-control-plane-06.txt > Pages : 27 > Date : 2015-06-08 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements (including > management components) and SFC functional elements. Also, this > document identifies a set of control interfaces to interact with SFC- > aware elements to establish, maintain or recover service function > chains. This document does not specify protocols nor extensions to > existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 8 23:34:09 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5301AD33F for ; Mon, 8 Jun 2015 23:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6MgLCmnsEoD for ; Mon, 8 Jun 2015 23:34:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1351AD34C for ; Mon, 8 Jun 2015 23:34:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXD70114; Tue, 09 Jun 2015 06:34:05 +0000 (GMT) Received: from SZXEMA413-HUB.china.huawei.com (10.82.72.72) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 9 Jun 2015 07:34:04 +0100 Received: from SZXEMA506-MBX.china.huawei.com ([169.254.3.98]) by SZXEMA413-HUB.china.huawei.com ([10.82.72.72]) with mapi id 14.03.0158.001; Tue, 9 Jun 2015 14:32:55 +0800 From: "Huangyong (Oliver)" To: "mohamed.boucadair@orange.com" , "sfc@ietf.org" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-06.txt Thread-Index: AQHQonZMwSPNk8u+uUmltok+dB54Lp2jp9cggAAPOWA= Date: Tue, 9 Jun 2015 06:32:55 +0000 Message-ID: <8172B566C79A4A4C8EB6C7B1F6529EFC61E29BE4@szxema506-mbx.china.huawei.com> References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.108.172] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 06:34:08 -0000 Med, Good work! Thank you. Cheers, Oliver --------------------------- Huangyong (Oliver) Network research, Huawei -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of mohamed.boucadair@oran= ge.com Sent: Tuesday, June 09, 2015 1:41 PM To: sfc@ietf.org Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt Dear all, This new version integrates the comments received from the list.=20 I do think the document is ready for a WG call for adoption. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de= =20 > internet-drafts@ietf.org Envoy=E9=A0: mardi 9 juin 2015 07:37 =C0=A0:=20 > i-d-announce@ietf.org Objet=A0: I-D Action:=20 > draft-ww-sfc-control-plane-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. >=20 >=20 > Title : Service Function Chaining (SFC) Control Plane > Components & Requirements > Authors : Hongyu Li > Qin Wu > Mohamed Boucadair > Christian Jacquenet > Walter Haeffner > Seungik Lee > Ron Parker > Linda Dunbar > Andrew Malis > Joel M. Halpern > Tirumaleswar Reddy > Prashanth Patil > Filename : draft-ww-sfc-control-plane-06.txt > Pages : 27 > Date : 2015-06-08 >=20 > Abstract: > This document describes requirements for conveying information > between Service Function Chaining (SFC) control elements (including > management components) and SFC functional elements. Also, this > document identifies a set of control interfaces to interact with SFC- > aware elements to establish, maintain or recover service function > chains. This document does not specify protocols nor extensions to > existing protocols. >=20 > This document exclusively focuses on SFC deployments that are under > the responsibility of a single administrative entity. Inter-domain > considerations are out of scope. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jun 9 04:20:50 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C011A0358; Tue, 9 Jun 2015 04:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs_Cw_Ssfi8Q; Tue, 9 Jun 2015 04:20:42 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903D91A0318; Tue, 9 Jun 2015 04:20:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2366ABEC3; Tue, 9 Jun 2015 12:20:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTuX4GAKZNs3; Tue, 9 Jun 2015 12:20:36 +0100 (IST) Received: from [172.16.20.132] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EDDDDBEC6; Tue, 9 Jun 2015 12:20:35 +0100 (IST) Message-ID: <5576CC01.2010306@cs.tcd.ie> Date: Tue, 09 Jun 2015 12:20:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> <55763405.2000804@cs.tcd.ie> <557637D9.3080202@joelhalpern.com> In-Reply-To: <557637D9.3080202@joelhalpern.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 11:20:46 -0000 Hi Joel, On 09/06/15 01:48, Joel M. Halpern wrote: > There was no formal discussion of this topic by the working group. > Carlos and I are reflecting what we understand from the passing > references and the very lack of interest in the topic from the working > group. I don't see how that correlates with a claim that this document meets the chartered goals. Are you saying the charter is OBE and thus maybe needs changing? > > I really do not think, in an architecture, that it makes sense to get > into a discussion of what we think will be implemented. Yes, and we are not getting into *what* would be implemented, we are arguing over whether or not the architecture says that security services are optional to implement. (Which you prefer and I don't.) > After all, > while I can cite my expectations, we can't prove it until we get down > the road. I tried to focus the text on substantive technical matters. > On the other hand, you seem to be trying to force the issue. That is a false dichotomy. I asked a specific question to which I have yet to see an answer: "Where is the analysis that says that data origin authentication is not needed and that data integrity is sufficient"? We do seem to agree that it's necessary to define a confidentiality service and either how to do (data-origin-authentication or data-integrity) for at least the meta-data. And I think getting rid of those brackets is the only substantive technical issue, aside from the stuff about MTI. But yes, I am trying to force the issue, but only to the point where we do not punt on decisions because in my experience that leads to worse outcomes in terms of DISCUSSes later. > While section 6 of BCP61 is focused on the question of whether > encryption is needed, it ends with the statement that cryptographic > techniques are likely to be needed, with an implication form context of > authentication and integrity. But even then, it does not go so far as > to say that cryptographic means for authentication and integrity are > mandatory, merely likely. So it seems very clear to me that even BCP > 61 allows for cases where such tools may not be mandatory to implement. Honestly, I find that to be a very weird reading of bcp61. I don't myself see any wiggle room in [1] which ends with " However security must be a MUST IMPLEMENT so that end users will have the option of enabling it when the situation calls for it. " In this case the relevant end users are folks who buy/deploy SFC things (just so's we don't get into a debate about "what's an end-user" here:-) [1] https://tools.ietf.org/html/bcp61#section-7 > > We are working on a control requirements document, and there I expect we > will call for mandatory strong authentication, integrity, and encryption > capabilities. The threats are much clearer, the responses are > well-defined, and the value is demonstrable. > > But we are talking here about the data plane packets. Packets being > passed through a chain of services on their way from a source to a > destination. I think we're talking about the overall SFC architecture here. > > I am sure that you could phrase the question to the working group in > such a way as to prompt extended discussion and disagreement. I am > equally sure that the question could be phrased in a way that would > result in a confirmation of Carlos' and my understanding of the working > groups intent, desire, and understanding. I don't get your point there sorry. Cheers, S. PS: I'll response to Carlos' mail in a while. Gotta do a thing first. > > Yours, > Joel > > On 6/8/15 8:32 PM, Stephen Farrell wrote: >> >> Hiya, >> >> On 09/06/15 01:11, Joel M. Halpern wrote: >>> Given that we do clearly recognize that there are cases where securing >>> the communication is necessary this comes down, from what you are saying >>> now, to the simple question of whether we have justified the absence of >>> an MTI security mechanism. >> >> If the question were simple, it'd be easier I guess:-) >> >>> >>> You are saying "no". We are saying "the working group did not ask for >>> it, and here the reasons we think that is defensible." >> >> Can you show me where the WG discussed this? (In the archive.) >> Seeing that discussion would help. If it has not happened, then >> seeing that discussion will help. >> >>> >>> BCP61 does recognize that it does not apply to all cases. >> >> I'm not sure what part(s) of bcp61 you mean, can you point me >> at that/those? >> >> >>> I am very concerned that if we write an MTI security mechanism into >>> this, almost no implementations will be compliant with the >>> specifications. That does not do us any good at all. >> >> Yes. Mythical security is no security I fully agree. But Carlos' >> text did not speak to unwillingness to implement, nor to any >> inability to define a usable/sufficiently-useful mechanism. >> >>> >>> You asked for us to be explicit, and to state our reasons. We have done >>> so. >> >> Carlos' recent text omitted some points mentioned above. >> >>> Yes, we could have a working group hum on whether we want an MTI >>> security mechanism in all solutions which comply with the architecture. >>> I think we already have clarity on that issue from the WG. And I >>> doubt >>> such a hum would change your mind if it went against you. >> >> I am not asking for a hum. I am asking to see the (archive of >> the) discussion demonstrating that clarity. Please send a URL. >> >> Thanks, >> S. >> >> >>> >>> Yours, >>> Joel >>> >>> On 6/8/15 7:53 PM, Stephen Farrell wrote: >>>> >>>> Hi Carlos, >>>> >>>> Thanks for that text, which I think seems to match well with what >>>> you and Joel have been saying. >>>> >>>> I have to say though that I don't find it at all convincing given >>>> that we have bcp61. Having some mti security so that it can be >>>> turned on when needed despite buying kit from multiple vendors is >>>> what bcp61 calls for and I really don't see why sfc is an exception. >>>> >>>> A question for you - is it useful for me to try de-construct the >>>> text below (on the above basis) or not? It may be a waste of time >>>> and we may be better off getting additional viewpoints on this >>>> instead. >>>> >>>> And in case it helps, I think the main (not the only) counter to what >>>> you propose below is the consideration that while sfc may only be >>>> well-defined for intradomain use now, intradomain use can in >>>> various ways span what are now clearly important trust boundaries, >>>> see tempora/belgacom/gemalto for examples. >>>> >>>> Cheers, >>>> S. >>>> >>>> >>>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>>>> Stephen, >>>>> >>>>> Please find some concrete text, with a sufficiently detailed >>>>> explanation, to anchor the discussion. >>>>> >>>>> Feedback? >>>>> >>>>> —>8— >>>>> 6.1. SFC Data Plane Security >>>>> >>>>> One of the aspects to consider as part of the SFC security model is >>>>> whether to mandate the implementation of, and strongly recommend the >>>>> use of authentication and encryption technology within the SFC data >>>>> plane. This architecture mandates the definition of mechanisms to >>>>> provide confidentiality and integrity of metadata carried by the >>>>> protocol, but makes not further recommendations. This is based on the >>>>> unusual operating constraints. Rather than being an end-to-end >>>>> protocol, or even a relayed protocol with a desire to reduce the >>>>> number of relays, the goal of this protocol is to deliver data >>>>> packets to a series of service functions. These functions are >>>>> selected and provided by a combination of user and operator >>>>> decisions. They are, in most cases, granted access to the data packet >>>>> contents and the metadata. Securing the packets from the service >>>>> functions would be counter-productive. >>>>> >>>>> One could argue for securing the packets as they traverse the >>>>> underlying network. Provisions for this are already included under >>>>> the “Service Overlay†title in this Security Considerations. In the >>>>> general case where every hop between service functions is over >>>>> untrusted media, that may be necessary and appropriate. However, the >>>>> initial target is for a single administrative domain, where if there >>>>> are any untrustued segments they will be few and well-recognized. >>>>> Even in the general case, most transport connections will be >>>>> sufficiently trusted so as not to warrant the cost of hop-wise >>>>> security mechanisms over a multi-hop transport. >>>>> >>>>> Given the operator focus on internal use of this tool, even demanding >>>>> implementation of such mechanisms is likely to place a cost on >>>>> delivery that will interfere with the use of this technology. It >>>>> should be understood that this architecture is a new model >>>>> replacement for a multiplicity of widely used techniques, most of >>>>> which do not even have the option of security mechanisms. >>>>> >>>>> This analysis leads to an expectation of a need for optional security >>>>> techniques well-integrated with the protocol so that they can be used >>>>> where needed, without mandating that all implementations include such >>>>> capabilities. >>>>> —>8— >>>>> >>>>> Thanks, >>>>> >>>>> — Carlos. >>>>> >>>>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>>>> wrote: >>>>>> >>>>>> This sounds like something Carlos and I can try to address in >>>>>> conjunction with the revisions. Sorry if I was slow to understand >>>>>> the quesiton. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>>>> >>>>>>> >>>>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>>>> The escurity considerations section addresses, as far as we >>>>>>>> understand >>>>>>>> them, the issues that a "security model" needs to cover. It is >>>>>>>> not done >>>>>>>> as an explicit model. We could recast the section as such a >>>>>>>> model, but >>>>>>>> it would end up saying the same things. >>>>>>> >>>>>>> Well, let's see what a revised ID looks like and then haggle about >>>>>>> that maybe. I think that'll be easier. (I note you did not say that >>>>>>> the charter text on this is OBE btw.) >>>>>>> >>>>>>>> We could write more explicitly some of the other assumptions we >>>>>>>> make, >>>>>>>> for example that the services to which user packets are >>>>>>>> delivered are >>>>>>>> trusted by the operator to examine the packets and associated >>>>>>>> metadata. >>>>>>>> We could note that the service functions are further trusted to >>>>>>>> modify >>>>>>>> the packet contents and metadata. >>>>>>>> We could add text that in most single-domain cases, the underlying >>>>>>>> infrastructure is trusted by the operator. >>>>>>> >>>>>>> If your goal as authors/WG is to not have mandatory to implement >>>>>>> security then yes you would I think need to explicitly justify that >>>>>>> in a convincing manner. Isn't it perhaps telling us something if you >>>>>>> chose to not explicitly say things like "trusted by the operator so >>>>>>> no security needed" in the draft? (Seems so to me tbh.) >>>>>>> >>>>>>>> >>>>>>>> Would adding text like that help? It would seem instead to >>>>>>>> provoke the >>>>>>>> BCP61 comment that you are now making. >>>>>>> >>>>>>> The BCP61 comment resulted from your proposed text ("adjunct" etc) >>>>>>> which >>>>>>> seems to me to run counter to that BCP. Are you arguing that such >>>>>>> text >>>>>>> would be consistent with BCP61? If not, then what is your >>>>>>> argument for >>>>>>> BCP61 not applying or being unwise in this case? >>>>>>> >>>>>>> Cheers, >>>>>>> S. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>>>> I am not sure how to usefully respond to your concern that you >>>>>>>>>> are not >>>>>>>>>> convinced that security mechanisms can be adjunct or optional. >>>>>>>>>> That >>>>>>>>>> seems to border on opinion, rather than factual basis for a >>>>>>>>>> discuss. >>>>>>>>>> Further, I really do not want to end up in a situation where the >>>>>>>>>> majority of implementations are not conformant to the >>>>>>>>>> architecture and >>>>>>>>>> protocol spec. >>>>>>>>>> And it is very clear that most of the environments at least >>>>>>>>>> for the >>>>>>>>>> initial, single domain, case that we are targeting will not need >>>>>>>>>> any >>>>>>>>>> form of authentication or data integrity in the SFC mechanism. >>>>>>>>> >>>>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Also, I realized looking at your comments and the charter, that >>>>>>>>>> I do not >>>>>>>>>> know know what would constitute a "security model" as you >>>>>>>>>> understand it. >>>>>>>>> >>>>>>>>> Ok - what is a security model as you understand what the charter >>>>>>>>> says about this deliverable? Since you're an author and the >>>>>>>>> charter >>>>>>>>> calls for that can you point me at where in the draft I find it >>>>>>>>> or why it is no longer needed/relevant/whatever? >>>>>>>>> >>>>>>>>> Ta, >>>>>>>>> S. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Yours, >>>>>>>>>> Joel >>>>>>>>>> >>>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>>>> >>>>>>>>>>> Hi Carlos, >>>>>>>>>>> >>>>>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>>>>> >>>>>>>>>> ... >>>>>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>>>>> >>>>>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>>>>> various bad situations that happened in the roll and karp >>>>>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>>>>> >>>>>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>>>>> implement. >>>>>>>>>>> >>>>>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>>>>> is sufficient or whether data origin authentication is >>>>>>>>>>> really needed here. (That could easily be something to be >>>>>>>>>>> addressed later in the WG but is not something to determine >>>>>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>>>>> if it has been done but not written down so far which may >>>>>>>>>>> be the case.) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> S. >>>>>>>>>>> >>>>>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>>>>>> on trying to get this document done in the next few days and >>>>>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> — Carlos. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>> >>>> >>> > From nobody Tue Jun 9 05:26:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074911B2BDD; Tue, 9 Jun 2015 05:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s_dubSUBV2Zf; Tue, 9 Jun 2015 05:25:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02B11B2BD7; Tue, 9 Jun 2015 05:25:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 15FBBBED6; Tue, 9 Jun 2015 13:25:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq-Cv2UK0Nfb; Tue, 9 Jun 2015 13:25:48 +0100 (IST) Received: from [172.16.22.181] (62-50-200-74.client.stsn.net [62.50.200.74]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 665EDBEB1; Tue, 9 Jun 2015 13:25:48 +0100 (IST) Message-ID: <5576DB4A.9020505@cs.tcd.ie> Date: Tue, 09 Jun 2015 13:25:46 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" , "Joel M. Halpern" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> <55763405.2000804@cs.tcd.ie> <557637D9.3080202@joelhalpern.com> <2A5EFB0C-6FCA-455A-83D1-E7395DF82E22@cisco.com> In-Reply-To: <2A5EFB0C-6FCA-455A-83D1-E7395DF82E22@cisco.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H3lddPgIk0uXIUPNxTsImo6aiXWvo2dEc" Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 12:25:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --H3lddPgIk0uXIUPNxTsImo6aiXWvo2dEc Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Carlos, On 09/06/15 02:45, Carlos Pignataro (cpignata) wrote: > Stephen, >=20 > To add to what Joel articulated, please find a three key points: >=20 > First, what we are taking about here is mandatory SFC encapsulation > encryption.=20 No. What we're talking about is mandatory *to implement* security services being called for by the SFC architecture. We are not talking about mandating *use* of those services and it's important to keep that front and centre in the discussion and to not be ambiguous. > That is really one piece of the security puzzle. But the > Service Overlay satisfy the security requirements of the specific SFC > deployment. And how would one do that if your vendor has chosen to not implement whatever security services are defined? > At the tunnel, we can turn on "authenticity and integrity > checking, and/or confidentiality provisions=E2=80=9D (the text is alrea= dy > there), and that would cover headers and payloads. It is not fully > clear (to me) why the fixation on mandating encrypting this > particular piece (more in the 3rd point). Same ambiguity above. That doesn't help. We're only talking MTI here. >=20 > The second point, when you say =E2=80=9CPlease send a URL=E2=80=9D, it = seems as if > you are hoping to find all security discussions consolidated into a > single convenient email thread. Yep, that'd be lovely:-) I realise life's not so simple. > Truth is, the topic was discussed in > various occasions, on the list, with off-list comments, in meetings, > and in multiple threads. I expect that this is better than =E2=80=9Ca U= RL=E2=80=9D > frankly. And I'm asking to see that. If it was all offlist or wasn't well documented in meeting minutes that's undesirable but entirely understandable. But in that case I'm sure you can understand why that makes it hard for me to understand the analysis. OTOH, Joel seemed to be saying that this had not really been discussed (on the list/in meetings), so I'm not sure which is the case. >=20 > So, a couple of relevant breadcrumbs FYI: All the WG discussions are > what drove the shaping of the security considerations from the > initial one-sentence that it was: " This document does not define a > new protocol and therefore creates no new security issues." I'm entirely happy to have a problem with that one sentence;-) The SFC architecture (and hence this document) certainly does create new security issues. >=20 > to today=E2=80=99s:=20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sfc-architecture-09.txt= &url1=3Ddraft-merged-sfc-architecture-01.txt#diff0127 > > > That did not happen in a single mega-discussion =E2=80=94 the more mea= ty > security discussions started at this comment > http://www.ietf.org/mail-archive/web/sfc/current/msg02869.html > , and > we had a milestone at > http://www.ietf.org/mail-archive/web/sfc/current/msg03126.html > . >=20 > Then the goal was to get to Hawaii with an even strengthened section. > Slide 4 at > https://tools.ietf.org/agenda/91/slides/slides-91-sfc-2.pdf > . And > really the list archives show this discussion sprinkled throughout > multiple times. So I had a look through those, thanks for hunting them down. But unfortunately I don't see in-depth security discussion - did I miss it? >=20 > The third point, regarding BCP61. BCP61 speaks about strong security > requirements for IETF =E2=80=9CStandard Protocols=E2=80=9D. However, th= is document > does not define protocols. Sure. For an architecture document, what I think we need to do is to say what security services need to be defined. And, in this case, we clearly need to follow bcp61 in saying that those need to be MTI, (from my POV) as the authors are asking to say that those are "adjuncts" and optional to implement. (Normally, silence on that topic might be sufficient, but I think in this case we should bottom out on it now since we already know there's very different opinions.) >=20 > I did mention to you already a couple of times that there is concrete > clear WG interest in working on these solutions, as per > https://tools.ietf.org/html/draft-reddy-sfc-nsh-encrypt-00 > . You > will find that draft-reddy-sfc-nsh-encrypt-00 is not a quick > placeholder-draft,=20 I've read that. It seems to call for a kerberos-like solution (which is credible) but as of now, that draft doesn't actually say "we're using kerberos for this" so I don't believe it currently specifies something that could be MTI and that would achieve interop. But sure, that draft could be adopted and developed by the WG to the point where it would be fine. > but energy wants to be placed here.=20 Yes, that's a concern. We need to get to something that does the job and is good enough that folks will implement. And it also needs to be good enough to deploy it when needed. > This does not > mean or imply that this architecture needs to cast MTI encryption. > That question can be answered when the protocol and the encryption > methods are defined. No. Not if the architecture says security is not MTI, in opposition to bcp61. If the architecture says that security services for confidentiality etc. need to be defined and MTI then yes the details can be sorted out later in the WG. >=20 > Further, BCP61 says =E2=80=9Censure that IETF standard protocols have t= he > necessary features to provide appropriate security for the > application as it may be used across the Internet=E2=80=9D =E2=80=94 an= d this > architecture is not defining an application that is used across the > Internet. See above. I hope I've answered that. Cheers, S. >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On Jun 8, 2015, at 8:48 PM, Joel M. Halpern >> wrote: >>=20 >> There was no formal discussion of this topic by the working group. >> Carlos and I are reflecting what we understand from the passing >> references and the very lack of interest in the topic from the >> working group. >>=20 >> I really do not think, in an architecture, that it makes sense to >> get into a discussion of what we think will be implemented. After >> all, while I can cite my expectations, we can't prove it until we >> get down the road. I tried to focus the text on substantive >> technical matters. On the other hand, you seem to be trying to >> force the issue. >>=20 >> While section 6 of BCP61 is focused on the question of whether >> encryption is needed, it ends with the statement that cryptographic >> techniques are likely to be needed, with an implication form >> context of authentication and integrity. But even then, it does >> not go so far as to say that cryptographic means for authentication >> and integrity are mandatory, merely likely. So it seems very >> clear to me that even BCP 61 allows for cases where such tools may >> not be mandatory to implement. >>=20 >> We are working on a control requirements document, and there I >> expect we will call for mandatory strong authentication, integrity, >> and encryption capabilities. The threats are much clearer, the >> responses are well-defined, and the value is demonstrable. >>=20 >> But we are talking here about the data plane packets. Packets >> being passed through a chain of services on their way from a source >> to a destination. >>=20 >> I am sure that you could phrase the question to the working group >> in such a way as to prompt extended discussion and disagreement. I >> am equally sure that the question could be phrased in a way that >> would result in a confirmation of Carlos' and my understanding of >> the working groups intent, desire, and understanding. >>=20 >> Yours, Joel >>=20 >> On 6/8/15 8:32 PM, Stephen Farrell wrote: >>>=20 >>> Hiya, >>>=20 >>> On 09/06/15 01:11, Joel M. Halpern wrote: >>>> Given that we do clearly recognize that there are cases where >>>> securing the communication is necessary this comes down, from >>>> what you are saying now, to the simple question of whether we >>>> have justified the absence of an MTI security mechanism. >>>=20 >>> If the question were simple, it'd be easier I guess:-) >>>=20 >>>>=20 >>>> You are saying "no". We are saying "the working group did not >>>> ask for it, and here the reasons we think that is defensible." >>>=20 >>> Can you show me where the WG discussed this? (In the archive.)=20 >>> Seeing that discussion would help. If it has not happened, then=20 >>> seeing that discussion will help. >>>=20 >>>>=20 >>>> BCP61 does recognize that it does not apply to all cases. >>>=20 >>> I'm not sure what part(s) of bcp61 you mean, can you point me at >>> that/those? >>>=20 >>>=20 >>>> I am very concerned that if we write an MTI security mechanism >>>> into this, almost no implementations will be compliant with >>>> the specifications. That does not do us any good at all. >>>=20 >>> Yes. Mythical security is no security I fully agree. But Carlos'=20 >>> text did not speak to unwillingness to implement, nor to any=20 >>> inability to define a usable/sufficiently-useful mechanism. >>>=20 >>>>=20 >>>> You asked for us to be explicit, and to state our reasons. We >>>> have done so. >>>=20 >>> Carlos' recent text omitted some points mentioned above. >>>=20 >>>> Yes, we could have a working group hum on whether we want an >>>> MTI security mechanism in all solutions which comply with the >>>> architecture. I think we already have clarity on that issue >>>> from the WG. And I doubt such a hum would change your mind if >>>> it went against you. >>>=20 >>> I am not asking for a hum. I am asking to see the (archive of=20 >>> the) discussion demonstrating that clarity. Please send a URL. >>>=20 >>> Thanks, S. >>>=20 >>>=20 >>>>=20 >>>> Yours, Joel >>>>=20 >>>> On 6/8/15 7:53 PM, Stephen Farrell wrote: >>>>>=20 >>>>> Hi Carlos, >>>>>=20 >>>>> Thanks for that text, which I think seems to match well with >>>>> what you and Joel have been saying. >>>>>=20 >>>>> I have to say though that I don't find it at all convincing >>>>> given that we have bcp61. Having some mti security so that it >>>>> can be turned on when needed despite buying kit from multiple >>>>> vendors is what bcp61 calls for and I really don't see why >>>>> sfc is an exception. >>>>>=20 >>>>> A question for you - is it useful for me to try de-construct >>>>> the text below (on the above basis) or not? It may be a waste >>>>> of time and we may be better off getting additional >>>>> viewpoints on this instead. >>>>>=20 >>>>> And in case it helps, I think the main (not the only) counter >>>>> to what you propose below is the consideration that while sfc >>>>> may only be well-defined for intradomain use now, intradomain >>>>> use can in various ways span what are now clearly important >>>>> trust boundaries, see tempora/belgacom/gemalto for examples. >>>>>=20 >>>>> Cheers, S. >>>>>=20 >>>>>=20 >>>>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>>>>> Stephen, >>>>>>=20 >>>>>> Please find some concrete text, with a sufficiently >>>>>> detailed explanation, to anchor the discussion. >>>>>>=20 >>>>>> Feedback? >>>>>>=20 >>>>>> =E2=80=94>8=E2=80=94 6.1. SFC Data Plane Security >>>>>>=20 >>>>>> One of the aspects to consider as part of the SFC security >>>>>> model is whether to mandate the implementation of, and >>>>>> strongly recommend the use of authentication and encryption >>>>>> technology within the SFC data plane. This architecture >>>>>> mandates the definition of mechanisms to provide >>>>>> confidentiality and integrity of metadata carried by the=20 >>>>>> protocol, but makes not further recommendations. This is >>>>>> based on the unusual operating constraints. Rather than >>>>>> being an end-to-end protocol, or even a relayed protocol >>>>>> with a desire to reduce the number of relays, the goal of >>>>>> this protocol is to deliver data packets to a series of >>>>>> service functions. These functions are selected and >>>>>> provided by a combination of user and operator decisions. >>>>>> They are, in most cases, granted access to the data packet=20 >>>>>> contents and the metadata. Securing the packets from the >>>>>> service functions would be counter-productive. >>>>>>=20 >>>>>> One could argue for securing the packets as they traverse >>>>>> the underlying network. Provisions for this are already >>>>>> included under the =E2=80=9CService Overlay=E2=80=9D title in this= Security >>>>>> Considerations. In the general case where every hop between >>>>>> service functions is over untrusted media, that may be >>>>>> necessary and appropriate. However, the initial target is >>>>>> for a single administrative domain, where if there are any >>>>>> untrustued segments they will be few and well-recognized.=20 >>>>>> Even in the general case, most transport connections will >>>>>> be sufficiently trusted so as not to warrant the cost of >>>>>> hop-wise security mechanisms over a multi-hop transport. >>>>>>=20 >>>>>> Given the operator focus on internal use of this tool, even >>>>>> demanding implementation of such mechanisms is likely to >>>>>> place a cost on delivery that will interfere with the use >>>>>> of this technology. It should be understood that this >>>>>> architecture is a new model replacement for a multiplicity >>>>>> of widely used techniques, most of which do not even have >>>>>> the option of security mechanisms. >>>>>>=20 >>>>>> This analysis leads to an expectation of a need for >>>>>> optional security techniques well-integrated with the >>>>>> protocol so that they can be used where needed, without >>>>>> mandating that all implementations include such=20 >>>>>> capabilities. =E2=80=94>8=E2=80=94 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> =E2=80=94 Carlos. >>>>>>=20 >>>>>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>>>>> wrote: >>>>>>>=20 >>>>>>> This sounds like something Carlos and I can try to >>>>>>> address in conjunction with the revisions. Sorry if I >>>>>>> was slow to understand the quesiton. >>>>>>>=20 >>>>>>> Yours, Joel >>>>>>>=20 >>>>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>>>>> The escurity considerations section addresses, as far >>>>>>>>> as we understand them, the issues that a "security >>>>>>>>> model" needs to cover. It is not done as an explicit >>>>>>>>> model. We could recast the section as such a model, >>>>>>>>> but it would end up saying the same things. >>>>>>>>=20 >>>>>>>> Well, let's see what a revised ID looks like and then >>>>>>>> haggle about that maybe. I think that'll be easier. (I >>>>>>>> note you did not say that the charter text on this is >>>>>>>> OBE btw.) >>>>>>>>=20 >>>>>>>>> We could write more explicitly some of the other >>>>>>>>> assumptions we make, for example that the services to >>>>>>>>> which user packets are delivered are trusted by the >>>>>>>>> operator to examine the packets and associated=20 >>>>>>>>> metadata. We could note that the service functions >>>>>>>>> are further trusted to modify the packet contents and >>>>>>>>> metadata. We could add text that in most >>>>>>>>> single-domain cases, the underlying infrastructure is >>>>>>>>> trusted by the operator. >>>>>>>>=20 >>>>>>>> If your goal as authors/WG is to not have mandatory to >>>>>>>> implement security then yes you would I think need to >>>>>>>> explicitly justify that in a convincing manner. Isn't >>>>>>>> it perhaps telling us something if you chose to not >>>>>>>> explicitly say things like "trusted by the operator so=20 >>>>>>>> no security needed" in the draft? (Seems so to me >>>>>>>> tbh.) >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Would adding text like that help? It would seem >>>>>>>>> instead to provoke the BCP61 comment that you are now >>>>>>>>> making. >>>>>>>>=20 >>>>>>>> The BCP61 comment resulted from your proposed text >>>>>>>> ("adjunct" etc) which seems to me to run counter to >>>>>>>> that BCP. Are you arguing that such text would be >>>>>>>> consistent with BCP61? If not, then what is your >>>>>>>> argument for BCP61 not applying or being unwise in this >>>>>>>> case? >>>>>>>>=20 >>>>>>>> Cheers, S. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Yours, Joel >>>>>>>>>=20 >>>>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>>>>> I am not sure how to usefully respond to your >>>>>>>>>>> concern that you are not convinced that security >>>>>>>>>>> mechanisms can be adjunct or optional. That seems >>>>>>>>>>> to border on opinion, rather than factual basis >>>>>>>>>>> for a discuss. Further, I really do not want to >>>>>>>>>>> end up in a situation where the majority of >>>>>>>>>>> implementations are not conformant to the=20 >>>>>>>>>>> architecture and protocol spec. And it is very >>>>>>>>>>> clear that most of the environments at least for >>>>>>>>>>> the initial, single domain, case that we are >>>>>>>>>>> targeting will not need any form of >>>>>>>>>>> authentication or data integrity in the SFC >>>>>>>>>>> mechanism. >>>>>>>>>>=20 >>>>>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Also, I realized looking at your comments and the >>>>>>>>>>> charter, that I do not know know what would >>>>>>>>>>> constitute a "security model" as you understand >>>>>>>>>>> it. >>>>>>>>>>=20 >>>>>>>>>> Ok - what is a security model as you understand >>>>>>>>>> what the charter says about this deliverable? Since >>>>>>>>>> you're an author and the charter calls for that can >>>>>>>>>> you point me at where in the draft I find it or why >>>>>>>>>> it is no longer needed/relevant/whatever? >>>>>>>>>>=20 >>>>>>>>>> Ta, S. >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> Yours, Joel >>>>>>>>>>>=20 >>>>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Hi Carlos, >>>>>>>>>>>>=20 >>>>>>>>>>>> Sorry for the delayed response - some more >>>>>>>>>>>> travel ensued;-( >>>>>>>>>>>>=20 >>>>>>>>>>> ... >>>>>>>>>>>> No, sorry. For one minor and two major >>>>>>>>>>>> reasons. >>>>>>>>>>>>=20 >>>>>>>>>>>> The first is that I want to ensure we do not >>>>>>>>>>>> end up in the various bad situations that >>>>>>>>>>>> happened in the roll and karp WGs, so a simple >>>>>>>>>>>> addition like that without any idea what is=20 >>>>>>>>>>>> likely to really happen isn't a good plan I >>>>>>>>>>>> think. >>>>>>>>>>>>=20 >>>>>>>>>>>> The second is that I am entirely unconvinced >>>>>>>>>>>> that any security mechanisms can be an >>>>>>>>>>>> "adjunct" or optional to implement. >>>>>>>>>>>>=20 >>>>>>>>>>>> The minor reason is that I don't think we have >>>>>>>>>>>> gotten to the bottom of whether data integrity >>>>>>>>>>>> of data in transit is sufficient or whether >>>>>>>>>>>> data origin authentication is really needed >>>>>>>>>>>> here. (That could easily be something to be=20 >>>>>>>>>>>> addressed later in the WG but is not something >>>>>>>>>>>> to determine now unless we do the analysis now, >>>>>>>>>>>> or describe that analysis if it has been done >>>>>>>>>>>> but not written down so far which may be the >>>>>>>>>>>> case.) >>>>>>>>>>>>=20 >>>>>>>>>>>> Cheers, S. >>>>>>>>>>>>=20 >>>>>>>>>>>> PS: I'm starting on vacation on Thursday so >>>>>>>>>>>> will try to be responsive on this in the >>>>>>>>>>>> meantime. However, we really ought keep in mind >>>>>>>>>>>> that getting the right outcome at this stage=20 >>>>>>>>>>>> could save a lot of effort later, so I wouldn't >>>>>>>>>>>> be too focused on trying to get this document >>>>>>>>>>>> done in the next few days and I think we ought >>>>>>>>>>>> be much more focused on doing our best with=20 >>>>>>>>>>>> ensuring that SFC doesn't hit security >>>>>>>>>>>> speedbumps later on. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> =E2=80=94 Carlos. >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ sfc >>>>>>> mailing list sfc@ietf.org=20 >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>>=20 >=20 >=20 --H3lddPgIk0uXIUPNxTsImo6aiXWvo2dEc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVdttKAAoJEC88hzaAX42izVwH/AjV+ZDgj1lU9izYouoADF85 RzW1wP/iBRNN5+TRuk1r/zXXtrBxzSLoOUBTyo/zLClzJv0bYmPDbx4iEuCNNhc5 Fax07ID6+svQK+hIrpP26qjM4QgTNhbU0zlO4l5fXVd1qnnKeofJTC1IeE/LqEEL Cbo8WZcahebWP9qaRSbSTF277AHWsxMLrnolZt//q8wFdoCjpaf82TjmDERQeeC2 o8kmEYOj1gWpOngFHnqxYtSxTIylLJ6ZwKkXbBn1q5z6+ds0xQo+DgWi/1h/b2U/ jAtLL9Csxg2hfgF+kqNHJHIoH1V0fyCewYL9WQQFKSfsfPHk0qF1zlhKDN2mDFA= =gfMH -----END PGP SIGNATURE----- --H3lddPgIk0uXIUPNxTsImo6aiXWvo2dEc-- From nobody Tue Jun 9 06:29:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 014F01A7003; Tue, 9 Jun 2015 06:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aBRVemmjg8T; Tue, 9 Jun 2015 06:29:07 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413DA1A6FFF; Tue, 9 Jun 2015 06:29:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id EE738251019; Tue, 9 Jun 2015 06:29:06 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 060292412BB; Tue, 9 Jun 2015 06:29:05 -0700 (PDT) Message-ID: <5576EA0F.3000209@joelhalpern.com> Date: Tue, 09 Jun 2015 09:28:47 -0400 From: Joel Halpern Direct User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Stephen Farrell , "Carlos Pignataro (cpignata)" References: <20150528125259.27648.30861.idtracker@ietfa.amsl.com> <74123F8B-A5F0-4936-A74A-693913870FD3@cisco.com> <5574A665.3080604@cs.tcd.ie> <5574AA33.5070609@joelhalpern.com> <5574AADA.8080606@cs.tcd.ie> <5574AC37.5010009@joelhalpern.com> <5574B1FB.5020706@cs.tcd.ie> <5574B9EE.2070002@joelhalpern.com> <55762AFE.2080604@cs.tcd.ie> <55762F4D.6070400@joelhalpern.com> <55763405.2000804@cs.tcd.ie> <557637D9.3080202@joelhalpern.com> <5576CC01.2010306@cs.tcd.ie> In-Reply-To: <5576CC01.2010306@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 09 Jun 2015 13:29:11 -0000 I agree that the wording in section 7 of BCP 61 makes clear that the end-user issue does apply here. I think that the biggest difference in this regard is that because there are a relatively small number of actual end users, and because they have the proven ability to be very specific about what they want, and to get it, I am much less concerned in this context that operators who wish to deploy secure mechanisms will be unable to get them. We have tried to be clear why we consider that the problem we are tasked to address does not require MTI security. At this point, I have no idea how to proceed with this aspect of the discussion. Part of the problem, it seems to me, is that you have said that you are perfectly happy if we take our time, perform a thorough security analysis including at least some analysis of possible solutions, and then write the rest of the architecture. Such would be needed, for example, to determine if data origin authentication is even tractable. I find myself perforce raising a point that is regularly raised, and one which I normally side with the IESG taking its time and being thorough. If we do not get this document done ASAP, we will not be able to use the document to inform the protocol work unless we significantly delay that work. In order to achieve an interoperable data plane protocol, most of us need to undertake and resolve the working group discussion of the protocol behavior and mechanisms. If we don't do that, the protocol will essentially be decided elsewhere. Which I would consider VERY unfortunate. That protocol will not have an MTI security mechanisms. (It won't be MTI because there will be no spec. And many people will leave such mechanisms out of their implementation.) We will likely get stuck with "interoperability by means of the biggest market force" (no insult to the folks who have that force, they have been VERY cooperative in the IETF work) if we do not ahve an IETF specification process to focus that discussion. The net is that if we write MTI into the archtiecture specification right now, we won't know what it means. We will then either ignore it in the protocol specification, or write something probably incorrect into the protocol specification, and have it ignored by most of the vendors. I must point out that we tried writing "must include security" into the IPv6 specification. Sorry, such words did not improve security availability at all. A similar pretense here will likely be of similar value. Yours, Joel On 6/9/15 7:20 AM, Stephen Farrell wrote: > > Hi Joel, > > On 09/06/15 01:48, Joel M. Halpern wrote: >> There was no formal discussion of this topic by the working group. >> Carlos and I are reflecting what we understand from the passing >> references and the very lack of interest in the topic from the working >> group. > > I don't see how that correlates with a claim that this document meets > the chartered goals. Are you saying the charter is OBE and thus maybe > needs changing? > >> >> I really do not think, in an architecture, that it makes sense to get >> into a discussion of what we think will be implemented. > > Yes, and we are not getting into *what* would be implemented, we are > arguing over whether or not the architecture says that security services > are optional to implement. (Which you prefer and I don't.) > >> After all, >> while I can cite my expectations, we can't prove it until we get down >> the road. I tried to focus the text on substantive technical matters. >> On the other hand, you seem to be trying to force the issue. > > That is a false dichotomy. > > I asked a specific question to which I have yet to see an answer: > "Where is the analysis that says that data origin authentication is > not needed and that data integrity is sufficient"? > > We do seem to agree that it's necessary to define a confidentiality > service and either how to do (data-origin-authentication or > data-integrity) for at least the meta-data. And I think getting > rid of those brackets is the only substantive technical issue, > aside from the stuff about MTI. > > But yes, I am trying to force the issue, but only to the point where > we do not punt on decisions because in my experience that leads to > worse outcomes in terms of DISCUSSes later. > >> While section 6 of BCP61 is focused on the question of whether >> encryption is needed, it ends with the statement that cryptographic >> techniques are likely to be needed, with an implication form context of >> authentication and integrity. But even then, it does not go so far as >> to say that cryptographic means for authentication and integrity are >> mandatory, merely likely. So it seems very clear to me that even BCP >> 61 allows for cases where such tools may not be mandatory to implement. > > Honestly, I find that to be a very weird reading of bcp61. I don't > myself see any wiggle room in [1] which ends with > > " > However security must be a MUST IMPLEMENT so that end users will have > the option of enabling it when the situation calls for it. > " > > In this case the relevant end users are folks who buy/deploy SFC > things (just so's we don't get into a debate about "what's an > end-user" here:-) > > [1] https://tools.ietf.org/html/bcp61#section-7 > >> >> We are working on a control requirements document, and there I expect we >> will call for mandatory strong authentication, integrity, and encryption >> capabilities. The threats are much clearer, the responses are >> well-defined, and the value is demonstrable. >> >> But we are talking here about the data plane packets. Packets being >> passed through a chain of services on their way from a source to a >> destination. > > I think we're talking about the overall SFC architecture here. > >> >> I am sure that you could phrase the question to the working group in >> such a way as to prompt extended discussion and disagreement. I am >> equally sure that the question could be phrased in a way that would >> result in a confirmation of Carlos' and my understanding of the working >> groups intent, desire, and understanding. > > I don't get your point there sorry. > > Cheers, > S. > > PS: I'll response to Carlos' mail in a while. Gotta do a thing > first. > > > >> >> Yours, >> Joel >> >> On 6/8/15 8:32 PM, Stephen Farrell wrote: >>> >>> Hiya, >>> >>> On 09/06/15 01:11, Joel M. Halpern wrote: >>>> Given that we do clearly recognize that there are cases where securing >>>> the communication is necessary this comes down, from what you are saying >>>> now, to the simple question of whether we have justified the absence of >>>> an MTI security mechanism. >>> >>> If the question were simple, it'd be easier I guess:-) >>> >>>> >>>> You are saying "no". We are saying "the working group did not ask for >>>> it, and here the reasons we think that is defensible." >>> >>> Can you show me where the WG discussed this? (In the archive.) >>> Seeing that discussion would help. If it has not happened, then >>> seeing that discussion will help. >>> >>>> >>>> BCP61 does recognize that it does not apply to all cases. >>> >>> I'm not sure what part(s) of bcp61 you mean, can you point me >>> at that/those? >>> >>> >>>> I am very concerned that if we write an MTI security mechanism into >>>> this, almost no implementations will be compliant with the >>>> specifications. That does not do us any good at all. >>> >>> Yes. Mythical security is no security I fully agree. But Carlos' >>> text did not speak to unwillingness to implement, nor to any >>> inability to define a usable/sufficiently-useful mechanism. >>> >>>> >>>> You asked for us to be explicit, and to state our reasons. We have done >>>> so. >>> >>> Carlos' recent text omitted some points mentioned above. >>> >>>> Yes, we could have a working group hum on whether we want an MTI >>>> security mechanism in all solutions which comply with the architecture. >>>> I think we already have clarity on that issue from the WG. And I >>>> doubt >>>> such a hum would change your mind if it went against you. >>> >>> I am not asking for a hum. I am asking to see the (archive of >>> the) discussion demonstrating that clarity. Please send a URL. >>> >>> Thanks, >>> S. >>> >>> >>>> >>>> Yours, >>>> Joel >>>> >>>> On 6/8/15 7:53 PM, Stephen Farrell wrote: >>>>> >>>>> Hi Carlos, >>>>> >>>>> Thanks for that text, which I think seems to match well with what >>>>> you and Joel have been saying. >>>>> >>>>> I have to say though that I don't find it at all convincing given >>>>> that we have bcp61. Having some mti security so that it can be >>>>> turned on when needed despite buying kit from multiple vendors is >>>>> what bcp61 calls for and I really don't see why sfc is an exception. >>>>> >>>>> A question for you - is it useful for me to try de-construct the >>>>> text below (on the above basis) or not? It may be a waste of time >>>>> and we may be better off getting additional viewpoints on this >>>>> instead. >>>>> >>>>> And in case it helps, I think the main (not the only) counter to what >>>>> you propose below is the consideration that while sfc may only be >>>>> well-defined for intradomain use now, intradomain use can in >>>>> various ways span what are now clearly important trust boundaries, >>>>> see tempora/belgacom/gemalto for examples. >>>>> >>>>> Cheers, >>>>> S. >>>>> >>>>> >>>>> On 08/06/15 02:35, Carlos Pignataro (cpignata) wrote: >>>>>> Stephen, >>>>>> >>>>>> Please find some concrete text, with a sufficiently detailed >>>>>> explanation, to anchor the discussion. >>>>>> >>>>>> Feedback? >>>>>> >>>>>> —>8— >>>>>> 6.1. SFC Data Plane Security >>>>>> >>>>>> One of the aspects to consider as part of the SFC security model is >>>>>> whether to mandate the implementation of, and strongly recommend the >>>>>> use of authentication and encryption technology within the SFC data >>>>>> plane. This architecture mandates the definition of mechanisms to >>>>>> provide confidentiality and integrity of metadata carried by the >>>>>> protocol, but makes not further recommendations. This is based on the >>>>>> unusual operating constraints. Rather than being an end-to-end >>>>>> protocol, or even a relayed protocol with a desire to reduce the >>>>>> number of relays, the goal of this protocol is to deliver data >>>>>> packets to a series of service functions. These functions are >>>>>> selected and provided by a combination of user and operator >>>>>> decisions. They are, in most cases, granted access to the data packet >>>>>> contents and the metadata. Securing the packets from the service >>>>>> functions would be counter-productive. >>>>>> >>>>>> One could argue for securing the packets as they traverse the >>>>>> underlying network. Provisions for this are already included under >>>>>> the “Service Overlay†title in this Security Considerations. In the >>>>>> general case where every hop between service functions is over >>>>>> untrusted media, that may be necessary and appropriate. However, the >>>>>> initial target is for a single administrative domain, where if there >>>>>> are any untrustued segments they will be few and well-recognized. >>>>>> Even in the general case, most transport connections will be >>>>>> sufficiently trusted so as not to warrant the cost of hop-wise >>>>>> security mechanisms over a multi-hop transport. >>>>>> >>>>>> Given the operator focus on internal use of this tool, even demanding >>>>>> implementation of such mechanisms is likely to place a cost on >>>>>> delivery that will interfere with the use of this technology. It >>>>>> should be understood that this architecture is a new model >>>>>> replacement for a multiplicity of widely used techniques, most of >>>>>> which do not even have the option of security mechanisms. >>>>>> >>>>>> This analysis leads to an expectation of a need for optional security >>>>>> techniques well-integrated with the protocol so that they can be used >>>>>> where needed, without mandating that all implementations include such >>>>>> capabilities. >>>>>> —>8— >>>>>> >>>>>> Thanks, >>>>>> >>>>>> — Carlos. >>>>>> >>>>>>> On Jun 7, 2015, at 5:38 PM, Joel M. Halpern >>>>>>> wrote: >>>>>>> >>>>>>> This sounds like something Carlos and I can try to address in >>>>>>> conjunction with the revisions. Sorry if I was slow to understand >>>>>>> the quesiton. >>>>>>> >>>>>>> Yours, >>>>>>> Joel >>>>>>> >>>>>>> On 6/7/15 5:04 PM, Stephen Farrell wrote: >>>>>>>> >>>>>>>> >>>>>>>> On 07/06/15 21:40, Joel M. Halpern wrote: >>>>>>>>> The escurity considerations section addresses, as far as we >>>>>>>>> understand >>>>>>>>> them, the issues that a "security model" needs to cover. It is >>>>>>>>> not done >>>>>>>>> as an explicit model. We could recast the section as such a >>>>>>>>> model, but >>>>>>>>> it would end up saying the same things. >>>>>>>> >>>>>>>> Well, let's see what a revised ID looks like and then haggle about >>>>>>>> that maybe. I think that'll be easier. (I note you did not say that >>>>>>>> the charter text on this is OBE btw.) >>>>>>>> >>>>>>>>> We could write more explicitly some of the other assumptions we >>>>>>>>> make, >>>>>>>>> for example that the services to which user packets are >>>>>>>>> delivered are >>>>>>>>> trusted by the operator to examine the packets and associated >>>>>>>>> metadata. >>>>>>>>> We could note that the service functions are further trusted to >>>>>>>>> modify >>>>>>>>> the packet contents and metadata. >>>>>>>>> We could add text that in most single-domain cases, the underlying >>>>>>>>> infrastructure is trusted by the operator. >>>>>>>> >>>>>>>> If your goal as authors/WG is to not have mandatory to implement >>>>>>>> security then yes you would I think need to explicitly justify that >>>>>>>> in a convincing manner. Isn't it perhaps telling us something if you >>>>>>>> chose to not explicitly say things like "trusted by the operator so >>>>>>>> no security needed" in the draft? (Seems so to me tbh.) >>>>>>>> >>>>>>>>> >>>>>>>>> Would adding text like that help? It would seem instead to >>>>>>>>> provoke the >>>>>>>>> BCP61 comment that you are now making. >>>>>>>> >>>>>>>> The BCP61 comment resulted from your proposed text ("adjunct" etc) >>>>>>>> which >>>>>>>> seems to me to run counter to that BCP. Are you arguing that such >>>>>>>> text >>>>>>>> would be consistent with BCP61? If not, then what is your >>>>>>>> argument for >>>>>>>> BCP61 not applying or being unwise in this case? >>>>>>>> >>>>>>>> Cheers, >>>>>>>> S. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Yours, >>>>>>>>> Joel >>>>>>>>> >>>>>>>>> On 6/7/15 4:34 PM, Stephen Farrell wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 07/06/15 21:31, Joel M. Halpern wrote: >>>>>>>>>>> I am not sure how to usefully respond to your concern that you >>>>>>>>>>> are not >>>>>>>>>>> convinced that security mechanisms can be adjunct or optional. >>>>>>>>>>> That >>>>>>>>>>> seems to border on opinion, rather than factual basis for a >>>>>>>>>>> discuss. >>>>>>>>>>> Further, I really do not want to end up in a situation where the >>>>>>>>>>> majority of implementations are not conformant to the >>>>>>>>>>> architecture and >>>>>>>>>>> protocol spec. >>>>>>>>>>> And it is very clear that most of the environments at least >>>>>>>>>>> for the >>>>>>>>>>> initial, single domain, case that we are targeting will not need >>>>>>>>>>> any >>>>>>>>>>> form of authentication or data integrity in the SFC mechanism. >>>>>>>>>> >>>>>>>>>> Hmm. Doesn't BCP61 directly address the above? >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Also, I realized looking at your comments and the charter, that >>>>>>>>>>> I do not >>>>>>>>>>> know know what would constitute a "security model" as you >>>>>>>>>>> understand it. >>>>>>>>>> >>>>>>>>>> Ok - what is a security model as you understand what the charter >>>>>>>>>> says about this deliverable? Since you're an author and the >>>>>>>>>> charter >>>>>>>>>> calls for that can you point me at where in the draft I find it >>>>>>>>>> or why it is no longer needed/relevant/whatever? >>>>>>>>>> >>>>>>>>>> Ta, >>>>>>>>>> S. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yours, >>>>>>>>>>> Joel >>>>>>>>>>> >>>>>>>>>>> On 6/7/15 4:15 PM, Stephen Farrell wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Carlos, >>>>>>>>>>>> >>>>>>>>>>>> Sorry for the delayed response - some more travel ensued;-( >>>>>>>>>>>> >>>>>>>>>>> ... >>>>>>>>>>>> No, sorry. For one minor and two major reasons. >>>>>>>>>>>> >>>>>>>>>>>> The first is that I want to ensure we do not end up in the >>>>>>>>>>>> various bad situations that happened in the roll and karp >>>>>>>>>>>> WGs, so a simple addition like that without any idea what is >>>>>>>>>>>> likely to really happen isn't a good plan I think. >>>>>>>>>>>> >>>>>>>>>>>> The second is that I am entirely unconvinced that any >>>>>>>>>>>> security mechanisms can be an "adjunct" or optional to >>>>>>>>>>>> implement. >>>>>>>>>>>> >>>>>>>>>>>> The minor reason is that I don't think we have gotten to >>>>>>>>>>>> the bottom of whether data integrity of data in transit >>>>>>>>>>>> is sufficient or whether data origin authentication is >>>>>>>>>>>> really needed here. (That could easily be something to be >>>>>>>>>>>> addressed later in the WG but is not something to determine >>>>>>>>>>>> now unless we do the analysis now, or describe that analysis >>>>>>>>>>>> if it has been done but not written down so far which may >>>>>>>>>>>> be the case.) >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> S. >>>>>>>>>>>> >>>>>>>>>>>> PS: I'm starting on vacation on Thursday so will try to be >>>>>>>>>>>> responsive on this in the meantime. However, we really ought >>>>>>>>>>>> keep in mind that getting the right outcome at this stage >>>>>>>>>>>> could save a lot of effort later, so I wouldn't be too focused >>>>>>>>>>>> on trying to get this document done in the next few days and >>>>>>>>>>>> I think we ought be much more focused on doing our best with >>>>>>>>>>>> ensuring that SFC doesn't hit security speedbumps later on. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> >>>>>>>>>>>>> — Carlos. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sfc mailing list >>>>>>> sfc@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>> >>>>> >>>> >> From nobody Tue Jun 9 06:55:27 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BE1B2C32 for ; Tue, 9 Jun 2015 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTXE7v5y55-d for ; Tue, 9 Jun 2015 06:55:24 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590A51B2C2C for ; Tue, 9 Jun 2015 06:55:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 40BAE24047C; Tue, 9 Jun 2015 06:55:24 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (173-163-203-241-Richmond.hfc.comcastbusiness.net [173.163.203.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id BB81F24075F; Tue, 9 Jun 2015 06:55:23 -0700 (PDT) Message-ID: <5576F038.2060400@joelhalpern.com> Date: Tue, 09 Jun 2015 09:55:04 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: mohamed.boucadair@orange.com, "sfc@ietf.org" References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:55:25 -0000 My question for the chairs is whether the issue of the document discussing SFCs or SFPs needs to be resolved before or after adoption. If the chairs consider that to be something that can be debated and resolved later, then I strongly support adoption of this document by the working group. Yours, Joel On 6/9/15 1:40 AM, mohamed.boucadair@orange.com wrote: > Dear all, > > This new version integrates the comments received from the list. > > I do think the document is ready for a WG call for adoption. > > Cheers, > Med > >> -----Message d'origine----- >> De : I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de >> internet-drafts@ietf.org >> Envoyé : mardi 9 juin 2015 07:37 >> À : i-d-announce@ietf.org >> Objet : I-D Action: draft-ww-sfc-control-plane-06.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : Service Function Chaining (SFC) Control Plane >> Components & Requirements >> Authors : Hongyu Li >> Qin Wu >> Mohamed Boucadair >> Christian Jacquenet >> Walter Haeffner >> Seungik Lee >> Ron Parker >> Linda Dunbar >> Andrew Malis >> Joel M. Halpern >> Tirumaleswar Reddy >> Prashanth Patil >> Filename : draft-ww-sfc-control-plane-06.txt >> Pages : 27 >> Date : 2015-06-08 >> >> Abstract: >> This document describes requirements for conveying information >> between Service Function Chaining (SFC) control elements (including >> management components) and SFC functional elements. Also, this >> document identifies a set of control interfaces to interact with SFC- >> aware elements to establish, maintain or recover service function >> chains. This document does not specify protocols nor extensions to >> existing protocols. >> >> This document exclusively focuses on SFC deployments that are under >> the responsibility of a single administrative entity. Inter-domain >> considerations are out of scope. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ww-sfc-control-plane-06 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > From nobody Tue Jun 9 18:00:40 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FDC1A9051; Tue, 9 Jun 2015 18:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncXQhEN_QeT8; Tue, 9 Jun 2015 18:00:34 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A8B1A904F; Tue, 9 Jun 2015 18:00:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2965; q=dns/txt; s=iport; t=1433898034; x=1435107634; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sejq7xMo9iWew/1xqHQ0tpHG88ImcyxEYlf7aOrkAYw=; b=GTj9oKKoc1f3OkT2majHj5n32CFDTidz26c2Bvi8qCA33PTPF0XWK5xm 4gS7Id33HBNhs+VgMO0zGHV49oR2nzSJ/+jKDXSi7zWbTSEJgqCmEAtNb 6e4ScC+uP4X7IVDFl6lBHpeYQmpXzTu6/EEU21bt5j4N0ydWim3CjTTll c=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BfBACxi3dV/4MNJK1cgxBUXwaDGLp5ZgmBNQcbCoV7AoFGOBQBAQEBAQEBgQqEIgEBAQECAQEBASBLCwULAgEGAhEBAwEBASoCAicLFwYIAgQOBQ6IGAgNj2CdGaQ5AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLQ4UGB4JoL4EWAQSTPoIYgUmHT5drJGKBWYE9b4FGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,584,1427760000"; d="asc'?scan'208";a="299114" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP; 10 Jun 2015 01:00:33 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5A10XmB022347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Jun 2015 01:00:33 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.166]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 9 Jun 2015 20:00:33 -0500 From: "Carlos Pignataro (cpignata)" To: Randy Presuhn Thread-Topic: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) Thread-Index: AQHQonF9UNzRkq1wJU2Wvlf+qhp5bp2lQKOA Date: Wed, 10 Jun 2015 01:00:32 +0000 Message-ID: References: <16519348.1433826151912.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> In-Reply-To: <16519348.1433826151912.JavaMail.root@mswamui-valley.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.215.199] Content-Type: multipart/signed; boundary="Apple-Mail=_68D39B61-6DA8-4D11-B4AA-879FD92B723B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: The IESG , "sfc@ietf.org" Subject: Re: [sfc] Stephen Farrell's Discuss on draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Jun 2015 01:00:36 -0000 --Apple-Mail=_68D39B61-6DA8-4D11-B4AA-879FD92B723B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Jun 9, 2015, at 1:02 AM, Randy Presuhn = wrote: >=20 > Hi - >=20 >> From: "Carlos Pignataro (cpignata)" >> Sent: Jun 8, 2015 6:45 PM >> To: "Joel M. Halpern" >> Cc: The IESG , "sfc@ietf.org" , Stephen = Farrell >> Subject: Re: [sfc] Stephen Farrell's Discuss on = draft-ietf-sfc-architecture-08: (with DISCUSS and COMMENT) > ... >> Further, BCP61 says =E2=80=9Censure that IETF standard protocols have >> the necessary features to provide appropriate security for the >> application as it may be used across the Internet=E2=80=9D =E2=80=94 = and this >> architecture is not defining an application that is used across >> the Internet. >=20 > Are you arguing that in the context of BCP61, this architecture > should be understood as an implicit applicability statement, > effectively mandating that SFC should not be used across the > Internet or across networks where eavesdropping / monitoring > is a possibility? As the SFC architecture is transport agnostic and the SFC encapsulation = can be transported over IP, the SFC encap (including metadata and = payload) can be protected by existing means. This is already covered in = the document. This would apply to for example inter-DC links. The = comment is in the context of protecting at the SFC encapsulation layer. Thank, =E2=80=94 Carlos. >=20 > Randy >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_68D39B61-6DA8-4D11-B4AA-879FD92B723B 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 iQIcBAEBCAAGBQJVd4wxAAoJEIXgpQGOZny91ZQP/3Am78ElvtFo7GdNwOss8s+b v3WP11BDLfbkiZAeRpBLMejuTra5MHxikSunVuHumreP4cR5dgjwa21GsXpJwFTj 9FJRxuCx/UfdIEZ89aV59MTSnhkOyJ57GiZxa0B5UbOytY8pRy5dsKPJyFXAlLcH GmlGKq/i16E+mWDMUyYWjos21OUbhKZ8aae8EC9hJNCGq/M8CVNuN6eCLIzZtGbm zLMigjk0ly2DiG7GOvY19MJkRDh+3CS9e5OBFafUvqlhcHjdNzS66geXycW9wmPy skpxz5GOZFoVZz8+4NfmN2cJegmq+IBSolkkdEvzyFc8f3aRcNEz+jYLxniGu16B 1UZG4ISh3WGb5S+Yn12+qlWOCp4Vg7RWRzx3jOy6sCmq18aV9Zo9/Uwg1DwfOc0s Ui+43mO6uA2bewweK8ieAQX6AR3i3X4TkZ08fI1unXajYEUP3FW4YWxyDkU291YZ IGNeIDgO3e037MO2a+sSXQ3Wb22e/dIiFLIEVk0NkVoamqfVQ14n6DP0fIO+K7Nd z5bm9xA/hbkBVePbAHG7KC20A6b4pQkuXva30x14C29QrJzsMlD+JU79a6gk80Oz kH1uf8It3/pki/6rD4jjaampqIGDMXVQzcyTJfdLjIrU+dN7OHjPcgSSvm6cfl3T srx1rkWtG1ZKbd9x0FPu =ibGz -----END PGP SIGNATURE----- --Apple-Mail=_68D39B61-6DA8-4D11-B4AA-879FD92B723B-- From nobody Fri Jun 19 08:43:23 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB791A90BE for ; Fri, 19 Jun 2015 08:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mANcUpFd7snk for ; Fri, 19 Jun 2015 08:43:20 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6F1A90BC for ; Fri, 19 Jun 2015 08:43:20 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([fe80::ac6b:cc1e:f2ff:93aa%18]) with mapi id 14.03.0195.001; Fri, 19 Jun 2015 11:43:19 -0400 From: Dave Dolson To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-dolson-sfc-hierarchical-01.txt Thread-Index: AQHQqqXHMMgO8UDE4EG+aBr/yT7iPZ2z92og Date: Fri, 19 Jun 2015 15:43:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [sfc] FW: New Version Notification for draft-dolson-sfc-hierarchical-01.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 15:43:22 -0000 V2UndmUgdGFrZW4gZmVlZGJhY2sgZnJvbSBhIGZldyBpbmRpdmlkdWFscyBhbmQgZG9uZSBzb21l IHNpZ25pZmljYW50IGVkaXRpbmcuDQpXZSBsb29rIGZvcndhcmQgdG8gZnVydGhlciBmZWVkYmFj ayBvbiB0aGlzIHN1YmplY3QuDQoNClRoYW5rcyBmb3IgYWxsIHRoZSBpbnRlcmVzdC4NCg0KDQoN CkRhdmlkIERvbHNvbg0KU2VuaW9yIFNvZnR3YXJlIEFyY2hpdGVjdCwgU2FuZHZpbmUgSW5jLg0K DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlkYXks IEp1bmUgMTksIDIwMTUgMTE6MzcgQU0NClRvOiBTaHVuc3VrZSBIb21tYTsgRGllZ28gUi4gTG9w ZXo7IERhdmUgRG9sc29uOyBEaWVnbyBMb3BlejsgRGF2ZSBEb2xzb247IFNodW5zdWtlIEhvbW1h DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWRvbHNvbi1zZmMt aGllcmFyY2hpY2FsLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1kb2xz b24tc2ZjLWhpZXJhcmNoaWNhbC0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0 ZWQgYnkgRGF2aWQgRG9sc29uIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoN Ck5hbWU6CQlkcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbA0KUmV2aXNpb246CTAxDQpUaXRs ZToJCUhpZXJhcmNoaWNhbCBTZXJ2aWNlIENoYWluaW5nDQpEb2N1bWVudCBkYXRlOgkyMDE1LTA2 LTE5DQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6CQkxMw0KVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kb2xzb24t c2ZjLWhpZXJhcmNoaWNhbC0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1kb2xzb24tc2ZjLWhpZXJhcmNoaWNhbC8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZG9sc29uLXNmYy1oaWVy YXJjaGljYWwtMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm P3VybDI9ZHJhZnQtZG9sc29uLXNmYy1oaWVyYXJjaGljYWwtMDENCg0KQWJzdHJhY3Q6DQogICBI aWVyYXJjaGljYWwgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyAoaFNGQykgaXMgYSBuZXR3b3Jr DQogICBhcmNoaXRlY3R1cmUgYWxsb3dpbmcgYW4gb3JnYW5pemF0aW9uIHRvIGNvbXBhcnRtZW50 YWxpemUgYSBsYXJnZS0NCiAgIHNjYWxlIG5ldHdvcmsgaW50byBtdWx0aXBsZSBkb21haW5zIG9m IGFkbWluaXN0cmF0aW9uLg0KDQogICBUaGUgZ29hbHMgb2YgaFNGQyBhcmUgdG8gbWFrZSBhIGxh cmdlLXNjYWxlIG5ldHdvcmsgZWFzaWVyIHRvIHJlYXNvbg0KICAgYWJvdXQsIHNpbXBsZXIgdG8g Y29udHJvbCBhbmQgdG8gc3VwcG9ydCBpbmRlcGVuZGVudCBmdW5jdGlvbmFsDQogICBncm91cHMg d2l0aGluIGxhcmdlIG9wZXJhdG9ycy4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From nobody Mon Jun 22 07:20:25 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292CA1A8AB7 for ; Mon, 22 Jun 2015 07:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vha_ar5lYpRD for ; Mon, 22 Jun 2015 07:20:20 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD21ACD44 for ; Mon, 22 Jun 2015 07:20:03 -0700 (PDT) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 22 Jun 2015 07:20:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,659,1427785200"; d="scan'208";a="512379503" Received: from orsmsx106.amr.corp.intel.com ([10.22.225.133]) by FMSMGA003.fm.intel.com with ESMTP; 22 Jun 2015 07:20:04 -0700 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX106.amr.corp.intel.com (10.22.225.133) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 22 Jun 2015 07:20:02 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.16]) by ORSMSX158.amr.corp.intel.com ([169.254.10.187]) with mapi id 14.03.0224.002; Mon, 22 Jun 2015 07:20:02 -0700 From: "Elzur, Uri" To: Joel Halpern Direct , "sfc@ietf.org" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gIAAiO2AgMOJl6A= Date: Mon, 22 Jun 2015 14:20:01 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> In-Reply-To: <54E28085.8070803@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.140] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 22 Jun 2015 14:20:24 -0000 Hi Joel I've recently reviewed the latest draft v 09. I still miss such a clarifica= tion. Pls point me in the right direction if it does exist somewhere in cha= pter 4. I'd like to suggest we add language referring to the specific example outli= ned below of SFF integrated with an overlay manager as a way to show how th= e logical elements can be implemented as part of an overlay and to clarify = we are not talking ONLY about a completely independent new Service overlay Thx Uri ("Oo-Ree") C: 949-378-7568 -----Original Message----- From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com]=20 Sent: Monday, February 16, 2015 3:43 PM To: Elzur, Uri; sfc@ietf.org Subject: Re: [sfc] clarification on SFC and Overlay interaction It seems like we can (and unless I am very confused, should) add such a sta= tement in the base portion of section 4. Carlos and I will work on this. = Thank you for calling our attention to the omission. Yours, Joel On 2/16/15 6:36 PM, Elzur, Uri wrote: > Agree. I do not recall however any such statement. I do recall many=20 > statement like section 4.5, indicating the separation and referring to =20 > topological and transport independence. Pls point me to the paragraph=20 > or we may want to add such clarification in the next rev > > Thx > > Uri ("Oo-Ree") > C: 949-378-7568 > > -----Original Message----- > From: Joel M. Halpern [mailto:jmh@joelhalpern.com] > Sent: Monday, February 16, 2015 3:24 PM > To: Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction > > If we do not have text in there that says that these logical components m= ay be combined in real world implementations or deployments with each other= or with components from outside the architecture, I could see adding that.= I thought we already said it. > > I would prefer not to add comments on any specific deployments, because t= here are so many ways to do so, and as far as I can tell, most of us think = the one in our head is the most likely / common / useful. > > Yours, > Joel > > On 2/16/15 5:36 PM, Elzur, Uri wrote: >> Joel >> >> Sounds good to me. However a clarification, maybe in the format of a=20 >> comment or example (as I suspect this may be a very common case, for >> some) in the draft will be of value >> >> Thx >> >> Uri ("Oo-Ree") >> C: 949-378-7568 >> >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, February 16, 2015 1:36 PM >> To: Elzur, Uri; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >> >> One of the key reasons for identifying the logical components is that th= ere are a broad range of ways that they can be composed. That does sound l= ike one possible composition. >> >> Yours, >> Joel >> >> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>> While section 4.5 of draft-ietf-sfc-architecture-04, states=20 >>> "underneath the SFF there are components responsible for performing=20 >>> the transport >>> (overlay) forwarding. They do not consults the SFC encapsulation or=20 >>> inner payload for performing these forwarding.", there is no reason=20 >>> to exclude the following private case, I'd assume. This is the case=20 >>> where the SFF is effectively integrated with the Overlay manager, or=20 >>> instantiated in other overlay network elements (e.g. vSwitch),=20 >>> enabling in essence SFC within an Overlay network, with no need for=20 >>> a separate SFC domain. >>> >>> To be clear (or clearer), this is not to suggest that transport or=20 >>> topological independence can be or should be bend, but simply to=20 >>> suggest a deployment scenario that may be popular for limited scale=20 >>> SFC >>> >>> Thx >>> >>> Uri ("Oo-Ree") >>> >>> C: 949-378-7568 >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >> From nobody Mon Jun 22 21:00:28 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02B31B32D1 for ; Mon, 22 Jun 2015 21:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp7uT-CEpHHQ for ; Mon, 22 Jun 2015 21:00:24 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903CF1B32D0 for ; Mon, 22 Jun 2015 21:00:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1515; q=dns/txt; s=iport; t=1435032024; x=1436241624; h=from:to:cc:subject:date:message-id:mime-version; bh=IQH7oqBWRTgBbOBTK1XWN7L4jhQaZxf8R8OoS2dkzS8=; b=kMTbiFAEnSVh/eU9+1jmp9eu4ZVnAYTKUlun803VxJyydcB0BCRSqDmx 1E5XMqekegLL1RdxLqzOusZZVEQHWOud8MZwlAkwPH2WHaNT8qg52rRCd AGdq0Nv1UoNU3uOh5LEKjzHm+QutkVJRpeX0km0jSsfqXcpkWGkKkbO+y c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DAAwBj2YhV/5JdJa1cgkVLVGW9UgmBZoV4gT84FAEBAQEBAQGBCoQZDAQdXBIBCwF0JwQOiDQNy1IBAQEBAQEBAQIBAQEBAQEBAQEVBJBLhDIFk30BhFWGeJgxJoN5gjWBAgEBAQ X-IronPort-AV: E=Sophos;i="5.13,664,1427760000"; d="scan'208,217";a="3826421" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 23 Jun 2015 04:00:23 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5N40Nd5028003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Jun 2015 04:00:23 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.112]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Mon, 22 Jun 2015 23:00:23 -0500 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: Adoption of I-D draft-kumar-sfc-offloads Thread-Index: AQHQrWkhhY/RF8QwKkybP1Fvxq7P/g== Date: Tue, 23 Jun 2015 04:00:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.78.224] Content-Type: multipart/alternative; boundary="_000_D1AE27E5345EEsmkumarciscocom_" MIME-Version: 1.0 Archived-At: Cc: Thomas Narten , "Jim Guichard \(jguichar\)" Subject: [sfc] Adoption of I-D draft-kumar-sfc-offloads X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 23 Jun 2015 04:00:27 -0000 --_000_D1AE27E5345EEsmkumarciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, I-D: https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/ We presented the offloads draft at the last two IETF WG meetings. We had a = good discussion at Honolulu based on which we updated the draft and present= ed at Dallas. We believe it is ready for WG call for adoption and request the chairs to c= all for one. Regards, Surendra. --_000_D1AE27E5345EEsmkumarciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4B74036B4237CA42B7132C44DABDEBA3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
All,

I-D: https://datatracker.ietf.org/doc/draft-kumar-sfc-offloads/

We presented the offloads draft at the last two IETF WG meetings. We h= ad a good discussion at Honolulu based on which we updated the draft and pr= esented at Dallas.
We believe it is ready for WG call for adoption and request the chairs= to call for one.

Regards,
Surendra.
--_000_D1AE27E5345EEsmkumarciscocom_-- From nobody Wed Jun 24 01:23:04 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF451B31FF for ; Wed, 24 Jun 2015 01:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUrrGWBgZkot for ; Wed, 24 Jun 2015 01:23:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF741B31FE for ; Wed, 24 Jun 2015 01:22:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BXW93180; Wed, 24 Jun 2015 08:22:58 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 24 Jun 2015 09:22:56 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.194]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Wed, 24 Jun 2015 16:22:52 +0800 From: "Huangjing (A)" To: "mohamed.boucadair@orange.com" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-06.txt Thread-Index: AQHQonZMwSPNk8u+uUmltok+dB54Lp2jp9cggBfAcCA= Date: Wed, 24 Jun 2015 08:22:52 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6741C79A@SZXEMA501-MBX.china.huawei.com> References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2015 08:23:03 -0000 Hi, Med, In section 3, the title is "SFC Control Plane Components & Interfaces", but= then in section 3.1, it says=20 "The components within the SFC Control & Management Planes and their intera= ctions are out of scope." Maybe the title should be updated Cheers James > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Tuesday, June 09, 2015 1:41 PM > To: sfc@ietf.org > Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt >=20 > Dear all, >=20 > This new version integrates the comments received from the list. >=20 > I do think the document is ready for a WG call for adoption. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part d= e > > internet-drafts@ietf.org Envoy=E9=A0: mardi 9 juin 2015 07:37 =C0=A0: > > i-d-announce@ietf.org Objet=A0: I-D Action: > > draft-ww-sfc-control-plane-06.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Service Function Chaining (SFC) Control Plane > > Components & Requirements > > Authors : Hongyu Li > > Qin Wu > > Mohamed Boucadair > > Christian Jacquenet > > Walter Haeffner > > Seungik Lee > > Ron Parker > > Linda Dunbar > > Andrew Malis > > Joel M. Halpern > > Tirumaleswar Reddy > > Prashanth Patil > > Filename : draft-ww-sfc-control-plane-06.txt > > Pages : 27 > > Date : 2015-06-08 > > > > Abstract: > > This document describes requirements for conveying information > > between Service Function Chaining (SFC) control elements (including > > management components) and SFC functional elements. Also, this > > document identifies a set of control interfaces to interact with SFC= - > > aware elements to establish, maintain or recover service function > > chains. This document does not specify protocols nor extensions to > > existing protocols. > > > > This document exclusively focuses on SFC deployments that are under > > the responsibility of a single administrative entity. Inter-domain > > considerations are out of scope. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-06 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jun 24 22:34:29 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E46A11B2F6A for ; Wed, 24 Jun 2015 22:34:27 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 B3pxyeGdZBvg for ; Wed, 24 Jun 2015 22:34:25 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4041B2F69 for ; Wed, 24 Jun 2015 22:34:25 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 4EF612ACA09; Thu, 25 Jun 2015 07:34:23 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 3482D38404E; Thu, 25 Jun 2015 07:34:23 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Thu, 25 Jun 2015 07:34:23 +0200 From: To: "Huangjing (A)" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-06.txt Thread-Index: AQHQonZMwSPNk8u+uUmltok+dB54Lp2jp9cggBfAcCCAAWKD4A== Date: Thu, 25 Jun 2015 05:34:22 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300533ACDA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <774B240D54DAB844B37EE80C2DD8E8BC6741C79A@SZXEMA501-MBX.china.huawei.com> In-Reply-To: <774B240D54DAB844B37EE80C2DD8E8BC6741C79A@SZXEMA501-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.6.25.42416 Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 05:34:28 -0000 Hi James,=20 Thank you for catching this.=20 I changed the title in my local copy to "SFC Control Plane: Reference Archi= tecture & Interfaces". Better? Cheers, Med > -----Message d'origine----- > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Huangjing (A) > Envoy=E9=A0: mercredi 24 juin 2015 10:23 > =C0=A0: BOUCADAIR Mohamed IMT/OLN > Cc=A0: sfc@ietf.org > Objet=A0: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-06.txt >=20 > Hi, Med, >=20 > In section 3, the title is "SFC Control Plane Components & Interfaces", > but then in section 3.1, it says > "The components within the SFC Control & Management Planes and their > interactions are out of scope." >=20 > Maybe the title should be updated >=20 > Cheers > James >=20 > > -----Original Message----- > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Tuesday, June 09, 2015 1:41 PM > > To: sfc@ietf.org > > Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt > > > > Dear all, > > > > This new version integrates the comments received from the list. > > > > I do think the document is ready for a WG call for adoption. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part= de > > > internet-drafts@ietf.org Envoy=E9=A0: mardi 9 juin 2015 07:37 =C0=A0: > > > i-d-announce@ietf.org Objet=A0: I-D Action: > > > draft-ww-sfc-control-plane-06.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : Service Function Chaining (SFC) Control > Plane > > > Components & Requirements > > > Authors : Hongyu Li > > > Qin Wu > > > Mohamed Boucadair > > > Christian Jacquenet > > > Walter Haeffner > > > Seungik Lee > > > Ron Parker > > > Linda Dunbar > > > Andrew Malis > > > Joel M. Halpern > > > Tirumaleswar Reddy > > > Prashanth Patil > > > Filename : draft-ww-sfc-control-plane-06.txt > > > Pages : 27 > > > Date : 2015-06-08 > > > > > > Abstract: > > > This document describes requirements for conveying information > > > between Service Function Chaining (SFC) control elements (includin= g > > > management components) and SFC functional elements. Also, this > > > document identifies a set of control interfaces to interact with > SFC- > > > aware elements to establish, maintain or recover service function > > > chains. This document does not specify protocols nor extensions t= o > > > existing protocols. > > > > > > This document exclusively focuses on SFC deployments that are unde= r > > > the responsibility of a single administrative entity. Inter-domai= n > > > considerations are out of scope. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-06 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Wed Jun 24 23:46:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E8F1B304E for ; Wed, 24 Jun 2015 23:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltzE4KSxYOUL for ; Wed, 24 Jun 2015 23:46:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639BD1A8A1E for ; Wed, 24 Jun 2015 23:46:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BUI05899; Thu, 25 Jun 2015 06:46:28 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 25 Jun 2015 07:46:27 +0100 Received: from SZXEMA501-MBX.china.huawei.com ([169.254.1.194]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0158.001; Thu, 25 Jun 2015 14:46:23 +0800 From: "Huangjing (A)" To: "mohamed.boucadair@orange.com" Thread-Topic: I-D Action: draft-ww-sfc-control-plane-06.txt Thread-Index: AQHQonZMwSPNk8u+uUmltok+dB54Lp2jp9cggBfAcCCAAWKD4IAAFWSQ Date: Thu, 25 Jun 2015 06:46:22 +0000 Message-ID: <774B240D54DAB844B37EE80C2DD8E8BC6741D9D4@SZXEMA501-MBX.china.huawei.com> References: <20150609053640.8097.3298.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B9330053333B4@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <774B240D54DAB844B37EE80C2DD8E8BC6741C79A@SZXEMA501-MBX.china.huawei.com> <787AE7BB302AE849A7480A190F8B93300533ACDA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93300533ACDA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.116.136] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "sfc@ietf.org" Subject: Re: [sfc] I-D Action: draft-ww-sfc-control-plane-06.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2015 06:46:33 -0000 Hi, Med, Yes, it is better now. Cheers James > -----Original Message----- > From: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Sent: Thursday, June 25, 2015 1:34 PM > To: Huangjing (A) > Cc: sfc@ietf.org > Subject: RE: I-D Action: draft-ww-sfc-control-plane-06.txt >=20 > Hi James, >=20 > Thank you for catching this. >=20 > I changed the title in my local copy to "SFC Control Plane: Reference > Architecture & Interfaces". Better? >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: sfc [mailto:sfc-bounces@ietf.org] De la part de Huangjing (A) > > Envoy=E9=A0: mercredi 24 juin 2015 10:23 =C0=A0: BOUCADAIR Mohamed IMT/= OLN > Cc > > : sfc@ietf.org Objet=A0: Re: [sfc] I-D Action: > > draft-ww-sfc-control-plane-06.txt > > > > Hi, Med, > > > > In section 3, the title is "SFC Control Plane Components & > > Interfaces", but then in section 3.1, it says "The components within > > the SFC Control & Management Planes and their interactions are out of > > scope." > > > > Maybe the title should be updated > > > > Cheers > > James > > > > > -----Original Message----- > > > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of > > > mohamed.boucadair@orange.com > > > Sent: Tuesday, June 09, 2015 1:41 PM > > > To: sfc@ietf.org > > > Subject: [sfc] TR: I-D Action: draft-ww-sfc-control-plane-06.txt > > > > > > Dear all, > > > > > > This new version integrates the comments received from the list. > > > > > > I do think the document is ready for a WG call for adoption. > > > > > > Cheers, > > > Med > > > > > > > -----Message d'origine----- > > > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la > > > > part de internet-drafts@ietf.org Envoy=E9=A0: mardi 9 juin 2015 07:= 37 =C0=A0: > > > > i-d-announce@ietf.org Objet=A0: I-D Action: > > > > draft-ww-sfc-control-plane-06.txt > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > > directories. > > > > > > > > > > > > Title : Service Function Chaining (SFC) Control > > Plane > > > > Components & Requirements > > > > Authors : Hongyu Li > > > > Qin Wu > > > > Mohamed Boucadair > > > > Christian Jacquenet > > > > Walter Haeffner > > > > Seungik Lee > > > > Ron Parker > > > > Linda Dunbar > > > > Andrew Malis > > > > Joel M. Halpern > > > > Tirumaleswar Reddy > > > > Prashanth Patil > > > > Filename : draft-ww-sfc-control-plane-06.txt > > > > Pages : 27 > > > > Date : 2015-06-08 > > > > > > > > Abstract: > > > > This document describes requirements for conveying information > > > > between Service Function Chaining (SFC) control elements (includ= ing > > > > management components) and SFC functional elements. Also, this > > > > document identifies a set of control interfaces to interact > > > > with > > SFC- > > > > aware elements to establish, maintain or recover service functio= n > > > > chains. This document does not specify protocols nor extensions= to > > > > existing protocols. > > > > > > > > This document exclusively focuses on SFC deployments that are un= der > > > > the responsibility of a single administrative entity. Inter-dom= ain > > > > considerations are out of scope. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > > https://datatracker.ietf.org/doc/draft-ww-sfc-control-plane/ > > > > > > > > There's also a htmlized version available at: > > > > https://tools.ietf.org/html/draft-ww-sfc-control-plane-06 > > > > > > > > A diff from the previous version is available at: > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ww-sfc-control-plane-06 > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > > submission until the htmlized version and diff are available at > > > > tools.ietf.org. > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > _______________________________________________ > > > > I-D-Announce mailing list > > > > I-D-Announce@ietf.org > > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > _______________________________________________ > > > sfc mailing list > > > sfc@ietf.org > > > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > > sfc mailing list > > sfc@ietf.org > > https://www.ietf.org/mailman/listinfo/sfc From nobody Fri Jun 26 08:15:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC57D1B2D08; Thu, 25 Jun 2015 16:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.001, MIME_QP_LONG_LINE=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 YHep7wOhqKo3; Thu, 25 Jun 2015 16:43:42 -0700 (PDT) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E081B2D05; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) Received: by padev16 with SMTP id ev16so58038595pad.0; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=b45Eok58qtbYvm5jmXNHl33E1D/lK8NHJ4p489jRVkM=; b=znOB1BzNsZOtFApeu9xmjRsuFUzIkotVICWe7yep/3OQ/ESx3d1KPkBFi9L9CRVmSA Myg61BKXEqa1BCzmvcZ4YhZ5cWdYUMvV5ZWjSR6KvR90ol3wXjpnBH2XC4d6FgV9JetJ O7ae9PR01Etl5KuhjIn3IbhH/pRKqsZV0uiAdRavNIUPKNaELKtSeMsI6zUAcM1rJL/e WOSaMlw7/0opKeuukQrdgvq9COGYbxxxcHsj23RSbsRQotT0YkpbAZCheCvVlP/VI5EM Tzw/TGRHE4Q5VsguLBFQ4Yhg47StKboWzKEbJuwBgJnq8tTHWGeFZyIPJSNypE6Y6cw6 bBlw== X-Received: by 10.66.119.136 with SMTP id ku8mr224953pab.93.1435275821599; Thu, 25 Jun 2015 16:43:41 -0700 (PDT) Received: from [128.107.125.67] (dhcp-128-107-125-67.cisco.com. [128.107.125.67]) by mx.google.com with ESMTPSA id fr2sm31240768pdb.22.2015.06.25.16.43.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 25 Jun 2015 16:43:39 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.5.2.150604 Date: Thu, 25 Jun 2015 16:43:31 -0700 From: alagalah To: , , , "groupbasedpolicy-dev@lists.opendaylight.org" , opendaylight sfc Message-ID: Thread-Topic: IETF 93 Prague Hackathon - OpenDaylight GroupBasedPolicy and ServiceFunctionChaining Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3518095418_12881009" Archived-At: X-Mailman-Approved-At: Fri, 26 Jun 2015 08:15:36 -0700 Subject: [sfc] IETF 93 Prague Hackathon - OpenDaylight GroupBasedPolicy and ServiceFunctionChaining X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 25 Jun 2015 23:43:43 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3518095418_12881009 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We are excited to welcome you to participate in, and are honored to be able to offer, our portion of the IETF 93 =AD Prague Hackathon, Jul 18-19. Our proposed ideas for the event are: https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP)/Hackathons/IETF= P rague15 You can register at the link above or directly at: https://www.ietf.org/hackathon/93-hackathon.html You can find out more about GroupBasedPolicy (GBP) and ServiceFunctionChaining (SFC) at our respective OpenDaylight project wikis. https://wiki.opendaylight.org/view/Group_Based_Policy_(GBP) https://wiki.opendaylight.org/view/Service_Function_Chaining:Main We hope to see you there! --B_3518095418_12881009 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
We are excited to wel= come you to participate in, and are honored to be able to offer, our portion= of the IETF 93 – Prague Hackathon, Jul 18-19.

Our proposed ideas for the event are:


You ca= n find out more about GroupBasedPolicy (GBP) and ServiceFunctionChaining (SF= C) at our respective OpenDaylight project wikis.


We hope to see you there!
--B_3518095418_12881009-- From nobody Sat Jun 27 07:58:15 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F5D1B2A10 for ; Sat, 27 Jun 2015 07:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEUlZdDv2vhb for ; Sat, 27 Jun 2015 07:58:12 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFFD1B29F5 for ; Sat, 27 Jun 2015 07:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2647; q=dns/txt; s=iport; t=1435417092; x=1436626692; h=from:to:subject:date:message-id:mime-version; bh=E75PJu665mwXl1ORfOoyjDmtCJB4bV0w5SACrLZbFo0=; b=QnNeIyPUT2fYczjbGODzxPOQx8FEtBVFXGJAznykGYdcWeozW8aKZxY4 LS2Dt+rgvCnQ0SV9tDE82b132dOLHROXE3rg9noiB4r2+8TwlEJeGLnZe YjEpQwics072qI3t4PrUBCmCU39KCffjVCwfYQiTFlu550NCNglcNnZkZ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CrAwChuI5V/4QNJK1bgkVMgTm9IwmJCTgUAQEBAQEBAYEKhCmBCwEMAXMnBIhCqQClZQELII93hQsFlAQBi1SBOoQRknAmY4MXgXJDgQIBAQE X-IronPort-AV: E=Sophos;i="5.13,689,1427760000"; d="scan'208,217";a="163490110" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP; 27 Jun 2015 14:58:11 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t5REwBVt031536 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 27 Jun 2015 14:58:11 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Sat, 27 Jun 2015 09:58:11 -0500 From: "Jim Guichard (jguichar)" To: "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYg== Date: Sat, 27 Jun 2015 14:58:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_D1B4325F13358jguicharciscocom_" MIME-Version: 1.0 Archived-At: Subject: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 27 Jun 2015 14:58:14 -0000 --_000_D1B4325F13358jguicharciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content =96 for example: * Does the document have useful content that should be moved into anoth= er WG document or progress on its own merit * Does the content have a good basis for one of the WG documents per th= e charter * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_D1B4325F13358jguicharciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Greetings WG:

Our meeting in Prague is fast approaching. As always the goal of the m= eeting will be to make the best use of our limited face-to-face time. With = that in mind we welcome requests for agenda time. 

As we build the meeting agenda our goal will be to select presentation= s that best further the work of the WG, and that generally means focusing o= n key charter deliverables and topics with important open issues to resolve= . When making a request please consider what you think the WG should do with its content =96 for example:
  • Does the document have useful content that should be moved into another= WG document or progress on its own merit
  • Does the content have a g= ood basis for one of the WG documents per the charter
  • Should the do= cument content be merged with one or more other documents, so that a combin= ed document could become a WG document
Jim & Thomas
--_000_D1B4325F13358jguicharciscocom_-- From nobody Mon Jun 29 08:39:15 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7181ACE20 for ; Mon, 29 Jun 2015 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nHEcCGMW6eE for ; Mon, 29 Jun 2015 08:39:12 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 808091ACE1C for ; Mon, 29 Jun 2015 08:39:12 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 11:39:11 -0400 From: Dave Dolson To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3Dn/yA Date: Mon, 29 Jun 2015 15:39:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.200.63] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830C56CD7wtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 29 Jun 2015 15:39:15 -0000 --_000_E8355113905631478EFF04F5AA706E9830C56CD7wtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, After the interest in Dallas, I got together a number of authors to help wi= th a new draft: draft-dolson-sfc-hierarchical. May I have a slot to present it? I'd like some advice on how it fits in the charter. I think it impacts Arch= itecture and Control Plane Mechanisms. I have interest (and authorship) from several service providers. -Dave From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, June 27, 2015 10:58 AM To: sfc@ietf.org Subject: [sfc] SFC WG agenda slots - Prague Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content - for example: * Does the document have useful content that should be moved into anoth= er WG document or progress on its own merit * Does the content have a good basis for one of the WG documents per th= e charter * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_E8355113905631478EFF04F5AA706E9830C56CD7wtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

After the interest in Dal= las, I got together a number of authors to help with a new draft: draft-dol= son-sfc-hierarchical.

 <= /p>

May I have a slot to pres= ent it?

 <= /p>

I’d like some advic= e on how it fits in the charter. I think it impacts Architecture and Contro= l Plane Mechanisms.

I have interest (and auth= orship) from several service providers.

 <= /p>

 <= /p>

-Dave

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, June 27, 2015 10:58 AM
To: sfc@ietf.org
Subject: [sfc] SFC WG agenda slots - Prague

 

Greetings WG:

 

Our meeting in Prague is fa= st approaching. As always the goal of the meeting will be to make the best = use of our limited face-to-face time. With that in mind we welcome requests for agenda time. 

 

As we build the meeting age= nda our goal will be to select presentations that best further the work of = the WG, and that generally means focusing on key charter deliverables and topics with important open issues to resolve. When making= a request please consider what you think the WG should do with its content= – for example:

  • Does the document have useful content that should be moved int= o another WG document or progress on its own merit
    • Does the content have a good basis for one of the WG documents= per the charter
  • Should the document content be merged with one or more other d= ocuments, so that a combined document could become a WG document=

Jim & Thomas=

--_000_E8355113905631478EFF04F5AA706E9830C56CD7wtlexchp2sandvi_-- From nobody Mon Jun 29 09:09:35 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32011ACEDE for ; Mon, 29 Jun 2015 09:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fud6oShenEIY for ; Mon, 29 Jun 2015 09:09:31 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by ietfa.amsl.com (Postfix) with ESMTP id 079321AD04E for ; Mon, 29 Jun 2015 09:09:30 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP; 29 Jun 2015 09:09:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,699,1427785200"; d="scan'208,217";a="736989351" Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2015 09:09:27 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.16]) by ORSMSX102.amr.corp.intel.com ([169.254.1.15]) with mapi id 14.03.0224.002; Mon, 29 Jun 2015 09:09:27 -0700 From: "Elzur, Uri" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3DqgJQ Date: Mon, 29 Jun 2015 16:09:26 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581CA6AB2@ORSMSX114.amr.corp.intel.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.22.254.138] Content-Type: multipart/alternative; boundary="_000_7E05C330D7FD6D4FAD0728C46B89958581CA6AB2ORSMSX114amrcor_" MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 29 Jun 2015 16:09:34 -0000 --_000_7E05C330D7FD6D4FAD0728C46B89958581CA6AB2ORSMSX114amrcor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Jim Pla allocate some time for NSH update Thx Uri ("Oo-Ree") C: 949-378-7568 From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Saturday, June 27, 2015 7:58 AM To: sfc@ietf.org Subject: [sfc] SFC WG agenda slots - Prague Greetings WG: Our meeting in Prague is fast approaching. As always the goal of the meetin= g will be to make the best use of our limited face-to-face time. With that = in mind we welcome requests for agenda time. As we build the meeting agenda our goal will be to select presentations tha= t best further the work of the WG, and that generally means focusing on key= charter deliverables and topics with important open issues to resolve. Whe= n making a request please consider what you think the WG should do with its= content - for example: * Does the document have useful content that should be moved into anoth= er WG document or progress on its own merit * Does the content have a good basis for one of the WG documents per th= e charter * Should the document content be merged with one or more other document= s, so that a combined document could become a WG document Jim & Thomas --_000_7E05C330D7FD6D4FAD0728C46B89958581CA6AB2ORSMSX114amrcor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI Jim

 

Pla allocate some time for NSH update=

 

Thx

 

Uri (“Oo-Ree”)=

C: 949-378-7568

 

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Jim Guichard (jguichar)
Sent: Saturday, June 27, 2015 7:58 AM
To: sfc@ietf.org
Subject: [sfc] SFC WG agenda slots - Prague

 

Greetings WG:

 

Our meeting in Prague is fast approachi= ng. As always the goal of the meeting will be to make the best use of our l= imited face-to-face time. With that in mind we welcome requests for agenda time. 

 

As we build the meeting agenda our goal= will be to select presentations that best further the work of the WG, and = that generally means focusing on key charter deliverables and topics with important open issues to resolve. When making a request pl= ease consider what you think the WG should do with its content – for = example:

  • Does the document have useful content that should be moved into another WG= document or progress on its own merit
  • Does the content have a good basis for one of the WG documents per the cha= rter
  • Should the document content be merged with one or more other documents, so= that a combined document could become a WG document
    • =

Jim & Thomas

--_000_7E05C330D7FD6D4FAD0728C46B89958581CA6AB2ORSMSX114amrcor_-- From nobody Mon Jun 29 12:51:17 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DBF1B2DF2 for ; Mon, 29 Jun 2015 12:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WB7wgEwauP86 for ; Mon, 29 Jun 2015 12:51:14 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812F11B2E4B for ; Mon, 29 Jun 2015 12:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6707; q=dns/txt; s=iport; t=1435607447; x=1436817047; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YJwqN7ZqMy1AY+zMDz3uaR67bZgs3kJeMI0b52k/E/g=; b=Xprdt92P1F7Y49GQiqDxHiwZ0EeYibJOLBAiXCigyYuwSsutDrJe8gcg LwjPL7DuyP6nFNwOO5IgkiWKAOGbpHML8plz5lPt55ZIaHt3mp2zFa4pW 5VZwviB5lJJLm1U3DOBCIP38I4zjUZ+fTGj9pMlcqLc/4FHTNYqUMEQxr k=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CyAwBVoJFV/40NJK1YA4MRVF8Ggxi6DgmBXAqFeAKBPzgUAQEBAQEBAYEKhCIBAQEDAQEBASAERwsFBwQCAQgRAQMBAQEnAwICJwsUAwYIAgQOBQ6IGQgNswmWQQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qELUkQBwYLglcvgRQFhRyOaAGCJIFQhUCCIJg7JmOBKRyBUm+BA0OBAgEBAQ X-IronPort-AV: E=Sophos;i="5.15,372,1432598400"; d="asc'?scan'208";a="164028200" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jun 2015 19:50:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t5TJokW6030497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jun 2015 19:50:46 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.112]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 14:50:46 -0500 From: "Carlos Pignataro (cpignata)" To: "Elzur, Uri" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gIAAiO2AgMOJl6CADQlKAA== Date: Mon, 29 Jun 2015 19:50:45 +0000 Message-ID: <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.55.109] Content-Type: multipart/signed; boundary="Apple-Mail=_A4407992-5D82-4F25-A1FF-3F0D48762FD4"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 29 Jun 2015 19:51:16 -0000 --Apple-Mail=_A4407992-5D82-4F25-A1FF-3F0D48762FD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Uri, I added the following text at the beginning of Section 4: =E2=80=9CWhile = this architecture describes functionally distinct logical components, = they could combined in various ways in deployed products.=E2=80=9D I think this covers all potential cases, instead of singling out one = example. The Section now starts like this: --->8--- The SFC Architecture is built out of architectural building blocks which are logical components; these logical components are classifiers, service function forwarders (SFF), the service functions themselves (SF), and SFC-proxies. While this architecture describes functionally distinct logical components, they could combined in various ways in deployed products. They are interconnected using the SFC Encapsulation. This results in a high level logical architecture of an SFC-enabled Domain which comprises: --->8--- Does this help? Thanks, =E2=80=94 Carlos. > On Jun 22, 2015, at 10:20 AM, Elzur, Uri wrote: >=20 > Hi Joel >=20 > I've recently reviewed the latest draft v 09. I still miss such a = clarification. Pls point me in the right direction if it does exist = somewhere in chapter 4. >=20 > I'd like to suggest we add language referring to the specific example = outlined below of SFF integrated with an overlay manager as a way to = show how the logical elements can be implemented as part of an overlay = and to clarify we are not talking ONLY about a completely independent = new Service overlay >=20 > Thx >=20 > Uri ("Oo-Ree") > C: 949-378-7568 >=20 > -----Original Message----- > From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] > Sent: Monday, February 16, 2015 3:43 PM > To: Elzur, Uri; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction >=20 > It seems like we can (and unless I am very confused, should) add such = a statement in the base portion of section 4. Carlos and I will work on = this. Thank you for calling our attention to the omission. >=20 > Yours, > Joel >=20 > On 2/16/15 6:36 PM, Elzur, Uri wrote: >> Agree. I do not recall however any such statement. I do recall many >> statement like section 4.5, indicating the separation and referring = to >> topological and transport independence. Pls point me to the paragraph >> or we may want to add such clarification in the next rev >>=20 >> Thx >>=20 >> Uri ("Oo-Ree") >> C: 949-378-7568 >>=20 >> -----Original Message----- >> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >> Sent: Monday, February 16, 2015 3:24 PM >> To: Elzur, Uri; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>=20 >> If we do not have text in there that says that these logical = components may be combined in real world implementations or deployments = with each other or with components from outside the architecture, I = could see adding that. I thought we already said it. >>=20 >> I would prefer not to add comments on any specific deployments, = because there are so many ways to do so, and as far as I can tell, most = of us think the one in our head is the most likely / common / useful. >>=20 >> Yours, >> Joel >>=20 >> On 2/16/15 5:36 PM, Elzur, Uri wrote: >>> Joel >>>=20 >>> Sounds good to me. However a clarification, maybe in the format of a >>> comment or example (as I suspect this may be a very common case, for >>> some) in the draft will be of value >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>>=20 >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Monday, February 16, 2015 1:36 PM >>> To: Elzur, Uri; sfc@ietf.org >>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>=20 >>> One of the key reasons for identifying the logical components is = that there are a broad range of ways that they can be composed. That = does sound like one possible composition. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>>> While section 4.5 of draft-ietf-sfc-architecture-04, states >>>> "underneath the SFF there are components responsible for performing >>>> the transport >>>> (overlay) forwarding. They do not consults the SFC encapsulation or >>>> inner payload for performing these forwarding.", there is no reason >>>> to exclude the following private case, I'd assume. This is the case >>>> where the SFF is effectively integrated with the Overlay manager, = or >>>> instantiated in other overlay network elements (e.g. vSwitch), >>>> enabling in essence SFC within an Overlay network, with no need for >>>> a separate SFC domain. >>>>=20 >>>> To be clear (or clearer), this is not to suggest that transport or >>>> topological independence can be or should be bend, but simply to >>>> suggest a deployment scenario that may be popular for limited scale >>>> SFC >>>>=20 >>>> Thx >>>>=20 >>>> Uri ("Oo-Ree") >>>>=20 >>>> C: 949-378-7568 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>>=20 >>>=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_A4407992-5D82-4F25-A1FF-3F0D48762FD4 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 iQIcBAEBCAAGBQJVkaGUAAoJEIXgpQGOZny9RREP/3JWTfwVa1yAZ/tCUSvLWudD n5329QSIvoBivH4dli65IU3zY0XAzL8HLDCF2dsOGBhDR1JCnptYy0wHv0/fIOTy Id3qdb8WC/QPPZb29uvFuFftmzzKVJHxmyg8CrAITn+NkSpa3K6jC/YjMhoIidLj qZ/TJu0FFtDBxaf7Eq6P/JZvXVVuN1OMpPSltoQPsAtMjJ/LrJzH+NEZk+w+mneh Ixe6rTYZqtxu2PaZhDBroNexzI38bEtZmXQoIlcqSyFCS9bInJuzExs9OwGnFsYG mDSTQvbBaCs9Qg8p1BN+VGRei0XB+eJC24OY97DCh9l3p6rfAmlg9anCstx0hud3 YMuYdS12YvZVKFgN67hANYNAhFPSN/AJfbWNjiQp8tRRo86py0Yy1l++fglYI0cb i9KhUpN/de1/+whezZQYkDzcANT7ITt2fPoWKIVkRSx1BU273Syu/prWlSzHa94S /XWeK8exVGfByQe9XSos3rFs8b2LnZO2FAb7Z/+vdq2aS6Ah6gZAAVSabtGtfRcf 0zxJQQNDbkC3Meo+eDcGlYrrTmi1NaXybV/QZrL6yYyGzC1GCYrN9Po8/FCf/Z+u nAUmcLK+7xQsZg2HF6tW8R5FF1KCMeqNEf9iYISnwkQiYNBoCVTS0Nk2BODNfPWn M4dvz2xhyUjSlKihT/m+ =a5/k -----END PGP SIGNATURE----- --Apple-Mail=_A4407992-5D82-4F25-A1FF-3F0D48762FD4-- From nobody Mon Jun 29 19:05:33 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43291ACE8B for ; Mon, 29 Jun 2015 19:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgeWhfNb0DXP for ; Mon, 29 Jun 2015 19:05:31 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC93E1A9232 for ; Mon, 29 Jun 2015 19:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3785; q=dns/txt; s=iport; t=1435629930; x=1436839530; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1xlcP3C5cNb46YIX7WfP1iQRK4UsqQhqV60De/qz/f8=; b=i0v6mE1uda6mDqka0uuNl1O1tqBTtyFaAFVLAHcV5s1AGRMPvXiUP/Tw C/LDKoglVDQQhyFqhSf+zNqVGb/VJ0WWd98Q7JztT6aNLmhQIQTJBukZB ByBekH4seIAg8WX7CX2GL4A23mXd9r4zgTon8wYU4AzEijGSBFkN+jbnk E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CpAwC4+JFV/5FdJa1bgxFUXwa9KgmBXQyFdgKBQzgUAQEBAQEBAYEKhCMBAQQBAQE3LQcbAgEIGB4QJwslAgQBEogvDconAQEBAQEBAQEBAQEBAQEBAQEBGotKhQ2EKwWMEodyAYRYhnyBOkKDT48Tg10mY4MXb4FGgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,374,1432598400"; d="scan'208";a="5712890" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jun 2015 02:05:29 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t5U25ThT026267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 02:05:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.76]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0195.001; Mon, 29 Jun 2015 21:05:29 -0500 From: "Larry Kreeger (kreeger)" To: Jeff Tantsura , "sfc@ietf.org" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAAOsBAIAAj+yAgAAsEQD//8akAIAG1heAgADREICAADuJAIAhihCAgEBxs4A= Date: Tue, 30 Jun 2015 02:05:28 +0000 Message-ID: References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.155.165.63] Content-Type: text/plain; charset="us-ascii" Content-ID: <9B95158A6A88E846810B01CC6D612B3A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sfc] NSH and UDP Transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 02:05:32 -0000 Following up on this, we would like to have a slot in Prague (somewhere) to present this draft. Jeff, Can we get on the agenda in RTGWG for this? Is there someone beside you that we should make this request to? Thanks, Larry On 5/19/15, 6:58 PM, "Surendra Kumar (smkumar)" wrote: >Dear Chairs, > >We submitted the draft on UDP transport for NSH (below) >Although we strongly believe it belongs in SFC, we would be happy to >present it in RTGWG or NVO3 as suggested by Jeff and Benson. > >Also, appreciate your consideration in getting a slot for this at Prague. > >Thanks, >Surendra. > >------- >A new version of I-D, draft-kumar-sfc-nsh-udp-transport-00.txt >has been successfully submitted by Surendra Kumar and posted to the >IETF repository. > >Name: draft-kumar-sfc-nsh-udp-transport >Revision: 00 >Title: UDP Overlay Transport For Network Service Header >Document date: 2015-05-16 >Group: Individual Submission >Pages: 9 >URL: =20 >https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-udp-transport-00. >t >xt >Status: =20 >https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/ >Htmlized: =20 >https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00 > > >Abstract: > This draft describes the transport encapsulation to carry Network > Service Header (NSH) over UDP protocol. This enables applications > and services using NSH to communicate over a simple layer-3 network > without topological constraints. It brings down the barrier to > implement overlay transports by not requiring additional overhead as > is typical of overlay mechanisms designed on top of UDP. > > As a first benefit, this method eases the deployment of Service > Function Chaining (SFC) by allowing SFC components to utilize the > basic UDP/IP stack available in virtually all network elements and > end systems to setup the overlays and realize SFCs. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat >------ > > >On 4/28/15, 10:47 AM, "Surendra Kumar (smkumar)" >wrote: > >>Thanks Benson, Larry! >> >>I will produce a draft for both the UDP port# and the ether-type and >>publish it within SFC WG based on the comments so far. >>The chairs can move it to the appropriate WG if they think otherwise. >> >>Surendra. >> >>On 4/28/15, 12:14 AM, "Benson Schliesser" wrote: >> >>>Hi, Larry and Jim - >>> >>>Larry Kreeger (kreeger) wrote: >>>> If someone wanted to write a draft specifying how to carry NSH over >>>> UDP, what WG would it be submitted to? >>> >>>As you probably know, NVO3 WG has adopted VXLAN-GPE which is an example >>>of a NSH-capable transport. I think this is a good example of what Jim >>>described as a "relevant WG for a given transport". >>> >>>But in the case of NSH carried directly in UDP, it seems to me that (as >>>Larry described) this is normally described in the protocol document >>>itself. Since NSH is intentionally flexible with regards to underlying >>>transport, I can imagine this being a companion document rather than >>>embedded in the NSH text. But in either case I think it makes the most >>>sense for the SFC WG to be the home for such a definition. >>> >>>Cheers, >>>-Benson >>> >>>_______________________________________________ >>>sfc mailing list >>>sfc@ietf.org >>>https://www.ietf.org/mailman/listinfo/sfc >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > From nobody Mon Jun 29 21:24:00 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84351B3064; Mon, 29 Jun 2015 21:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tNXuOZVHAQyn; Mon, 29 Jun 2015 21:23:54 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 243C11B308E; Mon, 29 Jun 2015 21:23:54 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-76-5591b2f36ee7 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.F4.07675.3F2B1955; Mon, 29 Jun 2015 23:04:51 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Tue, 30 Jun 2015 00:23:52 -0400 From: Jeff Tantsura To: "Larry Kreeger (kreeger)" Thread-Topic: [sfc] NSH and UDP Transport Thread-Index: AQHQe74agcJBg800a02J8OlwrEXysJ1W4pSAgAJq3YCAANo+AIAAj+yAgAAsEQCAAAm1gIAHCGGAgABbtYCAALDhAIAhihIAgEBxoAD//+OdHg== Date: Tue, 30 Jun 2015 04:23:52 +0000 Message-ID: <01A91F3E-8CA6-4E30-AFA6-C0AE2A043B54@ericsson.com> References: <55358DFD.2040804@joelhalpern.com> <5538F7F6.9070502@joelhalpern.com> <553F334D.2050907@queuefull.net> , 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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyuXSPt+7nTRNDDe5fELdY8GYxi8XNgzOZ LC68+c1s8eTBVnYHFo8pvzeyeixZ8pPJ48vlz2wBzFFcNimpOZllqUX6dglcGRN2tzEXzFas eNi+k72B8ZJUFyMnh4SAicTilYvZIGwxiQv31gPZXBxCAkcZJY5sOwyWEBJYDuS8TgOx2QQM JP5/O84CYosIGEq0Xr/OBNLALNDMKLH42XlmkISwgIbEwasz2bsYOYCKNCW+depA1NdJrP7x A6yXRUBV4ualiawgNq+AvcTE6UfYIRb/YJb4dnQjI0iCE2jZyfsP2EFsRqDrvp9awwRiMwuI S9x6Mp8J4moBiSV7IPZKCIhKvHz8jxWiRkdiwe5PbBC2tsSyha+ZIZYJSpyc+YRlAqPoLCSj ZiFpmYWkZRaSlgWMLKsYOUqLU8ty040MNzECo+WYBJvjDsYFnywPMQpwMCrx8C5onxgqxJpY VlyZe4hRmoNFSZxX2i8vVEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjdpb3OwQ9mMTmyDo7 zZh4Pcb99o19izzsfap2Jim3VHswtNS+8s4vVLmdZWgtrL/t33STg343AtMmyVnMFwp3DmsJ V/sV3ponMGPC3vIpL1fq64XrBe29o5BuYqmsytqsFnCpZl3Dwvuiho4LbSfvW3terMqlo6cp mv8D+1WtX60OvWmCS5RYijMSDbWYi4oTAbYmz9h3AgAA Archived-At: Cc: "rtgwg-chairs@tools.ietf.org" , "sfc@ietf.org" , "rtgwg@ietf.org" Subject: Re: [sfc] NSH and UDP Transport X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 04:23:58 -0000 Hi Larry, Noted, 10 minutes slot has been reserved for you. Regards, Jeff > On Jun 29, 2015, at 7:05 PM, Larry Kreeger (kreeger) = wrote: >=20 > Following up on this, we would like to have a slot in Prague (somewhere) > to present this draft. >=20 > Jeff, >=20 > Can we get on the agenda in RTGWG for this? Is there someone beside you > that we should make this request to? >=20 > Thanks, Larry >=20 >> On 5/19/15, 6:58 PM, "Surendra Kumar (smkumar)" wrot= e: >>=20 >> Dear Chairs, >>=20 >> We submitted the draft on UDP transport for NSH (below) >> Although we strongly believe it belongs in SFC, we would be happy to >> present it in RTGWG or NVO3 as suggested by Jeff and Benson. >>=20 >> Also, appreciate your consideration in getting a slot for this at Prague= . >>=20 >> Thanks, >> Surendra. >>=20 >> ------- >> A new version of I-D, draft-kumar-sfc-nsh-udp-transport-00.txt >> has been successfully submitted by Surendra Kumar and posted to the >> IETF repository. >>=20 >> Name: draft-kumar-sfc-nsh-udp-transport >> Revision: 00 >> Title: UDP Overlay Transport For Network Service Header >> Document date: 2015-05-16 >> Group: Individual Submission >> Pages: 9 >> URL: =20 >> https://www.ietf.org/internet-drafts/draft-kumar-sfc-nsh-udp-transport-0= 0. >> t >> xt >> Status: =20 >> https://datatracker.ietf.org/doc/draft-kumar-sfc-nsh-udp-transport/ >> Htmlized: =20 >> https://tools.ietf.org/html/draft-kumar-sfc-nsh-udp-transport-00 >>=20 >>=20 >> Abstract: >> This draft describes the transport encapsulation to carry Network >> Service Header (NSH) over UDP protocol. This enables applications >> and services using NSH to communicate over a simple layer-3 network >> without topological constraints. It brings down the barrier to >> implement overlay transports by not requiring additional overhead as >> is typical of overlay mechanisms designed on top of UDP. >>=20 >> As a first benefit, this method eases the deployment of Service >> Function Chaining (SFC) by allowing SFC components to utilize the >> basic UDP/IP stack available in virtually all network elements and >> end systems to setup the overlays and realize SFCs. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> The IETF Secretariat >> ------ >>=20 >>=20 >> On 4/28/15, 10:47 AM, "Surendra Kumar (smkumar)" >> wrote: >>=20 >>> Thanks Benson, Larry! >>>=20 >>> I will produce a draft for both the UDP port# and the ether-type and >>> publish it within SFC WG based on the comments so far. >>> The chairs can move it to the appropriate WG if they think otherwise. >>>=20 >>> Surendra. >>>=20 >>>> On 4/28/15, 12:14 AM, "Benson Schliesser" wrot= e: >>>>=20 >>>> Hi, Larry and Jim - >>>>=20 >>>> Larry Kreeger (kreeger) wrote: >>>>> If someone wanted to write a draft specifying how to carry NSH over >>>>> UDP, what WG would it be submitted to? >>>>=20 >>>> As you probably know, NVO3 WG has adopted VXLAN-GPE which is an exampl= e >>>> of a NSH-capable transport. I think this is a good example of what Jim >>>> described as a "relevant WG for a given transport". >>>>=20 >>>> But in the case of NSH carried directly in UDP, it seems to me that (a= s >>>> Larry described) this is normally described in the protocol document >>>> itself. Since NSH is intentionally flexible with regards to underlying >>>> transport, I can imagine this being a companion document rather than >>>> embedded in the NSH text. But in either case I think it makes the most >>>> sense for the SFC WG to be the home for such a definition. >>>>=20 >>>> Cheers, >>>> -Benson >>>>=20 >>>> _______________________________________________ >>>> sfc mailing list >>>> sfc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sfc >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >=20 From nobody Mon Jun 29 23:09:02 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A801B36CB for ; Mon, 29 Jun 2015 23:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQP7fUkT1aM0 for ; Mon, 29 Jun 2015 23:08:58 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by ietfa.amsl.com (Postfix) with ESMTP id CFEC21B36CA for ; Mon, 29 Jun 2015 23:08:58 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 29 Jun 2015 23:08:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,375,1432623600"; d="scan'208";a="720088783" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga001.jf.intel.com with ESMTP; 29 Jun 2015 23:08:53 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.16]) by ORSMSX107.amr.corp.intel.com ([169.254.1.71]) with mapi id 14.03.0224.002; Mon, 29 Jun 2015 23:08:53 -0700 From: "Elzur, Uri" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQsqTqWHhL4rRt+0+E4jBpGZu6Vp3EjLSg Date: Tue, 30 Jun 2015 06:08:52 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> In-Reply-To: <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 06:09:01 -0000 SGkgQ2FybG9zDQoNClRoYW5rcyBmb3IgZm9sbG93aW5nIHVwLiBGZXcgY29tbWVudHMNCg0KMSkg VGhlcmUgaXMgYW4gaW1wcmVzc2lvbiAoYnkgc29tZSkgdGhhdCBTRkMgUkVRVUlSRVMgYW4gaW5k ZXBlbmRlbnQgbGF5ZXIgRVZFTiBpZiBvbmUgaGFzIGFuIG92ZXJsYXkgZGVwbG95ZWQuIFdpdGhv dXQgcG9pbnRpbmcgb3V0IEFOWSB0ZWNobm9sb2d5LCBhIHNlbnRlbmNlIGxpa2Ug4oCcV2hpbGUg dGhpcyBhcmNoaXRlY3R1cmUgZGVzY3JpYmVzIGZ1bmN0aW9uYWxseSBkaXN0aW5jdCBsb2dpY2Fs IGNvbXBvbmVudHMgYW5kIHByb21vdGVzIHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UsIHRoZSBzZXJ2 aWNlIGNoYWluaW5nIGxheWVyIGNhbiBiZSBjb21iaW5lZCBpbiB2YXJpb3VzIHdheXMgd2l0aCBh biBvdmVybGF54oCdIGNhbiBleHBsYWluIHRoYXQgcG9pbnQuIEJUVzogSW4gdGhlIE5TSCBkcmFm dCwgd2UgZG8gbWFrZSB0aGUgYXNzdW1wdGlvbiB0aGF0IHRoZXJlIGlzIGFuIE92ZXJsYXkgb24g dG9wIG9mIHdoaWNoIFNGQyAoTlNIKSBpcyBkZXBsb3llZC4gVGhpcyBPdmVybGF5IGNhbiBiZSBk ZWRpY2F0ZWQgdG8gTlNIICBvciBzaGFyZWQgd2l0aCBhbiBvdmVybGF5IGZvciBuZXR3b3JrIHZp cnR1YWxpemF0aW9uLi4uDQoNCjIpIENsYXNzaWZpZXIgdnMgU0ZGIOKAkyBoYXZlIGxvb2tlZCBp bnRvIHJldiA5IG9mIHRoZSBhcmNoIGRyYWZ0LCBhc3N1bWUgdGhlIENsYXNzaWZpZXIgaXMgdGhl IGVudGl0eSB0aGF0IGluc2VydHMgdGhlIE5TSCBoZWFkZXIgaS5lLiBlbmNhcHN1bGF0ZXMgKHNl ZSBmaWd1cmUgMiksIHdlIG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgYXJjaGl0ZWN0dXJhbCBkaWFn cmFtIChmaWcgMykgdG8gY2xlYXJseSBzaG93IHRoZSBTZXJ2aWNlIENsYXNzaWZpZXIgYXMgcGFy dCBvZiB0aGUgYXJjaGl0ZWN0dXJlLiBBbHNvIG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgQ2xhc3Np ZmllciBkZWZpbml0aW9uIHRvIHRoYXQgZW5kIChsaWtlIGluIHRoZSBhYm92ZSwgYSBjbGFzc2lm aWVyIGNhbiBiZSBpbnRlZ3JhdGVkIGludG8gdGhlIFNGRiwgdGhlbiB3ZSBtYXkgd2FudCB0byBt ZW50aW9uIHRoYXQuIEluIGFueSBjYXNlLCB0aGUgU0ZGIHBlcmZvcm1zIHRoZSBOU0ggZGVjYXBz dWxhdGlvbikNCg0KVGh4DQoNClVyaSAo4oCcT28tUmVl4oCdKQ0KQzogOTQ5LTM3OC03NTY4DQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkgW21haWx0bzpjcGlnbmF0YUBjaXNjby5jb21dIA0KU2VudDogTW9uZGF5LCBKdW5lIDI5 LCAyMDE1IDEyOjUxIFBNDQpUbzogRWx6dXIsIFVyaQ0KQ2M6IEpvZWwgSGFscGVybiBEaXJlY3Q7 IHNmY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzZmNdIGNsYXJpZmljYXRpb24gb24gU0ZDIGFu ZCBPdmVybGF5IGludGVyYWN0aW9uDQoNCkhpLCBVcmksDQoNCkkgYWRkZWQgdGhlIGZvbGxvd2lu ZyB0ZXh0IGF0IHRoZSBiZWdpbm5pbmcgb2YgU2VjdGlvbiA0OiDigJxXaGlsZSB0aGlzIGFyY2hp dGVjdHVyZSBkZXNjcmliZXMgZnVuY3Rpb25hbGx5IGRpc3RpbmN0IGxvZ2ljYWwgY29tcG9uZW50 cywgdGhleSBjb3VsZCBjb21iaW5lZCBpbiB2YXJpb3VzIHdheXMgaW4gZGVwbG95ZWQgcHJvZHVj dHMu4oCdDQoNCkkgdGhpbmsgdGhpcyBjb3ZlcnMgYWxsIHBvdGVudGlhbCBjYXNlcywgaW5zdGVh ZCBvZiBzaW5nbGluZyBvdXQgb25lIGV4YW1wbGUuDQoNClRoZSBTZWN0aW9uIG5vdyBzdGFydHMg bGlrZSB0aGlzOg0KDQotLS0+OC0tLQ0KICAgVGhlIFNGQyBBcmNoaXRlY3R1cmUgaXMgYnVpbHQg b3V0IG9mIGFyY2hpdGVjdHVyYWwgYnVpbGRpbmcgYmxvY2tzDQogICB3aGljaCBhcmUgbG9naWNh bCBjb21wb25lbnRzOyB0aGVzZSBsb2dpY2FsIGNvbXBvbmVudHMgYXJlDQogICBjbGFzc2lmaWVy cywgc2VydmljZSBmdW5jdGlvbiBmb3J3YXJkZXJzIChTRkYpLCB0aGUgc2VydmljZSBmdW5jdGlv bnMNCiAgIHRoZW1zZWx2ZXMgKFNGKSwgYW5kIFNGQy1wcm94aWVzLiAgV2hpbGUgdGhpcyBhcmNo aXRlY3R1cmUgZGVzY3JpYmVzDQogICBmdW5jdGlvbmFsbHkgZGlzdGluY3QgbG9naWNhbCBjb21w b25lbnRzLCB0aGV5IGNvdWxkIGNvbWJpbmVkIGluDQogICB2YXJpb3VzIHdheXMgaW4gZGVwbG95 ZWQgcHJvZHVjdHMuDQoNCiAgIFRoZXkgYXJlIGludGVyY29ubmVjdGVkIHVzaW5nIHRoZSBTRkMg RW5jYXBzdWxhdGlvbi4gIFRoaXMgcmVzdWx0cyBpbg0KICAgYSBoaWdoIGxldmVsIGxvZ2ljYWwg YXJjaGl0ZWN0dXJlIG9mIGFuIFNGQy1lbmFibGVkIERvbWFpbiB3aGljaA0KICAgY29tcHJpc2Vz Og0KLS0tPjgtLS0NCg0KRG9lcyB0aGlzIGhlbHA/DQoNClRoYW5rcywNCg0K4oCUIENhcmxvcy4N Cg0KPiBPbiBKdW4gMjIsIDIwMTUsIGF0IDEwOjIwIEFNLCBFbHp1ciwgVXJpIDx1cmkuZWx6dXJA aW50ZWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIEpvZWwNCj4gDQo+IEkndmUgcmVjZW50bHkgcmV2 aWV3ZWQgdGhlIGxhdGVzdCBkcmFmdCB2IDA5LiBJIHN0aWxsIG1pc3Mgc3VjaCBhIGNsYXJpZmlj YXRpb24uIFBscyBwb2ludCBtZSBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uIGlmIGl0IGRvZXMgZXhp c3Qgc29tZXdoZXJlIGluIGNoYXB0ZXIgNC4NCj4gDQo+IEknZCBsaWtlIHRvIHN1Z2dlc3Qgd2Ug YWRkIGxhbmd1YWdlIHJlZmVycmluZyB0byB0aGUgc3BlY2lmaWMgZXhhbXBsZSANCj4gb3V0bGlu ZWQgYmVsb3cgb2YgU0ZGIGludGVncmF0ZWQgd2l0aCBhbiBvdmVybGF5IG1hbmFnZXIgYXMgYSB3 YXkgdG8gDQo+IHNob3cgaG93IHRoZSBsb2dpY2FsIGVsZW1lbnRzIGNhbiBiZSBpbXBsZW1lbnRl ZCBhcyBwYXJ0IG9mIGFuIG92ZXJsYXkgDQo+IGFuZCB0byBjbGFyaWZ5IHdlIGFyZSBub3QgdGFs a2luZyBPTkxZIGFib3V0ICBhIGNvbXBsZXRlbHkgaW5kZXBlbmRlbnQgDQo+IG5ldyBTZXJ2aWNl IG92ZXJsYXkNCj4gDQo+IFRoeA0KPiANCj4gVXJpICgiT28tUmVlIikNCj4gQzogOTQ5LTM3OC03 NTY4DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2VsIEhhbHBl cm4gRGlyZWN0IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21dDQo+IFNlbnQ6IE1v bmRheSwgRmVicnVhcnkgMTYsIDIwMTUgMzo0MyBQTQ0KPiBUbzogRWx6dXIsIFVyaTsgc2ZjQGll dGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc2ZjXSBjbGFyaWZpY2F0aW9uIG9uIFNGQyBhbmQgT3Zl cmxheSBpbnRlcmFjdGlvbg0KPiANCj4gSXQgc2VlbXMgbGlrZSB3ZSBjYW4gKGFuZCB1bmxlc3Mg SSBhbSB2ZXJ5IGNvbmZ1c2VkLCBzaG91bGQpIGFkZCBzdWNoIGEgc3RhdGVtZW50IGluIHRoZSBi YXNlIHBvcnRpb24gb2Ygc2VjdGlvbiA0LiAgQ2FybG9zIGFuZCBJIHdpbGwgd29yayBvbiB0aGlz LiAgVGhhbmsgeW91IGZvciBjYWxsaW5nIG91ciBhdHRlbnRpb24gdG8gdGhlIG9taXNzaW9uLg0K PiANCj4gWW91cnMsDQo+IEpvZWwNCj4gDQo+IE9uIDIvMTYvMTUgNjozNiBQTSwgRWx6dXIsIFVy aSB3cm90ZToNCj4+IEFncmVlLiBJIGRvIG5vdCByZWNhbGwgaG93ZXZlciBhbnkgc3VjaCBzdGF0 ZW1lbnQuIEkgZG8gcmVjYWxsIG1hbnkgDQo+PiBzdGF0ZW1lbnQgbGlrZSBzZWN0aW9uIDQuNSwg aW5kaWNhdGluZyB0aGUgc2VwYXJhdGlvbiBhbmQgcmVmZXJyaW5nIA0KPj4gdG8gdG9wb2xvZ2lj YWwgYW5kIHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UuIFBscyBwb2ludCBtZSB0byB0aGUgDQo+PiBw YXJhZ3JhcGggb3Igd2UgbWF5IHdhbnQgdG8gYWRkIHN1Y2ggY2xhcmlmaWNhdGlvbiBpbiB0aGUg bmV4dCByZXYNCj4+IA0KPj4gVGh4DQo+PiANCj4+IFVyaSAoIk9vLVJlZSIpDQo+PiBDOiA5NDkt Mzc4LTc1NjgNCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IEpv ZWwgTS4gSGFscGVybiBbbWFpbHRvOmptaEBqb2VsaGFscGVybi5jb21dDQo+PiBTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDE2LCAyMDE1IDM6MjQgUE0NCj4+IFRvOiBFbHp1ciwgVXJpOyBzZmNAaWV0 Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBjbGFyaWZpY2F0aW9uIG9uIFNGQyBhbmQgT3Zl cmxheSBpbnRlcmFjdGlvbg0KPj4gDQo+PiBJZiB3ZSBkbyBub3QgaGF2ZSB0ZXh0IGluIHRoZXJl IHRoYXQgc2F5cyB0aGF0IHRoZXNlIGxvZ2ljYWwgY29tcG9uZW50cyBtYXkgYmUgY29tYmluZWQg aW4gcmVhbCB3b3JsZCBpbXBsZW1lbnRhdGlvbnMgb3IgZGVwbG95bWVudHMgd2l0aCBlYWNoIG90 aGVyIG9yIHdpdGggY29tcG9uZW50cyBmcm9tIG91dHNpZGUgdGhlIGFyY2hpdGVjdHVyZSwgSSBj b3VsZCBzZWUgYWRkaW5nIHRoYXQuICBJIHRob3VnaHQgd2UgYWxyZWFkeSBzYWlkIGl0Lg0KPj4g DQo+PiBJIHdvdWxkIHByZWZlciBub3QgdG8gYWRkIGNvbW1lbnRzIG9uIGFueSBzcGVjaWZpYyBk ZXBsb3ltZW50cywgYmVjYXVzZSB0aGVyZSBhcmUgc28gbWFueSB3YXlzIHRvIGRvIHNvLCBhbmQg YXMgZmFyIGFzIEkgY2FuIHRlbGwsIG1vc3Qgb2YgdXMgdGhpbmsgdGhlIG9uZSBpbiBvdXIgaGVh ZCBpcyB0aGUgbW9zdCBsaWtlbHkgLyBjb21tb24gLyB1c2VmdWwuDQo+PiANCj4+IFlvdXJzLA0K Pj4gSm9lbA0KPj4gDQo+PiBPbiAyLzE2LzE1IDU6MzYgUE0sIEVsenVyLCBVcmkgd3JvdGU6DQo+ Pj4gSm9lbA0KPj4+IA0KPj4+IFNvdW5kcyBnb29kIHRvIG1lLiBIb3dldmVyIGEgY2xhcmlmaWNh dGlvbiwgbWF5YmUgaW4gdGhlIGZvcm1hdCBvZiBhIA0KPj4+IGNvbW1lbnQgb3IgZXhhbXBsZSAo YXMgSSBzdXNwZWN0IHRoaXMgbWF5IGJlIGEgdmVyeSBjb21tb24gY2FzZSwgZm9yDQo+Pj4gc29t ZSkgaW4gdGhlIGRyYWZ0IHdpbGwgYmUgb2YgdmFsdWUNCj4+PiANCj4+PiBUaHgNCj4+PiANCj4+ PiBVcmkgKCJPby1SZWUiKQ0KPj4+IEM6IDk0OS0zNzgtNzU2OA0KPj4+IA0KPj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFttYWlsdG86am1o QGpvZWxoYWxwZXJuLmNvbV0NCj4+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE2LCAyMDE1IDE6 MzYgUE0NCj4+PiBUbzogRWx6dXIsIFVyaTsgc2ZjQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6 IFtzZmNdIGNsYXJpZmljYXRpb24gb24gU0ZDIGFuZCBPdmVybGF5IGludGVyYWN0aW9uDQo+Pj4g DQo+Pj4gT25lIG9mIHRoZSBrZXkgcmVhc29ucyBmb3IgaWRlbnRpZnlpbmcgdGhlIGxvZ2ljYWwg Y29tcG9uZW50cyBpcyB0aGF0IHRoZXJlIGFyZSBhIGJyb2FkIHJhbmdlIG9mIHdheXMgdGhhdCB0 aGV5IGNhbiBiZSBjb21wb3NlZC4gIFRoYXQgZG9lcyBzb3VuZCBsaWtlIG9uZSBwb3NzaWJsZSBj b21wb3NpdGlvbi4NCj4+PiANCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+Pj4gDQo+Pj4gT24gMi8x Ni8xNSA0OjMyIFBNLCBFbHp1ciwgVXJpIHdyb3RlOg0KPj4+PiBXaGlsZSBzZWN0aW9uIDQuNSBv ZiBkcmFmdC1pZXRmLXNmYy1hcmNoaXRlY3R1cmUtMDQsIHN0YXRlcyANCj4+Pj4gInVuZGVybmVh dGggdGhlIFNGRiB0aGVyZSBhcmUgY29tcG9uZW50cyByZXNwb25zaWJsZSBmb3IgcGVyZm9ybWlu ZyANCj4+Pj4gdGhlIHRyYW5zcG9ydA0KPj4+PiAob3ZlcmxheSkgZm9yd2FyZGluZy4gVGhleSBk byBub3QgY29uc3VsdHMgdGhlIFNGQyBlbmNhcHN1bGF0aW9uIG9yIA0KPj4+PiBpbm5lciBwYXls b2FkIGZvciBwZXJmb3JtaW5nIHRoZXNlIGZvcndhcmRpbmcuIiwgdGhlcmUgaXMgbm8gcmVhc29u IA0KPj4+PiB0byBleGNsdWRlIHRoZSBmb2xsb3dpbmcgcHJpdmF0ZSBjYXNlLCBJJ2QgYXNzdW1l LiBUaGlzIGlzIHRoZSBjYXNlIA0KPj4+PiB3aGVyZSB0aGUgU0ZGIGlzIGVmZmVjdGl2ZWx5IGlu dGVncmF0ZWQgd2l0aCB0aGUgT3ZlcmxheSBtYW5hZ2VyLCANCj4+Pj4gb3IgaW5zdGFudGlhdGVk IGluIG90aGVyIG92ZXJsYXkgbmV0d29yayBlbGVtZW50cyAoZS5nLiB2U3dpdGNoKSwgDQo+Pj4+ IGVuYWJsaW5nIGluIGVzc2VuY2UgU0ZDIHdpdGhpbiBhbiBPdmVybGF5IG5ldHdvcmssIHdpdGgg bm8gbmVlZCBmb3IgDQo+Pj4+IGEgc2VwYXJhdGUgU0ZDIGRvbWFpbi4NCj4+Pj4gDQo+Pj4+IFRv IGJlIGNsZWFyIChvciBjbGVhcmVyKSwgdGhpcyBpcyBub3QgdG8gc3VnZ2VzdCB0aGF0IHRyYW5z cG9ydCBvciANCj4+Pj4gdG9wb2xvZ2ljYWwgaW5kZXBlbmRlbmNlIGNhbiBiZSBvciBzaG91bGQg YmUgYmVuZCwgYnV0IHNpbXBseSB0byANCj4+Pj4gc3VnZ2VzdCBhIGRlcGxveW1lbnQgc2NlbmFy aW8gdGhhdCBtYXkgYmUgcG9wdWxhciBmb3IgbGltaXRlZCBzY2FsZSANCj4+Pj4gU0ZDDQo+Pj4+ IA0KPj4+PiBUaHgNCj4+Pj4gDQo+Pj4+IFVyaSAoIk9vLVJlZSIpDQo+Pj4+IA0KPj4+PiBDOiA5 NDktMzc4LTc1NjgNCj4+Pj4gDQo+Pj4+IA0KPj4+PiANCj4+Pj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+ PiBzZmNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zZmMNCj4+Pj4gDQo+Pj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzZmMgbWFpbGluZyBsaXN0DQo+IHNmY0BpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KDQo= From nobody Tue Jun 30 04:57:42 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2491A8A47 for ; Tue, 30 Jun 2015 04:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.297 X-Spam-Level: * X-Spam-Status: No, score=1.297 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTG1P_hYoDJl for ; Tue, 30 Jun 2015 04:57:39 -0700 (PDT) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 363921A8A3C for ; Tue, 30 Jun 2015 04:57:38 -0700 (PDT) Received: from vc1.ecl.ntt.co.jp (vc1.ecl.ntt.co.jp [129.60.86.153]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t5UBvaiG005152; Tue, 30 Jun 2015 20:57:36 +0900 Received: from vc1.ecl.ntt.co.jp (localhost [127.0.0.1]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 2DF8C5F63F; Tue, 30 Jun 2015 20:57:47 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by vc1.ecl.ntt.co.jp (Postfix) with ESMTP id 136075F623; Tue, 30 Jun 2015 20:57:47 +0900 (JST) Received: from [IPv6:::1] ([129.60.13.28]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id t5UBvHC9029350; Tue, 30 Jun 2015 20:57:36 +0900 Message-ID: <5592845D.8040704@lab.ntt.co.jp> Date: Tue, 30 Jun 2015 20:58:21 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: "Jim Guichard (jguichar)" , "sfc@ietf.org" X-TM-AS-MML: disable Archived-At: Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 11:57:41 -0000 Hi Jim, I reflected feedback, which we received at the Dallas meeting, onto draft-homma-sfc-forwarding-methods-analysis, and I would like to request a slot to present it. Thanks, Shunsuke On 2015/06/27 23:58, Jim Guichard (jguichar) wrote: > Greetings WG: > > Our meeting in Prague is fast approaching. As always the goal of the > meeting will be to make the best use of our limited face-to-face time. > With that in mind we welcome requests for agenda time. > > As we build the meeting agenda our goal will be to select presentations > that best further the work of the WG, and that generally means focusing > on key charter deliverables and topics with important open issues to > resolve. When making a request please consider what you think the WG > should do with its content – for example: > > * Does the document have useful content that should be moved into > another WG document or progress on its own merit > * Does the content have a good basis for one of the WG documents per > the charter > * Should the document content be merged with one or more other > documents, so that a combined document could become a WG document > > Jim & Thomas > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Jun 30 07:56:14 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7CC1AC3B9 for ; Tue, 30 Jun 2015 07:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLT4yt9u7WMW for ; Tue, 30 Jun 2015 07:56:09 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CBD21A92EC for ; Tue, 30 Jun 2015 07:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9695; q=dns/txt; s=iport; t=1435676169; x=1436885769; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Mw9IOtNMkQIk+TWbGZXOD1hL9rE8b+qtZcUNSRC7mMI=; b=SlQmscISjlyXxC2z/XApWo8FN/Wgf5QvG85bHzx0eRLGSaIw4/ACiQpv u28QbUSklJ5WXLgWgBtrnNgeJp8hu3lqC6N4w+rrv06LYI4Ew30hMvavn tBvvkqNYQre0DFQTckr/BULwA/MYKYv2on2wwEFjfX63VGuxW3pjxoLRd A=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ApBQCqrZJV/4cNJK1YA4MRVF8Ggxi6LIFdCoV4AoFMORMBAQEBAQEBgQqEIgEBAQMBAQEBIARHCwUHBAIBCBEBAwEBAScDAgInCxQDBggCBA4FDogZCA2waZZvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLSoQtSRAHBguCVy+BFAWFHI5rAYIkgVGFQYIggTqEEoMNh2GIAyZjgSkcgVJvgQNDgQIBAQE X-IronPort-AV: E=Sophos; i="5.15,378,1432598400"; d="asc'?scan'208"; a="7790810" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jun 2015 14:55:41 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t5UEtffB014865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 14:55:41 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.112]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 09:55:40 -0500 From: "Carlos Pignataro (cpignata)" To: "Elzur, Uri" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gIAAiO2AgMOJl6CADQlKAIAArLQAgACTMAA= Date: Tue, 30 Jun 2015 14:55:39 +0000 Message-ID: <2B8D89D3-C772-4ED7-A3FE-AC923019E7F4@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.150.54.255] Content-Type: multipart/signed; boundary="Apple-Mail=_B7770474-12FC-4E42-9C55-7CED34F7A52B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 14:56:12 -0000 --Apple-Mail=_B7770474-12FC-4E42-9C55-7CED34F7A52B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Uri, Thanks for the comments, please see inline. > On Jun 30, 2015, at 2:08 AM, Elzur, Uri wrote: >=20 > Hi Carlos >=20 > Thanks for following up. Few comments >=20 > 1) There is an impression (by some) that SFC REQUIRES an independent = layer EVEN if one has an overlay deployed. Without pointing out ANY = technology, a sentence like =E2=80=9CWhile this architecture describes = functionally distinct logical components and promotes transport = independence, the service chaining layer can be combined in various ways = with an overlay=E2=80=9D can explain that point. BTW: In the NSH draft, = we do make the assumption that there is an Overlay on top of which SFC = (NSH) is deployed. This Overlay can be dedicated to NSH or shared with = an overlay for network virtualization=E2=80=A6 >=20 If I read this correctly, you are proposing to add =E2=80=9Cpromotes = transport independence=E2=80=9D. I think that the document already = covers this point in detail. Also, it is not the service layer that is = combined, but rather the components, so part of this re-write could be a = bit confusing. I am happy to try to rewrite and sharpen this sentence, but I really = think that nothing you say is precluded. > 2) Classifier vs SFF =E2=80=93 have looked into rev 9 of the arch = draft, assume the Classifier is the entity that inserts the NSH header = i.e. encapsulates (see figure 2), we may want to update the = architectural diagram (fig 3) to clearly show the Service Classifier as = part of the architecture. Figure 2 already shows the classifier as part of the architecture. I am = not sure how to update Figure 3 without making it unreadable. Remember = fig 3 is not showing and end-to-end view of the SFP. > Also may want to update the Classifier definition to that end (like in = the above, a classifier can be integrated into the SFF, then we may want = to mention that. In any case, the SFF performs the NSH decapsulation) I am hesitant to add a very specific example to the general sentence = above. Otherwise, we might end up implying that other combinations are = not possible. Since the role of classification and use of the SFC = encapsulation is covered in detail in full sections of the doc, I=E2=80=99= d recommend we do not try to summarize here. We welcome other comments on this of course, Thanks, =E2=80=94 Carlos. >=20 > Thx >=20 > Uri (=E2=80=9COo-Ree=E2=80=9D) > C: 949-378-7568 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] > Sent: Monday, June 29, 2015 12:51 PM > To: Elzur, Uri > Cc: Joel Halpern Direct; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction >=20 > Hi, Uri, >=20 > I added the following text at the beginning of Section 4: =E2=80=9CWhile= this architecture describes functionally distinct logical components, = they could combined in various ways in deployed products.=E2=80=9D >=20 > I think this covers all potential cases, instead of singling out one = example. >=20 > The Section now starts like this: >=20 > --->8--- > The SFC Architecture is built out of architectural building blocks > which are logical components; these logical components are > classifiers, service function forwarders (SFF), the service = functions > themselves (SF), and SFC-proxies. While this architecture describes > functionally distinct logical components, they could combined in > various ways in deployed products. >=20 > They are interconnected using the SFC Encapsulation. This results = in > a high level logical architecture of an SFC-enabled Domain which > comprises: > --->8--- >=20 > Does this help? >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >> On Jun 22, 2015, at 10:20 AM, Elzur, Uri wrote: >>=20 >> Hi Joel >>=20 >> I've recently reviewed the latest draft v 09. I still miss such a = clarification. Pls point me in the right direction if it does exist = somewhere in chapter 4. >>=20 >> I'd like to suggest we add language referring to the specific example >> outlined below of SFF integrated with an overlay manager as a way to >> show how the logical elements can be implemented as part of an = overlay >> and to clarify we are not talking ONLY about a completely = independent >> new Service overlay >>=20 >> Thx >>=20 >> Uri ("Oo-Ree") >> C: 949-378-7568 >>=20 >> -----Original Message----- >> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >> Sent: Monday, February 16, 2015 3:43 PM >> To: Elzur, Uri; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>=20 >> It seems like we can (and unless I am very confused, should) add such = a statement in the base portion of section 4. Carlos and I will work on = this. Thank you for calling our attention to the omission. >>=20 >> Yours, >> Joel >>=20 >> On 2/16/15 6:36 PM, Elzur, Uri wrote: >>> Agree. I do not recall however any such statement. I do recall many >>> statement like section 4.5, indicating the separation and referring >>> to topological and transport independence. Pls point me to the >>> paragraph or we may want to add such clarification in the next rev >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>>=20 >>> -----Original Message----- >>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>> Sent: Monday, February 16, 2015 3:24 PM >>> To: Elzur, Uri; sfc@ietf.org >>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>=20 >>> If we do not have text in there that says that these logical = components may be combined in real world implementations or deployments = with each other or with components from outside the architecture, I = could see adding that. I thought we already said it. >>>=20 >>> I would prefer not to add comments on any specific deployments, = because there are so many ways to do so, and as far as I can tell, most = of us think the one in our head is the most likely / common / useful. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/16/15 5:36 PM, Elzur, Uri wrote: >>>> Joel >>>>=20 >>>> Sounds good to me. However a clarification, maybe in the format of = a >>>> comment or example (as I suspect this may be a very common case, = for >>>> some) in the draft will be of value >>>>=20 >>>> Thx >>>>=20 >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>>=20 >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Monday, February 16, 2015 1:36 PM >>>> To: Elzur, Uri; sfc@ietf.org >>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>>=20 >>>> One of the key reasons for identifying the logical components is = that there are a broad range of ways that they can be composed. That = does sound like one possible composition. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>>>> While section 4.5 of draft-ietf-sfc-architecture-04, states >>>>> "underneath the SFF there are components responsible for = performing >>>>> the transport >>>>> (overlay) forwarding. They do not consults the SFC encapsulation = or >>>>> inner payload for performing these forwarding.", there is no = reason >>>>> to exclude the following private case, I'd assume. This is the = case >>>>> where the SFF is effectively integrated with the Overlay manager, >>>>> or instantiated in other overlay network elements (e.g. vSwitch), >>>>> enabling in essence SFC within an Overlay network, with no need = for >>>>> a separate SFC domain. >>>>>=20 >>>>> To be clear (or clearer), this is not to suggest that transport or >>>>> topological independence can be or should be bend, but simply to >>>>> suggest a deployment scenario that may be popular for limited = scale >>>>> SFC >>>>>=20 >>>>> Thx >>>>>=20 >>>>> Uri ("Oo-Ree") >>>>>=20 >>>>> C: 949-378-7568 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> sfc mailing list >>>>> sfc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 --Apple-Mail=_B7770474-12FC-4E42-9C55-7CED34F7A52B 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 iQIcBAEBCAAGBQJVkq3sAAoJEIXgpQGOZny99UoP/2yi2d5WBLgs2eb0Oou4BjoD cS5h5WI8HtkF+v+axvnHDScgn1MPcuL4elbBmcoCFpVAnQ4cuYTZqJgPDi81+QGD UBbccVnzIRa+7/k2e441aCXvQAJXmiEHqnjv2lEFV5k4X2c4iO4fpmKQiuLpV/nx GLJwQgpj1pSgEKwDVhPKwK5Ydt2QF34IQlVjvIj7U8bm6Cwtf2NsS9mSyCWZASZ1 eJoE5slCnQ5wby1RlWZ2MmtJ69wYuY9FgQ0Vyu2X0VhahX64TPSe9k/UtGjB/PZX TWAetBWcKAHceB+C/JojSxkO7GbhT61JAO3WYjYaZNNbz+QJe0rBWWTdRgA67Zlh FwrnGIws9oc0XSjmzg5PyjENybB4aVEIQFSnjN5/5kSgE10f08+iKaW3EklI7qQL dfclINbeAnMYw4G4HBpOB2xDUt2DcCTSfJApYqIqKmrri6qN8OYzF8ZnCY/VouEE Lkkp0QBZRDSqJA0LW9Q4PLUyV16lA9j4fvE3HnC/tEFLf4CyYVzqf2mr9DjHy4jy U7YqaZ3AI3XO015g75OMEdXRrijNcuyCAy3ONsNDpSxYoi2APPaQuPD4Zmj1uGTu q2+hN5PdtuGLGuvlfUUr6yF9CQq6N+nHWNKt/MbaUwcFuFjvbUy6/yX6pFMn4XAa 4S0HGxTsUnACTcZMgu4w =04Ne -----END PGP SIGNATURE----- --Apple-Mail=_B7770474-12FC-4E42-9C55-7CED34F7A52B-- From nobody Tue Jun 30 08:32:53 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E552C1A9234 for ; Tue, 30 Jun 2015 08:32:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4rhNUnvSQVv for ; Tue, 30 Jun 2015 08:32:49 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 58B241A9043 for ; Tue, 30 Jun 2015 08:32:49 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 30 Jun 2015 08:32:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,378,1432623600"; d="scan'208";a="755912400" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga002.jf.intel.com with ESMTP; 30 Jun 2015 08:32:48 -0700 Received: from orsmsx112.amr.corp.intel.com (10.22.240.13) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.224.2; Tue, 30 Jun 2015 08:32:43 -0700 Received: from orsmsx114.amr.corp.intel.com ([169.254.8.16]) by ORSMSX112.amr.corp.intel.com ([169.254.12.27]) with mapi id 14.03.0224.002; Tue, 30 Jun 2015 08:32:43 -0700 From: "Elzur, Uri" To: "Carlos Pignataro (cpignata)" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQsqTqWHhL4rRt+0+E4jBpGZu6Vp3EjLSggAENAoD//5MFEA== Date: Tue, 30 Jun 2015 15:32:43 +0000 Message-ID: <7E05C330D7FD6D4FAD0728C46B89958581CAA072@ORSMSX114.amr.corp.intel.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> <2B8D89D3-C772-4ED7-A3FE-AC923019E7F4@cisco.com> In-Reply-To: <2B8D89D3-C772-4ED7-A3FE-AC923019E7F4@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.254.139] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 15:32:52 -0000 SGkgQ2FybG9zDQoNClBscyBzZWUgYmVsb3cgW1VFXQ0KDQpUaHgNCg0KVXJpICjigJxPby1SZWXi gJ0pDQpDOiA5NDktMzc4LTc1NjgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0g DQpTZW50OiBUdWVzZGF5LCBKdW5lIDMwLCAyMDE1IDc6NTYgQU0NClRvOiBFbHp1ciwgVXJpDQpD YzogSm9lbCBIYWxwZXJuIERpcmVjdDsgc2ZjQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NmY10g Y2xhcmlmaWNhdGlvbiBvbiBTRkMgYW5kIE92ZXJsYXkgaW50ZXJhY3Rpb24NCg0KSGksIFVyaSwN Cg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHBsZWFzZSBzZWUgaW5saW5lLg0KDQo+IE9uIEp1 biAzMCwgMjAxNSwgYXQgMjowOCBBTSwgRWx6dXIsIFVyaSA8dXJpLmVsenVyQGludGVsLmNvbT4g d3JvdGU6DQo+IA0KPiBIaSBDYXJsb3MNCj4gDQo+IFRoYW5rcyBmb3IgZm9sbG93aW5nIHVwLiBG ZXcgY29tbWVudHMNCj4gDQo+IDEpIFRoZXJlIGlzIGFuIGltcHJlc3Npb24gKGJ5IHNvbWUpIHRo YXQgU0ZDIFJFUVVJUkVTIGFuIGluZGVwZW5kZW50IA0KPiBsYXllciBFVkVOIGlmIG9uZSBoYXMg YW4gb3ZlcmxheSBkZXBsb3llZC4gV2l0aG91dCBwb2ludGluZyBvdXQgQU5ZIA0KPiB0ZWNobm9s b2d5LCBhIHNlbnRlbmNlIGxpa2Ug4oCcV2hpbGUgdGhpcyBhcmNoaXRlY3R1cmUgZGVzY3JpYmVz IA0KPiBmdW5jdGlvbmFsbHkgZGlzdGluY3QgbG9naWNhbCBjb21wb25lbnRzIGFuZCBwcm9tb3Rl cyB0cmFuc3BvcnQgDQo+IGluZGVwZW5kZW5jZSwgdGhlIHNlcnZpY2UgY2hhaW5pbmcgbGF5ZXIg Y2FuIGJlIGNvbWJpbmVkIGluIHZhcmlvdXMgDQo+IHdheXMgd2l0aCBhbiBvdmVybGF54oCdIGNh biBleHBsYWluIHRoYXQgcG9pbnQuIEJUVzogSW4gdGhlIE5TSCBkcmFmdCwgDQo+IHdlIGRvIG1h a2UgdGhlIGFzc3VtcHRpb24gdGhhdCB0aGVyZSBpcyBhbiBPdmVybGF5IG9uIHRvcCBvZiB3aGlj aCBTRkMgDQo+IChOU0gpIGlzIGRlcGxveWVkLiBUaGlzIE92ZXJsYXkgY2FuIGJlIGRlZGljYXRl ZCB0byBOU0ggIG9yIHNoYXJlZCANCj4gd2l0aCBhbiBvdmVybGF5IGZvciBuZXR3b3JrIHZpcnR1 YWxpemF0aW9u4oCmDQo+IA0KDQpJZiBJIHJlYWQgdGhpcyBjb3JyZWN0bHksIHlvdSBhcmUgcHJv cG9zaW5nIHRvIGFkZCDigJxwcm9tb3RlcyB0cmFuc3BvcnQgaW5kZXBlbmRlbmNl4oCdLiBJIHRo aW5rIHRoYXQgdGhlIGRvY3VtZW50IGFscmVhZHkgY292ZXJzIHRoaXMgcG9pbnQgaW4gZGV0YWls LiBBbHNvLCBpdCBpcyBub3QgdGhlIHNlcnZpY2UgbGF5ZXIgdGhhdCBpcyBjb21iaW5lZCwgYnV0 IHJhdGhlciB0aGUgY29tcG9uZW50cywgc28gcGFydCBvZiB0aGlzIHJlLXdyaXRlIGNvdWxkIGJl IGEgYml0IGNvbmZ1c2luZy4NCg0KSSBhbSBoYXBweSB0byB0cnkgdG8gcmV3cml0ZSBhbmQgc2hh cnBlbiB0aGlzIHNlbnRlbmNlLCBidXQgSSByZWFsbHkgdGhpbmsgdGhhdCBub3RoaW5nIHlvdSBz YXkgaXMgcHJlY2x1ZGVkLg0KW1VFXSB0aGUgcG9pbnQgaXMgYWJvdXQgYnVpbGRpbmcgU0ZDIGlu dG8gYW4gZXhpc3RpbmcgTmV0VmlydCBPdmVybGF5LiBUbyBzaGFycGVuIHRoYXQgcG9pbnQsIEkn bSBhZGRpbmcgYWxiZWl0IHRoYXQgU0ZDIHByb21vdGVzL2Fzc3VtZXMvbWFuZGF0ZXMgVHJhbnNw b3J0IGluZGVwZW5kZW5jZSwgbWVyZ2luZyBTRkMgaW50byBhbiBleGlzaXRpbmcgb3ZlcmxheSBp cyBwb3NzaWJsZS4gSSB0aGluayBpdCB0YWtlcyBjbGVhciBzdGF0ZW1lbnQgZm9yIGZvbGtzIHRv IHNlZSBhcyBpdCBjb21lcyBhY3Jvc3MgdG8gbWUgYW5kIG90aGVycyBhcyBpZiB0aGlzIGlzIG5v dCBwb3NzaWJsZQ0KDQo+IDIpIENsYXNzaWZpZXIgdnMgU0ZGIOKAkyBoYXZlIGxvb2tlZCBpbnRv IHJldiA5IG9mIHRoZSBhcmNoIGRyYWZ0LCBhc3N1bWUgdGhlIENsYXNzaWZpZXIgaXMgdGhlIGVu dGl0eSB0aGF0IGluc2VydHMgdGhlIE5TSCBoZWFkZXIgaS5lLiBlbmNhcHN1bGF0ZXMgKHNlZSBm aWd1cmUgMiksIHdlIG1heSB3YW50IHRvIHVwZGF0ZSB0aGUgYXJjaGl0ZWN0dXJhbCBkaWFncmFt IChmaWcgMykgdG8gY2xlYXJseSBzaG93IHRoZSBTZXJ2aWNlIENsYXNzaWZpZXIgYXMgcGFydCBv ZiB0aGUgYXJjaGl0ZWN0dXJlLg0KDQpGaWd1cmUgMiBhbHJlYWR5IHNob3dzIHRoZSBjbGFzc2lm aWVyIGFzIHBhcnQgb2YgdGhlIGFyY2hpdGVjdHVyZS4gSSBhbSBub3Qgc3VyZSBob3cgdG8gdXBk YXRlIEZpZ3VyZSAzIHdpdGhvdXQgbWFraW5nIGl0IHVucmVhZGFibGUuIFJlbWVtYmVyIGZpZyAz IGlzIG5vdCBzaG93aW5nIGFuZCBlbmQtdG8tZW5kIHZpZXcgb2YgdGhlIFNGUC4NCltVRV0gd2l0 aG91dCBhIGNsYXNzaWZpZXIgRmlnIDMgaXMgaW5jb21wbGV0ZSBJTUhPLCBpdCBpcyB0aGUgQ2xh c3NpZmllciB0aGF0IGlzIGxvY2F0ZWQgYXQgdGhlIGJvdW5kYXJ5IG9mIHRoZSBub24gZW5jYXBz dWxhdGVkIGFuZCBTRkMtZW5jYXBzdWxhdGVkIHdvcmxkLiBBbmQgdGhpcyBpcyBhbHNvIHdoeSBJ IHdhcyBwcm9wb3NpbmcgdG8gdXBkYXRlIHRoZSBkZWZpbml0aW9uLiBUaGUgc3VnZ2VzdGlvbiBp cyB0byBtYWtlIGl0IGNsZWFyIGl0IGlzIG5vdCB0aGVTRkYgdGhhdCBpcyBlbmNhcHN1bGF0aW5n IHRoZSBmaXJzdCBTRkMgcGFja2V0DQoNCj4gQWxzbyBtYXkgd2FudCB0byB1cGRhdGUgdGhlIENs YXNzaWZpZXIgZGVmaW5pdGlvbiB0byB0aGF0IGVuZCAobGlrZSBpbiANCj4gdGhlIGFib3ZlLCBh IGNsYXNzaWZpZXIgY2FuIGJlIGludGVncmF0ZWQgaW50byB0aGUgU0ZGLCB0aGVuIHdlIG1heSAN Cj4gd2FudCB0byBtZW50aW9uIHRoYXQuIEluIGFueSBjYXNlLCB0aGUgU0ZGIHBlcmZvcm1zIHRo ZSBOU0ggDQo+IGRlY2Fwc3VsYXRpb24pDQoNCkkgYW0gaGVzaXRhbnQgdG8gYWRkIGEgdmVyeSBz cGVjaWZpYyBleGFtcGxlIHRvIHRoZSBnZW5lcmFsIHNlbnRlbmNlIGFib3ZlLiBPdGhlcndpc2Us IHdlIG1pZ2h0IGVuZCB1cCBpbXBseWluZyB0aGF0IG90aGVyIGNvbWJpbmF0aW9ucyBhcmUgbm90 IHBvc3NpYmxlLiBTaW5jZSB0aGUgcm9sZSBvZiBjbGFzc2lmaWNhdGlvbiBhbmQgdXNlIG9mIHRo ZSBTRkMgZW5jYXBzdWxhdGlvbiBpcyBjb3ZlcmVkIGluIGRldGFpbCBpbiBmdWxsIHNlY3Rpb25z IG9mIHRoZSBkb2MsIEnigJlkIHJlY29tbWVuZCB3ZSBkbyBub3QgdHJ5IHRvIHN1bW1hcml6ZSBo ZXJlLg0KW1VFXSBub3Qgc3VnZ2VzdGluZyB0byBsaW1pdCB0aGUgZ2VuZXJhbGl0eSBvZiB0aGUg YXJjaGl0ZWN0dXJlIGFuZCBmb3IgbWUgdGhlcmUgaXMgbm8gbmVlZCB0byBpbmNsdWRlIHRoZSBl eGFtcGxlIG9mIGEgY2xhc3NpZmllciBpbnRlZ3JhdGVkIGludG8gU0ZGLiBPbiB0aGUgY29udHJh cnkgSSBtdWNoIHByZWZlciB0byBzZWUgdGhlIGFib3ZlIGNsYXJpZmljYXRpb24gb2YgdGhlIENs YXNzaWZpZXIgaW5kZXBlbmRlbnQgcm9sZQ0KIA0KV2Ugd2VsY29tZSBvdGhlciBjb21tZW50cyBv biB0aGlzIG9mIGNvdXJzZSwNCg0KVGhhbmtzLA0KDQrigJQgQ2FybG9zLg0KDQo+IA0KPiBUaHgN Cj4gDQo+IFVyaSAo4oCcT28tUmVl4oCdKQ0KPiBDOiA5NDktMzc4LTc1NjgNCj4gDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRh KSBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbV0NCj4gU2VudDogTW9uZGF5LCBKdW5lIDI5LCAy MDE1IDEyOjUxIFBNDQo+IFRvOiBFbHp1ciwgVXJpDQo+IENjOiBKb2VsIEhhbHBlcm4gRGlyZWN0 OyBzZmNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzZmNdIGNsYXJpZmljYXRpb24gb24gU0ZD IGFuZCBPdmVybGF5IGludGVyYWN0aW9uDQo+IA0KPiBIaSwgVXJpLA0KPiANCj4gSSBhZGRlZCB0 aGUgZm9sbG93aW5nIHRleHQgYXQgdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDQ6IOKAnFdoaWxl IHRoaXMgYXJjaGl0ZWN0dXJlIGRlc2NyaWJlcyBmdW5jdGlvbmFsbHkgZGlzdGluY3QgbG9naWNh bCBjb21wb25lbnRzLCB0aGV5IGNvdWxkIGNvbWJpbmVkIGluIHZhcmlvdXMgd2F5cyBpbiBkZXBs b3llZCBwcm9kdWN0cy7igJ0NCj4gDQo+IEkgdGhpbmsgdGhpcyBjb3ZlcnMgYWxsIHBvdGVudGlh bCBjYXNlcywgaW5zdGVhZCBvZiBzaW5nbGluZyBvdXQgb25lIGV4YW1wbGUuDQo+IA0KPiBUaGUg U2VjdGlvbiBub3cgc3RhcnRzIGxpa2UgdGhpczoNCj4gDQo+IC0tLT44LS0tDQo+ICAgVGhlIFNG QyBBcmNoaXRlY3R1cmUgaXMgYnVpbHQgb3V0IG9mIGFyY2hpdGVjdHVyYWwgYnVpbGRpbmcgYmxv Y2tzDQo+ICAgd2hpY2ggYXJlIGxvZ2ljYWwgY29tcG9uZW50czsgdGhlc2UgbG9naWNhbCBjb21w b25lbnRzIGFyZQ0KPiAgIGNsYXNzaWZpZXJzLCBzZXJ2aWNlIGZ1bmN0aW9uIGZvcndhcmRlcnMg KFNGRiksIHRoZSBzZXJ2aWNlIGZ1bmN0aW9ucw0KPiAgIHRoZW1zZWx2ZXMgKFNGKSwgYW5kIFNG Qy1wcm94aWVzLiAgV2hpbGUgdGhpcyBhcmNoaXRlY3R1cmUgZGVzY3JpYmVzDQo+ICAgZnVuY3Rp b25hbGx5IGRpc3RpbmN0IGxvZ2ljYWwgY29tcG9uZW50cywgdGhleSBjb3VsZCBjb21iaW5lZCBp bg0KPiAgIHZhcmlvdXMgd2F5cyBpbiBkZXBsb3llZCBwcm9kdWN0cy4NCj4gDQo+ICAgVGhleSBh cmUgaW50ZXJjb25uZWN0ZWQgdXNpbmcgdGhlIFNGQyBFbmNhcHN1bGF0aW9uLiAgVGhpcyByZXN1 bHRzIGluDQo+ICAgYSBoaWdoIGxldmVsIGxvZ2ljYWwgYXJjaGl0ZWN0dXJlIG9mIGFuIFNGQy1l bmFibGVkIERvbWFpbiB3aGljaA0KPiAgIGNvbXByaXNlczoNCj4gLS0tPjgtLS0NCj4gDQo+IERv ZXMgdGhpcyBoZWxwPw0KPiANCj4gVGhhbmtzLA0KPiANCj4g4oCUIENhcmxvcy4NCj4gDQo+PiBP biBKdW4gMjIsIDIwMTUsIGF0IDEwOjIwIEFNLCBFbHp1ciwgVXJpIDx1cmkuZWx6dXJAaW50ZWwu Y29tPiB3cm90ZToNCj4+IA0KPj4gSGkgSm9lbA0KPj4gDQo+PiBJJ3ZlIHJlY2VudGx5IHJldmll d2VkIHRoZSBsYXRlc3QgZHJhZnQgdiAwOS4gSSBzdGlsbCBtaXNzIHN1Y2ggYSBjbGFyaWZpY2F0 aW9uLiBQbHMgcG9pbnQgbWUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBpZiBpdCBkb2VzIGV4aXN0 IHNvbWV3aGVyZSBpbiBjaGFwdGVyIDQuDQo+PiANCj4+IEknZCBsaWtlIHRvIHN1Z2dlc3Qgd2Ug YWRkIGxhbmd1YWdlIHJlZmVycmluZyB0byB0aGUgc3BlY2lmaWMgZXhhbXBsZSANCj4+IG91dGxp bmVkIGJlbG93IG9mIFNGRiBpbnRlZ3JhdGVkIHdpdGggYW4gb3ZlcmxheSBtYW5hZ2VyIGFzIGEg d2F5IHRvIA0KPj4gc2hvdyBob3cgdGhlIGxvZ2ljYWwgZWxlbWVudHMgY2FuIGJlIGltcGxlbWVu dGVkIGFzIHBhcnQgb2YgYW4gDQo+PiBvdmVybGF5IGFuZCB0byBjbGFyaWZ5IHdlIGFyZSBub3Qg dGFsa2luZyBPTkxZIGFib3V0ICBhIGNvbXBsZXRlbHkgDQo+PiBpbmRlcGVuZGVudCBuZXcgU2Vy dmljZSBvdmVybGF5DQo+PiANCj4+IFRoeA0KPj4gDQo+PiBVcmkgKCJPby1SZWUiKQ0KPj4gQzog OTQ5LTM3OC03NTY4DQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9t OiBKb2VsIEhhbHBlcm4gRGlyZWN0IFttYWlsdG86am1oLmRpcmVjdEBqb2VsaGFscGVybi5jb21d DQo+PiBTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDE2LCAyMDE1IDM6NDMgUE0NCj4+IFRvOiBFbHp1 ciwgVXJpOyBzZmNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFJlOiBbc2ZjXSBjbGFyaWZpY2F0aW9u IG9uIFNGQyBhbmQgT3ZlcmxheSBpbnRlcmFjdGlvbg0KPj4gDQo+PiBJdCBzZWVtcyBsaWtlIHdl IGNhbiAoYW5kIHVubGVzcyBJIGFtIHZlcnkgY29uZnVzZWQsIHNob3VsZCkgYWRkIHN1Y2ggYSBz dGF0ZW1lbnQgaW4gdGhlIGJhc2UgcG9ydGlvbiBvZiBzZWN0aW9uIDQuICBDYXJsb3MgYW5kIEkg d2lsbCB3b3JrIG9uIHRoaXMuICBUaGFuayB5b3UgZm9yIGNhbGxpbmcgb3VyIGF0dGVudGlvbiB0 byB0aGUgb21pc3Npb24uDQo+PiANCj4+IFlvdXJzLA0KPj4gSm9lbA0KPj4gDQo+PiBPbiAyLzE2 LzE1IDY6MzYgUE0sIEVsenVyLCBVcmkgd3JvdGU6DQo+Pj4gQWdyZWUuIEkgZG8gbm90IHJlY2Fs bCBob3dldmVyIGFueSBzdWNoIHN0YXRlbWVudC4gSSBkbyByZWNhbGwgbWFueSANCj4+PiBzdGF0 ZW1lbnQgbGlrZSBzZWN0aW9uIDQuNSwgaW5kaWNhdGluZyB0aGUgc2VwYXJhdGlvbiBhbmQgcmVm ZXJyaW5nIA0KPj4+IHRvIHRvcG9sb2dpY2FsIGFuZCB0cmFuc3BvcnQgaW5kZXBlbmRlbmNlLiBQ bHMgcG9pbnQgbWUgdG8gdGhlIA0KPj4+IHBhcmFncmFwaCBvciB3ZSBtYXkgd2FudCB0byBhZGQg c3VjaCBjbGFyaWZpY2F0aW9uIGluIHRoZSBuZXh0IHJldg0KPj4+IA0KPj4+IFRoeA0KPj4+IA0K Pj4+IFVyaSAoIk9vLVJlZSIpDQo+Pj4gQzogOTQ5LTM3OC03NTY4DQo+Pj4gDQo+Pj4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBKb2VsIE0uIEhhbHBlcm4gW21haWx0bzpq bWhAam9lbGhhbHBlcm4uY29tXQ0KPj4+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgMTYsIDIwMTUg MzoyNCBQTQ0KPj4+IFRvOiBFbHp1ciwgVXJpOyBzZmNAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBS ZTogW3NmY10gY2xhcmlmaWNhdGlvbiBvbiBTRkMgYW5kIE92ZXJsYXkgaW50ZXJhY3Rpb24NCj4+ PiANCj4+PiBJZiB3ZSBkbyBub3QgaGF2ZSB0ZXh0IGluIHRoZXJlIHRoYXQgc2F5cyB0aGF0IHRo ZXNlIGxvZ2ljYWwgY29tcG9uZW50cyBtYXkgYmUgY29tYmluZWQgaW4gcmVhbCB3b3JsZCBpbXBs ZW1lbnRhdGlvbnMgb3IgZGVwbG95bWVudHMgd2l0aCBlYWNoIG90aGVyIG9yIHdpdGggY29tcG9u ZW50cyBmcm9tIG91dHNpZGUgdGhlIGFyY2hpdGVjdHVyZSwgSSBjb3VsZCBzZWUgYWRkaW5nIHRo YXQuICBJIHRob3VnaHQgd2UgYWxyZWFkeSBzYWlkIGl0Lg0KPj4+IA0KPj4+IEkgd291bGQgcHJl ZmVyIG5vdCB0byBhZGQgY29tbWVudHMgb24gYW55IHNwZWNpZmljIGRlcGxveW1lbnRzLCBiZWNh dXNlIHRoZXJlIGFyZSBzbyBtYW55IHdheXMgdG8gZG8gc28sIGFuZCBhcyBmYXIgYXMgSSBjYW4g dGVsbCwgbW9zdCBvZiB1cyB0aGluayB0aGUgb25lIGluIG91ciBoZWFkIGlzIHRoZSBtb3N0IGxp a2VseSAvIGNvbW1vbiAvIHVzZWZ1bC4NCj4+PiANCj4+PiBZb3VycywNCj4+PiBKb2VsDQo+Pj4g DQo+Pj4gT24gMi8xNi8xNSA1OjM2IFBNLCBFbHp1ciwgVXJpIHdyb3RlOg0KPj4+PiBKb2VsDQo+ Pj4+IA0KPj4+PiBTb3VuZHMgZ29vZCB0byBtZS4gSG93ZXZlciBhIGNsYXJpZmljYXRpb24sIG1h eWJlIGluIHRoZSBmb3JtYXQgb2YgDQo+Pj4+IGEgY29tbWVudCBvciBleGFtcGxlIChhcyBJIHN1 c3BlY3QgdGhpcyBtYXkgYmUgYSB2ZXJ5IGNvbW1vbiBjYXNlLCANCj4+Pj4gZm9yDQo+Pj4+IHNv bWUpIGluIHRoZSBkcmFmdCB3aWxsIGJlIG9mIHZhbHVlDQo+Pj4+IA0KPj4+PiBUaHgNCj4+Pj4g DQo+Pj4+IFVyaSAoIk9vLVJlZSIpDQo+Pj4+IEM6IDk0OS0zNzgtNzU2OA0KPj4+PiANCj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJvbTogSm9lbCBNLiBIYWxwZXJuIFtt YWlsdG86am1oQGpvZWxoYWxwZXJuLmNvbV0NCj4+Pj4gU2VudDogTW9uZGF5LCBGZWJydWFyeSAx NiwgMjAxNSAxOjM2IFBNDQo+Pj4+IFRvOiBFbHp1ciwgVXJpOyBzZmNAaWV0Zi5vcmcNCj4+Pj4g U3ViamVjdDogUmU6IFtzZmNdIGNsYXJpZmljYXRpb24gb24gU0ZDIGFuZCBPdmVybGF5IGludGVy YWN0aW9uDQo+Pj4+IA0KPj4+PiBPbmUgb2YgdGhlIGtleSByZWFzb25zIGZvciBpZGVudGlmeWlu ZyB0aGUgbG9naWNhbCBjb21wb25lbnRzIGlzIHRoYXQgdGhlcmUgYXJlIGEgYnJvYWQgcmFuZ2Ug b2Ygd2F5cyB0aGF0IHRoZXkgY2FuIGJlIGNvbXBvc2VkLiAgVGhhdCBkb2VzIHNvdW5kIGxpa2Ug b25lIHBvc3NpYmxlIGNvbXBvc2l0aW9uLg0KPj4+PiANCj4+Pj4gWW91cnMsDQo+Pj4+IEpvZWwN Cj4+Pj4gDQo+Pj4+IE9uIDIvMTYvMTUgNDozMiBQTSwgRWx6dXIsIFVyaSB3cm90ZToNCj4+Pj4+ IFdoaWxlIHNlY3Rpb24gNC41IG9mIGRyYWZ0LWlldGYtc2ZjLWFyY2hpdGVjdHVyZS0wNCwgc3Rh dGVzIA0KPj4+Pj4gInVuZGVybmVhdGggdGhlIFNGRiB0aGVyZSBhcmUgY29tcG9uZW50cyByZXNw b25zaWJsZSBmb3IgDQo+Pj4+PiBwZXJmb3JtaW5nIHRoZSB0cmFuc3BvcnQNCj4+Pj4+IChvdmVy bGF5KSBmb3J3YXJkaW5nLiBUaGV5IGRvIG5vdCBjb25zdWx0cyB0aGUgU0ZDIGVuY2Fwc3VsYXRp b24gDQo+Pj4+PiBvciBpbm5lciBwYXlsb2FkIGZvciBwZXJmb3JtaW5nIHRoZXNlIGZvcndhcmRp bmcuIiwgdGhlcmUgaXMgbm8gDQo+Pj4+PiByZWFzb24gdG8gZXhjbHVkZSB0aGUgZm9sbG93aW5n IHByaXZhdGUgY2FzZSwgSSdkIGFzc3VtZS4gVGhpcyBpcyANCj4+Pj4+IHRoZSBjYXNlIHdoZXJl IHRoZSBTRkYgaXMgZWZmZWN0aXZlbHkgaW50ZWdyYXRlZCB3aXRoIHRoZSBPdmVybGF5IA0KPj4+ Pj4gbWFuYWdlciwgb3IgaW5zdGFudGlhdGVkIGluIG90aGVyIG92ZXJsYXkgbmV0d29yayBlbGVt ZW50cyAoZS5nLiANCj4+Pj4+IHZTd2l0Y2gpLCBlbmFibGluZyBpbiBlc3NlbmNlIFNGQyB3aXRo aW4gYW4gT3ZlcmxheSBuZXR3b3JrLCB3aXRoIA0KPj4+Pj4gbm8gbmVlZCBmb3IgYSBzZXBhcmF0 ZSBTRkMgZG9tYWluLg0KPj4+Pj4gDQo+Pj4+PiBUbyBiZSBjbGVhciAob3IgY2xlYXJlciksIHRo aXMgaXMgbm90IHRvIHN1Z2dlc3QgdGhhdCB0cmFuc3BvcnQgb3IgDQo+Pj4+PiB0b3BvbG9naWNh bCBpbmRlcGVuZGVuY2UgY2FuIGJlIG9yIHNob3VsZCBiZSBiZW5kLCBidXQgc2ltcGx5IHRvIA0K Pj4+Pj4gc3VnZ2VzdCBhIGRlcGxveW1lbnQgc2NlbmFyaW8gdGhhdCBtYXkgYmUgcG9wdWxhciBm b3IgbGltaXRlZCANCj4+Pj4+IHNjYWxlIFNGQw0KPj4+Pj4gDQo+Pj4+PiBUaHgNCj4+Pj4+IA0K Pj4+Pj4gVXJpICgiT28tUmVlIikNCj4+Pj4+IA0KPj4+Pj4gQzogOTQ5LTM3OC03NTY4DQo+Pj4+ PiANCj4+Pj4+IA0KPj4+Pj4gDQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPj4+Pj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4+Pj4gc2ZjQGlldGYu b3JnDQo+Pj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPj4+ Pj4gDQo+Pj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPj4gc2ZjIG1haWxpbmcgbGlzdA0KPj4gc2ZjQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NmYw0KPiANCg0K From nobody Tue Jun 30 09:01:41 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2F61ACD42 for ; Tue, 30 Jun 2015 09:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2S2SZsPXK6d for ; Tue, 30 Jun 2015 09:01:38 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1681ACD3D for ; Tue, 30 Jun 2015 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2284; q=dns/txt; s=iport; t=1435680098; x=1436889698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=AZkOkCSvFA438CJk9nVH9+ELHSXxXN7JQ8MdVGcyuMI=; b=EdAC5vcCKtwj+U8Et6pXHhKetNZAr3WriewBHV0/KxkErh/2mWV/vTM0 jhGZRsLO7E0Ru9qpcKaShG4ImNlaUoMnD4PEGSqbOSMXwCqdLmjlfno24 NFXnXbFD4lnReQFQTD2+FgP85j2cKPu/2AxRv5AR8CRwD8QfnGKJrj/l5 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/BABUvJJV/5RdJa1bgxFUXwa9RoFhCoV4AoFPORMBAQEBAQEBgQqEIwEBBAEBAWsLEAIBCBguJwslAgQBDQWILw3IBgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0qELVkHhCsFhwOFSIc8AYtWgTqEEpJxJmODF28BgQJDgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,378,1432598400"; d="scan'208";a="164327679" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2015 16:01:37 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t5UG1amF032294 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jun 2015 16:01:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.177]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 11:01:36 -0500 From: "Reinaldo Penno (repenno)" To: "Jim Guichard (jguichar)" , "sfc@ietf.org" Thread-Topic: [sfc] SFC WG agenda slots - Prague Thread-Index: AQHQsOmuFIw1+/NXJ0OcpkbP+ocVYp3FShyA///OnYA= Date: Tue, 30 Jun 2015 16:01:36 +0000 Message-ID: References: <5592845D.8040704@lab.ntt.co.jp> In-Reply-To: <5592845D.8040704@lab.ntt.co.jp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.9.150325 x-originating-ip: [10.24.139.139] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Keith Burns \(krb\)" Subject: Re: [sfc] SFC WG agenda slots - Prague X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 16:01:40 -0000 Hello Jim, we would like a slot to present the integration of SFC and Group Based Policy in the context of ODL and OpenvSwitch. We intend to touch on the following points: - Overall integration picture and goals - Interesting problems we faced and solved within SFC such as: - Overlapping networking contexts - OpenvSwitch NSH data plane - SFC Yang models augmentations and changes. Thanks, Reinaldo =20 On 6/30/15, 4:58 AM, "Shunsuke Homma" wrote: >Hi Jim, > >I reflected feedback, which we received at the Dallas meeting, onto >draft-homma-sfc-forwarding-methods-analysis, and I would like to request >a slot to present it. > >Thanks, >Shunsuke > >On 2015/06/27 23:58, Jim Guichard (jguichar) wrote: >> Greetings WG: >> >> Our meeting in Prague is fast approaching. As always the goal of the >> meeting will be to make the best use of our limited face-to-face time. >> With that in mind we welcome requests for agenda time. >> >> As we build the meeting agenda our goal will be to select presentations >> that best further the work of the WG, and that generally means focusing >> on key charter deliverables and topics with important open issues to >> resolve. When making a request please consider what you think the WG >> should do with its content =AD for example: >> >> * Does the document have useful content that should be moved into >> another WG document or progress on its own merit >> * Does the content have a good basis for one of the WG documents per >> the charter >> * Should the document content be merged with one or more other >> documents, so that a combined document could become a WG document >> >> Jim & Thomas >> >> >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >> > > >--=20 >---------------------------------- >Shunsuke Homma > >TEL: +81 422 59 3486 >FAX: +81 422 60 7460 > >NTT Network Service System Labs. >Musashino city, Tokyo, Japan >---------------------------------- > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Jun 30 13:44:34 2015 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC951B2EFB for ; Tue, 30 Jun 2015 13:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRMlONQ5F8Ai for ; Tue, 30 Jun 2015 13:44:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CFE1B2EEE for ; Tue, 30 Jun 2015 13:44:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55721; q=dns/txt; s=iport; t=1435697066; x=1436906666; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=gUoE+RHACytb8i2rIjWGpjWuuv0n3E4X82VP1IBaBTk=; b=jW776FFNlLYtd/sSCQbG0JhyxXly3SHzqYRJ0vpRTNXhy6xtgcEiP78X MZTXqf7b5w+9QlRnYt4mRUw9E5uK9MdQ8j1H4CJorx8D23JZDkbMGsUjz R+QHGvahGfvuLVCk4WfgfX0I7eM4bwsREpatDNNez6hlkXu0/Tl4rIaPS E=; X-Files: signature.asc : 841 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D4AwBz/pJV/5hdJa1YA4JFTFRfBoMYuiYJgUgZAQmFeAKBVTgUAQEBAQEBAYEKhCIBAQEDAQEBASAERwsFBwQCAQgRAQMBAQEgAQYDAgInCxQDBggCBA4FDogZCA2ySZZ/AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLSoQtAUgQBwYLglcvgRQFhRyOawGCJIFRhUGCIIE6hBKDDYdhiAMmY4EpHIFSb4EDAR8jgQIBAQE X-IronPort-AV: E=Sophos;i="5.15,380,1432598400"; d="asc'?scan'208,217";a="5967280" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jun 2015 20:44:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t5UKiPrH016462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jun 2015 20:44:25 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.112]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 30 Jun 2015 15:44:24 -0500 From: "Carlos Pignataro (cpignata)" To: "Elzur, Uri" Thread-Topic: [sfc] clarification on SFC and Overlay interaction Thread-Index: AQHQSjCk/CO92w19PkOCqp0Z1D8ImZzz3I0wgACUXQD//3x9gIAAiO2AgMOJl6CADQlKAIAArLQAgACTMACAAApagIAAVxSA Date: Tue, 30 Jun 2015 20:44:23 +0000 Message-ID: <6C7E9E36-40C4-4D0A-80AF-E74B9CB8C758@cisco.com> References: <7E05C330D7FD6D4FAD0728C46B89958581B7E39A@ORSMSX114.amr.corp.intel.com> <54E262B8.2010605@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E414@ORSMSX114.amr.corp.intel.com> <54E27BFA.2010608@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581B7E4A5@ORSMSX114.amr.corp.intel.com> <54E28085.8070803@joelhalpern.com> <7E05C330D7FD6D4FAD0728C46B89958581C98149@ORSMSX114.amr.corp.intel.com> <5EC6B28A-0F3C-4E28-B596-394DDB9EB89D@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CA902C@ORSMSX114.amr.corp.intel.com> <2B8D89D3-C772-4ED7-A3FE-AC923019E7F4@cisco.com> <7E05C330D7FD6D4FAD0728C46B89958581CAA072@ORSMSX114.amr.corp.intel.com> In-Reply-To: <7E05C330D7FD6D4FAD0728C46B89958581CAA072@ORSMSX114.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.82.213.226] Content-Type: multipart/signed; boundary="Apple-Mail=_24094F09-BB63-4D53-8919-0B1AF618C0EB"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Joel Halpern Direct , "sfc@ietf.org" Subject: Re: [sfc] clarification on SFC and Overlay interaction X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 30 Jun 2015 20:44:33 -0000 --Apple-Mail=_24094F09-BB63-4D53-8919-0B1AF618C0EB Content-Type: multipart/alternative; boundary="Apple-Mail=_FFABAAD5-38F5-4333-8B03-0433D4B00525" --Apple-Mail=_FFABAAD5-38F5-4333-8B03-0433D4B00525 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Uri, Thanks for the follow-up, please see inline. > On Jun 30, 2015, at 11:32 AM, Elzur, Uri wrote: >=20 > Hi Carlos >=20 > Pls see below [UE] >=20 > Thx >=20 > Uri (=E2=80=9COo-Ree=E2=80=9D) > C: 949-378-7568 >=20 > -----Original Message----- > From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com = ] > Sent: Tuesday, June 30, 2015 7:56 AM > To: Elzur, Uri > Cc: Joel Halpern Direct; sfc@ietf.org > Subject: Re: [sfc] clarification on SFC and Overlay interaction >=20 > Hi, Uri, >=20 > Thanks for the comments, please see inline. >=20 >> On Jun 30, 2015, at 2:08 AM, Elzur, Uri wrote: >>=20 >> Hi Carlos >>=20 >> Thanks for following up. Few comments >>=20 >> 1) There is an impression (by some) that SFC REQUIRES an independent >> layer EVEN if one has an overlay deployed. Without pointing out ANY >> technology, a sentence like =E2=80=9CWhile this architecture = describes >> functionally distinct logical components and promotes transport >> independence, the service chaining layer can be combined in various >> ways with an overlay=E2=80=9D can explain that point. BTW: In the NSH = draft, >> we do make the assumption that there is an Overlay on top of which = SFC >> (NSH) is deployed. This Overlay can be dedicated to NSH or shared >> with an overlay for network virtualization=E2=80=A6 >>=20 >=20 > If I read this correctly, you are proposing to add =E2=80=9Cpromotes = transport independence=E2=80=9D. I think that the document already = covers this point in detail. Also, it is not the service layer that is = combined, but rather the components, so part of this re-write could be a = bit confusing. >=20 > I am happy to try to rewrite and sharpen this sentence, but I really = think that nothing you say is precluded. > [UE] the point is about building SFC into an existing NetVirt Overlay. = To sharpen that point, I'm adding albeit that SFC = promotes/assumes/mandates Transport independence, merging SFC into an = exisiting overlay is possible. I think it takes clear statement for = folks to see as it comes across to me and others as if this is not = possible Let me push back a bit more on this. The document already has statements = like this: One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. And Section 4.1 seems quite explicit. What makes you think from the document that transport independence is = not the case? >=20 >> 2) Classifier vs SFF =E2=80=93 have looked into rev 9 of the arch = draft, assume the Classifier is the entity that inserts the NSH header = i.e. encapsulates (see figure 2), we may want to update the = architectural diagram (fig 3) to clearly show the Service Classifier as = part of the architecture. >=20 > Figure 2 already shows the classifier as part of the architecture. I = am not sure how to update Figure 3 without making it unreadable. = Remember fig 3 is not showing and end-to-end view of the SFP. > [UE] without a classifier Fig 3 is incomplete IMHO, it is the = Classifier that is located at the boundary of the non encapsulated and = SFC-encapsulated world. And this is also why I was proposing to update = the definition. The suggestion is to make it clear it is not theSFF that = is encapsulating the first SFC packet >=20 I don=E2=80=99t disagree with this comment. However, I was asking for a = more pragmatic answer: how (in the ascii visual) do you propose to = improve the art to add the classifier (since it is quite full as is)? Figure 3 does not show the packet flow (from classifier, etc.) I am most certainly not opposed to this, and happy to update it =E2=80=94 = I am just not sure how. An alternative, is to actually rename the caption of the figure (to say = =E2=80=9Csome SFC arch components=E2=80=9D) I do believe this is not a concern in any case, since Figure 2 is quite = explicit... >> Also may want to update the Classifier definition to that end (like = in >> the above, a classifier can be integrated into the SFF, then we may >> want to mention that. In any case, the SFF performs the NSH >> decapsulation) >=20 > I am hesitant to add a very specific example to the general sentence = above. Otherwise, we might end up implying that other combinations are = not possible. Since the role of classification and use of the SFC = encapsulation is covered in detail in full sections of the doc, I=E2=80=99= d recommend we do not try to summarize here. > [UE] not suggesting to limit the generality of the architecture and = for me there is no need to include the example of a classifier = integrated into SFF. On the contrary I much prefer to see the above = clarification of the Classifier independent role >=20 Can you point out to where this is not allowed? I fear that next would = be =E2=80=9Cwell, why not add that component A can be integrated into = component B, and component =CE=B2 into component =CE=B1, and =E2=80=A6" Thanks, =E2=80=94 Carlos. > We welcome other comments on this of course, >=20 > Thanks, >=20 > =E2=80=94 Carlos. >=20 >>=20 >> Thx >>=20 >> Uri (=E2=80=9COo-Ree=E2=80=9D) >> C: 949-378-7568 >>=20 >> -----Original Message----- >> From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] >> Sent: Monday, June 29, 2015 12:51 PM >> To: Elzur, Uri >> Cc: Joel Halpern Direct; sfc@ietf.org >> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>=20 >> Hi, Uri, >>=20 >> I added the following text at the beginning of Section 4: =E2=80=9CWhil= e this architecture describes functionally distinct logical components, = they could combined in various ways in deployed products.=E2=80=9D >>=20 >> I think this covers all potential cases, instead of singling out one = example. >>=20 >> The Section now starts like this: >>=20 >> --->8--- >> The SFC Architecture is built out of architectural building blocks >> which are logical components; these logical components are >> classifiers, service function forwarders (SFF), the service = functions >> themselves (SF), and SFC-proxies. While this architecture describes >> functionally distinct logical components, they could combined in >> various ways in deployed products. >>=20 >> They are interconnected using the SFC Encapsulation. This results = in >> a high level logical architecture of an SFC-enabled Domain which >> comprises: >> --->8--- >>=20 >> Does this help? >>=20 >> Thanks, >>=20 >> =E2=80=94 Carlos. >>=20 >>> On Jun 22, 2015, at 10:20 AM, Elzur, Uri = wrote: >>>=20 >>> Hi Joel >>>=20 >>> I've recently reviewed the latest draft v 09. I still miss such a = clarification. Pls point me in the right direction if it does exist = somewhere in chapter 4. >>>=20 >>> I'd like to suggest we add language referring to the specific = example >>> outlined below of SFF integrated with an overlay manager as a way to >>> show how the logical elements can be implemented as part of an >>> overlay and to clarify we are not talking ONLY about a completely >>> independent new Service overlay >>>=20 >>> Thx >>>=20 >>> Uri ("Oo-Ree") >>> C: 949-378-7568 >>>=20 >>> -----Original Message----- >>> From: Joel Halpern Direct [mailto:jmh.direct@joelhalpern.com] >>> Sent: Monday, February 16, 2015 3:43 PM >>> To: Elzur, Uri; sfc@ietf.org >>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>=20 >>> It seems like we can (and unless I am very confused, should) add = such a statement in the base portion of section 4. Carlos and I will = work on this. Thank you for calling our attention to the omission. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 2/16/15 6:36 PM, Elzur, Uri wrote: >>>> Agree. I do not recall however any such statement. I do recall many >>>> statement like section 4.5, indicating the separation and referring >>>> to topological and transport independence. Pls point me to the >>>> paragraph or we may want to add such clarification in the next rev >>>>=20 >>>> Thx >>>>=20 >>>> Uri ("Oo-Ree") >>>> C: 949-378-7568 >>>>=20 >>>> -----Original Message----- >>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>> Sent: Monday, February 16, 2015 3:24 PM >>>> To: Elzur, Uri; sfc@ietf.org >>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>>=20 >>>> If we do not have text in there that says that these logical = components may be combined in real world implementations or deployments = with each other or with components from outside the architecture, I = could see adding that. I thought we already said it. >>>>=20 >>>> I would prefer not to add comments on any specific deployments, = because there are so many ways to do so, and as far as I can tell, most = of us think the one in our head is the most likely / common / useful. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 2/16/15 5:36 PM, Elzur, Uri wrote: >>>>> Joel >>>>>=20 >>>>> Sounds good to me. However a clarification, maybe in the format of >>>>> a comment or example (as I suspect this may be a very common case, >>>>> for >>>>> some) in the draft will be of value >>>>>=20 >>>>> Thx >>>>>=20 >>>>> Uri ("Oo-Ree") >>>>> C: 949-378-7568 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Joel M. Halpern [mailto:jmh@joelhalpern.com] >>>>> Sent: Monday, February 16, 2015 1:36 PM >>>>> To: Elzur, Uri; sfc@ietf.org >>>>> Subject: Re: [sfc] clarification on SFC and Overlay interaction >>>>>=20 >>>>> One of the key reasons for identifying the logical components is = that there are a broad range of ways that they can be composed. That = does sound like one possible composition. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> On 2/16/15 4:32 PM, Elzur, Uri wrote: >>>>>> While section 4.5 of draft-ietf-sfc-architecture-04, states >>>>>> "underneath the SFF there are components responsible for >>>>>> performing the transport >>>>>> (overlay) forwarding. They do not consults the SFC encapsulation >>>>>> or inner payload for performing these forwarding.", there is no >>>>>> reason to exclude the following private case, I'd assume. This is >>>>>> the case where the SFF is effectively integrated with the Overlay >>>>>> manager, or instantiated in other overlay network elements (e.g. >>>>>> vSwitch), enabling in essence SFC within an Overlay network, with >>>>>> no need for a separate SFC domain. >>>>>>=20 >>>>>> To be clear (or clearer), this is not to suggest that transport = or >>>>>> topological independence can be or should be bend, but simply to >>>>>> suggest a deployment scenario that may be popular for limited >>>>>> scale SFC >>>>>>=20 >>>>>> Thx >>>>>>=20 >>>>>> Uri ("Oo-Ree") >>>>>>=20 >>>>>> C: 949-378-7568 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> sfc mailing list >>>>>> sfc@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sfc >>>>>>=20 >>>>>=20 >>>=20 >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc --Apple-Mail=_FFABAAD5-38F5-4333-8B03-0433D4B00525 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Uri,

Thanks for the follow-up, please see inline.

On Jun 30, 2015, at 11:32 AM, Elzur, Uri <uri.elzur@intel.com>= wrote:

Hi Carlos

Pls see below [UE]

Thx

Uri = (=E2=80=9COo-Ree=E2=80=9D)
C: 949-378-7568

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com] 
Sent: Tuesday, June 30, 2015 7:56 AM
To: Elzur, Uri
Cc: Joel Halpern Direct; sfc@ietf.org
Subject: Re: [sfc] = clarification on SFC and Overlay interaction

Hi, Uri,

Thanks for the comments, please see = inline.

On Jun 30, 2015, at 2:08 AM, Elzur, Uri <uri.elzur@intel.com>= wrote:

Hi Carlos

Thanks for following up. Few comments

1) There is an impression (by some) that SFC REQUIRES an = independent 
layer EVEN if one has an overlay deployed. Without pointing = out ANY 
technology, a sentence like =E2=80=9CWhile this architecture = describes 
functionally distinct logical components and promotes = transport 
independence, the service chaining layer can be combined in = various 
ways with an overlay=E2=80=9D can explain that point. BTW: In = the NSH draft, 
we do make the assumption that there is an Overlay on top of = which SFC 
(NSH) is deployed. This Overlay can be dedicated to NSH =  or shared 
with an overlay for network virtualization=E2=80=A6


If I read this correctly, you are proposing to = add =E2=80=9Cpromotes transport independence=E2=80=9D. I think that the = document already covers this point in detail. Also, it is not the = service layer that is combined, but rather the components, so part of = this re-write could be a bit confusing.

I am happy to try to rewrite and sharpen this = sentence, but I really think that nothing you say is = precluded.
[UE] the point is about = building SFC into an existing NetVirt Overlay. To sharpen that point, = I'm adding albeit that SFC promotes/assumes/mandates Transport = independence, merging SFC into an exisiting overlay is possible. I think = it takes clear statement for folks to see as it comes across to me and = others as if this is not possible

Let me push back a bit more on this. The document = already has statements like this:
  =  One of the key architecture principles of SFC is that the = SFC
   encapsulation remain transport = independent.

And= Section 4.1 seems quite explicit.

What makes you think from the document = that transport independence is not the case?


2) Classifier vs SFF = =E2=80=93 have looked into rev 9 of the arch draft, assume the = Classifier is the entity that inserts the NSH header i.e. encapsulates = (see figure 2), we may want to update the architectural diagram (fig 3) = to clearly show the Service Classifier as part of the architecture.

Figure 2 already shows the = classifier as part of the architecture. I am not sure how to update = Figure 3 without making it unreadable. Remember fig 3 is not showing and = end-to-end view of the SFP.
[UE] without a classifier = Fig 3 is incomplete IMHO, it is the Classifier that is located at the = boundary of the non encapsulated and SFC-encapsulated world. And this is = also why I was proposing to update the definition. The suggestion is to = make it clear it is not theSFF that is encapsulating the first SFC = packet


I don=E2=80=99= t disagree with this comment. However, I was asking for a more pragmatic = answer: how (in the ascii visual) do you propose to improve the art to = add the classifier (since it is quite full as is)?

Figure 3 does not show the packet flow (from = classifier, etc.)

I am most = certainly not opposed to this, and happy to update it =E2=80=94 I am = just not sure how.

An alternative, = is to actually rename the caption of the figure (to say =E2=80=9Csome = SFC arch components=E2=80=9D)

I do = believe this is not a concern in any case, since Figure 2 is quite = explicit...

Also may want to update the Classifier definition to = that end (like in 
the above, a classifier can be integrated into the SFF, then = we may 
want to mention that. In any case, the SFF performs the = NSH 
decapsulation)

I am hesitant to add a very specific example to = the general sentence above. Otherwise, we might end up implying that = other combinations are not possible. Since the role of classification = and use of the SFC encapsulation is covered in detail in full sections = of the doc, I=E2=80=99d recommend we do not try to summarize = here.
[UE] not suggesting to = limit the generality of the architecture and for me there is no need to = include the example of a classifier integrated into SFF. On the contrary = I much prefer to see the above clarification of the Classifier = independent role


Can you = point out to where this is not allowed? I fear that next would be = =E2=80=9Cwell, why not add that component A can be integrated into = component B, and component =CE=B2 in= to component =CE=B1, and =E2=80=A6"

Thanks,

=E2=80=94= Carlos.

We welcome other comments = on this of course,

Thanks,

=E2=80=94 Carlos.


Thx

Uri (=E2=80=9COo-Ree=E2=80=9D)
C: = 949-378-7568

-----Original Message-----
From: Carlos Pignataro (cpignata) [mailto:cpignata@cisco.com]
Sent: Monday, = June 29, 2015 12:51 PM
To: Elzur, Uri
Cc: = Joel Halpern Direct; sfc@ietf.org
Subject: Re: [sfc] = clarification on SFC and Overlay interaction

Hi, Uri,

I added the following = text at the beginning of Section 4: =E2=80=9CWhile this architecture = describes functionally distinct logical components, they could combined = in various ways in deployed products.=E2=80=9D

I think this covers all potential cases, instead of singling = out one example.

The Section now starts = like this:

--->8---
 The SFC Architecture is built out of architectural = building blocks
 which are logical components; these = logical components are
 classifiers, service function = forwarders (SFF), the service functions
 themselves = (SF), and SFC-proxies.  While this architecture describes
 functionally distinct logical components, they could = combined in
 various ways in deployed products.

 They are interconnected using the SFC = Encapsulation.  This results in
 a high level = logical architecture of an SFC-enabled Domain which
 comprises:
--->8---

Does this help?

Thanks,

=E2=80=94 Carlos.

On Jun 22, 2015, at = 10:20 AM, Elzur, Uri <uri.elzur@intel.com> wrote:

Hi Joel

I've recently reviewed = the latest draft v 09. I still miss such a clarification. Pls point me = in the right direction if it does exist somewhere in chapter 4.

I'd like to suggest we add language referring = to the specific example 
outlined = below of SFF integrated with an overlay manager as a way to 
show how the = logical elements can be implemented as part of an 
overlay and = to clarify we are not talking ONLY about  a completely 
independent = new Service overlay

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Joel Halpern = Direct [mailto:jmh.direct@joelhalpern.com]
Sent: = Monday, February 16, 2015 3:43 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

It seems like we can (and = unless I am very confused, should) add such a statement in the base = portion of section 4.  Carlos and I will work on this.  Thank = you for calling our attention to the omission.

Yours,
Joel

On = 2/16/15 6:36 PM, Elzur, Uri wrote:
Agree. I do not recall however any such statement. I do = recall many 
statement like section 4.5, indicating the separation and = referring 
to topological and transport independence. Pls point me to = the 
paragraph or we may want to add such clarification in the = next rev

Thx

Uri= ("Oo-Ree")
C: 949-378-7568

-----Original Message-----
From: Joel M. = Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, = February 16, 2015 3:24 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

If we do not have text in there = that says that these logical components may be combined in real world = implementations or deployments with each other or with components from = outside the architecture, I could see adding that.  I thought we = already said it.

I would prefer not to add = comments on any specific deployments, because there are so many ways to = do so, and as far as I can tell, most of us think the one in our head is = the most likely / common / useful.

Yours,
Joel

On 2/16/15 5:36 PM, Elzur, = Uri wrote:
Joel

Sounds good to me. However a clarification, = maybe in the format of 
a comment or = example (as I suspect this may be a very common case, 
for
some) in the draft will be of value

Thx

Uri ("Oo-Ree")
C: 949-378-7568

-----Original = Message-----
From: Joel M. Halpern [mailto:jmh@joelhalpern.com]
Sent: Monday, = February 16, 2015 1:36 PM
To: Elzur, Uri; sfc@ietf.org
Subject: Re: [sfc] clarification on SFC and Overlay = interaction

One of the key reasons for = identifying the logical components is that there are a broad range of = ways that they can be composed.  That does sound like one possible = composition.

Yours,
Joel

On 2/16/15 4:32 PM, Elzur, Uri wrote:
While section 4.5 of = draft-ietf-sfc-architecture-04, states 
"underneath = the SFF there are components responsible for 
performing = the transport
(overlay) forwarding. They do not consults = the SFC encapsulation 
or inner = payload for performing these forwarding.", there is no 
reason to = exclude the following private case, I'd assume. This is 
the case = where the SFF is effectively integrated with the Overlay 
manager, or = instantiated in other overlay network elements (e.g. 
vSwitch), = enabling in essence SFC within an Overlay network, with 
no need for = a separate SFC domain.

To be clear (or = clearer), this is not to suggest that transport or 
topological = independence can be or should be bend, but simply to 
suggest a = deployment scenario that may be popular for limited 
scale SFC

Thx

Uri = ("Oo-Ree")

C: 949-378-7568



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



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

= --Apple-Mail=_FFABAAD5-38F5-4333-8B03-0433D4B00525-- --Apple-Mail=_24094F09-BB63-4D53-8919-0B1AF618C0EB 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 iQIcBAEBCAAGBQJVkv+nAAoJEIXgpQGOZny9CIMP/iu8Dm/mlh8Qjr+v2zH5QusQ Y3WtggxzXQZYw0ax4wGYXisCMwwAnFu/8nnchyvPBxexFXYCCj4CPJc8Mu1RUaMU OjqdXRI5rJibrpSrhnJQA1x1J+iXVboog6zvHfTscFVnrkNgFxzrbunzATBC6Y/I mhIeg2Hrvw6iaEmo+efdwn8jUrG2ZTqPVJ5gSVfkILlty0sdlNZGgHbJMeFclRLh 88tffc1cnGKTqpJU8hk3BIgZsJWcGjcaGkwYBBK1mt4lWQs3x4sTFRjNdwIDschu fjE8p2fO3rjsImnEcY1F/AsebS+L7Ugd5Svi8ScwhPI+ehCEXt0QrlKkmCG/FbPI qI6lPNzNgfQu7RUHD/rUbiBKywteA/oAlc5Xo/z2FpkV5dEX5PELQS0ngI/bRpeu l50rvvPeMd/fLO3EvK1nFNiwMlRA6ZyCw35obfp7+cOG4iRuSC/VEwJVX5Eo4Tjq b1HtGPAngdgrbIeBg8vmuHyUvo7m86RxBMHMlEyaqKkH1oWjXbepiFaLX0DqHzA0 t1L1gxv+6D6zkdFG43jBN5FYV5KFQgcxvURUCowri67i0u9yU+qTkaan6Jb/ybLx gnWayHAi28+poZGoN1pEpKMiIUpj0rMmVhUWiXcDpPeOeGffOpsCpsoV0WdV9rex RSU0Bm6DQTKP/6LOSoD2 =DQ+s -----END PGP SIGNATURE----- --Apple-Mail=_24094F09-BB63-4D53-8919-0B1AF618C0EB--