From nobody Mon Nov 3 06:32:27 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E661A038E for ; Mon, 3 Nov 2014 06:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DrI96T1MWnJw for ; Mon, 3 Nov 2014 06:32:20 -0800 (PST) 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 0469C1A0382 for ; Mon, 3 Nov 2014 06:32:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5048; q=dns/txt; s=iport; t=1415025140; x=1416234740; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dWZRUkpQefQcH4hK8bwQl/sa0s+T828jwt7ssUxFkZc=; b=Ce0hqMesC45URXu+sJupC76HvD/rPSqqTeA4qkiM7mSM+5h+ZruLhOWh YlYLuXGSdYtSLcmOek3eTzPhq1MSj/FGXaqdTIEEfX/Rl/YrPKKiD2SMA 4eny5uxVm3Rup6D+K4+a9kt3PS87IKYr6tgFFt8F/wVwUXF7v/Q4hG9n/ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFALqQV1StJA2G/2dsb2JhbABcgmsjVFgEzXwMh0sCgSAWAQEBAQF9hAIBAQEEAQEBaxcEAgEIEQEDAQEoBycLFAMGCAIEARIJiDgBDMdUAQEBAQEBAQEBAQEBAQEBAQEBAQEYkRcGhEUFkhqET4cYgTE9gxCIFYU0hAmCNIFEbAGBR4EDAQEB X-IronPort-AV: E=Sophos;i="5.07,308,1413244800"; d="scan'208";a="368842905" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP; 03 Nov 2014 14:32:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA3EWJkF019072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Nov 2014 14:32:19 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Mon, 3 Nov 2014 08:32:18 -0600 From: "Ken Gray (kegray)" To: Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism Thread-Index: AQHP8gISMJ/u8rBG0kS6N5KtvH7/wpxPAeuA Date: Mon, 3 Nov 2014 14:32:18 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645E24012@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E24012@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.78.82] Content-Type: text/plain; charset="Windows-1252" Content-ID: <58C3492E881B9247A29FB6A2FB0599D3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/GuTVsAq7ShKdZ-uN-8wMSy_eOVo Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 03 Nov 2014 14:32:25 -0000 For starters, it seems as if the authors link two statements as non-debatable fact, when they really =8A are debatable: Section 4.3 " For the approach 1) above, all the forwarding nodes, e.g. SFFs, need to look up the SFF-sequence or SFF-SF-sequence for every packet to determine the next hop. For large flows, i.e. large number of packets in the flow, the processing of interpreting the SFF- sequence/SFF-SF-sequence is repetitive and can be resource Intensive." One would suspect the above is a bad implementation of a forwarder =8A Section 6.1 " As mentioned in the previous section, encoding exact RSP path requiring all involved nodes to interpret SFF-SF-sequence in each packet to establish runtime forwarding policy, which can be resource intensive. This approach is not optimal when the RSP doesn't change very frequently, as in minutes or hours." Not a fact just because it was stated above. You always have to resolve a next hop if you're a forwarder, regardless of the methodology that you learn (or maintain) the next hop. How "expensive" this is would be an implementation detail. Further, it doesn't really appear as if the authors are offering an alternative, so these are (IMO) gratuitous statements that don't have a lot to do with the proposed framework. For the Global restoration sections (section 6): Why doesn't updating the classifier at the headend work for global restoration? Further, the line "This method won't cause any contention issue among all the involved nodes." in section 6.1 is confusing. What does it refer to? Section 6.2 is a boondoggle (we don't need another signaling protocol, IMHO), as is the idea of having coordinated RSP capabilities between the classifiers (see - we don't need another signaling protocol). The SFFs can be updated without having to maintain their consistency through some head-end driven state machine. Changing the SFP on the classifying node implicitly signals the new path. Updating the SFFs is an orchestration/SDN problem. Section 6.3 is a solvable transaction problem - use NETCONF, use OF with barrier messages - is coordinated updates of the forwarders your ultimate concern here? =20 BTW (same section), if you have a single NMS node, yeah, you have problems and restoration of service paths is just one of many. Which leads us to 6.4, which I think is how most of us imagined that SFC was supposed to work, but I don't see the need for "until all the involved SFF nodes complete the installation of the new steering policy for the path." Again, is the main point of this whole paper to beware of the transactional nature of updating the forwarders in the path? You can completely lose the first paragraph of section 7. I hope the authors are not still struggling with the concept of instance anonymity in load balancing (it seems like you had come to grips with that in your Local Repair section), because that concept (more than scale) makes it impossible for the head end to be aware of all instances. The rest of what you describe is essentially "anycast", IMO. On 10/27/14 12:21 PM, "Linda Dunbar" wrote: >Rendered Service Path was introduced by draft-ietf-sfc-architecture to >represent a constrained specification of where packets using a certain >service chain must go. > >This draft proposes a framework to represent RSP and restoration scheme >when some functions on a RSP fails (or to be replaced by new ones). > >We are looking for comments and suggestions. > >Linda & Andy > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, October 27, 2014 11:01 AM >To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >Subject: New Version Notification for draft-dunbar-sfc-path-control-00.txt > > >A new version of I-D, draft-dunbar-sfc-path-control-00.txt >has been successfully submitted by Linda Dunbar and posted to the IETF >repository. > >Name: draft-dunbar-sfc-path-control >Revision: 00 >Title: Framework for Service Function Path Control >Document date: 2014-10-24 >Group: Individual Submission >Pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-path-control-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-dunbar-sfc-path-control/ >Htmlized: =20 >http://tools.ietf.org/html/draft-dunbar-sfc-path-control-00 > > >Abstract: > This draft describes the framework of protection and restoration of > Service Function Path when some service functions on the path fail > or need to be replaced. > > =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 > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 4 08:12:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3281A8AFD for ; Tue, 4 Nov 2014 08:12:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ONqNcM_yySB8 for ; Tue, 4 Nov 2014 08:12:00 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8911A19F5 for ; Tue, 4 Nov 2014 08:11:59 -0800 (PST) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id A5D4F4A6D6BDC for ; Tue, 4 Nov 2014 16:11:52 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id sA4GBrKF021099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 4 Nov 2014 11:11:54 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Tue, 4 Nov 2014 11:11:54 -0500 From: "Dolganow, Andrew (Andrew)" To: "sfc@ietf.org" Thread-Topic: draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwg== Date: Tue, 4 Nov 2014 16:11:53 +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.5.141003 x-originating-ip: [135.5.27.18] Content-Type: multipart/alternative; boundary="_000_D07E5FE1614B1andrewdolganowalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Y0KVzxhvcxfHpt-zME5WNYwrPyA Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Nov 2014 16:12:01 -0000 --_000_D07E5FE1614B1andrewdolganowalcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew --_000_D07E5FE1614B1andrewdolganowalcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1A6FB31A82C19E4A876AF91476C33098@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
During the last IETF there were several attendees (including myself) w= ho voice strong opinion against mandatory the inclusion of the information = beyond based header and service path header. Not all applications require t= he extra overhead. A discussion on the list followed (see attached email that initiated that discussion) o= n alternative encodings including mechanisms like use of one of the reserve= d bit or using another MD Type value to represent header without Mandatory = Context Headers.

Can the authors comment on whether they are strongly opposed to includ= e in their draft a proposal that has an option to encode the NSH without th= e Mandatory Context Headers? I am OK with an encoding that either:
  • makes  Mandatory Context Headers optional or
  • Has two types= of NSG MD Type 0x1 - the mandatory context headers are present, 0x2 the ma= ndatory context header are not included  (optional variable length met= adata could still be used in that type  of header)

Andrew


--_000_D07E5FE1614B1andrewdolganowalcatellucentcom_-- From nobody Tue Nov 4 15:47:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371CA1A1A31 for ; Tue, 4 Nov 2014 15:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 iD4-jNZMBRLs for ; Tue, 4 Nov 2014 15:47:25 -0800 (PST) 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 6A7DD1A064C for ; Tue, 4 Nov 2014 15:47:24 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOK57342; Tue, 04 Nov 2014 23:47:23 +0000 (GMT) Received: from DFWEML706-CHM.china.huawei.com (10.193.5.225) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 4 Nov 2014 23:47:22 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml706-chm ([10.193.5.225]) with mapi id 14.03.0158.001; Tue, 4 Nov 2014 15:47:17 -0800 From: Linda Dunbar To: "Ken Gray (kegray)" , "sfc@ietf.org" Thread-Topic: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism Thread-Index: AQHP93L94RXdgl+Db0qVE4aDSBNpY5xPgJ+Q Date: Tue, 4 Nov 2014 23:47:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E2B7F8@dfweml701-chm> References: <4A95BA014132FF49AE685FAB4B9F17F645E24012@dfweml701-chm> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.199] Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/g21eqMyHSnD8I5A2VDnQJHbGX8I Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 04 Nov 2014 23:47:29 -0000 Ken,=20 Thanks for your comments. Replies are inserted below: -----Original Message----- From: Ken Gray (kegray) [mailto:kegray@cisco.com]=20 Sent: Monday, November 03, 2014 8:32 AM To: Linda Dunbar; sfc@ietf.org Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Pat= h control Mechanism Section 4.3 " For the approach 1) above, all the forwarding nodes, e.g. SFFs, need to look up the SFF-sequence or SFF-SF-sequence for every packet to determine the next hop. For large flows, i.e. large number of packets in the flow, the processing of interpreting the SFF- sequence/SFF-SF-sequence is repetitive and can be resource Intensive." One would suspect the above is a bad implementation of a forwarder =A9 [Linda] Yes the wording needs some enhancement. The intent is to say if the= forwarding nodes forward traffic based on the SFF-SF-sequence encoded in t= he packets, the "lookup" entry is the "SFF-SF-sequence" in the packet. Spec= ial consideration is needed.=20 What do you think of changing to the following text: "The approach 1) above is basically "two dimensional" Source Routing, not = only with explicit SFF nodes on the path, but also with exact SF sequence b= y each SFF node. For large flows, i.e. large number of packets in the flow,= repeating the SFF-sequence/SFF-SF-sequence encoding in all packets can was= te bandwidth, which is not suitable for environment where bandwidth is limi= ted."=20 Section 6.1 " As mentioned in the previous section, encoding exact RSP pat= h requiring all involved nodes to interpret SFF-SF-sequence in each packet to establish runtime forwarding policy, which can be resource intensive. This approach is not optimal when the RSP doesn't change very frequently, as in minutes or hours." Not a fact just because it was stated above. You always have to resolve a = next hop if you're a forwarder, regardless of the methodology that you lear= n (or maintain) the next hop. [Linda] Yes, you can use "Source Routing" as developed by SPRING. But most = of today deployed routers use pre-established "forwarding table" for next h= op.=20 How "expensive" this is would be an implementation detail. Further, it do= esn't really appear as if the authors are offering an alternative, so these= are (IMO) gratuitous statements that don't have a lot to do with the propo= sed framework. [Linda] How about changing the wording to the following?=20 " As mentioned in the previous section, encoding exact RSP path in every pa= cket has the benefit and the issues of source routing. This approach may no= t be optimal when the RSP doesn't change very frequently, as in minutes or = hours, or bandwidth is limited." For the Global restoration sections (section 6): Why doesn't updating the classifier at the headend work for global restorat= ion? [Linda] Yes, one method is to escalate fault to the head end classifier nod= e. Another method is regional repair, as MPLS's FRR.=20 Further, the line "This method won't cause any contention issue among all t= he involved nodes." in section 6.1 is confusing. What does it refer to? [Linda] it means " Encoding the exact SFF-SF-sequence in every packet won't= cause any contention issue among all the involved nodes when changes occur= ." Section 6.2 is a boondoggle (we don't need another signaling protocol, IMHO= ), as is the idea of having coordinated RSP capabilities between the classi= fiers (see - we don't need another signaling protocol). The SFFs can be up= dated without having to maintain their consistency through some head-end dr= iven state machine. Changing the SFP on the classifying node implicitly si= gnals the new path. Updating the SFFs is an orchestration/SDN problem. [Linda] This section is NOT to introduce another signaling protocol. This s= ection is to describe using MPLS RSVP to establish the RSP. We will improve= the wording to reflect this.=20 Section 6.3 is a solvable transaction problem - use NETCONF, use OF with ba= rrier messages - is coordinated updates of the forwarders your ultimate con= cern here? =20 BTW (same section), if you have a single NMS node, yeah, you have problems = and restoration of service paths is just one of many. Which leads us to 6.4, which I think is how most of us imagined that SFC wa= s supposed to work, but I don't see the need for "until all the involved SF= F nodes complete the installation of the new steering policy for the path."= Again, is the main point of this whole paper to beware of the transaction= al nature of updating the forwarders in the path? [Linda] Glad to see that is "most of us imaged what SFC was supposed to wor= k". The main point is to describe an approach with "Source routing" until a= ll the SFF nodes nailed up the proper connections to SF nodes and next hop = SFF node.=20 You can completely lose the first paragraph of section 7. I hope the autho= rs are not still struggling with the concept of instance anonymity in load = balancing (it seems like you had come to grips with that in your Local Repa= ir section), because that concept (more than scale) makes it impossible for= the head end to be aware of all instances. [Linda] This is not about multiple same-function "instances" attached to on= e SFF node. Those SFICs can be handled by the SFF via local load balance as= described in SFC-Arch. This section is to describe scenario of the Figure = in Section 6.=20 The rest of what you describe is essentially "anycast", IMO. [Linda] How?=20 Thank you very much.=20 Linda=20 On 10/27/14 12:21 PM, "Linda Dunbar" wrote: >Rendered Service Path was introduced by draft-ietf-sfc-architecture to=20 >represent a constrained specification of where packets using a certain=20 >service chain must go. > >This draft proposes a framework to represent RSP and restoration scheme=20 >when some functions on a RSP fails (or to be replaced by new ones). > >We are looking for comments and suggestions. > >Linda & Andy > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Monday, October 27, 2014 11:01 AM >To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >Subject: New Version Notification for=20 >draft-dunbar-sfc-path-control-00.txt > > >A new version of I-D, draft-dunbar-sfc-path-control-00.txt >has been successfully submitted by Linda Dunbar and posted to the IETF=20 >repository. > >Name: draft-dunbar-sfc-path-control >Revision: 00 >Title: Framework for Service Function Path Control >Document date: 2014-10-24 >Group: Individual Submission >Pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-dunbar-sfc-path-control-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-dunbar-sfc-path-control/ >Htmlized: =20 >http://tools.ietf.org/html/draft-dunbar-sfc-path-control-00 > > >Abstract: > This draft describes the framework of protection and restoration of > Service Function Path when some service functions on the path fail > or need to be replaced. > > =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. > >The IETF Secretariat > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 4 19:06:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55691A87A8 for ; Tue, 4 Nov 2014 19:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw5_e9gF1hdK for ; Tue, 4 Nov 2014 19:06:01 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 22B411A87A7 for ; Tue, 4 Nov 2014 19:06:00 -0800 (PST) Received: from mfs6.rdh.ecl.ntt.co.jp (mfs6.rdh.ecl.ntt.co.jp [129.60.39.149]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id sA535wXm010067; Wed, 5 Nov 2014 12:05:58 +0900 Received: from mfs6.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 6069FE00CC; Wed, 5 Nov 2014 12:05:58 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs6.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 54DE7E00CB; Wed, 5 Nov 2014 12:05:58 +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 sA535oAr004227; Wed, 5 Nov 2014 12:05:58 +0900 Message-ID: <5459943D.5080901@lab.ntt.co.jp> Date: Wed, 05 Nov 2014 12:06:37 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.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: http://mailarchive.ietf.org/arch/msg/sfc/G3oyMSeB2XymsHgOt77LI5XzaX4 Subject: Re: [sfc] SFC Honolulu meeting agenda X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 05 Nov 2014 03:06:05 -0000 Hi Jim and Thomas, We would like to have a 5-10min slot for presenting the draft about forwarding methods analysis: http://www.ietf.org/internet-drafts/draft-homma-sfc-forwarding-methods-analysis-00.txt The purpose of this draft is clarifying the most applicable forwarding method based on network or service requirements. We believe that this analysis will be important for SFC and we would like to discuss the topic further. cheers, Shunsuke (2014/10/06 22:26), Jim Guichard (jguichar) wrote: > Greetings WG: > > Our meeting at the upcoming Honolulu venue is fast approaching. As > always, the goal of the meeting will be to make the best use of limited > face-to-face time. > > As we build the meeting agenda we welcome requests for agenda time. As > always, the goal of a meeting slot is to best further the work of the > WG, and that generally means focussing on key charter deliverables and > topics with important open issues to resolve. In the case of individual > IDs, the goal isn’t necessarily to present what is in the draft but > rather to help the WG decide what to do with the ID. With that in mind, > when making an agenda 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 it’s own merit > * Does the content have a good basis for one of the WG documents per > the charter (in order for that to happen the document needs to be > the most appropriate out of the collection of related documents) > * 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 Wed Nov 5 12:13:36 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCEE1ACD17 for ; Wed, 5 Nov 2014 12:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 kilvMAAh5FM3 for ; Wed, 5 Nov 2014 12:13:31 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4361ACFDA for ; Wed, 5 Nov 2014 12:10:24 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml401-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHS05251; Wed, 05 Nov 2014 14:10:23 -0600 (CST) Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 5 Nov 2014 20:10:22 +0000 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml703-chm ([10.193.5.130]) with mapi id 14.03.0158.001; Wed, 5 Nov 2014 12:10:11 -0800 From: Linda Dunbar To: Xuxiaohu , Lizhenbin , "hshah@ciena.com" , "luismiguel.contrerasmurillo@telefonica.com" , "sfc@ietf.org" Thread-Topic: Questions to draft-xu-sfc-using-mpls-spring-01 Thread-Index: Ac/5NH+0BkXIsBNTTbObisORG5WiVA== Date: Wed, 5 Nov 2014 20:10:10 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645E2C35A@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.199] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645E2C35Adfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/j-nL0Mrsy7uUuKq239XnvOAj7l4 Subject: [sfc] Questions to draft-xu-sfc-using-mpls-spring-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 20:13:34 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645E2C35Adfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Xiao Hu, et al, With the MPLS Stacked Label approach described in your draft, there is real= ly no need for packets to be encapsulated with SFC header anymore, is it? Or the MPLS label is effectively the SFC ID, correct? Your draft describes the SFF nodes advertise SIDs (Segment) for their local= ly attached SFs. Does it mean that each SF has a unique SID? How about dif= ferent instances of same Service Function? Does the SFF also has it own SI= D? Each SFF may have many SFs attached to different ports. Does SFF expose tho= se port information to head end classifier node? Thank you very much, Linda --_000_4A95BA014132FF49AE685FAB4B9F17F645E2C35Adfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Xiao Hu, et al,

 

 

With the MPLS Stacked Label approach described in yo= ur draft, there is really no need for packets to be encapsulated with SFC h= eader anymore, is it?

Or the MPLS label is effectively the SFC ID, correct= ?

 

Your draft describes the SFF nodes advertise SIDs (S= egment) for their locally attached SFs. Does it mean that each SF  has= a unique SID? How about different instances of same Service Function? &nbs= p;Does the SFF also has it own SID?

Each SFF may have many SFs attached to different por= ts. Does SFF expose those port information to head end classifier node?

 

Thank you very much,

 

Linda  

--_000_4A95BA014132FF49AE685FAB4B9F17F645E2C35Adfweml701chm_-- From nobody Wed Nov 5 17:58:11 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3821D1A001D for ; Wed, 5 Nov 2014 17:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 SGNmoZElLh3s for ; Wed, 5 Nov 2014 17:58:08 -0800 (PST) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058C01A0010 for ; Wed, 5 Nov 2014 17:58:07 -0800 (PST) Received: from 172.18.9.243 (EHLO lhreml403-hub.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHS26002; Wed, 05 Nov 2014 19:58:07 -0600 (CST) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 6 Nov 2014 01:58:05 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Thu, 6 Nov 2014 09:57:56 +0800 From: Xuxiaohu To: Linda Dunbar , Lizhenbin , "hshah@ciena.com" , "luismiguel.contrerasmurillo@telefonica.com" , "sfc@ietf.org" Thread-Topic: Questions to draft-xu-sfc-using-mpls-spring-01 Thread-Index: Ac/5NH+0BkXIsBNTTbObisORG5WiVAALhJvQ Date: Thu, 6 Nov 2014 01:57:55 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CA70C@NKGEML512-MBS.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645E2C35A@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E2C35A@dfweml701-chm> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CA70CNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bxWUzbYV58MQct_0AuquO0R9pKM Subject: Re: [sfc] Questions to draft-xu-sfc-using-mpls-spring-01 X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 01:58:10 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CA70CNKGEML512MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Your observation is correct. In the MPLS-SPRING-based SFC approach as desc= ribed in the draft, since the SFC or SFP information has been encoded in an= MPLS label stack, there is no need for carrying the SFC header anymore for= the SFC or SFP indication purpose. As for the SF SID allocation, each SFF which has at least one instance of a= given SF attached to it would allocate a label for that SF, rather than al= locating a label for each instance. In other words, multiple instances of a= given SF would share the same label. How to make a load-balance among thos= e instances of a given SF is local matter of the SFF. Yes, each SFF would have its own SID which is actually the node SID for tha= t SFF. Best regards, Xiaohu From: Linda Dunbar Sent: Thursday, November 06, 2014 4:10 AM To: Xuxiaohu; Lizhenbin; hshah@ciena.com; luismiguel.contrerasmurillo@telef= onica.com; sfc@ietf.org Subject: Questions to draft-xu-sfc-using-mpls-spring-01 Xiao Hu, et al, With the MPLS Stacked Label approach described in your draft, there is real= ly no need for packets to be encapsulated with SFC header anymore, is it? Or the MPLS label is effectively the SFC ID, correct? Your draft describes the SFF nodes advertise SIDs (Segment) for their local= ly attached SFs. Does it mean that each SF has a unique SID? How about dif= ferent instances of same Service Function? Does the SFF also has it own SI= D? Each SFF may have many SFs attached to different ports. Does SFF expose tho= se port information to head end classifier node? Thank you very much, Linda --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CA70CNKGEML512MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

 

Your observation is correct.  In the MPLS-SPRING-based SFC a= pproach as described in the draft, since the SFC or SFP information has bee= n encoded in an MPLS label stack, there is no need for carrying the SFC header anymore for the SFC or SFP indication = purpose.

 

As for the SF SID allocation, each SFF which has at least one ins= tance of a given SF attached to it would allocate a label for that SF, rath= er than allocating a label for each instance. In other words, multiple instances of a given SF would share the same labe= l. How to make a load-balance among those instances of a given SF is local = matter of the SFF.

 

Yes, each SFF would have its own SID which is actually the node S= ID for that SFF.

 

Best regards,

Xiaohu

 

From: Linda Dunbar
Sent: Thursday, November 06, 2014 4:10 AM
To: Xuxiaohu; Lizhenbin; hshah@ciena.com; luismiguel.contrerasmurill= o@telefonica.com; sfc@ietf.org
Subject: Questions to draft-xu-sfc-using-mpls-spring-01

 

Xiao Hu, et al,

 

 

With the MPLS Stacked Label app= roach described in your draft, there is really no need for packets to be en= capsulated with SFC header anymore, is it?

Or the MPLS label is effectivel= y the SFC ID, correct?

 

Your draft describes the SFF no= des advertise SIDs (Segment) for their locally attached SFs. Does it mean t= hat each SF  has a unique SID? How about different instances of same S= ervice Function?  Does the SFF also has it own SID?

Each SFF may have many SFs atta= ched to different ports. Does SFF expose those port information to head end= classifier node?

 

Thank you very much,

 

Linda  <= /p>

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CA70CNKGEML512MBSchi_-- From nobody Thu Nov 6 15:21:03 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7162E1ACD0E for ; Thu, 6 Nov 2014 15:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYt0R-95pv49 for ; Thu, 6 Nov 2014 15:20:59 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE861ACD0D for ; Thu, 6 Nov 2014 15:20:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13306; q=dns/txt; s=iport; t=1415316059; x=1416525659; h=from:to:subject:date:message-id:mime-version; bh=lzFtiTdrl7VOn07yE+Ov9HOXWq27w9yMd6CA0PNXT/A=; b=NvLw6a+hVNFyTgpfACkMNiE9dwmcHTGx47wrn0DRL4gJ4mtAiudT0hFF Z9Z6MRH5nMwLJ16AmVcpkOB+bUdv//cVqiqRrdvz6+UtS6FAvNcW7kqcD GxPe15MMk78x3TxSrxqranNJWugCbbXy6688Wd0gDgTXxL5m/RuauYj9H c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFACoCXFStJA2M/2dsb2JhbABbgkhGVFkEyyqHVYEZFgEBAQEBfYQCAQIELV4BCA4DAwECKDkUCQoEARKIQc9kAQEBAQEFAQEBAQEdkQCEYwWQA4IhhFOHH5ZbgX4ggVpsgUiBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,328,1413244800"; d="scan'208,217";a="370092817" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP; 06 Nov 2014 23:20:37 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sA6NKbt4025571 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Nov 2014 23:20:37 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.32]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 6 Nov 2014 17:20:37 -0600 From: "Surendra Kumar (smkumar)" To: Dave Dolson , "sfc@ietf.org" Thread-Topic: [sfc] questions on draft-quinn-sfc-nsh-03 Thread-Index: AQHP+hhFE4qEneqlFEyEtEhJ65C7Qw== Date: Thu, 6 Nov 2014 23:20:36 +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.5.141003 x-originating-ip: [10.155.165.183] Content-Type: multipart/alternative; boundary="_000_D081417F596D8smkumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/u5vhYQROjqDPQHzz1fudChV7N8s Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 06 Nov 2014 23:21:01 -0000 --_000_D081417F596D8smkumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable David, Some responses Inline. From: Dave Dolson > Date: Friday, October 31, 2014 9:54 AM To: "sfc@ietf.org" > Subject: [sfc] questions on draft-quinn-sfc-nsh-03 After reading draft-quinn-sfc-nsh-03, I have some questions and comments: The optional TLV format: - the TLV length should by in bytes (vs. words), allowing strings that aren= 't a multiple of 4 bytes, with padding to 4-byte alignment. This is the Dia= meter approach, for example. (RFC6733) - Encoding "critical" in upper bit of Type is confusing. Why not use one of= the reserved flags in the header? Or make type 7 bit field? SK> It can effectively be processed as a 7-bit field if you treat the 7th a= s another flag but it also provides the flexibility of categorizing certain= types as critical by definition. - the wording about critical should be clarified. =93Receiver=94 devices MU= ST drop and =93transit=94 devices MUST NOT drop; neither =93receiver=94 nor= =93transit=94 is clearly defined. I think you intend that the critical typ= es must be understood by the end-point (e.g., the protocol end-point addres= sed by the GRE packet). The definition of service index action is not precise. It says that if it i= s zero, the packet is to be dropped, but I could not understand if that me= ans if received with a zero or if received with "1" and decremented to zero= ? Instead, I claim that a packet received with a service index of zero is act= ually a valid packet if this is the end of the chain and the packet is de-e= ncapsulated. It would be a configuration error for there to be a forwarding entry that h= as another hop in the chain for service index zero. (My understanding is that an NSH forwarding table is indexed by at least {p= ath_id, service_index}, pointing to a record that indicates either next hop= in the chain or end of chain.) Of course, lack of an entry in NSH forwarding table would also cause the pa= cket to be dropped. SK> Received with zero or one is an error and must be dropped. Here is a ps= eudo code of how I would use it : -- SFF receive path processing for NSH encapsulated pkt -- If (NSH.si <=3D 1) { Drop & follow error path } NSH.si-- if (NSH.si =3D=3D 1) { Strip NSH Hand the pkt to the network-forwarder } else { Determine SFP next-hop Continue on SFP if no error } -- I feel that it is not necessary to fix the number of mandatory headers at 4= . The number of headers could be subject to the scheme of the MD type, allo= wing optimization to different use cases. Maybe 2 or 5 are useful in differ= ent cases. There is no discussion of fragmentation or prohibition thereof. SK> Arch document has a section on fragmentation. This being an encapsulati= on, a reference or some discussion of it is a good idea. Surendra. Thanks, David Dolson Senior Software Architect Sandvine --_000_D081417F596D8smkumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
David,

Some responses Inline.

From: Dave Dolson <ddolson@sandvine.com>
Date: Friday, October 31, 2014 9:54= AM
To: "sfc@ietf.org" <sfc@ietf.= org>
Subject: [sfc] questions on draft-q= uinn-sfc-nsh-03

After reading draft-quinn-sfc-nsh-03, I have some qu= estions and comments:

 

The optional TLV format:

- the TLV length should by in bytes (vs. words), all= owing strings that aren't a multiple of 4 bytes, with padding to 4-byte ali= gnment. This is the Diameter approach, for example. (RFC6733)

- Encoding "critical" in upper bit of Type= is confusing. Why not use one of the reserved flags in the header? Or make= type 7 bit field?
SK> It can effectively be processed as a 7-bit field if you treat the 7t= h as another flag but it also provides the flexibility of categorizing cert= ain types as critical by definition.

- the wording about critical should be clarified. = =93Receiver=94 devices MUST drop and =93transit=94 devices MUST NOT drop; n= either =93receiver=94 nor =93transit=94 is clearly defined. I think you int= end that the critical types must be understood by the end-point (e.g., the protocol end-point addressed by the GRE packet).=

 

The definition of service index action is not precis= e. It says that if it is zero, the packet is to be dropped,  but I cou= ld not understand if that means if received with a zero or if received with= "1" and decremented to zero?

Instead, I claim that a packet received with a servi= ce index of zero is actually a valid packet if this is the end of the chain= and the packet is de-encapsulated.

It would be a configuration error for there to be a = forwarding entry that has another hop in the chain for service index zero.<= o:p>

(My understanding is that an NSH forwarding table is= indexed by at least {path_id, service_index}, pointing to a record that in= dicates either next hop in the chain or end of chain.)

Of course, lack of an entry in NSH forwarding table = would also cause the packet to be dropped.
SK> Received with zero or one is an error and must be dropped. Here= is a pseudo code of how I would use it :
-- SFF receive path proce= ssing for NSH encapsulated pkt --
If (NSH.si <=3D 1) {
  Drop & follow error path
}

NSH.si--

if (NSH.si =3D=3D 1) {
    Strip NSH
    Hand the pkt to the network-f= orwarder
} else {
    Determine SFP next-hop=
    Continue on SFP if no error
}
--

 

I feel that it is not necessary to fix the number of= mandatory headers at 4. The number of headers could be subject to the sche= me of the MD type, allowing optimization to different use cases. Maybe 2 or= 5 are useful in different cases.

 

There is no discussion of fragmentation or prohibiti= on thereof.
SK> Arch document has a section on fragmentation. This being an encapsul= ation, a reference or some discussion of it is a good idea.

Surendra. 

 

Thanks,

David Dolson

Senior Software Architect

Sandvine

 

 --_000_D081417F596D8smkumarciscocom_-- From nobody Thu Nov 6 22:19:27 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6D01ACEF5; Thu, 6 Nov 2014 22:19:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 BgBHasDnkwRu; Thu, 6 Nov 2014 22:19:24 -0800 (PST) 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 9BD071ACEED; Thu, 6 Nov 2014 22:19:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLJ13322; Fri, 07 Nov 2014 06:19:22 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Nov 2014 06:19:21 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 7 Nov 2014 14:19:16 +0800 From: Xuxiaohu To: David Mozes , Erik Nordmark , Marc Binderberger , Tom Herbert Thread-Topic: [nvo3] Concerns about NVO3 dataplane requirements document +BFD Thread-Index: Ac/5pX3IHQHQBkBcQm6OPC6ftJTTKQAq/uWA Date: Fri, 7 Nov 2014 06:19:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CAA9D@NKGEML512-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/G9XdLRYfkpc8UEQDDiWDzpJMO-0 Cc: "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Concerns about NVO3 dataplane requirements document +BFD X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 07 Nov 2014 06:19:25 -0000 > > Meta-Data: I probably missed some discussions (sorry!) but what data > > would this be? >=20 > As I tried to clarify in my response to Tom the meta-data discussion in t= he IETF > was mostly about vendor-specific service meta-data, but perhaps this term= is > being used for more general extensibility? >=20 > I think there should be ways to add better assurance (checksum, keyed > hashes) for the NVO3 header. But perhaps that can be in fixed fields in a= fixed > length header. >=20 > In terms of the overall architecture there is a desire to carry some serv= ice > meta-data with frames. The sfc WG is thinking about doing that using a se= parate > NSH header. The NSH header pursued in the SFC WG contains not only metadata but also se= rvice function chain/path info. I wonder whether the SFC is the only applic= ation scenario of metadata. If no, it seems better to decouple metadata and= the SFC/SFP info. Best regards, Xiaohu From nobody Fri Nov 7 16:59:32 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C21A00BA; Fri, 7 Nov 2014 16:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.581 X-Spam-Level: X-Spam-Status: No, score=-13.581 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 jABXGBWEmdT2; Fri, 7 Nov 2014 16:59:26 -0800 (PST) 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 B50451A00B9; Fri, 7 Nov 2014 16:59:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1592; q=dns/txt; s=iport; t=1415408366; x=1416617966; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=TyFsDrhhDOH4O684+/IjIJKceos8JTh3wkfteEltifI=; b=JPI28F9liJeUxjekgLsDZc9JGVctkFpSR0PJu8It8Pwv0vfNDWH7o8dF GDskm6hZ0C3RWqs6T0hdLxHToHMg405jSbKmMjyS06uCmpbZEwOCifwEm 3s0+wTULe7tCU8gpKAxJp8al5xA+tiBkeLyUOaXMJXN5u2eFrtLPScJ5k Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYIALJpXVStJV2c/2dsb2JhbABbgw5UWQTLTwqHSwICAoEaFgEBAQEBfYQDAQEDAQEBATc0CxACAQgSJBAnCxcOAQEEAQ0FiDgJDc8TAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKdYYcB4RLAQSSJ4tzllyDeWyBSIEDAQEB X-IronPort-AV: E=Sophos;i="5.07,336,1413244800"; d="scan'208";a="94578631" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP; 08 Nov 2014 00:59:25 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id sA80xO7J018458 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 00:59:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Fri, 7 Nov 2014 18:59:24 -0600 From: "Larry Kreeger (kreeger)" To: Xuxiaohu , David Mozes , "Erik Nordmark" , Marc Binderberger , Tom Herbert Thread-Topic: [nvo3] Concerns about NVO3 dataplane requirements document +BFD Thread-Index: Ac/5pX3IHQHQBkBcQm6OPC6ftJTTKQAq/uWAACM/qQA= Date: Sat, 8 Nov 2014 00:59:24 +0000 Message-ID: References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CAA9D@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082CAA9D@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [10.155.166.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <82473AE63ED0564E8CABCB81F7FBB181@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/_1ACbqupawfhbS9BoCVsbJo9o-U Cc: "nvo3@ietf.org" , "sfc@ietf.org" Subject: Re: [sfc] [nvo3] Concerns about NVO3 dataplane requirements document +BFD X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Nov 2014 00:59:27 -0000 Hi Xiaohu, On 11/6/14 10:19 PM, "Xuxiaohu" wrote: >> > Meta-Data: I probably missed some discussions (sorry!) but what data >> > would this be? >>=20 >> As I tried to clarify in my response to Tom the meta-data discussion in >>the IETF >> was mostly about vendor-specific service meta-data, but perhaps this >>term is >> being used for more general extensibility? >>=20 >> I think there should be ways to add better assurance (checksum, keyed >> hashes) for the NVO3 header. But perhaps that can be in fixed fields in >>a fixed >> length header. >>=20 >> In terms of the overall architecture there is a desire to carry some >>service >> meta-data with frames. The sfc WG is thinking about doing that using a >>separate >> NSH header. > >The NSH header pursued in the SFC WG contains not only metadata but also >service function chain/path info. I wonder whether the SFC is the only >application scenario of metadata. If no, it seems better to decouple >metadata and the SFC/SFP info. > >Best regards, >Xiaohu draft-quinn-sfc-nsh-03 made it possible to use NSH for applications beyond SFC by adding a MD Type (MD=3DMetadata) field (one MD Type is allocated for SFC). This opens the door to allow NSH to carry extensions to the Network Virtualization layer beyond what is built into the base header that all implementations must support, such as a virtual network ID and OAM flag. - Larry > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 From nobody Sat Nov 8 06:41:09 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFB51A1B69 for ; Sat, 8 Nov 2014 06:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.181 X-Spam-Level: X-Spam-Status: No, score=-12.181 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, URIBL_RHS_DOB=1.514, 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 m9ODAsx6vSmc for ; Sat, 8 Nov 2014 06:41:03 -0800 (PST) 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 673001A1B5E for ; Sat, 8 Nov 2014 06:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10562; q=dns/txt; s=iport; t=1415457665; x=1416667265; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=k7QrEvaRn3mA45/UWz00ix5pR4DprtLBPhNEoQTggNo=; b=gTkAAlgKPF3jIfSq587mztG2qlnX8KLLNsAUviEvb0LQPMm52Sw0gAIi fV4n49gzQhHYS+bqOrbQTWrapG1ITHIqFudN55N8Rm9QCLGojgMGfF0RU ySnmziwzIoOtDOPn143KwFIfgiy3hT5SYx5gHKCGt9QA8MPNzQxRsvEwH Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFoqXlStJV2U/2dsb2JhbABbgmsjVFkEy1AMh00CgRsWAQEBAQF9hAIBAQEEAQEBC1cIARcEAgEIEQEDAQEBJwcnCxQDBggCBAESCYg4AQzNeQEBAQEBAQEBAQEBAQEBAQEBAQEBGJA5XwaERQWSJ4RUhx+BMj2DEYgbhTiECYI1gURsAYEFQoEDAQEB X-IronPort-AV: E=Sophos;i="5.07,340,1413244800"; d="scan'208";a="370591102" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP; 08 Nov 2014 14:41:03 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sA8Ef21H011946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 8 Nov 2014 14:41:02 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Sat, 8 Nov 2014 08:41:02 -0600 From: "Ken Gray (kegray)" To: Linda Dunbar , "sfc@ietf.org" Thread-Topic: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism Thread-Index: AQHP8gISMJ/u8rBG0kS6N5KtvH7/wpxPAeuAgAKR+QCABUweAA== Date: Sat, 8 Nov 2014 14:41:01 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645E24012@dfweml701-chm> <4A95BA014132FF49AE685FAB4B9F17F645E2B7F8@dfweml701-chm> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645E2B7F8@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.151] Content-Type: text/plain; charset="iso-8859-2" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/S2LvTPwYRUa14L4qzpJ27i9K1T4 Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service Path control Mechanism X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Nov 2014 14:41:07 -0000 Linda, I would suggest the authors rework from scratch under the assumption that commentary on the efficacy of the SFC header in general be made separately on the separate header draft and advocacy for the use of the transport header also be contained therein. In that light, we could discuss my doubts about the scalability of using RSVP for pathing at host-host scale or even edge-edge scales and how apparently ignorant that approach might be of the potential scale of host involvement as head-end and encapsulator of the flow (and thus doing RSVP signaling). There too, we can discuss the potential limitations of using SR in lieu of the SFP part of the header. If they remove the conflation of their document with the extant header document (ostensibly this is a draft about HA as the Abstract indicates) and work from the assumption that the header exists and that the transport, regardless of type has it's own HA ramifications that don't need to be enumerated (in fact, they can use this sentence as a summary). Thus they can potentially create an informative document that might suggest mediation of the (obvious) global repair scenario of changing the classifier-to-chain mapping at the headend of the service overlay (in light of their concerns about it) or alternatives to anycast (if they have any) as the alternative to (the obvious) anycast methods for local repair. IMHO, both global and local repair of the service overlay should proceed without the direct requirement of involvement of transport, since one of the fundamental benefits of creating a service overlay (really ANY overlay) is that it is decoupled from and indirectly benefits from changes in the transport that provide HA (without having to be changed itself). Since the current status quo is that we have no service overlay, and we are ostensibly here to fill that gap, we need really take no action if we want the transport header to subsume that role. Fundamentally, it's time the AD(s) stepped in and decide how much longer this "discussion" derails work in this WG. What are we here for? If you want (and this is directed FAR beyond Linda personally) to keep horking with transport ("transport overlay CAN BE service overlay, let's discuss") to fill this role (service overlay), go to BESS or PALS, initiate your effort there and be done with it (and I will happily argue the merits THERE) - if the AD(s) support that! We can waste time THERE. I thought that was the purpose of the re-organization. Here we have another WG being dragged into the hell of "MPLS is overlay" (NVO3 should have been a learning experience - we should start from the premise of "yes, there is MPLS, please see BESS/PALS - what if there isn't?" instead of constantly "forking" anything that explores the world beyond). On 11/4/14 6:47 PM, "Linda Dunbar" wrote: >Ken,=20 > >Thanks for your comments. Replies are inserted below: > >-----Original Message----- >From: Ken Gray (kegray) [mailto:kegray@cisco.com] >Sent: Monday, November 03, 2014 8:32 AM >To: Linda Dunbar; sfc@ietf.org >Subject: Re: [sfc] Solicit comments and suggestions to Rendered Service >Path control Mechanism > > >Section 4.3 " For the approach 1) above, all the forwarding nodes, e.g. >SFFs, need > to look up the SFF-sequence or SFF-SF-sequence for every packet to > determine the next hop. For large flows, i.e. large number of > packets in the flow, the processing of interpreting the SFF- > sequence/SFF-SF-sequence is repetitive and can be resource Intensive." > >One would suspect the above is a bad implementation of a forwarder =A9 > >[Linda] Yes the wording needs some enhancement. The intent is to say if >the forwarding nodes forward traffic based on the SFF-SF-sequence encoded >in the packets, the "lookup" entry is the "SFF-SF-sequence" in the >packet. Special consideration is needed. > >What do you think of changing to the following text: > > "The approach 1) above is basically "two dimensional" Source Routing, >not only with explicit SFF nodes on the path, but also with exact SF >sequence by each SFF node. For large flows, i.e. large number of packets >in the flow, repeating the SFF-sequence/SFF-SF-sequence encoding in all >packets can waste bandwidth, which is not suitable for environment where >bandwidth is limited." > > >Section 6.1 " As mentioned in the previous section, encoding exact RSP >path > requiring all involved nodes to interpret SFF-SF-sequence in each > packet to establish runtime forwarding policy, which can be resource > intensive. This approach is not optimal when the RSP doesn't change > very frequently, as in minutes or hours." > > >Not a fact just because it was stated above. You always have to resolve >a next hop if you're a forwarder, regardless of the methodology that you >learn (or maintain) the next hop. > >[Linda] Yes, you can use "Source Routing" as developed by SPRING. But >most of today deployed routers use pre-established "forwarding table" for >next hop.=20 > > How "expensive" this is would be an implementation detail. Further, it >doesn't really appear as if the authors are offering an alternative, so >these are (IMO) gratuitous statements that don't have a lot to do with >the proposed framework. >[Linda] How about changing the wording to the following? >" As mentioned in the previous section, encoding exact RSP path in every >packet has the benefit and the issues of source routing. This approach >may not be optimal when the RSP doesn't change very frequently, as in >minutes or hours, or bandwidth is limited." > > >For the Global restoration sections (section 6): > >Why doesn't updating the classifier at the headend work for global >restoration? >[Linda] Yes, one method is to escalate fault to the head end classifier >node. Another method is regional repair, as MPLS's FRR. > > >Further, the line "This method won't cause any contention issue among all >the involved > nodes." in section 6.1 is confusing. What does it refer to? > >[Linda] it means " Encoding the exact SFF-SF-sequence in every packet >won't cause any contention issue among all the involved nodes when >changes occur." > >Section 6.2 is a boondoggle (we don't need another signaling protocol, >IMHO), as is the idea of having coordinated RSP capabilities between the >classifiers (see - we don't need another signaling protocol). The SFFs >can be updated without having to maintain their consistency through some >head-end driven state machine. Changing the SFP on the classifying node >implicitly signals the new path. Updating the SFFs is an >orchestration/SDN problem. >[Linda] This section is NOT to introduce another signaling protocol. This >section is to describe using MPLS RSVP to establish the RSP. We will >improve the wording to reflect this. > > >Section 6.3 is a solvable transaction problem - use NETCONF, use OF with >barrier messages - is coordinated updates of the forwarders your ultimate >concern here? =20 > >BTW (same section), if you have a single NMS node, yeah, you have >problems and restoration of service paths is just one of many. > >Which leads us to 6.4, which I think is how most of us imagined that SFC >was supposed to work, but I don't see the need for "until all the >involved SFF nodes complete the installation of the new steering policy >for the path." Again, is the main point of this whole paper to beware of >the transactional nature of updating the forwarders in the path? > >[Linda] Glad to see that is "most of us imaged what SFC was supposed to >work". The main point is to describe an approach with "Source routing" >until all the SFF nodes nailed up the proper connections to SF nodes and >next hop SFF node. > > >You can completely lose the first paragraph of section 7. I hope the >authors are not still struggling with the concept of instance anonymity >in load balancing (it seems like you had come to grips with that in your >Local Repair section), because that concept (more than scale) makes it >impossible for the head end to be aware of all instances. > >[Linda] This is not about multiple same-function "instances" attached to >one SFF node. Those SFICs can be handled by the SFF via local load >balance as described in SFC-Arch. This section is to describe scenario of >the Figure in Section 6. > > > >The rest of what you describe is essentially "anycast", IMO. >[Linda] How?=20 > >Thank you very much. > >Linda=20 > >On 10/27/14 12:21 PM, "Linda Dunbar" wrote: > >>Rendered Service Path was introduced by draft-ietf-sfc-architecture to >>represent a constrained specification of where packets using a certain >>service chain must go. >> >>This draft proposes a framework to represent RSP and restoration scheme >>when some functions on a RSP fails (or to be replaced by new ones). >> >>We are looking for comments and suggestions. >> >>Linda & Andy >> >>-----Original Message----- >>From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>Sent: Monday, October 27, 2014 11:01 AM >>To: Andrew G. Malis; Linda Dunbar; Andrew G. Malis; Linda Dunbar >>Subject: New Version Notification for >>draft-dunbar-sfc-path-control-00.txt >> >> >>A new version of I-D, draft-dunbar-sfc-path-control-00.txt >>has been successfully submitted by Linda Dunbar and posted to the IETF >>repository. >> >>Name: draft-dunbar-sfc-path-control >>Revision: 00 >>Title: Framework for Service Function Path Control >>Document date: 2014-10-24 >>Group: Individual Submission >>Pages: 15 >>URL: =20 >>http://www.ietf.org/internet-drafts/draft-dunbar-sfc-path-control-00.txt >>Status: =20 >>https://datatracker.ietf.org/doc/draft-dunbar-sfc-path-control/ >>Htmlized: =20 >>http://tools.ietf.org/html/draft-dunbar-sfc-path-control-00 >> >> >>Abstract: >> This draft describes the framework of protection and restoration of >> Service Function Path when some service functions on the path fail >> or need to be replaced. >> >> =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 >> >>_______________________________________________ >>sfc mailing list >>sfc@ietf.org >>https://www.ietf.org/mailman/listinfo/sfc > From nobody Sat Nov 8 07:10:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AE91A19EA for ; Sat, 8 Nov 2014 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BysSWH6PJht6 for ; Sat, 8 Nov 2014 07:10:10 -0800 (PST) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEE91A1BC0 for ; Sat, 8 Nov 2014 07:10:08 -0800 (PST) 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; Sat, 8 Nov 2014 10:10:07 -0500 From: Dave Dolson To: "haibin.song@huawei.com" Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-03 Thread-Index: Ac/6wQKi5wpVfEbDRLi0ncF9P52vkQ== Date: Sat, 8 Nov 2014 15:10:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.196.10] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830AD8D2Dwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/cHEtQ1Wr_Oxw08FXu0SYT3nIXQs Cc: "sfc@ietf.org" Subject: [sfc] comments on draft-song-sfc-legacy-sf-mapping-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 08 Nov 2014 15:10:19 -0000 --_000_E8355113905631478EFF04F5AA706E9830AD8D2Dwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Haibin, Did you consider, for layer2-transparent devices: - Some classes of SF may need to not only modify packets but also = inject them (for example a transparent cache sending content from its disk) - Some classes of SF may need to inject a packet in the opposite d= irection of a received packet (for example a firewall responding to a TCP S= YN with a RST). How would the non-SFC-aware layer2-transparent devices behave when injectin= g or responding to packets within a TCP session? I believe it is common for these devices to re-use layer2 addresses that we= re seen earlier on the TCP session. For example, when responding to a SYN with RST, we would expect the Etherne= t source/dest to be reversed. It seems to me that these behaviors would rule out any sort of per-packet a= pproach because the SFF would not recognize the injected packets. Furthermore, I don't think your "layer2 MAC address" scheme works in this c= ase, as currently written using the source address. The VLAN family of approaches seems robust to the above behaviors (if suppo= rted by the transparent SF). The 5-tuple approach also seems fairly robust against those behaviors, assu= ming state doesn't time out too quickly (e.g., there may be spontaneous TCP= retransmissions after several seconds). The multi-tenant issues with the 5-tuple approach could be addressed by add= ing more fields to the tuple. E.g., add VLAN to make 6-tuple. David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E9830AD8D2Dwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Haibin,

Did you consider, for layer2-transparent devices:

-     &= nbsp;    Some classes of SF may need to not only modify pack= ets but also inject them (for example a transparent cache sending content f= rom its disk)

-     &= nbsp;    Some classes of SF may need to inject a packet in t= he opposite direction of a received packet (for example a firewall respondi= ng to a TCP SYN with a RST).

 

How would the non-SFC-aware layer2-transparent devic= es behave when injecting or responding to packets within a TCP session?

I believe it is common for these devices to re-use l= ayer2 addresses that were seen earlier on the TCP session.

For example, when responding to a SYN with RST, we w= ould expect the Ethernet source/dest to be reversed.

 

It seems to me that these behaviors would rule out a= ny sort of per-packet approach because the SFF would not recognize the inje= cted packets.

 

Furthermore, I don’t think your “layer2 = MAC address” scheme works in this case, as currently written using th= e source address.

 

The VLAN family of approaches seems robust to the ab= ove behaviors (if supported by the transparent SF).

The 5-tuple approach also seems fairly robust agains= t those behaviors, assuming state doesn’t time out too quickly (e.g.,= there may be spontaneous TCP retransmissions after several seconds).<= /o:p>

 

The multi-tenant issues with the 5-tuple approach co= uld be addressed by adding more fields to the tuple. E.g., add VLAN to make= 6-tuple.

 

 

David Dolson

Senior Software Architect

Sandvine

 

--_000_E8355113905631478EFF04F5AA706E9830AD8D2Dwtlexchp2sandvi_-- From nobody Sun Nov 9 18:09:31 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52451A87DE for ; Sun, 9 Nov 2014 18:09:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 cnfxHFmc_d90 for ; Sun, 9 Nov 2014 18:09:15 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B56EB1A887D for ; Sun, 9 Nov 2014 18:09:03 -0800 (PST) Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 9 Nov 2014 19:09:03 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e31.co.us.ibm.com (192.168.1.131) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 9 Nov 2014 19:09:01 -0700 Received: from b03cxnp08026.gho.boulder.ibm.com (b03cxnp08026.gho.boulder.ibm.com [9.17.130.18]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 50AB21FF0040 for ; Sun, 9 Nov 2014 18:57:45 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by b03cxnp08026.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAA290ON47120578 for ; Mon, 10 Nov 2014 03:09:00 +0100 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAA2900p001410 for ; Sun, 9 Nov 2014 19:09:00 -0700 Received: from cichlid.raleigh.ibm.com ([9.80.91.77]) by d03av04.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sAA28xq4001344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 9 Nov 2014 19:08:59 -0700 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id sAA28wTO018279 for ; Sun, 9 Nov 2014 21:08:58 -0500 Date: Sun, 09 Nov 2014 21:08:58 -0500 Message-ID: From: Thomas Narten To: sfc@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14111002-8236-0000-0000-000006CA59CB Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/kwrHQ3TNltLm1OxEyg7zNLqsshU Subject: [sfc] Processing of draft-liu-sfc-use-cases-08.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, 10 Nov 2014 02:09:27 -0000 This WG has an outstanding issue of what to do with draft-liu-sfc-use-cases-08.txt. Reviewing some history, when the WG was originally formed there was a debate about how best to handle SFC use cases generally. There were some who felt we should have a number of individual, scenario-specific, use case documents. There were also calls for a single general use-case document that covered everything, The WG ended up adopting two more-specific documents (sfc-use-case-mobility & sfc-dc-use-cases), deferring action on the more general document draft-liu-sfc-use-cases-08.txt. Since that decision, there have been repeated calls from the authors (with support from others) to adopt liu-sfc-use-cases as well. However, the chairs have hesitated for a number of reasons, as outlined below. 1) The purpose of use-case documents is to drive requirements. One doesn't need a use-case document for every possible use case. At some point, having yet another document yields diminishing returns. we would observe, that so far, none of the use-case documents seem to have produced any "requirements" in the sense of pointing out something SFC needs to do that isn't already covered in the architecture/problem statement. That suggests to us that the use case documents have limited value. 2) We continue to have concerns about what additional/different content liu-sfc-use-cases has compared with the other documents. The discussions so far have not been very illuminating, being mostly generic "I think it has value" vs. "don't need it". (Thomas will separately post a note with specific concerns.) 3) My (Thomas') approach to WG documents is simple and has been consistent for many years: what is in the best interest of the community and what is best for the readers of RFCs long after a WG has finished. Having more documents can make it more difficult for someone to sift through the various documents to find the ones of value. That is especially true when the same general topic is covered in multiple documents. In such cases, there is often overlapping content. 4) The real work of the WG is the architecture and protocols. That is where the WG should be spending its cycles. Every document a WG takes on takes WG resources away from other documents (i.e., to review and iterate). This is not just a WG statement, but an IETF statement. Every document a WG produces goes through IETF LC and IESG review. That takes resources. The IETF complains regularly about lack of cycles and poor quality work reaching the IESG. The best place to address that concern is at the WG, including by not adopting all documents that someone wants to publish. We would prefer that the WG focus its efforts on the documents that matter the most. 5) It would be easy to call for adoption, and most likely there would be enough show of support to support adoption. However, the IETF is not a simple democracy where decisions are made by simple vote counts. Hence, our hesitation in asking for WG adoption of this document. If the document was an important component to the WG's core deliverables, we would of course expect the WG to take it on. Absent that, however, we think it would be better to focus on core documents. Thomas & Jim From nobody Sun Nov 9 18:18:25 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4475F1A8850 for ; Sun, 9 Nov 2014 18:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 bKOo9lQRND3A for ; Sun, 9 Nov 2014 18:18:22 -0800 (PST) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B351A00EB for ; Sun, 9 Nov 2014 18:18:22 -0800 (PST) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Sun, 9 Nov 2014 21:18:21 -0500 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Sun, 9 Nov 2014 21:18:18 -0500 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id E866A6E8047 for ; Sun, 9 Nov 2014 21:18:16 -0500 (EST) Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by b01cxnp22034.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAA2IIXC21954786 for ; Mon, 10 Nov 2014 02:18:18 GMT Received: from d01av04.pok.ibm.com (localhost [127.0.0.1]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAA2IHRw017761 for ; Sun, 9 Nov 2014 21:18:17 -0500 Received: from cichlid.raleigh.ibm.com ([9.80.91.77]) by d01av04.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sAA2IHUi017722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 9 Nov 2014 21:18:17 -0500 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id sAA2IGvR023545 for ; Sun, 9 Nov 2014 21:18:16 -0500 Date: Sun, 09 Nov 2014 21:18:16 -0500 Message-ID: From: Thomas Narten To: sfc@ietf.org User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14111002-0025-0000-0000-000001084724 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/0yuQywh6mQ78WiXlHMu87pkETBk Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 10 Nov 2014 02:18:24 -0000 Note: chair hat off. I have a number of concerns with the document, including: 1) I don't see what significant content it has beyond what the other WG use case documents contain. 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this section is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And how is that a "use case"? TE already exists. Does the addition of SFC somehow change things? 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. That has been an assumption in SFC from the start. Doesn't the problem statement/architecture say as much? 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not sure what use case has Ethernet in it or why that is called out. SFC can run over Ethernet so long as it is also an IP subnet. Or is this section trying to say something else? If so, what? 5) Section 4.6 talks about service path forking. The WG has discussed "forking" multiple times, and it's a basic part of SFC. So what exactly is this section that isn't covered elsewhere? 6) I don't follow or understand the "recursive SFC" section. When it talks about different service providers, I have to wonder how that applies to SFC, given our scope is restricted to a single administrative domain. But more to the point, how does "recursive" differ from straightforward SFC usage, where different subscribers use different service chains? Thomas From nobody Mon Nov 10 07:06:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5A71A9039 for ; Mon, 10 Nov 2014 07:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 pqoNBxYBSraf for ; Mon, 10 Nov 2014 07:05:58 -0800 (PST) Received: from sangam.sce.carleton.ca (sangam.sce.carleton.ca [134.117.56.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F2DD1A903C for ; Mon, 10 Nov 2014 07:05:58 -0800 (PST) Received: from MacPC2 (206-188-90-150.cpe.distributel.net [206.188.90.150]) (authenticated bits=0) by sangam.sce.carleton.ca (8.14.4/8.14.4) with ESMTP id sAAF5uTp017939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 10 Nov 2014 10:05:57 -0500 From: "Changcheng Huang" To: "'Thomas Narten'" References: In-Reply-To: Date: Mon, 10 Nov 2014 10:05:57 -0500 Organization: Carleton University Message-ID: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac/8jJ0yG2hTQuJESHGv86j1w1tI5QAYsdag Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/nf01ompJUC2zh_C6bW6KqWSalHo Cc: sfc@ietf.org Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: huang@sce.carleton.ca List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Nov 2014 15:06:01 -0000 Hi Thomas, I appreciate that you clearly state your questions and concerns. This will be very helpful for the working group to move forward. With due respect, I have some brief comments. 1. The WG has approved three use case documents as internet-draft. However there were still some heated discussions about service path forking, which has not been clearly addressed by the three use case documents. This leads to a question about whether we have really understood all important use cases and their impacts. I share your comments on IETF's reluctance to pass a large number of low quality RFCs. There is very little chance that these three use cases will all become RFCs. It will also look strange for a reader outside the WG to read three use case documents instead of one. IMHO, the WG should generate a merged use case document that gets the supports across the working group. To this end, this draft use case document in question can be a good starting point. I hope, as the chair, you can help lead the WG to reach consensus rather than majority votes as the WG has been doing. 2. About Item 6 in your email, I know the WG has limited its scope to a single administrative domain. This is fine if the protocols developed by this working group can be easily extended to multiple domains in future. However, some of the existing protocol proposals in the WG are quite rigid and hard to extend. This will likely make those protocols short-lived. As you said in the earlier email, it is in the best interest of this WG to develop good quality protocols that can stand the test of time. In Section 2.9 of the problem statement document that is currently being approved by IETF, crossing administrative boundaries is considered important for providing end-to-end service visibility. This is a good comment for taking the big picture into account. More information about recursive SFC can be found in draft-huang-sfc-use-case-recursive-service-00. Best regards, Chang -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Sunday, November 09, 2014 9:18 PM To: sfc@ietf.org Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Note: chair hat off. I have a number of concerns with the document, including: 1) I don't see what significant content it has beyond what the other WG use case documents contain. 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this section is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And how is that a "use case"? TE already exists. Does the addition of SFC somehow change things? 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. That has been an assumption in SFC from the start. Doesn't the problem statement/architecture say as much? 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not sure what use case has Ethernet in it or why that is called out. SFC can run over Ethernet so long as it is also an IP subnet. Or is this section trying to say something else? If so, what? 5) Section 4.6 talks about service path forking. The WG has discussed "forking" multiple times, and it's a basic part of SFC. So what exactly is this section that isn't covered elsewhere? 6) I don't follow or understand the "recursive SFC" section. When it talks about different service providers, I have to wonder how that applies to SFC, given our scope is restricted to a single administrative domain. But more to the point, how does "recursive" differ from straightforward SFC usage, where different subscribers use different service chains? Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 10 13:49:12 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC8B1A6FCC for ; Mon, 10 Nov 2014 13:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 TdRAg43OjiLm for ; Mon, 10 Nov 2014 13:49:07 -0800 (PST) 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 103551A6F9C for ; Mon, 10 Nov 2014 13:49:06 -0800 (PST) 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 BOP91444; Mon, 10 Nov 2014 21:49:05 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 10 Nov 2014 21:49:04 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML702-CHM.china.huawei.com ([169.254.4.76]) with mapi id 14.03.0158.001; Mon, 10 Nov 2014 13:49:00 -0800 From: Cathy Zhang To: "Dolganow, Andrew (Andrew)" , "sfc@ietf.org" Thread-Topic: draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQ Date: Mon, 10 Nov 2014 21:49:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.76] Content-Type: multipart/alternative; boundary="_000_A2C96F6779E6A041BC7023CC207FC99418FAB5F8SJCEML701CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VPdfzkL9zzxm3x-ycFW92acPjAM Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 10 Nov 2014 21:49:11 -0000 --_000_A2C96F6779E6A041BC7023CC207FC99418FAB5F8SJCEML701CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, Thanks for bringing this up. As authors of another service chain header dra= ft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your= proposal. Your proposal is in sync with our service chain header draft, i.e., besides= the base header and path header, all other information can be expressed as= optional metadata in TLV format. Last IETF meeting's conclusion is to merge the two header drafts----NSH dra= ft and SCH draft. We have reached out to the NSH authors about doing the m= erging as well as addressing the comments/opinions voiced in the Toronto IE= TF meeting and email alias. Thanks, SCH authors From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andr= ew) Sent: Tuesday, November 04, 2014 8:12 AM To: sfc@ietf.org Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Heade= rs remains the only option for NSH During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew --_000_A2C96F6779E6A041BC7023CC207FC99418FAB5F8SJCEML701CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andrew,<= /span>

 

Thanks for bringing th= is up. As authors of another service chain header draft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your proposal.

Your proposal is in sy= nc with our service chain header draft, i.e., besides the base header and p= ath header, all other information can be expressed as optional metadata in = TLV format.

 

Last IETF meeting̵= 7;s conclusion is to merge the two header drafts----NSH draft and SCH draft= .  We have reached out to the NSH authors about doing the merging as w= ell as addressing the comments/opinions voiced in the Toronto IETF meeting and email alias.  

 

Thanks,

SCH authors=

 

 

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andrew)
Sent: Tuesday, November 04, 2014 8:12 AM
To: sfc@ietf.org
Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandat= ory Context Headers remains the only option for NSH

 

During = the last IETF there were several attendees (including myself) who voice str= ong opinion against mandatory the inclusion of the information beyond based= header and service path header. Not all applications require the extra overhead. A discussion on the list foll= owed (see attached email that initiated that discussion) on alternative enc= odings including mechanisms like use of one of the reserved bit or using an= other MD Type value to represent header without Mandatory Context Headers.

&n= bsp;

Can the= authors comment on whether they are strongly opposed to include in their d= raft a proposal that has an option to encode the NSH without the Mandatory = Context Headers? I am OK with an encoding that either:

  • makes  Mandatory Context Headers opti= onal or
  • Has two types of NSG MD Type 0x1 - the man= datory context headers are present, 0x2 the mandatory context header are no= t included  (optional variable length metadata could still be used in = that type  of header)

&n= bsp;

Andrew<= o:p>

&n= bsp;

&n= bsp;

--_000_A2C96F6779E6A041BC7023CC207FC99418FAB5F8SJCEML701CHMchi_-- From nobody Mon Nov 10 15:15:29 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FE31ACFD0 for ; Mon, 10 Nov 2014 15:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jzk1QGxiSLmd for ; Mon, 10 Nov 2014 15:15:24 -0800 (PST) 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 1221E1ACFCF for ; Mon, 10 Nov 2014 15:15:23 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0174.001; Mon, 10 Nov 2014 15:15:22 -0800 From: Ron Parker To: "huang@sce.carleton.ca" , 'Thomas Narten' Thread-Topic: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP/IydYFeiJBLwE0adStHSWJzcqZxafKyAgAACYqA= Date: Mon, 10 Nov 2014 23:15:23 +0000 Message-ID: References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> In-Reply-To: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.136.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/sIZ_68W1xnRcwXv2v4WWZ-ln-Ng Cc: "sfc@ietf.org" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 10 Nov 2014 23:15:28 -0000 Chang, I agree that after all is said and done with SFC, it will make much more se= nse for a reader to view a single use case document to provide the context = as to why the architecture and protocols turned out the way they did. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang Sent: Monday, November 10, 2014 10:06 AM To: 'Thomas Narten' Cc: sfc@ietf.org Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Hi Thomas, I appreciate that you clearly state your questions and concerns. This will = be very helpful for the working group to move forward. With due respect, I = have some brief comments. 1. The WG has approved three use case documents as internet-draft. However = there were still some heated discussions about service path forking, which = has not been clearly addressed by the three use case documents. This leads = to a question about whether we have really understood all important use cas= es and their impacts. I share your comments on IETF's reluctance to pass a = large number of low quality RFCs. There is very little chance that these th= ree use cases will all become RFCs. It will also look strange for a reader = outside the WG to read three use case documents instead of one. IMHO, the W= G should generate a merged use case document that gets the supports across = the working group. To this end, this draft use case document in question ca= n be a good starting point. I hope, as the chair, you can help lead the WG = to reach consensus rather than majority votes as the WG has been doing.=20 2. About Item 6 in your email, I know the WG has limited its scope to a sin= gle administrative domain. This is fine if the protocols developed by this = working group can be easily extended to multiple domains in future. However, some of the existing protocol proposals in the WG are quite rigid = and hard to extend. This will likely make those protocols short-lived. As y= ou said in the earlier email, it is in the best interest of this WG to deve= lop good quality protocols that can stand the test of time. In Section 2.9 of the problem statement document that is currently being approved by I= ETF, crossing administrative boundaries is considered important for providi= ng end-to-end service visibility. This is a good comment for taking the big= picture into account. More information about recursive SFC can be found in= draft-huang-sfc-use-case-recursive-service-00. =20 Best regards, Chang =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Sunday, November 09, 2014 9:18 PM To: sfc@ietf.org Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Note: chair hat off. I have a number of concerns with the document, including: 1) I don't see what significant content it has beyond what the other WG use= case documents contain. 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this se= ction is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And ho= w is that a "use case"? TE already exists. Does the addition of SFC somehow= change things? 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. That has been an assumption in SFC from the start. Doesn't the problem stat= ement/architecture say as much? 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not= sure what use case has Ethernet in it or why that is called out. SFC can r= un over Ethernet so long as it is also an IP subnet. Or is this section try= ing to say something else? If so, what? 5) Section 4.6 talks about service path forking. The WG has discussed "fork= ing" multiple times, and it's a basic part of SFC. So what exactly is this = section that isn't covered elsewhere?=20 6) I don't follow or understand the "recursive SFC" section. When it talks = about different service providers, I have to wonder how that applies to SF= C, given our scope is restricted to a single administrative domain. But mor= e to the point, how does "recursive" differ from straightforward SFC usage, where different subscribers use diff= erent service chains? Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 10 15:52:39 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862711A010C for ; Mon, 10 Nov 2014 15:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKgiY-XTwVOX for ; Mon, 10 Nov 2014 15:52:34 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213AF1A8761 for ; Mon, 10 Nov 2014 15:52:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4396; q=dns/txt; s=iport; t=1415663554; x=1416873154; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ExuSWE4u9NPeuLaAshDx/fcjhiTFmdNiFLLL7ZKZ+Bc=; b=CmsxpPk3FHyLpSIDX9Ki8ZYKMNdeab5d8+2eox3oqUgeTk5Nk3IItD8n N7p2Iby83tcGoDjvdzB+I4gGh2ZqU0OihS/CnBmuQMZW/2TiLRgr0k+8X SpW2a5+83gzdq+4uD1YEJASUz175lpWTpuEn0Aj0mrJ1xSyeMgZqYRKyd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADNPYVStJA2E/2dsb2JhbABcgw5UWQTLdgqHTwKBIBYBAQEBAX2EAgEBAQQBAQE3NAsMBAIBCBEBAwEBFgkJBycLFAMGCAIEAQ0FiEENzRwBAQEBAQEBAQEBAQEBAQEBAQEBAQETBJAzCgcBUAcGBIRBBZAOgiOLdIE0hwGKIYQKg3psgQYJFyKBAwEBAQ X-IronPort-AV: E=Sophos;i="5.07,356,1413244800"; d="scan'208";a="95315427" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP; 10 Nov 2014 23:52:33 +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 sAANqXN2019105 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 23:52:33 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 17:52:33 -0600 From: "Jim Guichard (jguichar)" To: "huang@sce.carleton.ca" , "'Thomas Narten'" Thread-Topic: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP/IyhNqQbnAL4DkKyC3GZwO0a3pxaWyWAgAAupIA= Date: Mon, 10 Nov 2014 23:52:32 +0000 Message-ID: References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> In-Reply-To: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.100.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <2820AA1F2A5EB347907BDDA4F162710D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/56icIAax4QfaV_5dceL-1HrMSCs Cc: "sfc@ietf.org" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 10 Nov 2014 23:52:36 -0000 Hi Chang, Some comments inline. On 11/10/14, 10:05 AM, "Changcheng Huang" wrote: >Hi Thomas, > >I appreciate that you clearly state your questions and concerns. This will >be very helpful for the working group to move forward. With due respect, I >have some brief comments. > >1. The WG has approved three use case documents as internet-draft. However >there were still some heated discussions about service path forking, which >has not been clearly addressed by the three use case documents. This leads >to a question about whether we have really understood all important use >cases and their impacts. I share your comments on IETF's reluctance to >pass >a large number of low quality RFCs. There is very little chance that these >three use cases will all become RFCs. It will also look strange for a >reader >outside the WG to read three use case documents instead of one. IMHO, the >WG >should generate a merged use case document that gets the supports across >the >working group. To this end, this draft use case document in question can >be >a good starting point. I hope, as the chair, you can help lead the WG to >reach consensus rather than majority votes as the WG has been doing. Jim> What specifically is missing from the SFC architecture specification that this use case document highlights? =20 >=20 > >2. About Item 6 in your email, I know the WG has limited its scope to a >single administrative domain. This is fine if the protocols developed by >this working group can be easily extended to multiple domains in future. >However, some of the existing protocol proposals in the WG are quite rigid >and hard to extend. This will likely make those protocols short-lived. As Jim> which protocol proposals are you referring too and what specifically is hard to extend? >you said in the earlier email, it is in the best interest of this WG to >develop good quality protocols that can stand the test of time. In Section >2.9 of the problem statement document that is currently being approved by >IETF, crossing administrative boundaries is considered important for >providing end-to-end service visibility. This is a good comment for taking >the big picture into account. More information about recursive SFC can be >found in draft-huang-sfc-use-case-recursive-service-00. > >Best regards, > >Chang =20 > >-----Original Message----- >From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten >Sent: Sunday, November 09, 2014 9:18 PM >To: sfc@ietf.org >Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt > >Note: chair hat off. > >I have a number of concerns with the document, including: > >1) I don't see what significant content it has beyond what the other WG >use >case documents contain. > >2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this >section is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And >how is that a "use case"? TE already exists. Does the addition of SFC >somehow change things? > >3) Section 4.4 seems to simply say that some SFC flows are bi-directional. >That has been an assumption in SFC from the start. Doesn't the problem >statement/architecture say as much? > >4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm >not >sure what use case has Ethernet in it or why that is called out. SFC can >run >over Ethernet so long as it is also an IP subnet. Or is this section >trying >to say something else? If so, what? > >5) Section 4.6 talks about service path forking. The WG has discussed >"forking" multiple times, and it's a basic part of SFC. So what exactly is >this section that isn't covered elsewhere? > >6) I don't follow or understand the "recursive SFC" section. When it talks >about different service providers, I have to wonder how that applies to >SFC, given our scope is restricted to a single administrative domain. But >more to the point, how does "recursive" >differ from straightforward SFC usage, where different subscribers use >different service chains? > >Thomas > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc > > >_______________________________________________ >sfc mailing list >sfc@ietf.org >https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 10 17:07:06 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458C91A1BB9 for ; Mon, 10 Nov 2014 17:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.495 X-Spam-Level: X-Spam-Status: No, score=-7.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, 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 X1Xtf3wc4fXR for ; Mon, 10 Nov 2014 17:07:01 -0800 (PST) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E99A1A1AAD for ; Mon, 10 Nov 2014 17:07:00 -0800 (PST) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 10 Nov 2014 18:06:59 -0700 Received: from d03dlp01.boulder.ibm.com (9.17.202.177) by e39.co.us.ibm.com (192.168.1.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 10 Nov 2014 18:06:58 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 76AF91FF0039 for ; Mon, 10 Nov 2014 17:55:42 -0700 (MST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAB16vv655115942 for ; Tue, 11 Nov 2014 02:06:57 +0100 Received: from d03av05.boulder.ibm.com (localhost [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAB15sLY023691 for ; Mon, 10 Nov 2014 18:05:54 -0700 Received: from cichlid.raleigh.ibm.com ([9.80.86.228]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id sAB15rvA023656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Nov 2014 18:05:54 -0700 Received: from cichlid.raleigh.ibm.com.us.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id sAB15qIE024657; Mon, 10 Nov 2014 20:05:52 -0500 Date: Mon, 10 Nov 2014 20:05:52 -0500 Message-ID: From: Thomas Narten To: Ron Parker In-Reply-To: References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/23.1 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 14111101-0033-0000-0000-000002A1B01B Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/lcIK45mNpYBPIG0VGl54F5S6WvY Cc: "sfc@ietf.org" , "huang@sce.carleton.ca" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 11 Nov 2014 01:07:03 -0000 Hi Ron. > I agree that after all is said and done with SFC, it will make much > more sense for a reader to view a single use case document to > provide the context as to why the architecture and protocols turned > out the way they did. But I don't see how to get there from here at this point. We've already got two documents, three if you count the more general one, and they'd have to be merged. More work someone has to do. And there has never really been WG consensus for just one merged document. As a general rule, I personally would prefer one document over many, but I think we're past that. And again, how much effort does the WG want to spend on use cases? Will doing more use case work over the next few months make our architecture/protocols better or get them completed more quickly? I have doubts... Thomas From nobody Mon Nov 10 18:20:18 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28A1AD43F for ; Mon, 10 Nov 2014 18:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.902 X-Spam-Level: X-Spam-Status: No, score=-0.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwNfbyv7iUAP for ; Mon, 10 Nov 2014 18:20:12 -0800 (PST) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 681C31AD442 for ; Mon, 10 Nov 2014 18:20:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.07,357,1413205200"; d="scan'208";a="44423683" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 11 Nov 2014 13:02:13 +1100 X-IronPort-AV: E=McAfee;i="5600,1067,7618"; a="266583392" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 11 Nov 2014 13:19:48 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 11 Nov 2014 13:19:47 +1100 From: "Pham, Chuong D" To: Ron Parker , "huang@sce.carleton.ca" , 'Thomas Narten' Date: Tue, 11 Nov 2014 13:18:51 +1100 Thread-Topic: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Thread-Index: Ac/9S9Rd0L7nXu1MQVuq2MmOyN723gACXz+g Message-ID: <5602569641FB314FB4D9AD5659D41B9C2C30A3B083@WSMSG3154V.srv.dir.telstra.com> References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/VBR0_xRa_HiUqFTLJr5k192_kWc Cc: "sfc@ietf.org" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 11 Nov 2014 02:20:15 -0000 I also support Chang's and Ron's statements. It is strange to isolate the u= se cases from each domain into separate documents without any consideration= for relationship, commonality and synergy between the use cases. We don't = work like that over here. In fact, we used to work like that... Chuong -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=20 Sent: Tuesday, 11 November 2014 10:15 AM To: huang@sce.carleton.ca; 'Thomas Narten' Cc: sfc@ietf.org Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Chang, I agree that after all is said and done with SFC, it will make much more se= nse for a reader to view a single use case document to provide the context = as to why the architecture and protocols turned out the way they did. Ron -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang Sent: Monday, November 10, 2014 10:06 AM To: 'Thomas Narten' Cc: sfc@ietf.org Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Hi Thomas, I appreciate that you clearly state your questions and concerns. This will = be very helpful for the working group to move forward. With due respect, I = have some brief comments. 1. The WG has approved three use case documents as internet-draft. However = there were still some heated discussions about service path forking, which = has not been clearly addressed by the three use case documents. This leads = to a question about whether we have really understood all important use cas= es and their impacts. I share your comments on IETF's reluctance to pass a = large number of low quality RFCs. There is very little chance that these th= ree use cases will all become RFCs. It will also look strange for a reader = outside the WG to read three use case documents instead of one. IMHO, the W= G should generate a merged use case document that gets the supports across = the working group. To this end, this draft use case document in question ca= n be a good starting point. I hope, as the chair, you can help lead the WG = to reach consensus rather than majority votes as the WG has been doing.=20 2. About Item 6 in your email, I know the WG has limited its scope to a sin= gle administrative domain. This is fine if the protocols developed by this = working group can be easily extended to multiple domains in future. However, some of the existing protocol proposals in the WG are quite rigid = and hard to extend. This will likely make those protocols short-lived. As y= ou said in the earlier email, it is in the best interest of this WG to deve= lop good quality protocols that can stand the test of time. In Section 2.9 of the problem statement document that is currently being approved by I= ETF, crossing administrative boundaries is considered important for providi= ng end-to-end service visibility. This is a good comment for taking the big= picture into account. More information about recursive SFC can be found in= draft-huang-sfc-use-case-recursive-service-00. =20 Best regards, Chang =20 -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Sunday, November 09, 2014 9:18 PM To: sfc@ietf.org Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Note: chair hat off. I have a number of concerns with the document, including: 1) I don't see what significant content it has beyond what the other WG use= case documents contain. 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this se= ction is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And ho= w is that a "use case"? TE already exists. Does the addition of SFC somehow= change things? 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. That has been an assumption in SFC from the start. Doesn't the problem stat= ement/architecture say as much? 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not= sure what use case has Ethernet in it or why that is called out. SFC can r= un over Ethernet so long as it is also an IP subnet. Or is this section try= ing to say something else? If so, what? 5) Section 4.6 talks about service path forking. The WG has discussed "fork= ing" multiple times, and it's a basic part of SFC. So what exactly is this = section that isn't covered elsewhere?=20 6) I don't follow or understand the "recursive SFC" section. When it talks = about different service providers, I have to wonder how that applies to SF= C, given our scope is restricted to a single administrative domain. But mor= e to the point, how does "recursive" differ from straightforward SFC usage, where different subscribers use diff= erent service chains? Thomas _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 10 18:32:13 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6201AD476 for ; Mon, 10 Nov 2014 18:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwBq0aUeYL2a for ; Mon, 10 Nov 2014 18:32:05 -0800 (PST) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 3743A1AD474 for ; Mon, 10 Nov 2014 18:32:05 -0800 (PST) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 21:32:04 -0500 From: Dave Dolson To: "Surendra Kumar (smkumar)" , "sfc@ietf.org" Thread-Topic: [sfc] questions on draft-quinn-sfc-nsh-03 Thread-Index: AQHP+hhFE4qEneqlFEyEtEhJ65C7Q5xaue4g Date: Tue, 11 Nov 2014 02:32:04 +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.196.10] Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E9830ADA2BCwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NPXDseZQLNfWWjKbdqgeR4vj-sY Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 02:32:10 -0000 --_000_E8355113905631478EFF04F5AA706E9830ADA2BCwtlexchp2sandvi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I made this comment: "I feel that it is not necessary to fix the number of mandatory headers at = 4. The number of headers could be subject to the scheme of the MD type, all= owing optimization to different use cases. Maybe 2 or 5 are useful in diffe= rent cases. Are you willing to changing the spec to accommodate this? I would also add = an MD type to mean "no fixed metadata" From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Thursday, November 06, 2014 1:21 PM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03 David, Some responses Inline. From: Dave Dolson > Date: Friday, October 31, 2014 9:54 AM To: "sfc@ietf.org" > Subject: [sfc] questions on draft-quinn-sfc-nsh-03 After reading draft-quinn-sfc-nsh-03, I have some questions and comments: The optional TLV format: - the TLV length should by in bytes (vs. words), allowing strings that aren= 't a multiple of 4 bytes, with padding to 4-byte alignment. This is the Dia= meter approach, for example. (RFC6733) - Encoding "critical" in upper bit of Type is confusing. Why not use one of= the reserved flags in the header? Or make type 7 bit field? SK> It can effectively be processed as a 7-bit field if you treat the 7th a= s another flag but it also provides the flexibility of categorizing certain= types as critical by definition. - the wording about critical should be clarified. "Receiver" devices MUST d= rop and "transit" devices MUST NOT drop; neither "receiver" nor "transit" i= s clearly defined. I think you intend that the critical types must be under= stood by the end-point (e.g., the protocol end-point addressed by the GRE p= acket). The definition of service index action is not precise. It says that if it i= s zero, the packet is to be dropped, but I could not understand if that me= ans if received with a zero or if received with "1" and decremented to zero= ? Instead, I claim that a packet received with a service index of zero is act= ually a valid packet if this is the end of the chain and the packet is de-e= ncapsulated. It would be a configuration error for there to be a forwarding entry that h= as another hop in the chain for service index zero. (My understanding is that an NSH forwarding table is indexed by at least {p= ath_id, service_index}, pointing to a record that indicates either next hop= in the chain or end of chain.) Of course, lack of an entry in NSH forwarding table would also cause the pa= cket to be dropped. SK> Received with zero or one is an error and must be dropped. Here is a ps= eudo code of how I would use it : -- SFF receive path processing for NSH encapsulated pkt -- If (NSH.si <=3D 1) { Drop & follow error path } NSH.si-- if (NSH.si =3D=3D 1) { Strip NSH Hand the pkt to the network-forwarder } else { Determine SFP next-hop Continue on SFP if no error } -- I feel that it is not necessary to fix the number of mandatory headers at 4= . The number of headers could be subject to the scheme of the MD type, allo= wing optimization to different use cases. Maybe 2 or 5 are useful in differ= ent cases. There is no discussion of fragmentation or prohibition thereof. SK> Arch document has a section on fragmentation. This being an encapsulati= on, a reference or some discussion of it is a good idea. Surendra. Thanks, David Dolson Senior Software Architect Sandvine --_000_E8355113905631478EFF04F5AA706E9830ADA2BCwtlexchp2sandvi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I made this comment:

“I feel that it is= not necessary to fix the number of mandatory headers at 4. The number of h= eaders could be subject to the scheme of the MD type, allowing optimization= to different use cases. Maybe 2 or 5 are useful in different cases.

 

Are you willing to cha= nging the spec to accommodate this? I would also add an MD type to mean = 220;no fixed metadata”

 

 

 

From: Surendra= Kumar (smkumar) [mailto:smkumar@cisco.com]
Sent: Thursday, November 06, 2014 1:21 PM
To: Dave Dolson; sfc@ietf.org
Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03

 

David,<= o:p>

&n= bsp;

Some re= sponses Inline.

&n= bsp;

From: Dave Dolson <ddolson@sandvine.com>
Date: Friday, October 31, 2014 9:54 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] questions on draft-quinn-sfc-nsh-03=

&n= bsp;

After reading draft-quin= n-sfc-nsh-03, I have some questions and comments:

 =

The optional TLV format:=

- the TLV length should = by in bytes (vs. words), allowing strings that aren't a multiple of 4 bytes= , with padding to 4-byte alignment. This is the Diameter approach, for exam= ple. (RFC6733)

- Encoding "critica= l" in upper bit of Type is confusing. Why not use one of the reserved = flags in the header? Or make type 7 bit field?

SK> = It can effectively be processed as a 7-bit field if you treat the 7th as an= other flag but it also provides the flexibility of categorizing certain typ= es as critical by definition.

- the wording about crit= ical should be clarified. “Receiver” devices MUST drop and R= 20;transit” devices MUST NOT drop; neither “receiver” nor= “transit” is clearly defined. I think you intend that the crit= ical types must be understood by the end-point (e.g., the protocol end-point addresse= d by the GRE packet).

 =

The definition of servic= e index action is not precise. It says that if it is zero, the packet is to= be dropped,  but I could not understand if that means if received wit= h a zero or if received with "1" and decremented to zero?

Instead, I claim that a = packet received with a service index of zero is actually a valid packet if = this is the end of the chain and the packet is de-encapsulated.<= /span>

It would be a configurat= ion error for there to be a forwarding entry that has another hop in the ch= ain for service index zero.

(My understanding is tha= t an NSH forwarding table is indexed by at least {path_id, service_index}, = pointing to a record that indicates either next hop in the chain or end of = chain.)

Of course, lack of an en= try in NSH forwarding table would also cause the packet to be dropped.=

SK> = Received with zero or one is an error and must be dropped. Here is a pseudo= code of how I would use it :

-- SFF receive path processing for NSH encapsu= lated pkt --=

If (NSH.si <=3D 1) {

  Drop & follow error path

}

&n= bsp;

NSH.si--

&n= bsp;

if (NSH.si =3D=3D 1) {

    Strip NSH

    Hand the pkt to the network-forw= arder=

} else {

    Determine SFP next-hop

    Continue on SFP if no error

}

--

 

 =

I feel that it is not ne= cessary to fix the number of mandatory headers at 4. The number of headers = could be subject to the scheme of the MD type, allowing optimization to dif= ferent use cases. Maybe 2 or 5 are useful in different cases.

 =

There is no discussion o= f fragmentation or prohibition thereof.

SK> = Arch document has a section on fragmentation. This being an encapsulation, = a reference or some discussion of it is a good idea.

&n= bsp;

Surendr= a. 

 =

Thanks,

David Dolson<= /span>

Senior Software Architec= t

Sandvine

 =

--_000_E8355113905631478EFF04F5AA706E9830ADA2BCwtlexchp2sandvi_-- From nobody Mon Nov 10 19:38:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB80C1AD515 for ; Mon, 10 Nov 2014 19:38:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.493 X-Spam-Level: X-Spam-Status: No, score=-7.493 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZG658ViHGakl for ; Mon, 10 Nov 2014 19:37:59 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-01.alcatel-lucent.com [135.245.210.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C0EC1AD519 for ; Mon, 10 Nov 2014 19:37:59 -0800 (PST) Received: from us70tusmtp2.zam.alcatel-lucent.com (unknown [135.5.2.64]) by Websense Email Security Gateway with ESMTPS id 36D97626420C8; Tue, 11 Nov 2014 03:37:55 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id sAB3bsRp023817 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Nov 2014 22:37:55 -0500 Received: from US70UWXCHMBA03.zam.alcatel-lucent.com ([169.254.9.112]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Mon, 10 Nov 2014 22:37:54 -0500 From: "Dolganow, Andrew (Andrew)" To: "Surendra Kumar (smkumar)" , Paul Quinn Thread-Topic: [sfc] questions on draft-quinn-sfc-nsh-03 Thread-Index: AQHP+hhFE4qEneqlFEyEtEhJ65C7Q5xaue4ggAAToWU= Date: Tue, 11 Nov 2014 03:37:54 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_ED360E196C7046B5A038CA1DD3B7D3FAalcatellucentcom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/l95REB4sc2Jsefe_HYCyYNKszg4 Cc: "sfc@ietf.org" , Dave Dolson Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 03:38:03 -0000 --_000_ED360E196C7046B5A038CA1DD3B7D3FAalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just to again reiterate the number of mandatory headers. I and Dave are ok with using MD type to encode that. This MD 1 would carry = only base and service path header. The header should also allow inclusion o= f optional headers. Andrew Sent from my iPhone On Nov 10, 2014, at 4:32 PM, Dave Dolson > wrote: I made this comment: =93I feel that it is not necessary to fix the number of mandatory headers a= t 4. The number of headers could be subject to the scheme of the MD type, a= llowing optimization to different use cases. Maybe 2 or 5 are useful in dif= ferent cases. Are you willing to changing the spec to accommodate this? I would also add = an MD type to mean =93no fixed metadata=94 From: Surendra Kumar (smkumar) [mailto:smkumar@cisco.com] Sent: Thursday, November 06, 2014 1:21 PM To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03 David, Some responses Inline. From: Dave Dolson > Date: Friday, October 31, 2014 9:54 AM To: "sfc@ietf.org" > Subject: [sfc] questions on draft-quinn-sfc-nsh-03 After reading draft-quinn-sfc-nsh-03, I have some questions and comments: The optional TLV format: - the TLV length should by in bytes (vs. words), allowing strings that aren= 't a multiple of 4 bytes, with padding to 4-byte alignment. This is the Dia= meter approach, for example. (RFC6733) - Encoding "critical" in upper bit of Type is confusing. Why not use one of= the reserved flags in the header? Or make type 7 bit field? SK> It can effectively be processed as a 7-bit field if you treat the 7th a= s another flag but it also provides the flexibility of categorizing certain= types as critical by definition. - the wording about critical should be clarified. =93Receiver=94 devices MU= ST drop and =93transit=94 devices MUST NOT drop; neither =93receiver=94 nor= =93transit=94 is clearly defined. I think you intend that the critical typ= es must be understood by the end-point (e.g., the protocol end-point addres= sed by the GRE packet). The definition of service index action is not precise. It says that if it i= s zero, the packet is to be dropped, but I could not understand if that me= ans if received with a zero or if received with "1" and decremented to zero= ? Instead, I claim that a packet received with a service index of zero is act= ually a valid packet if this is the end of the chain and the packet is de-e= ncapsulated. It would be a configuration error for there to be a forwarding entry that h= as another hop in the chain for service index zero. (My understanding is that an NSH forwarding table is indexed by at least {p= ath_id, service_index}, pointing to a record that indicates either next hop= in the chain or end of chain.) Of course, lack of an entry in NSH forwarding table would also cause the pa= cket to be dropped. SK> Received with zero or one is an error and must be dropped. Here is a ps= eudo code of how I would use it : -- SFF receive path processing for NSH encapsulated pkt -- If (NSH.si <=3D 1) { Drop & follow error path } NSH.si-- if (NSH.si =3D=3D 1) { Strip NSH Hand the pkt to the network-forwarder } else { Determine SFP next-hop Continue on SFP if no error } -- I feel that it is not necessary to fix the number of mandatory headers at 4= . The number of headers could be subject to the scheme of the MD type, allo= wing optimization to different use cases. Maybe 2 or 5 are useful in differ= ent cases. There is no discussion of fragmentation or prohibition thereof. SK> Arch document has a section on fragmentation. This being an encapsulati= on, a reference or some discussion of it is a good idea. Surendra. Thanks, David Dolson Senior Software Architect Sandvine _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_ED360E196C7046B5A038CA1DD3B7D3FAalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just to again reiterate the number of mandatory headers.

I and Dave are ok with using MD type to encode that. This MD 1 would c= arry only base and service path header. The header should also allow inclus= ion of optional headers. 

Andrew

Sent from my iPhone

On Nov 10, 2014, at 4:32 PM, Dave Dolson <ddolson@sandvine.com> wrote:

I made this comment:

=93I feel that it is not= necessary to fix the number of mandatory headers at 4. The number of heade= rs could be subject to the scheme of the MD type, allowing optimization to = different use cases. Maybe 2 or 5 are useful in different cases.

 

Are you willing to cha= nging the spec to accommodate this? I would also add an MD type to mean =93= no fixed metadata=94

 

 

 

From: Surendra= Kumar (smkumar) [mailto:smkumar@cisco= .com]
Sent: Thursday, November 06, 2014 1:21 PM
To: Dave Dolson; sfc@ietf.org Subject: Re: [sfc] questions on draft-quinn-sfc-nsh-03

 

David,<= o:p>

&n= bsp;

Some re= sponses Inline.

&n= bsp;

From: Dave Dolson <ddolson@sandvine.com>
Date: Friday, October 31, 2014 9:54 AM
To: "sfc@ietf.org" <= ;sfc@ietf.org>
Subject: [sfc] questions on draft-quinn-sfc-nsh-03=

&n= bsp;

After reading draft-quin= n-sfc-nsh-03, I have some questions and comments:

 =

The optional TLV format:=

- the TLV length should = by in bytes (vs. words), allowing strings that aren't a multiple of 4 bytes= , with padding to 4-byte alignment. This is the Diameter approach, for exam= ple. (RFC6733)

- Encoding "critica= l" in upper bit of Type is confusing. Why not use one of the reserved = flags in the header? Or make type 7 bit field?

SK> = It can effectively be processed as a 7-bit field if you treat the 7th as an= other flag but it also provides the flexibility of categorizing certain typ= es as critical by definition.

- the wording about crit= ical should be clarified. =93Receiver=94 devices MUST drop and =93transit= =94 devices MUST NOT drop; neither =93receiver=94 nor =93transit=94 is clea= rly defined. I think you intend that the critical types must be understood by the end-point (e.g., the protocol end-point addresse= d by the GRE packet).

 =

The definition of servic= e index action is not precise. It says that if it is zero, the packet is to= be dropped,  but I could not understand if that means if received wit= h a zero or if received with "1" and decremented to zero?

Instead, I claim that a = packet received with a service index of zero is actually a valid packet if = this is the end of the chain and the packet is de-encapsulated.<= /span>

It would be a configurat= ion error for there to be a forwarding entry that has another hop in the ch= ain for service index zero.

(My understanding is tha= t an NSH forwarding table is indexed by at least {path_id, service_index}, = pointing to a record that indicates either next hop in the chain or end of = chain.)

Of course, lack of an en= try in NSH forwarding table would also cause the packet to be dropped.=

SK> = Received with zero or one is an error and must be dropped. Here is a pseudo= code of how I would use it :

-- SFF receive path processing for NSH encapsu= lated pkt --=

If (NSH.si <= =3D 1) {

  Drop & follow error path

}

&n= bsp;

NSH.si--<= span style=3D"font-size:10.5pt;color:black">

&n= bsp;

if (NSH.si =3D= =3D 1) {

    Strip NSH

    Hand the pkt to the network-forw= arder=

} else {

    Determine SFP next-hop

    Continue on SFP if no error

}

--

 

 =

I feel that it is not ne= cessary to fix the number of mandatory headers at 4. The number of headers = could be subject to the scheme of the MD type, allowing optimization to dif= ferent use cases. Maybe 2 or 5 are useful in different cases.

 =

There is no discussion o= f fragmentation or prohibition thereof.

SK> = Arch document has a section on fragmentation. This being an encapsulation, = a reference or some discussion of it is a good idea.

&n= bsp;

Surendr= a. 

 =

Thanks,

David Dolson<= /span>

Senior Software Architec= t

Sandvine

 =

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_ED360E196C7046B5A038CA1DD3B7D3FAalcatellucentcom_-- From nobody Mon Nov 10 22:45:07 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CBD1AD517 for ; Mon, 10 Nov 2014 22:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 R6hfnupa4JYw for ; Mon, 10 Nov 2014 22:45:02 -0800 (PST) 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 E220D1ACDD6 for ; Mon, 10 Nov 2014 22:45:00 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOQ24254; Tue, 11 Nov 2014 06:44:59 +0000 (GMT) Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Nov 2014 06:44:58 +0000 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.14]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Tue, 11 Nov 2014 14:44:47 +0800 From: Jiangyuanlong To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] Processing of draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP/Itj8tNcyw+ht0mdQzbCblW7R5xay87w Date: Tue, 11 Nov 2014 06:44:47 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A7F4E2F@szxema506-mbs.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/woJkpG4PLiZlyHtIS6kM6jJGfnk Subject: Re: [sfc] Processing of draft-liu-sfc-use-cases-08.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, 11 Nov 2014 06:45:05 -0000 Hi Tom, Please see my comments inline. Regards, Yuanlong -----Original Message----- From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten Sent: Monday, November 10, 2014 10:09 AM To: sfc@ietf.org Subject: [sfc] Processing of draft-liu-sfc-use-cases-08.txt This WG has an outstanding issue of what to do with draft-liu-sfc-use-cases-08.txt. Reviewing some history, when the WG was originally formed there was a debate about how best to handle SFC use cases generally. There were some who felt we should have a number of individual, scenario-specific, use case documents. There were also calls for a single general use-case document that covered everything, The WG ended up adopting two more-specific documents (sfc-use-case-mobility & sfc-dc-use-cases), deferring action on the more general document draft-liu-sfc-use-cases-08.txt. Since that decision, there have been repeated calls from the authors (with support from others) to adopt liu-sfc-use-cases as well. However, the chairs have hesitated for a number of reasons, as outlined below. 1) The purpose of use-case documents is to drive requirements. One doesn't need a use-case document for every possible use case. At some point, having yet another document yields diminishing returns. we would observe, that so far, none of the use-case documents seem to have produced any "requirements" in the sense of pointing out something SFC needs to do that isn't already covered in the architecture/problem statement. That suggests to us that the use case documents have limited value. [JY] I have a different opinion here. The architecture draft has been evolv= ing all the time, quite a few requirements from use cases and other I-Ds ar= e reflected in its newer version, not in its initial version. Furthermore, = the use case drafts not only serve the people who are doing SFC architectur= e, but also help those who are not familiar with SFC to understand the arch= itecture (e.g., those not in the WG, and future developers).=20 2) We continue to have concerns about what additional/different content liu-sfc-use-cases has compared with the other documents. The discussions so far have not been very illuminating, being mostly generic "I think it has value" vs. "don't need it". (Thomas will separately post a note with specific concerns.) 3) My (Thomas') approach to WG documents is simple and has been consistent for many years: what is in the best interest of the community and what is best for the readers of RFCs long after a WG has finished. Having more documents can make it more difficult for someone to sift through the various documents to find the ones of value. That is especially true when the same general topic is covered in multiple documents. In such cases, there is often overlapping content. [JY] This makes sense, but the chairs definitely took a different approach = when other use case documents were adopted half a year ago.=20 4) The real work of the WG is the architecture and protocols. That is where the WG should be spending its cycles. Every document a WG takes on takes WG resources away from other documents (i.e., to review and iterate). This is not just a WG statement, but an IETF statement. Every document a WG produces goes through IETF LC and IESG review. That takes resources. The IETF complains regularly about lack of cycles and poor quality work reaching the IESG. The best place to address that concern is at the WG, including by not adopting all documents that someone wants to publish. We would prefer that the WG focus its efforts on the documents that matter the most. 5) It would be easy to call for adoption, and most likely there would be enough show of support to support adoption. However, the IETF is not a simple democracy where decisions are made by simple vote counts. Hence, our hesitation in asking for WG adoption of this document. If the document was an important component to the WG's core deliverables, we would of course expect the WG to take it on. Absent that, however, we think it would be better to focus on core documents. Thomas & Jim _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc From nobody Mon Nov 10 23:55:50 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AB11AD564 for ; Mon, 10 Nov 2014 23:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 K4f5ohJqn0hw for ; Mon, 10 Nov 2014 23:55:45 -0800 (PST) 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 B66CB1AD57F for ; Mon, 10 Nov 2014 23:55:44 -0800 (PST) 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 BOQ31729; Tue, 11 Nov 2014 07:55:43 +0000 (GMT) Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Nov 2014 07:55:41 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Tue, 11 Nov 2014 15:55:36 +0800 From: "Songhaibin (A)" To: Dave Dolson Thread-Topic: comments on draft-song-sfc-legacy-sf-mapping-03 Thread-Index: Ac/6wQKi5wpVfEbDRLi0ncF9P52vkQCvbD7Q Date: Tue, 11 Nov 2014 07:55:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bzPp_grKbEzNbEL5YJ6rwFKbuGI Cc: "sfc@ietf.org" Subject: Re: [sfc] comments on draft-song-sfc-legacy-sf-mapping-03 X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 07:55:47 -0000 Dave, Sorry for the late response. See inline. Best Regards! -Haibin From: Dave Dolson [mailto:ddolson@sandvine.com]=20 Sent: Saturday, November 08, 2014 11:10 PM To: Songhaibin (A) Cc: sfc@ietf.org Subject: comments on draft-song-sfc-legacy-sf-mapping-03 Haibin, Did you consider, for layer2-transparent devices: - Some classes of SF may need to not only modify packets but also inject th= em (for example a transparent cache sending content from its disk) - Some classes of SF may need to inject a packet in the opposite direction = of a received packet (for example a firewall responding to a TCP SYN with a= RST). [Haibin]This is a very good question. I did consider the former case (altho= ugh have not documented it in the draft), but indeed have not considered th= e latter case.=20 For the former case, if it is a SFC aware service function instance, then s= ervice function instance needs to encapsulate the new packets with the same= encapsulation with the related received packets. If it is a SFC unaware s= ervice function instance, then SFC proxy needs to know how to co-relate the= new packet with the original packet, and it could be manually configured i= n the SFC proxy. >How would the non-SFC-aware layer2-transparent devices behave when injecti= ng or responding to packets within a TCP session? I believe it is common for these devices to re-use layer2 addresses that we= re seen earlier on the TCP session. For example, when responding to a SYN with RST, we would expect the Etherne= t source/dest to be reversed. >It seems to me that these behaviors would rule out any sort of per-packet = approach because the SFF would not recognize the injected packets. [Haibin] I think when you say SFF, you actually mean SFC proxy. You are ri= ght that SFC proxy would not recognize the injected packets. So you mean wi= th unchanged layer 2 addresses, and new packets generated with SF instance,= then SFC proxy cannot tell the packets from each other. Is my understandin= g right? And here is my consideration for it: First, it depends on whether = we allow a per packet meta data in the SFC architecture. If we allow it, th= en we must solve the problem on how to correlate the metadata with the orig= inal packet in a SFC proxy. Second, assume that we allow it, then SFC proxy= must write something down (when receive packets from SFF) that can be late= r to recognize the packet (when receive packets from the SF instance). And = it is also possible a SFC proxy could be configured to "know" the SF instan= ces it is attached to. As "MAC address" could not work to recognize the ori= ginal packet, then SFC proxy needs to use some other additional fields for = it IMO. What do you think? >Furthermore, I don't think your "layer2 MAC address" scheme works in this = case, as currently written using the source address. [Haibin] Agree. >The VLAN family of approaches seems robust to the above behaviors (if supp= orted by the transparent SF). The 5-tuple approach also seems fairly robust against those behaviors, assu= ming state doesn't time out too quickly (e.g., there may be spontaneous TCP= retransmissions after several seconds). [Haibin] Assume there is no per packet meta data. Then I agree. By the way,= if there is any consensus on whether or not allow per packet meta data in = the WG? >The multi-tenant issues with the 5-tuple approach could be addressed by ad= ding more fields to the tuple. E.g., add VLAN to make 6-tuple. [Haibin] Right. It could be. Thank you very much. It is indeed a question that is needed to think carefu= lly and documented in the draft. Best Regards! -Haibin David Dolson Senior Software Architect Sandvine From nobody Tue Nov 11 05:15:02 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE4A1AC3EA for ; Tue, 11 Nov 2014 05:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-NeDyKNbx9c for ; Tue, 11 Nov 2014 05:14:59 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3631C1AC3AD for ; Tue, 11 Nov 2014 05:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11704; q=dns/txt; s=iport; t=1415711699; x=1416921299; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=h1bywDjQreDptzZqhmv92wfY24sCbqGPSqwMYQBhPcM=; b=M/MzO4ehnP4z4doKkOvG6x66I+XBzYXnz+kOKrhaj8Yqt2zMlmVW00vt TPO0tTrYrDNmeWdIWMw29zhYoZQSYanJGs33KfAdQqitnuToCXOW6DPl8 LnBIy/xrYL+M4DhpRvKVMylLukRad0NxG2cEeM5XPpTrzOrdbInMIEyYA U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAOgKYlStJA2E/2dsb2JhbABcgkhGVFkEzAwBCYdPAoEaFgEBAQEBfYQCAQEBBAEBAWsLEAIBCBEEAQEkBAcnCxQJCAIEDgWIQQ3NTgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkDIRAUwEBgECgyuBHgWSMYRTgkeEWoE0kSKECoI2gURsAYEOOYEDAQEB X-IronPort-AV: E=Sophos; i="5.07,361,1413244800"; d="scan'208,217"; a="95494629" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP; 11 Nov 2014 13:14:58 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sABDEwaC018071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 13:14:58 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.140]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 07:14:58 -0600 From: "Paul Quinn (paulq)" To: Cathy Zhang Thread-Topic: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQgAFqM4A= Date: Tue, 11 Nov 2014 13:14:58 +0000 Message-ID: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.127.152] Content-Type: multipart/alternative; boundary="_000_55741672D88A4138A79CD5B1F8A83A86ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/EwXiw3x3AmMT-x18kqLIXJsngjM Cc: "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 13:15:01 -0000 --_000_55741672D88A4138A79CD5B1F8A83A86ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Cathy, We need to be accurate here: there was no =93conclusion=94 to merge drafts,= rather your co-author presented some slides that highlighted what you and = your co-authors feels are areas of similarity and suggested that a merge sh= ould occur. We =97 the NSH co-authors =97 are happy to discuss this with y= ou (and are actively doing so) to see if we can reach an agreement on joint= text in order to ensure that we meet the WG goals=94 Thanks Paul On Nov 10, 2014, at 4:49 PM, Cathy Zhang > wrote: Hi Andrew, Thanks for bringing this up. As authors of another service chain header dra= ft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your= proposal. Your proposal is in sync with our service chain header draft, i.e., besides= the base header and path header, all other information can be expressed as= optional metadata in TLV format. Last IETF meeting=92s conclusion is to merge the two header drafts----NSH d= raft and SCH draft. We have reached out to the NSH authors about doing the= merging as well as addressing the comments/opinions voiced in the Toronto = IETF meeting and email alias. Thanks, SCH authors From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andr= ew) Sent: Tuesday, November 04, 2014 8:12 AM To: sfc@ietf.org Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Heade= rs remains the only option for NSH During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_55741672D88A4138A79CD5B1F8A83A86ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Cathy, 

We need to be accurate here: there was no =93conclusion=94 to merge drafts,= rather your co-author presented some slides that highlighted what you and = your co-authors feels are areas of similarity and suggested that a merge sh= ould occur.  We =97 the NSH co-authors =97 are happy to discuss this with you (and are actively doing so) to see = if we can reach an agreement on joint text in order to ensure that we meet = the WG goals=94

Thanks
Paul


On Nov 10, 2014, at 4:49 PM, Cathy Zhang <Cathy.H.Zhang@huawei.com> wrote:

Hi Andrew,
 
Thanks for bringing this up. As au= thors of another service chain header draft (https://data= tracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your proposal.
Your proposal is in sync with our = service chain header draft, i.e., besides the base header and path header, = all other information can be expressed as optional metadata in TLV format.<= o:p>
 
Last IETF meeting=92s conclusion i= s to merge the two header drafts----NSH draft and SCH draft.  We have = reached out to the NSH authors about doing the merging as well as addressin= g the comments/opinions voiced in the Toronto IETF meeting and email alias.  
 
Thanks,
SCH authors
 
 
From:<= /span> sfc [= mailto:sfc-bounces@ietf.org] = ;On Behalf Of Dolganow, = Andrew (Andrew)
Sent: Tuesday, Nov= ember 04, 2014 8:12 AM
To: sfc@= ietf.org
Subject: [sfc] dra= ft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remai= ns the only option for NSH
 
During the last IETF there were several = attendees (including myself) who voice strong opinion against mandatory the= inclusion of the information beyond based header and service path header. = Not all applications require the extra overhead. A discussion on the list followed (see attached email that initi= ated that discussion) on alternative encodings including mechanisms like us= e of one of the reserved bit or using another MD Type value to represent he= ader without Mandatory Context Headers.
 
Can the authors comment on whether they = are strongly opposed to include in their draft a proposal that has an optio= n to encode the NSH without the Mandatory Context Headers? I am OK with an = encoding that either:
  • makes  Mandatory Context Headers op= tional or
  • Has two types of NSG MD Type 0x1 - the m= andatory context headers are present, 0x2 the mandatory context header are = not included  (optional variable length metadata could still be used i= n that type  of header)
 
Andrew
 
 
_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.ietf.org/mailman/listinfo/sfc

--_000_55741672D88A4138A79CD5B1F8A83A86ciscocom_-- From nobody Tue Nov 11 08:13:48 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E48E1A9041 for ; Tue, 11 Nov 2014 08:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOOYzXpjhxrI for ; Tue, 11 Nov 2014 08:13:39 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 625301A9043 for ; Tue, 11 Nov 2014 08:13:38 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id sABGDUAe029169; Wed, 12 Nov 2014 01:13:30 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 5A00FE00B8; Wed, 12 Nov 2014 01:13:30 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4DB0EE00B7; Wed, 12 Nov 2014 01:13:30 +0900 (JST) Received: from [127.0.0.1] ([129.60.20.75]) by imail3.m.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id sABGDSPT008126; Wed, 12 Nov 2014 01:13:30 +0900 Message-ID: <5462355F.30503@lab.ntt.co.jp> Date: Wed, 12 Nov 2014 01:12:15 +0900 From: Kengo Naito User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Pham, Chuong D" , Ron Parker , "huang@sce.carleton.ca" , "'Thomas Narten'" References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> <5602569641FB314FB4D9AD5659D41B9C2C30A3B083@WSMSG3154V.srv.dir.telstra.com> In-Reply-To: <5602569641FB314FB4D9AD5659D41B9C2C30A3B083@WSMSG3154V.srv.dir.telstra.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/LQEX-B6TYUM4OCB3wCPfm7RZ_fA Cc: "sfc@ietf.org" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 11 Nov 2014 16:13:46 -0000 Hi all, IMO, I don't think it is strange to have several separate documents, as use cases of SFC may vary greatly in each environment. I think it is more useful if people can read precise use case and considerations of each environment. Also, each document is well written in term of this point. Cheers, Kengo (2014/11/11 11:18), Pham, Chuong D wrote: > I also support Chang's and Ron's statements. It is strange to isolate the use cases from each domain into separate documents without any consideration for relationship, commonality and synergy between the use cases. We don't work like that over here. In fact, we used to work like that... > Chuong > > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Tuesday, 11 November 2014 10:15 AM > To: huang@sce.carleton.ca; 'Thomas Narten' > Cc: sfc@ietf.org > Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt > > Chang, > > I agree that after all is said and done with SFC, it will make much more sense for a reader to view a single use case document to provide the context as to why the architecture and protocols turned out the way they did. > > Ron > > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang > Sent: Monday, November 10, 2014 10:06 AM > To: 'Thomas Narten' > Cc: sfc@ietf.org > Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt > > Hi Thomas, > > I appreciate that you clearly state your questions and concerns. This will be very helpful for the working group to move forward. With due respect, I have some brief comments. > > 1. The WG has approved three use case documents as internet-draft. However there were still some heated discussions about service path forking, which has not been clearly addressed by the three use case documents. This leads to a question about whether we have really understood all important use cases and their impacts. I share your comments on IETF's reluctance to pass a large number of low quality RFCs. There is very little chance that these three use cases will all become RFCs. It will also look strange for a reader outside the WG to read three use case documents instead of one. IMHO, the WG should generate a merged use case document that gets the supports across the working group. To this end, this draft use case document in question can be a good starting point. I hope, as the chair, you can help lead the WG to reach consensus rather than majority votes as the WG has been doing. > > 2. About Item 6 in your email, I know the WG has limited its scope to a single administrative domain. This is fine if the protocols developed by this working group can be easily extended to multiple domains in future. > However, some of the existing protocol proposals in the WG are quite rigid and hard to extend. This will likely make those protocols short-lived. As you said in the earlier email, it is in the best interest of this WG to develop good quality protocols that can stand the test of time. In Section > 2.9 of the problem statement document that is currently being approved by IETF, crossing administrative boundaries is considered important for providing end-to-end service visibility. This is a good comment for taking the big picture into account. More information about recursive SFC can be found in draft-huang-sfc-use-case-recursive-service-00. > > Best regards, > > Chang > > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > Sent: Sunday, November 09, 2014 9:18 PM > To: sfc@ietf.org > Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt > > Note: chair hat off. > > I have a number of concerns with the document, including: > > 1) I don't see what significant content it has beyond what the other WG use case documents contain. > > 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this section is trying to say. Is it saying SFC needs TE? Or TE needs SFC? And how is that a "use case"? TE already exists. Does the addition of SFC somehow change things? > > 3) Section 4.4 seems to simply say that some SFC flows are bi-directional. > That has been an assumption in SFC from the start. Doesn't the problem statement/architecture say as much? > > 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm not sure what use case has Ethernet in it or why that is called out. SFC can run over Ethernet so long as it is also an IP subnet. Or is this section trying to say something else? If so, what? > > 5) Section 4.6 talks about service path forking. The WG has discussed "forking" multiple times, and it's a basic part of SFC. So what exactly is this section that isn't covered elsewhere? > > 6) I don't follow or understand the "recursive SFC" section. When it talks about different service providers, I have to wonder how that applies to SFC, given our scope is restricted to a single administrative domain. But more to the point, how does "recursive" > differ from straightforward SFC usage, where different subscribers use different service chains? > > Thomas > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > -- ---------------------------------------- NTT Network Technology Laboratories Kengo Naito E-Mail: naito.kengo@lab.ntt.co.jp TEL: +81 422-59-4949 ---------------------------------------- From nobody Tue Nov 11 12:32:37 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829A31A910F for ; Tue, 11 Nov 2014 12:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lR07kq8e8gIj for ; Tue, 11 Nov 2014 12:32:31 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C7F1A8917 for ; Tue, 11 Nov 2014 12:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4640; q=dns/txt; s=iport; t=1415737925; x=1416947525; h=from:to:subject:date:message-id:mime-version; bh=uSCUn7ThG57Gzp1v+GVbtuJ/gC9ct0QZwoko1p6CVZw=; b=IElv2q9iNraFHVwEk0FV+Iu5QSOXIlnR/5q2ABPKQnuQdW/J84UuS3DA NOhr8E9+Cn/N6sn3aNMpsDWgHE4UzbMt5FQ9pDWuvs3KBJmKyMEouzVNM KoXI0ACYJdHbKuJvOpXU73YnHN1cCmRN/RklwDZNNB9qKDN9bQsnT9i1n E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFABtxYlStJA2N/2dsb2JhbABcgkhGgTHVDhYBAQEBAX2ECYELAQx0JwQBiFPPSwEBAQcBAQEBAR2QQwEBhSEFkjGLdJZgg3qBezmBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,362,1413244800"; d="scan'208,217"; a="95641918" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 11 Nov 2014 20:32:05 +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 sABKW4sl013686 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 11 Nov 2014 20:32:04 GMT Received: from xmb-rcd-x11.cisco.com ([169.254.1.149]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 11 Nov 2014 14:32:04 -0600 From: "Deepak Kumar (dekumar)" To: "draft-aldrin-sfc-oam-framework@tools.ietf.org" , "sfc@ietf.org" Thread-Topic: Mail regarding draft-aldrin-sfc-oam-framework Thread-Index: AQHP/e6NCk2lBK7nW06FOr7svBp+LA== Date: Tue, 11 Nov 2014 20:32:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.79.119] Content-Type: multipart/alternative; boundary="_000_D087962097628dekumarciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/X5Dh1Ge1qrSuSnfzNe9Wrz_p-Ts Subject: [sfc] Mail regarding draft-aldrin-sfc-oam-framework X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 20:32:33 -0000 --_000_D087962097628dekumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In section 2. SFC Layering Model We have Service Layer which can also be broken down in the layers as within= a service Function chain we can have multiple SFPs due to one of the SFF c= hanging the classifier. In Section 3.1 we are mentioning Availability which I am not sure is right = term as performance management has concept of Availability also as a SLA, a= s for customer finding loss is not that important SLA but important SLA is = availability and unavailability of the flow over time as that's the SLA tha= t can be sold. To find faults in real time Alarm Indication Signal technique or notificati= on should also be considered, eg:- within a service function chain, one of = the SFF/SF is restarted and this belong to multiple SFC chain. In section 3.1.2 =96 This should be extended to say that protocol should be= able to provide the SLAs instead of delay, and loss calculation. Just loss= calculation is not enough to determine availability of circuit. In section 4.1 We should also add verify packet re-ordering and corruption in unidrirectio= nal connection. Also we should say "Proactively and on-demand" test alternate or protected = paths to ensure reliability of network configuration. On Section 4.4 same Performance has to be extended. Even for Performance we should have both proactive and on-demain support fr= om the protocool to be developer later. Most of the time Performance Measurement fails because OAM packet doesn't t= ake the same path as data path and also where the timestamping or delay is = measured. As "O" bit is in the header protocol has to be defined such that = "o" bit is not checked in middle of network. Framework should atleast talk about Measurement Point. Thanks, Deepak --_000_D087962097628dekumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <89527CA9704B9F488702B7D4DBD79E2E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

In section 2. SFC Layering Model

We have Service Layer which can also be broken down in the layers as w= ithin a service Function chain we can have multiple SFPs due to one of the = SFF changing the classifier.

In Section 3.1 we are mentioning Availability which I am not sure is r= ight term as performance management has concept of Availability also as a S= LA, as for customer finding loss is not that important SLA but important SL= A is availability and unavailability of the flow over time as that's the SLA that can be sold.

To find faults in real time Alarm Indication Signal technique or notif= ication should also be considered, eg:- within a service function chain, on= e of the SFF/SF is restarted and this belong to multiple SFC chain.

In section 3.1.2 =96 This should be extended to say that protocol shou= ld be able to provide the SLAs instead of delay, and loss calculation. Just= loss calculation is not enough to determine availability of circuit.

In section 4.1

We should also add verify packet re-ordering and corruption in unidrir= ectional connection.
Also we should say "Proactively and on-demand" test alternat= e or protected paths to ensure reliability of network configuration.

On Section 4.4 same Performance has to be extended. 
Even for Performance we should have both proactive and on-demain suppo= rt from the protocool to be developer later.

Most of the time Performance Measurement fails because OAM packet does= n't take the same path as data path and also where the timestamping or dela= y is measured. As "O" bit is in the header protocol has to be def= ined such that "o" bit is not checked in middle of network.

Framework should atleast talk about Measurement Point.

Thanks,
Deepak
--_000_D087962097628dekumarciscocom_-- From nobody Tue Nov 11 13:22:04 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F045B1ACDBB for ; Tue, 11 Nov 2014 13:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 rqC5RKVVgBMb for ; Tue, 11 Nov 2014 13:21:55 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CC61A9104 for ; Tue, 11 Nov 2014 13:21:55 -0800 (PST) X-AuditID: c618062d-f79206d0000014d2-99-54622542b60a Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 2F.97.05330.24522645; Tue, 11 Nov 2014 16:03:30 +0100 (CET) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Tue, 11 Nov 2014 16:21:45 -0500 From: David Allan I To: "sfc@ietf.org" Thread-Topic: OAM discussion.... Thread-Index: Ac/98dyot2erpWjCTzGv7EjJ18j0nw== Date: Tue, 11 Nov 2014 21:21:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C393186A3eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyuXRPiK6TalKIwaN3khZPHmxld2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsctfcwFDf4Vf24+YmlgfOPcxcjJISFgItH1fAYbhC0mceHe eiCbi0NI4AijxP61O1kgnOWMEleW3mIGqWITMJDY8/8LI4gtIqAoce7lBBYQW1hAWuJl824W iLiCxNPHbawQtp7EoksL2EFsFgFViXW/fzKB2LwCvhILl74Eq2EE2vz91BqwOLOAuMStJ/OZ IC4SkFiy5zwzhC0q8fLxP1YIW0lizutrzBD1+RJLbuxmhZgpKHFy5hOWCYxCs5CMmoWkbBaS Moi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0OLUsN93IYBMjMPSPSbDp7mDc89Ly EKMAB6MSD68Bd2KIEGtiWXFl7iFGaQ4WJXHeWbXzgoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwLtStXtqULqT7WarlvVZ43OyID+xGh1gURYP961evjBedceP3qav+t0L0Y+N6jGYILW1k 8djk/Hyp81ytIMbMhKYA85Mad31OPPn/vsbJQHTND5bwxidnGkxMTAW503iapvooKMjYbT9T 7v+Fq7/9buBuh+tPrGXKrfpq/FZlxnyWXbHp2jYlluKMREMt5qLiRAAr5aW8XgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/OrGMOrz6FwiW00YQJJVoRkD575U Subject: [sfc] OAM discussion.... X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 11 Nov 2014 21:22:00 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C393186A3eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi A recap of my comments stated and unstated at the mike..... 1) We need to sort out and document the difference between what can be= achieved by explicit protocol design, and what requires impersonation of a= pplication traffic by a "golden customer" or similar concept. The latter re= quiring some larger wrapper that encapsulates the SFC infrastructure and ca= n inject and measure non-OAM application impersonating traffic. IMO there is nothing about an SF can be usefully tested by a specific OAM p= rotocol as it will not fate share with any aspect of the function as the SF= will be application specific and the OAM won't be. So there is no point in= trying/pretending. IMO a specific OAM protocol should be able to verify th= e service graph for a given SFP and that is about it, and we should focus o= n what aspects of the infrastructure that can be tested via explicit protoc= ol design. IMO that would be limited to aspects of path configuration and f= ault management. Performance measurement being impossible. 2) As for the Golden Customer concept, Luca raised a good point that s= uch traffic should not be able to leak into the larger network. MPLS OAM us= es the 127/8 prefix to do this. So solutions exist. 3) The language needs a bit of work. At first I found it incomprehensi= ble, primary because of the abuse of the term "availability". To an OAM guy= , availability is a "metric" (e.g. 99.993% uptime), and not a "state". Read= ing the document suggests that "availability" is really referring to a "sta= te". That being said I highly suspect that it will provide impossible to define = an availability metric or set of metrics for a service function path (purpo= se being customer facing) or an individual service function (purpose being = supplier auditing) although I could see a business rationale for trying ;-)= ... 4) What we could consider would be a framework whereby vendors could o= ffer test scripts for the "golden customer" (treating the chain as a black = box DUT) IF the group believes such functionality is ultimately required. I= 'm not sure we would really want to standardize this vs. simply suggest the= possibility and leave it to SF providers to sort out. That's the view from here Dave --_000_E6C17D2345AC7A45B7D054D407AA205C393186A3eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

A recap of my comments stated and unstated at the mi= ke…..

 

1)      We need to sort out and document the difference bet= ween what can be achieved by explicit protocol design, and what requires im= personation of application traffic by a “golden customer” or si= milar concept. The latter requiring some larger wrapper that encapsulates the SFC infrastructure and can inject and measur= e non-OAM application impersonating traffic.

 

IMO there is nothing about an SF can be usefu= lly tested by a specific OAM protocol as it will not fate share with any as= pect of the function as the SF will be application specific and the OAM won= ’t be. So there is no point in trying/pretending. IMO a specific OAM protocol should be able to verify the service graph for= a given SFP and that is about it, and we should focus on what aspects of t= he infrastructure that can be tested via explicit protocol design. IMO that= would be limited to aspects of path configuration and fault management. Performance measurement being imp= ossible.

 

2)      As for the Golden Customer concept, Luca raised a g= ood point that such traffic should not be able to leak into the larger netw= ork. MPLS OAM uses the 127/8 prefix to do this. So solutions exist.

 

3)      The language needs a bit of work. At first I found = it incomprehensible, primary because of the abuse of the term “availa= bility”. To an OAM guy, availability is a “metric” (e.g. = 99.993% uptime), and not a “state”. Reading the document suggests that “availability” is really referring to a “s= tate”.

 

That being said I highly suspect that it will= provide impossible to define an availability metric or set of metrics for = a service function path (purpose being customer facing) or an individual se= rvice function (purpose being supplier auditing) although I could see a business rationale for trying ;-)… =

 

4)      What we could consider would be a framework whereby= vendors could offer test scripts for the “golden customer” (tr= eating the chain as a black box DUT) IF the group believes such functionali= ty is ultimately required. I’m not sure we would really want to standardize this vs. simply suggest the possibility and lea= ve it to SF providers to sort out.

 

That’s the view from here

Dave

--_000_E6C17D2345AC7A45B7D054D407AA205C393186A3eusaamb105erics_-- From nobody Tue Nov 11 16:52:52 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616181A8903 for ; Tue, 11 Nov 2014 16:52:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 btmMQJHrE57W for ; Tue, 11 Nov 2014 16:52:43 -0800 (PST) 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 324531A870D for ; Tue, 11 Nov 2014 16:52:43 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLN34318; Wed, 12 Nov 2014 00:52:41 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 12 Nov 2014 00:52:39 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.18]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Wed, 12 Nov 2014 08:52:28 +0800 From: "Zhulei (MBB Research)" To: "sfc@ietf.org" Thread-Topic: Timeline to SFC architecture and encapslution discussion Thread-Index: Ac/+EX2jYlxlZkIzQe238xjC4+Mg+g== Date: Wed, 12 Nov 2014 00:52:28 +0000 Message-ID: <470F27D1263A1B4EB73491ED995DE6252597585A@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.119] Content-Type: multipart/alternative; boundary="_000_470F27D1263A1B4EB73491ED995DE6252597585ANKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tG05w3FW5BDveWxG8BMla4JgpOI Cc: "narten@us.ibm.com" , "jguichar@cisco.com" , "Zhulei \(MBB Research\)" Subject: [sfc] Timeline to SFC architecture and encapslution discussion X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 12 Nov 2014 00:52:45 -0000 --_000_470F27D1263A1B4EB73491ED995DE6252597585ANKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQoNCg0KUmVwZWF0IHRoZSBjb21tZW50cyBvbmxpbmUgaW4gbGlzdC4gIFdo ZW4gSSBzYXcgdGltZWxsaW5lIFNGQyBhcmNoaXRlY3R1cmUsIHRoYXQgbWFkZSBwcm9ncmVzcyB0 byBnZXQgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IHJlYWR5IHNvb24uDQoNCg0KDQpUaGUgY29tbWVu dCBpcyB0aGF0IHRoZSBkaXNjdXNzaW9ucyBvbiBhcmNoaXRlY3R1cmUgaGF2ZSBub3QgYmVlbiB0 b3VjaGVkIHRvIGVuY2Fwc2x1dGlvbiBwYXJ0IHlldCwgYW5kIGFyY2hpdGVjdHVyZSBsZXZlbCBk aXNjdXNzaW9ucyBhcmUgcmFpc2VkIGJ5IG90aGVyIGRyYWZ0aW5nIHdvcmtzIGR1cmluZyB0aGlz IHdlZWsuIE15IGFzc3VtcHRpb24gdG8gdGhpcyBzdGFnZSB3ZSBtaWdodCBub3QgdGFrZSB0aGUg bXVjaCBsb2FkIG9uIGFyY2hpdGVjdHVyZSwgZm9yIGxvbmcgdGltZSwgYmVmb3JlIHdlIHN0YXJ0 IHNwZWNpZmljYXRpb24uDQoNCg0KDQpJZiB0aGUgdGltZWxpbmUgb2Ygd29ya2luZyBncm91cCBp cyB0byBmaW5hbGl6ZSBlbmNhcHVzbHV0aW9uIHByb3RvY29sIGluIEF1Z3VzdCAyMDE1LCB3ZSBt aWdodCBiZSBhYm91dCB0aW1lIHRvIHN0YXJ0IHByb3RvY29sIGRzaWN1c3Npb24gZm9yIG15IEdp LUxBTiB1c2UgY2FzZS4NCg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KWmh1IExlaQ0KDQoNCg== --_000_470F27D1263A1B4EB73491ED995DE6252597585ANKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hello all,

 

Repeat the comments online in list.  When I saw timelline SFC = architecture, that made progress to get architecture document ready soon.

 

The comment is that the discussions on architecture have not been touche= d to encapslution part yet, and architecture level discussions are raised b= y other drafting works during this week. My assumption to this stage we mig= ht not take the much load on architecture, for long time, before we start specification.

 

If the timeline of working group is to finalize encapuslution protocol i= n August 2015, we might be about time to start protocol dsicussion for= my Gi-LAN use case.

 

Best regards,

Zhu Lei

 

--_000_470F27D1263A1B4EB73491ED995DE6252597585ANKGEML512MBSchi_-- From nobody Wed Nov 12 12:06:40 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C557A1A8706 for ; Wed, 12 Nov 2014 12:06:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAhSEWKFuZa9 for ; Wed, 12 Nov 2014 12:05:56 -0800 (PST) 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 BEEB91AD020 for ; Wed, 12 Nov 2014 12:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=141022; q=dns/txt; s=iport; t=1415822737; x=1417032337; h=message-id:date:from:reply-to:mime-version:to:cc:subject; bh=Pf+jx+CW726vOo04mSsTzQB1pBT8iLTjeT7pouDAFVI=; b=F41nSUbd7IOy/lzJWM5pOWG6ulEdTFGuXG15COLh+8Fb9RJRB7D0w04d 3z0aIA6yN0RuylvKNF6rw4vzBbjeTwwaMNfqLc2fULvf6rAmvYxzDHtjW r7sAdpl4jfgdU3+nTcDSlm49DpGM9j4j6sSp316ZgBQ7vZ3oSWnb8Q7X3 k=; X-IronPort-AV: E=Sophos;i="5.07,370,1413244800"; d="scan'208,217";a="368540687" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP; 12 Nov 2014 20:05:19 +0000 Received: from [10.21.81.24] (sjc-vpn4-280.cisco.com [10.21.81.24]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id sACK5InD012522; Wed, 12 Nov 2014 20:05:18 GMT Message-ID: <5463BD7D.6000007@cisco.com> Date: Wed, 12 Nov 2014 20:05:17 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-sfc-architecture@ools.ietf.org Content-Type: multipart/alternative; boundary="------------090705070101090606030805" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Akqz_U-FW4PlBeYzkNx6JMErWtY Cc: "sfc@ietf.org" , sfc-chairs@tools.ietf.org Subject: [sfc] Some concerns about draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:06:21 -0000 This is a multi-part message in MIME format. --------------090705070101090606030805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit SB> This document lacks the precision and that I would have hoped for SB> in an architecture. I understand that the this was deliberate SB> in order to allow implementation flexibility, but I don't SB> buy that. SB> SB> What we have here is a type of layered network, and whilst SB> verbal discussions have refuted that, you have many references SB> to overlay topologies. SB> SB> This would be better understood if you described it as a layered SB> system, if you only used generalized the components with fully SB> functionality, and then explained which could be NULL. In the SB> case of sub-functional components they should not be part of the SB> core architecture, but the techniques used to create a full function SB> component by assistance (the proxy) described outside the main SB> architecture. SB> SB> I understand that in part the approach used here was to allow SB> a mixture of implementation styles - the concept of explicit SB> and implicit SFE - with network layer constructs supplying the SB> implicit SFE. However it would be better to think of the use SB> of implicit SFE as a type of network recursion in which the SB> the encapsulator (which I think is distinct from the classifier) SB> chooses how to encode the SFP on the packet. SB> SB> I have a nagging concern about the way that the terms packets is SB> used in this text. The way it is used one would expect that there SB> is a one for one mapping between input and output packets, but that SB> is surely not the case. A trivial point is the case where an SF SB> needs to defragment. Although at the physical layer the units are SB> packets, there may surely be higher order constructs traveling SB> between SFs. Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-02 Abstract This document describes an architecture for the specification, sb> an arch or THE arch? 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. This document does not propose solutions, protocols, or extensions to existing protocols. 1. Introduction This document describes an architecture used for the creation and sb> and or THE ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components. An overview of the issues associated with the deployment of end-to- end service function chains, abstract sets of service functions and their ordering constraints that create a composite service and the subsequent "steering" of traffic flows through said service functions, is described in [I-D.ietf-sfc-problem-statement]. This architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity. Service function chains enable composite services that are constructed from one or more service functions. 1.1. Scope This document defines a framework to realize Service Function Chaining (SFC) with minimum requirements on the physical topology of the network. The proposed solution relies on initial packet classification. Packets initially classified for handling by a set of Service Functions (SFs) in the SFC-enabled domain are then forwarded to that set of SFs for processing. SB> Are you allowed to reclassify, or do staged classification? SB> Yes you are - you say so later - but that is not implied SB> by the above. This document does not make any assumption on the deployment context. The proposed framework covers both fixed and mobile networks. SB> Given that you make no deployment context assumption, surely SB> the followup mobile/fixed specific is not relevant. The architecture described herein is assumed to be applicable to a single network administrative domain. While it is possible for the architectural principles and components to be applied to inter-domain SFCs, these are left for future study. 1.2. Assumptions The following assumptions are made: o Not all SFs can be characterized with a standard definition in terms of technical description, detailed specification, configuration, etc. o There is no global or standard list of SFs enabled in a given administrative domain. The set of SFs varies as a function of the service to be provided and according to the networking environment. o There is no global or standard SF chaining logic. The ordered set of SFs that needs to be enabled to deliver a given service is specific to each administrative entity. SB> Surely it is application specific even within an admistration? o The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain. SB? see previous Halpern & Pignataro Expires March 24, 2015 [Page 3] Internet-Draft SFC Architecture September 2014 o Several SF chaining policies can be simultaneously applied within an administrative domain to meet various business requirements. o No assumption is made on how FIBs and RIBs of involved nodes are populated. o How to bind traffic to a given SF chain is policy-based. 1.3. Definition of Terms Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a firewall. Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted. SB> I think that you probably need an explicit definition of service. SB> I find the text in the definition of NS self referential which is SB> not helpful. Classification: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. SB> Isn't it really SB> Locally instantiated matching of traffic flows against policy for SB> subsequent application of the required set of network service functions. SB> The policy may be ustomer/network/service specific. Classifier: An element that performs Classification. SB> A network element perhaps? Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints that must SB> Isn't the SFC also ordered? be applied to packets and/or frames selected as a result of classification. SB> Packets, or higher order constructs like flows? You cannot SB> do some of the SFs packet by packet The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. SB> See my earlier not about the apparently more restricted definition SB> I think that you need to make the generalization clearer earlier. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a Service Function can be realized as a virtual element or be embedded in a physical network element. One or multiple Service Functions SB> multiple or more? can be embedded in the same network element. Multiple Halpern & Pignataro Expires March 24, 2015 [Page 4] Internet-Draft SFC Architecture September 2014 occurrences of the Service Function can exist in the same administrative domain. One or more Service Functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract Service Functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), LI (Lawful Intercept), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer. SB> Not sure those are abstract SFs, surely they are explicit? An SF may be SFC encapsulation aware, that is it receives and acts on information in the SFC encapsulation, or unaware, in which case data forwarded to the SF does not contain the SFC encapsulation. Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, a service function forwarder is responsible for delivering traffic to a classifier when needed and supported, mapping out traffic to another SFF (in the same or different type of overlay), and terminating the SFP. SB> In these days of NFV it may not be received from the network. SB> Surely the traffic is native until it gets to a classifier. The SB> way you have it here it looks like the first element is the SFF SB> but I am not sure that is the case. SB> Perhaps: A service function forwarder is responsible for forwarding SB> traffic between service functions. Metadata: provides the ability to exchange context information between classifiers and SFs and among SFs. SB> I think the first noun is missing in the above, but in any case SB> I think a more complete definition is needed. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network. SB> You have not defined control components. SB> I think "notion" is a redundant term. SB> I am somewhat confused by your definition. SB> Is this really about the mapping of packets between an arbitrary SB> member of an SF to a specific instance of the SF? SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC Encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries data plane context information, also referred to as metadata. SB> Surely the "SFC E is used to attach the information needed to SB> direct the packet through the ordered set of SFs, together with SB> associated metadata. An additional network layer encapsulation is needed SB> to carry the packet over the physical network. Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to Halpern & Pignataro Expires March 24, 2015 [Page 5] Internet-Draft SFC Architecture September 2014 identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. SB> Not sure of the wisdom of including a definition for the future, since SB> when you use it you may need to tune the definition. SFC-enabled Domain: A network or region of a network that implements SFC. An SFC-enabled Domain is limited to a single network administrative domain. SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements. SB> Not sure considering then as logical is quite right. It depends SB> on the mapping of the operation to the physical. I could see SB> cases where they are physical. Surely the point is that they SB> may be co-located with another network function such as a router SB> an operating system component such as a hypervisor. 2. Architectural Concepts The following sections describe the foundational concepts of service function chaining and the SFC architecture. Service Function Chaining enables the creation of composite (network) services that consist of an ordered set of Service Functions (SF) that must be applied to packets and/or frames selected as a result of classification. Each SF is referenced using an identifier that is unique within an SF-enabled domain. No IANA registry is required to store the identity of SFs. SB> I am still worried about using packets. Obviously we operate on SB> pkts, but the operation may require the reconstuction of some SB> packet grouping typically some element of a flow before the operation SB> can be performed. A trivial example is defragmenting a packet group SB> but since we are dealing with abstract SFs we cannot specify the SB> the unit of operation. Service Function Chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. SB> The above is a bit late in the text. I think it needs to go earlier. 2.1. Service Function Chains In most networks, services are constructed as abstract sequences of SB> I don't think that are abstract in this context. SB> Are you talking about traditional (current physically instantiated SB> SFCs in the previous sentence? SFs that represent SFCs. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed. SB> Again I am not sure "abstrated view" is right here Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF. Such graph nodes (SFs) can be part of zero, one, or many SFCs. A given graph node (SF) can appear one time or multiple times in a given SFC. SB> Not sure that graphs is right, since you only show the case SB> of a linear chain. The construct you are going to use is SB> graph, but that is not what the figure shows. SFCs can start from the origination point of the service function graph (i.e.: node 1 in Figure 1), or from any subsequent node in the graph. SB> OK so are you trying to distinguish between physically and SB> SFC (the new technology) instantiated SFCS? SFs may therefore become branching nodes in the graph, with Halpern & Pignataro Expires March 24, 2015 [Page 6] Internet-Draft SFC Architecture September 2014 those SFs selecting edges that move traffic to one or more branches. An SFC can have more than one terminus. SB> Again that is not what your figure shows. ,-+-. ,---. ,---. ,---. / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) \ / \ / \ / \ / `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' Figure 1: Service Function Chain Graphs 2.2. Service Function Chain Symmetry SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic. SFCs may contain cycles; that is traffic may need to traverse one or more SFs within an SFC more than once. Solutions will need to ensure suitable disambiguation for such situations. The architectural allowance that is made for SFPs that delegate choice to the network for which SFs and/or SFFs a packet will visit creates potential issues here. A solution that allows such delegation needs to also describe how the solution ensures that those service chains that require service function chain symmetry can achieve that. Further, there are state tradeoffs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier Halpern & Pignataro Expires March 24, 2015 [Page 7] Internet-Draft SFC Architecture September 2014 functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example: a single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier. Another case is the one of stateful classifiers where several classifiers may be clustered and share state. Lastly, another case entails fully distributed classifiers, where synchronization needs to be provided through unspecified means. This is a non-comprehensive list of common cases. SB> Isn't an important class of classifiers one that learns state from the SB> egress packets/flows that is then used to provide state for the SB> return packets/flow 2.3. Service Function Paths A service function path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and SB> Not sure "more granular" is needed. operational constraints to the abstract requirements of a service SB> Not sure they are abstract requirements. When you apply them they SB> are explicit. chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes. As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP says essentially that SB> "says essentially is not a tight definition" any order of SFF and SF may be used as long as it is within data center 1, and where the second SFP allows the same latitude, but only within data center 2. Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs may be associated with a single SFC. SB> So a SFP is a specific instance of a member of the set of available SFCs SB> chosen as a result of applying policy at one or points along the SFC? The architecture allows for the same SF to be reachable through multiple SFFs. In these cases, some SFPs may constrain which SFF is used to reach which SF, while some SFPs may leave that decision to the SFF itself. Further, the architecture allows for two or more SFs to be attached to the same SFF, and possibly connected via internal means allowing more effective communication. In these cases, some solutions or Halpern & Pignataro Expires March 24, 2015 [Page 8] Internet-Draft SFC Architecture September 2014 deployments may choose to use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for such an environment. This must be coordinated with the SFF so that the service function forwarding can properly perform its job. Implementation details of such mechanisms are considered out of scope for this document, and can include a spectrum of methods: for example situations including all next-hops explicitly, others where a list of possible next-hops is provided and the selection is local, or cases with just an identifier, where all resolution is local. This architecture also allows the same SF to be part of multiple SFPs. SB> Didn't you just say that? 3. Architecture Principles Service function chaining is predicated on several key architectural principles: 1. Topological independence: no changes to the underlay network forwarding topology - implicit, or explicit - are needed to deploy and invoke SFs or SFCs. 2. Plane separation: dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding). 3. Classification: traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e. forming a service graph) thus enabling changes/updates to the SFC by SFs. Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, or it can come from external systems. SB> I think that it can surely be as a result of higher level inspections? 4. Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration). Generally speaking, metadata can be thought of as providing and sharing the result of classification SB> Just classifications, or classifications and processing operations? SB> There is gray zone between a packet forwarding system and SB> a distributed computing system and I am not sure where SFC fits, SB> nor am I sure that it makes sense to be specific at this stage. SB> It is entirely possible that an SFC consumes the packet/flow SB> rather than only having the capability to forward it between SB> in ingress and egress. (that occurs within the SFC- enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose Halpern & Pignataro Expires March 24, 2015 [Page 9] Internet-Draft SFC Architecture September 2014 that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. 5. Service definition independence: The SFC architecture does not depend on the details of SFs themselves. Additionally, no IANA registry is required to store the list of SFs. SB> Yes, but you should be careful not to preclude it. 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. SB> Yes and no. What about the resource implications? 7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria. 4. Core SFC Architecture Components At a very high level, the logical architecture of an SFC-enabled Domain comprises: SB> A list would be handy rather than just a figure, and you need SB> some text to expand on the figure. o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: Service Function Chain Architecture SB> This is a very confusing diagram SB> Surely the SFC encap is attached to the packet SB> The fig seems to confuse the the packets and the path. The following sub-sections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how each of these architectural components interact is provided in Figure 3: SB> Well maybe, but it's not quite obvious what you are showing. SB> some overview text would help before you get into the detail. Halpern & Pignataro Expires March 24, 2015 [Page 10] Internet-Draft SFC Architecture September 2014 +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation | SFC | +---------+ +----------------+ Encapsulation +---------+ |SFC-Aware|-----------------+ \ +------------|SFC Proxy| | SF | ... ----------+ \ \ / +---------+ +---------+ \ \ \ / +-------+--------+ | SF Forwarder | | (SFF) | +-------+--------+ | SFC Encapsulation | ... SFC-enabled Domain ... | Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ __,-' `'''' Figure 3: Service Function Chain Architecture Components SB> Coming back here after reading a bit more. Is the SFF to be considered the SB> hub in a hub and spoke processing model for a set of SFs? If so it would SB> be useful to say that up front. However that raises the issue of whether SB> the single network attachment point that you show is desirable. A standard SB> firewall design would not mix dirty and clean traffic, and yet that is SB> what the above appears to show. 4.1. SFC Encapsulation The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required. SB> I don't think that is quite right. Surely the SB> SFC encapsulation enables to select the next SB> element of the path? The SFC encapsulation provides explicit information used to identify SB> Provides or carries? the SFP. However, the SFC encapsulation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. SB> ... but surely it is a shim layer of some sort? If packets need to flow between separate physical platforms, the SFC encapsulation therefore relies on an outer network transport. SB> Surely it is network layer header specific to the inter SFC SB> transport? Transit forwarders -- such as router and switches -- simply forward SFC encapsulated packets based on the outer (non-SFC) encapsulation. SB> d/simply/ Halpern & Pignataro Expires March 24, 2015 [Page 11] Internet-Draft SFC Architecture September 2014 One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such any network transport protocol may be used to carry the SFC encapsulated traffic. SB> Not sure I like "network transport protocol" since this is going SB> to be confused with transport layer and I am not sure whether SB> you would require a transport layer, indeed the SFE might will SB> be considered a transport layer in the classical sense. 4.2. Service Function (SF) The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation. SB> I do not understand the above para. While the SFC architecture defines a new encapsulation - the SFC encapsulation - SB> no it does not - it is not defined in this memo. You introduce SB> the concept and define some of the characteristics of it. and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6). The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section. SB> The above is confusing. Do they participate in the architecture (this SB> text)? I think that you mean that in order to employ SF instances SB> that do not understand the SFE, a proxy as a gateway between the SB> the SFE aware domain and the non-SFE aware domain. Now if it is SB> a gateway why is it not called a gateway rather than a proxy which SB> is something that does something on behalf of something else. SB> I would think that it might be a SFE proxy, but that is not quite SB> right either. This architecture allows an SF to be part of multiple SFPs and SFCs. SB> I am sure you said that before. 4.3. Service Function Forwarder (SFF) The SFF is responsible for forwarding packets and/or frames received from the network to one or more SFs associated with a given SFF using information conveyed in the SFC encapsulation. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. SB> It is not clear why it needs to be the exact same SFF The collection of SFFs and associated SFs creates a service plane overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this service plane, the SFF component connects different SFs that form a service function path. SB> This conceptual model seems quite fundamental and this I SB> am surprised that it is not much earlier in the document. SB> I have been wondering why the SFC system was not considered SB> an overlay network of some sort, and was told by the authors SB> that this was not possible. The above seems at odds with that Sb> statement. SFFs maintain the requisite SFP forwarding information. SB> Maintain - as in being the control plane for this, or SB> maintain as in store? SFP forwarding information is associated with a service path identifier that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed by the constraints of the SFP. If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the Halpern & Pignataro Expires March 24, 2015 [Page 12] Internet-Draft SFC Architecture September 2014 SF may well be stateful. Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification. SB> I feel that the issue of handing higher order objects needs to have SB> been introduced much earlier in the architecture. The SFF also has the information to allow it to forward packets to the next SFF after applying local service functions. Again, while there may be only a single choice available, the architecture allows for multiple choices for the next SFF. As with SFs, the solution needs to operate such that the behavior with regard to specific flows (see the Rendered Service Path) is stable. The selection of available SFs and next SFFs may be interwoven when an SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what is allowed in these cases. Even when the SFF supports and utilizes multiple choices, the decision as to whether to use flow-specific mechanisms or coarser grained means to ensure that the behavior of specific flows is stable is a matter for specific solutions and specific implementations. The SFF component has the following primary responsibilities: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and if needed forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata. 2. Terminating SFPs : An SFC is completely executed when traffic has traversed all required SFs in a chain. When traffic arrives at the SFF after the last SF has finished processing it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and delivers the packet back to the network for forwarding. 3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. This state information may be used for a range of SFP-related tasks such as ensuring consistent treatment of all packets in a given flow, ensuring symmetry or for state-aware SFC Proxy functionality (see Section 4.8). Halpern & Pignataro Expires March 24, 2015 [Page 13] Internet-Draft SFC Architecture September 2014 4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information if it can be arranged to provide explicit service path information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. SB> The title does not seem quite right. What I think you have SB> is a system in which you map an SFC onto an explicit path SB> of some sort in the lower layers (I was going to say network layer SB> but I am not sure if that is what you intend). So I am not sure SB> derived is the correct word. It would be closer to say "emulation SB> of SFF using explicit network paths. Noting that these paths may SB> be encoded in the packet or encoded in the FIB. 4.4. SFC-Enabled Domain Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information. Using the term node to refer generically to an entity that is performing a set of functions, in this context, an SFC Boundary Node denotes a node that connects one SFC-enabled domain to a node either located in another SFC-enabled domain or in a domain that is SFC- unaware. An SFC Boundary node can act as egress or ingress. SB> do you mean or or and/or i.e. can it be both at the same time. An SFC Egress Node denotes a SFC Boundary Node that handles traffic leaving the SFC-enabled domain the Egress Node belongs to. Such a node is required to remove any information specific to the SFC Domain, typically the SFC Encapsulation. An SFC Ingress Node denotes an SFC Boundary Node that handles traffic entering the SFC-enabled domain. In most solutions and deployments this will need to include a classifier, and will be responsible for adding the SFC encapsulation to the packet. SB> Logically doesn't it always include the classifier, where the set of SB> classifier types includes the null classifier? The only exception SB> I suppose is when you are receiving traffic from a trusted SB> SFC aware peer, but it might be better to be more explicit SB> about the normal case and then introduce the exception 4.5. Network Overlay and Network Components Underneath the SFF there are components responsible for performing the transport (overlay) forwarding. They do not consult the SFC encapsulation or inner payload for performing this forwarding. They only consult the outer-transport encapsulation for the transport (overlay) forwarding. SB> This layer model needs to be brought out much earlier instead of SB> having the reader deduce it up to this point. SB> Indeed the layering model makes for a better way of explaining SB> the operation of the system. 4.6. SFC Proxy In order for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions) a logical SFC proxy function may be used. SB> Is it a logical proxy or a real proxy, and why only may, surely SB> it *is* used. Halpern & Pignataro Expires March 24, 2015 [Page 14] Internet-Draft SFC Architecture September 2014 This function sits between an SFF and one or more SFs to which the SFF is directing traffic. The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path. Thus, from the point of view of the SFF, the SFC proxy appears to be part of an SFC aware SF. Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC aware SF. The details of that are not part of this architecture. The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF are dependent upon the specific behaviors and capabilities of that SFC-unaware SF, and thus are also out of scope for this architecture. Specifically, for traffic received from the SFF intended for the SF the proxy is representing, the SFC proxy: o Removes the SFC encapsulation from SFC encapsulated packets. o Identifies the required SF to be applied based on available information including that carried in the SFC encapsulation. o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, GRE, VXLAN. o Forwards the original payload via the selected local attachment circuit to the appropriate SF. SB> I think you have missed the storage of the SFE and I am not SB> sure how this gets back to the specific packet. This causes me SB> wonder if it is the original payload or not since it may by SB> now be SFC modified. It is surely the SFE payload that gets SB> passed up, and to re-attach the correct SFE afterwards, might SB> you not have to modify it? When traffic is returned from the SF: o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to re-apply the correct SFC encapsulation. SB> This function is surely split between the outbound and inbound SB> proxy functions. Halpern & Pignataro Expires March 24, 2015 [Page 15] Internet-Draft SFC Architecture September 2014 o Delivers the packet with the SFC Encapsulation to the SFF, as would happen with packets returned from an SFC-aware SF. Alternatively, a service provider may decide to exclude legacy service functions from an SFC domain. SB> This might have been better expressed earlier in the text my noting SB> that the proxy was optional, making the afterthought above redundant. 4.7. Classification Traffic from the network that satisfies classification criteria is directed into an SFP and forwarded to the requisite service function(s). Classification is handled by a service classification function; initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier and the requirements of the SFC policy. For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A, or quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B. As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created. Classification results in attaching the traffic to a specific SFP. SB> How about: SFC domain ingress traffic is first processed by a classifier which either rejects the traffic or prepares it for processing by the required SFs. The classifier applies policy to the packet to determine the required SFC, and then to map that to the required SFP. The classifier applies the corresponding SFE and if necessary the appropriate network layer encapsulation and forwards the packet to the first SFF on the chain. 4.8. Re-Classification and Branching The SFC architecture supports re-classification (or non-initial classification) as well. SB> This is interesting, surely the packet only enters the SB> SFC when it has been been classified (including the null classification) SB> and has the SFE applied? As packets traverse an SFP, re- classification may occur - typically performed by a classification function co-resident with a service function. SB> Architecturally you may always want to include a reclassifier SB> on exit (and may be entry) to every SF. It may be null, but it's SB> probably better that it is there. Reclassification may result in the selection of a new SFP, an update of the associated metadata, or both. This is referred to as "branching". For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. However, when the DPI service function is executed, attack traffic is detected at the application layer. DPI_1 re-classifies the traffic as attack and alters the service path to SFP B, to include a firewall for policy enforcement: dropping the traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would be returned to the original SFF. In this simple example, the DPI service function re-classifies the traffic based on local application layer classification capabilities (that were not available during the initial classification step). When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform re-classification of traffic to determine the SFP. The SFC Proxy is concerned with re-attaching information SB> This should have been part of the earlier proxy functional definition. SB> Maybe if you moved this up earlier before proxy it would all be clearer. Halpern & Pignataro Expires March 24, 2015 [Page 16] Internet-Draft SFC Architecture September 2014 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such classification to a flow lookup. 4.9. Shared Metadata SB> Isn't metadata always shared? If no one else sees it, there is SB> no point in generating it. Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange and the sharing of service-derived information to the network. Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture: o Allows elements that typically operate as ships in the night to exchange information. SB> That is a sort of tautology. If they share MD they are not true SB> SITN. Surely this is about in band and outband state sharing. o Encodes information about the network and/or data for post- service forwarding. o Creates an identifier used for policy binding by SFs. Context information can be derived in several ways: SB> This list does not scan properly from the intro fragment above. o External sources o Network node classification o Service function classification 5. Additional Architectural Concepts There are a number of issues which solutions need to address, and which the architecture informs but does not determine. This section lays out some of those concepts. 5.1. The Role of Policy Much of the behavior of service chains is driven by operator and per- customer policy. This architecture is structured to isolate the policy interactions from the data plane and control logic. Specifically, it is assumed that the service chaining control plane creates the service paths. The service chaining data plane is used to deliver the classified packets along the service chains to the intended service functions. Policy, in contrast, interacts with the system in other places. Policies and policy engines may monitor service functions to decide if additional (or fewer) instances of services are needed. SB> This seems to be conflating policy and resource management, and SB> I am not sure this is wise. The resource manager should consult SB> policy, but the problems are distinct. When Halpern & Pignataro Expires March 24, 2015 [Page 17] Internet-Draft SFC Architecture September 2014 applicable, those decisions may in turn result in interactions that direct the control logic to change the SFP placement or packet classification rules. Similarly, operator service policy, often managed by operational or business support systems (OSS or BSS), will frequently determine what service functions are available. Operator service policies also determine which sequences of functions are valid and are to be used or made available. The offering of service chains to customers, and the selection of which service chain a customer wishes to use, are driven by a combination of operator and customer policies using appropriate portals in conjunction with the OSS and BSS tools. These selections then drive the service chaining control logic, which in turn establishes the appropriate packet classification rules. SB> Didn't you just say the above. In any case it might be better in SB> the form of an intro rather than a conclusion. 5.2. SFC Control Plane This is part of the overall architecture but outside the scope of this document. SB> The specifics of the architecture of the CP may be out of scope SB> but I cannot see how it can be out of scope of the main SB> architecture, unless you want to reclassify this as the SFC packet SB> plane architecture. SB> SB> As I read more of this text I am unclear why this in not promoted SB> to the main body of the text. The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay. For instance, an SFC construction may be static; selecting exactly which SFFs and which SFs from those SFFs are to be used, or it may be dynamic, allowing the network to perform some or all of the choices of SFF or SF to use to deliver the selected service chain within the constraints represented by the service path. In the SFC architecture, SFs are resources; SB> SFs or SF instances? I don't think it becomes an accountable SB> resource until it is instantiated. the control plane manages and communicates their capabilities, availability and location in fashions suitable for the transport and SFC operations in use. The control plane is also responsible for the creation of the context (see below). The control plane may be distributed (using new or existing control plane protocols), or be centralized, or a combination of the two. The SFC control plane provides the following functionality: 1. An SFC-enabled domain wide view of all available service function resources as well as the network locators through which they are reachable. 2. Uses SFC policy to construct service function chains, and associated service function paths. Halpern & Pignataro Expires March 24, 2015 [Page 18] Internet-Draft SFC Architecture September 2014 3. Selection of specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the time of delivering traffic to them). 4. Provides requisite SFC data plane information to the SFC architecture components, most notably the SFF. 5. Allocation of metadata associated with a given SFP and propagation of the metadata to relevant SFs and/or SFC encapsulation-proxies or their respective policy planes. SB> I am not sure what it means to allocate metadata. Do you mean SB> MD storage, or MD packet space? 5.3. Resource Control The SFC system may be responsible for managing all resources necessary for the SFC components to function. This includes network constraints used to plan and choose network path(s) between service function forwarders, network communication paths between service function forwarders and their attached service functions, characteristics of the nodes themselves such as memory, number of virtual interfaces, routes, and instantiation, configuration, and deletion of SFs. The SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system. While all of these aspects are part of the overall system, they are beyond the scope of this architecture. SB> The relationship between the RC/RM and the CP seems unclear. 5.4. Infinite Loop Detection and Avoidance This SFC architecture is predicated on topological independence from the underlying forwarding topology. Consequently, a service topology is created by Service Function Paths or by the local decisions of the Service Function Forwarders based on the constraints expressed in the SFP. SB> The concept of service topologies and overlays would be useful much earlier in the text. Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once. The Service Chaining solution needs to permit these limited and policy-compliant loops. At the same time, the solutions must ensure that indefinite and unbounded loops cannot be formed, as such would consume unbounded resources without delivering any value. In other words, this architecture prevents infinite Service Function Loops, even when Service Functions may be invoked multiple times in the same SFP. SB> You say it does, but I don't see how it does it. Do you anticipate SB> it happening in the CP or the DP or both? SB> Halpern & Pignataro Expires March 24, 2015 [Page 19] Internet-Draft SFC Architecture September 2014 5.5. Load Balancing Considerations Supporting function elasticity and high-availability should not overly complicate SFC or lead to unnecessary scalability problems. In the simplest case, where there is only a single function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. SB> It is unusual to lead with the dejenerate case (i.e. no SFC) In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SFP exists (the metadata changes but the SFP does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4. +---+ +---++--->web server source+-->|sff|+-->|sf1|+--->web server +---+ +---++--->web server Figure 4: Simple Load Balancing By extrapolation, in the case where intermediary functions within a chain had similar "elastic" behaviors, we do not need separate chains to account for this behavior - as long as the traffic coalesces to a common next-hop after the point of elasticity. In Figure 5, we have a chain of five service functions between the traffic source and its destination. +---+ +---+ +---+ +---+ +---+ +---+ |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | +-----+-----+ +-----+-----+ | | + + +---+ +---+ +---+ +---+ +---+ source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination +---+ +---+ +---+ +---+ +---+ + + + | | | +---+ +---+ +---+ |sf1| |sf3| |sf5| +---+ +---+ +---+ Figure 5: Load Balancing Halpern & Pignataro Expires March 24, 2015 [Page 20] Internet-Draft SFC Architecture September 2014 This would be represented as one service function path: sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be made up of one or multiple components. In this architecture, the SFF may handle load distribution based on policy. It can also be seen in the above that the same service function may be reachable through multiple SFFs, as discussed earlier. The selection of which SFF to use to reach SF3 may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints. In the latter case, it needs to be assured that exactly one SFF takes responsibility to steer traffic through SF3. SB> Shouldn't the architecture lead with the general case and note SB> that any function can be replaced with the null function. 5.6. MTU and Fragmentation Considerations This architecture prescribes additional information being added to packets to identify service function paths and often to represent metadata. It also envisions adding transport information to carry packets along service function paths, at least between service function forwarders. This added information increases the size of the packet to be carried by service chaining. Such additions could potentially increase the packet size beyond the MTU supported on some or all of the media used in the service chaining domain. Such packet size increases can thus cause operational MTU problems. Requiring fragmentation and reassembly in an SFF would be a major processing increase, and might be impossible with some transports. SB> Sure but the SFE is teh network layer of the SFC plane and could SB> do this. Expecting service functions to deal with packets fragmented by the SFC function might be onerous even when such fragmentation was possible. Thus, at the very least, solutions need to pay attention to the size cost of their approach. There may be alternative or additional means available, although any solution needs to consider the tradeoffs. These considerations apply to any generic architecture that increases the header size. There are also more specific MTU considerations: Effects on Path MTU Discovery (PMTUD) as well as deployment considerations. Deployments within a single administrative control or even a single Data Center complex can afford more flexibility in dealing with larger packets, and deploying existing mitigations that decrease the likelihood of fragmentation or discard. 5.7. SFC OAM Operations, Administration, and Maintenance (OAM) tools are an integral part of the architecture. These serve various purposes, including fault detection and isolation, and performance management. For example, there are many advantages of SFP liveness detection, Halpern & Pignataro Expires March 24, 2015 [Page 21] Internet-Draft SFC Architecture September 2014 including status reporting, support for resiliency operations and policies, and an enhanced ability to balance load. Service Function Paths create a services topology, and OAM performs various functions within this service layer. Furthermore, SFC OAM follows the same architectural principles of SFC in general. For example, topological independence (including the ability to run OAM over various overlay technologies) and classification-based policy. We can subdivide the SFC OAM architecture in two parts: o In-band: OAM packets follow the same path and share fate with user packets, within the service topology. For this, they also follow the architectural principle of consistent policy identifiers, and use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are particularly important here. o Out-of-band: reporting beyond the actual data plane. An additional layer beyond the data-plane OAM allows for additional alerting and measurements. This architecture prescribes end-to-end SFP OAM functions, which implies SFF understanding of whether an in-band packet is an OAM or user packet. However, service function validation is outside of the scope of this architecture, and application-level OAM is not what this architecture prescribes. Some of the detailed functions performed by SFC OAM include fault detection and isolation in a Service Function Path or a Service Function, verification that connectivity using SFPs is both effective and directing packets to the intended service functions, service path tracing, diagnostic and fault isolation, alarm reporting, performance measurement, locking and testing of service functions, validation with the control plane (see Section 5.2), and also allow for vendor- specific as well as experimental functions. SFC should leverage, and if needed extend relevant existing OAM mechanisms. 5.8. Resilience and Redundancy As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These may be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state, as for example stateful-firewall state, is the responsibility of the SF, and not addressed by this architecture. Halpern & Pignataro Expires March 24, 2015 [Page 22] Internet-Draft SFC Architecture September 2014 Multiple techniques are available to address this issue. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this. Solutions can also make use of MAC or IP level redundancy mechanisms such as VRRP. Also, particularly for SF failures, load balancers co-located with the SFF or as part of the service function delivery mechanism can provide such robustness. Similarly, operational requirements imply resilience in the face of load changes. While mechanisms for managing (e.g., monitoring, instantiating, loading images, providing configuration to service function chaining control, deleting, etc.) virtual machines are out of scope for this architecture, solutions can and are aided by describing how they can make use of scaling mechanisms. SB> Given that we are introducing a new network layer construct including SB> something that is or is a very close cousin to a network layer, surely SB> we are missing an opportunity by not including this on day one. 6. Security Considerations This document does not define a new protocol and therefore creates no new security issues. Security considerations apply to the realization of this architecture. Such realization ought to provide means to protect the SFC-enabled domain and its borders against various forms of attacks, including DDoS attacks. Further, SFC OAM Functions need to not negatively affect the security considerations of an SFC-enabled domain. Additionally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed, poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network. SB> I just don't buy this for a security analysis. The Architecture needs SB> direct the compenent designers to look at security issues associated SB> with the new components and functionality being introduced. SB> For example the SFE will have special considerations, so will the SB> the path changes that you talk about earlier. Then there is resource SB> conflicts and their impact as a security problem. Then there is the SB> issue of privacy. Really each component of the ach needs to be looked SB> at from a security PoV and guidance provided to the component designer. - Stewart --------------090705070101090606030805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
SB> This document lacks the precision and that I would have hoped for 
SB> in an architecture. I understand that the this was deliberate 
SB> in order to allow implementation flexibility, but I don't 
SB> buy that.
SB>
SB> What we have here is a type of layered network, and whilst 
SB> verbal discussions have refuted that, you have many references
SB> to overlay topologies.
SB>
SB> This would be better understood if you described it as a layered
SB> system, if you only used generalized the components with fully
SB> functionality, and then explained which could be NULL. In the 
SB> case of sub-functional components they should not be part of the 
SB> core architecture, but the techniques used to create a full function
SB> component by assistance (the proxy) described outside the main
SB> architecture.
SB>
SB> I understand that in part the approach used here was to allow
SB> a mixture of implementation styles - the concept of explicit
SB> and implicit SFE - with network layer constructs supplying the 
SB> implicit SFE. However it would be better to think of the use
SB> of implicit SFE as a type of network recursion in which the 
SB> the encapsulator (which I think is distinct from the classifier)
SB> chooses how to encode the SFP on the packet.
SB>
SB> I have a nagging concern about the way that the terms packets is
SB> used in this text. The way it is used one would expect that there
SB> is a one for one mapping between input and output packets, but that
SB> is surely not the case. A trivial point is the case where an SF
SB> needs to defragment. Although at the physical layer the units are
SB> packets, there may surely be higher order constructs traveling
SB> between SFs. 


 Service Function Chaining (SFC) Architecture
                     draft-ietf-sfc-architecture-02

Abstract

   This document describes an architecture for the specification,
sb> an arch or THE arch?
   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.  This document does not propose solutions,
   protocols, or extensions to existing protocols.



1.  Introduction

   This document describes an architecture used for the creation and
sb> and or THE
   ongoing maintenance of Service Function Chains (SFC) in a network.
   It includes architectural concepts, principles, and components.

   An overview of the issues associated with the deployment of end-to-
   end service function chains, abstract sets of service functions and
   their ordering constraints that create a composite service and the
   subsequent "steering" of traffic flows through said service
   functions, is described in [I-D.ietf-sfc-problem-statement].

   This architecture presents a model addressing the problematic aspects
   of existing service deployments, including topological independence
   and configuration complexity.

   Service function chains enable composite services that are
   constructed from one or more service functions.

1.1.  Scope

   This document defines a framework to realize Service Function
   Chaining (SFC) with minimum requirements on the physical topology of
   the network.  The proposed solution relies on initial packet
   classification.  Packets initially classified for handling by a set
   of Service Functions (SFs) in the SFC-enabled domain are then
   forwarded to that set of SFs for processing.

SB> Are you allowed to reclassify, or do staged classification? 
SB> Yes you are - you say so later - but that is not implied
SB> by the above.

   This document does not make any assumption on the deployment context.
   The proposed framework covers both fixed and mobile networks.

SB> Given that you make no deployment context assumption, surely
SB> the followup mobile/fixed specific is not relevant.

   The architecture described herein is assumed to be applicable to a
   single network administrative domain.  While it is possible for the
   architectural principles and components to be applied to inter-domain
   SFCs, these are left for future study.

1.2.  Assumptions

   The following assumptions are made:

   o  Not all SFs can be characterized with a standard definition in
      terms of technical description, detailed specification,
      configuration, etc.

   o  There is no global or standard list of SFs enabled in a given
      administrative domain.  The set of SFs varies as a function of the
      service to be provided and according to the networking
      environment.

   o  There is no global or standard SF chaining logic.  The ordered set
      of SFs that needs to be enabled to deliver a given service is
      specific to each administrative entity.

SB> Surely it is application specific even within an admistration?

 o  The chaining of SFs and the criteria to invoke them are specific
      to each administrative entity that operates an SF-enabled domain.

SB? see previous


Halpern & Pignataro      Expires March 24, 2015                 [Page 3]

Internet-Draft              SFC Architecture              September 2014


   o  Several SF chaining policies can be simultaneously applied within
      an administrative domain to meet various business requirements.

   o  No assumption is made on how FIBs and RIBs of involved nodes are
      populated.

   o  How to bind traffic to a given SF chain is policy-based.

1.3.  Definition of Terms

   Network Service:  An offering provided by an operator that is
        delivered using one or more service functions.  This may also be
        referred to as a composite service.  The term "service" is used
        to denote a "network service" in the context of this document.

        Note: Beyond this document, the term "service" is overloaded
        with varying definitions.  For example, to some a service is an
        offering composed of several elements within the operator's
        network, whereas for others a service, or more specifically a
        network service, is a discrete element such as a firewall.
        Traditionally, such services (in the latter sense) host a set of
        service functions and have a network locator where the service
        is hosted.

SB> I think that you probably need an explicit definition of service.
SB> I find the text in the definition of NS self referential which is
SB> not helpful.


 Classification:  Locally instantiated policy and customer/network/
        service profile matching of traffic flows for identification of
        appropriate outbound forwarding actions.

SB> Isn't it really

SB> Locally instantiated matching of traffic flows against policy for
SB> subsequent application of the required set of network service functions. 
SB> The policy may be ustomer/network/service specific.




 Classifier:  An element that performs Classification.

SB> A network element perhaps?

 Service Function Chain (SFC):  A service function chain defines a set
        of abstract service functions and ordering constraints that must

SB> Isn't the SFC also ordered?

        be applied to packets and/or frames selected as a result of
        classification.  
SB> Packets, or higher order constructs like flows? You cannot
SB> do some of the SFs packet by packet

        The implied order may not be a linear
        progression as the architecture allows for SFCs that copy to
        more than one branch, and also allows for cases where there is
        flexibility in the order in which service functions need to be
        applied.  The term service chain is often used as shorthand for
        service function chain.

SB> See my earlier not about the apparently more restricted definition
SB> I think that you need to make the generalization clearer earlier.

 Service Function (SF):  A function that is responsible for specific
        treatment of received packets.  A Service Function can act at
        various layers of a protocol stack (e.g., at the network layer
        or other OSI layers).  As a logical component, a Service
        Function can be realized as a virtual element or be embedded in
        a physical network element.  One or multiple Service Functions
SB> multiple or more?
       can be embedded in the same network element.  Multiple




Halpern & Pignataro      Expires March 24, 2015                 [Page 4]

Internet-Draft              SFC Architecture              September 2014


        occurrences of the Service Function can exist in the same
        administrative domain.

        One or more Service Functions can be involved in the delivery of
        added-value services.  A non-exhaustive list of abstract Service
        Functions includes: firewalls, WAN and application acceleration,
        Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
        balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
        HOST_ID injection, HTTP Header Enrichment functions, TCP
        optimizer.

SB> Not sure those are abstract SFs, surely they are explicit?

        An SF may be SFC encapsulation aware, that is it receives and
        acts on information in the SFC encapsulation, or unaware, in
        which case data forwarded to the SF does not contain the SFC
        encapsulation.

   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as handling traffic
        coming back from the SF.  Additionally, a service function
        forwarder is responsible for delivering traffic to a classifier
        when needed and supported, mapping out traffic to another SFF
        (in the same or different type of overlay), and terminating the
        SFP.


SB> In these days of NFV it may not be received from the network.
SB> Surely the traffic is native until it gets to a classifier. The
SB> way you have it here it looks like the first element is the SFF
SB> but I am not sure that is the case.
SB> Perhaps: A service function forwarder is responsible for forwarding
SB> traffic between service functions. 

 Metadata:  provides the ability to exchange context information
        between classifiers and SFs and among SFs.

SB> I think the first noun is missing in the above, but in any case
SB> I think a more complete definition is needed.

 Service Function Path (SFP):  The SFP provides a level of indirection
        between the fully abstract notion of service chain as a sequence
        of abstract service functions to be delivered, and the fully
        specified notion of exactly which SFF/SFs the packet will visit
        when it actually traverses the network.  By allowing the control
        components to specify this level of indirection, the operator
        may control the degree of SFF/SF selection authority that is
        delegated to the network.

SB> You have not defined control components.
SB> I think "notion" is a redundant term.
SB> I am somewhat confused by your definition.
SB> Is this really about the mapping of packets between an arbitrary
SB> member of an SF to a specific instance of the SF?

 SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
        identification, and is used by the SFC-aware functions, such as
        the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
        for network packet forwarding.  In addition to SFP
        identification, the SFC encapsulation carries data plane context
        information, also referred to as metadata.

SB> Surely the "SFC E is used to attach the information needed to
SB> direct the packet through the ordered set of SFs, together with
SB> associated metadata. An additional  network layer encapsulation is needed
SB> to carry the packet over the physical network.


 Rendered Service Path (RSP):  The Service Function Path is a
        constrained specification of where packets using a certain
        service chain must go.  While it may be so constrained as to



Halpern & Pignataro      Expires March 24, 2015                 [Page 5]

Internet-Draft              SFC Architecture              September 2014


        identify the exact locations, it can also be less specific.
        Packets themselves are of course transmitted from and to
        specific places in the network, visiting a specific sequence of
        SFFs and SFs.  This sequence of actual visits by a packet to
        specific SFFs and SFs in the network is known as the Rendered
        Service Path (RSP).  This definition is included here for use by
        later documents, such as when solutions may need to discuss the
        actual sequence of locations the packets visit.


SB> Not sure of the wisdom of including a definition for the future, since
SB> when you use it you may need to tune the definition.

 SFC-enabled Domain:  A network or region of a network that implements
        SFC.  An SFC-enabled Domain is limited to a single network
        administrative domain.

   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
        SFC-unaware service function.  SFC proxies are logical elements.

SB> Not sure considering then as logical is quite right. It depends
SB> on the mapping of the operation to the physical. I could see
SB> cases where they are physical. Surely the point is that they
SB> may be co-located with another network function such as a router
SB> an operating system component such as a hypervisor.


 2.  Architectural Concepts

   The following sections describe the foundational concepts of service
   function chaining and the SFC architecture.

   Service Function Chaining enables the creation of composite (network)
   services that consist of an ordered set of Service Functions (SF)
   that must be applied to packets and/or frames selected as a result of
   classification.  Each SF is referenced using an identifier that is
   unique within an SF-enabled domain.  No IANA registry is required to
   store the identity of SFs.


SB> I am still worried about using packets. Obviously we operate on
SB> pkts, but the operation may require the reconstuction of some
SB> packet grouping typically some element of a flow before the operation
SB> can be performed. A trivial example is defragmenting a packet group
SB> but since we are dealing with abstract SFs we cannot specify the 
SB> the unit of operation.

    Service Function Chaining is a concept that provides for more than
   just the application of an ordered set of SFs to selected traffic;
   rather, it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities.

SB> The above is a bit late in the text. I think it needs to go earlier.

 2.1.  Service Function Chains

   In most networks, services are constructed as abstract sequences of
SB> I don't think that are abstract in this context.
SB> Are you talking about traditional (current physically instantiated
SB> SFCs in the previous sentence?

   SFs that represent SFCs.  At a high level, an SFC is an abstracted
   view of a service that specifies the set of required SFs as well as
   the order in which they must be executed.  

SB> Again I am not sure "abstrated view" is right here

   Graphs, as illustrated in
   Figure 1, define an SFC, where each graph node represents the
   required existence of at least one abstract SF.  Such graph nodes
   (SFs) can be part of zero, one, or many SFCs.  A given graph node
   (SF) can appear one time or multiple times in a given SFC.

SB> Not sure that graphs is right, since you only show the case
SB> of a linear chain. The construct you are going to use is
SB> graph, but that is not what the figure shows.

   SFCs can start from the origination point of the service function
   graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
   graph.  

SB> OK so are you trying to distinguish between physically and
SB> SFC (the new technology) instantiated SFCS?

   SFs may therefore become branching nodes in the graph, with



Halpern & Pignataro      Expires March 24, 2015                 [Page 6]

Internet-Draft              SFC Architecture              September 2014


   those SFs selecting edges that move traffic to one or more branches.
   An SFC can have more than one terminus.


SB> Again that is not what your figure shows.

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   6   )+---->(   8   )
    \     /       \     /        \     /        \     /
     `---'         `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   3   )+---->(   7   )+---->(   9   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   7   )+---->(   8   )+---->(   4   )+---->(   7   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

                  Figure 1: Service Function Chain Graphs

2.2.  Service Function Chain Symmetry

   SFCs may be unidirectional or bidirectional.  A unidirectional SFC
   requires that traffic be forwarded through the ordered SFs in one
   direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a
   symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in
   which the SF instances are the same in opposite directions.  A hybrid
   SFC has attributes of both unidirectional and bidirectional SFCs;
   that is to say some SFs require symmetric traffic, whereas other SFs
   do not process reverse traffic or are independent of the
   corresponding forward traffic.

   SFCs may contain cycles; that is traffic may need to traverse one or
   more SFs within an SFC more than once.  Solutions will need to ensure
   suitable disambiguation for such situations.

   The architectural allowance that is made for SFPs that delegate
   choice to the network for which SFs and/or SFFs a packet will visit
   creates potential issues here.  A solution that allows such
   delegation needs to also describe how the solution ensures that those
   service chains that require service function chain symmetry can
   achieve that.

   Further, there are state tradeoffs in symmetry.  Symmetry may be
   realized in several ways depending on the SFF and classifier



Halpern & Pignataro      Expires March 24, 2015                 [Page 7]

Internet-Draft              SFC Architecture              September 2014


   functionality.  In some cases, "mirrored" classification (i.e., from
   Source to Destination and from Destination to Source) policy may be
   deployed, whereas in others shared state between classifiers may be
   used to ensure that symmetric flows are correctly identified, then
   steered along the required SFP.  At a high level, there are various
   common cases.  In a non-exhaustive way, there can be for example: a
   single classifier (or a small number of classifiers), in which case
   both incoming and outgoing flows could be recognized at the same
   classifier, so the synchronization would be feasible by internal
   mechanisms internal to the classifier.  Another case is the one of
   stateful classifiers where several classifiers may be clustered and
   share state.  Lastly, another case entails fully distributed
   classifiers, where synchronization needs to be provided through
   unspecified means.  This is a non-comprehensive list of common cases.

SB> Isn't an important class of classifiers one that learns state from the 
SB> egress packets/flows that is then used to provide state for the 
SB> return packets/flow

 2.3.  Service Function Paths

   A service function path (SFP) is a mechanism used by service chaining
   to express the result of applying more granular policy and
SB> Not sure "more granular" is needed.

   operational constraints to the abstract requirements of a service
SB> Not sure they are abstract requirements. When you apply them they
SB> are explicit.

   chain (SFC).  This architecture does not mandate the degree of
   specificity of the SFP.  Architecturally, within the same SFC-enabled
   domain, some SFPs may be fully specified, selecting exactly which SFF
   and which SF are to be visited by packets using that SFP, while other
   SFPs may be quite vague, deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC.  The
   specificity may be anywhere in between these extremes.

   As an example of such an intermediate specificity, there may be two
   SFPs associated with a given SFC, where one SFP says essentially that

SB> "says essentially is not a tight definition"

   any order of SFF and SF may be used as long as it is within data
   center 1, and where the second SFP allows the same latitude, but only
   within data center 2.

   Thus, the policies and logic of SFP selection or creation (depending
   upon the solution) produce what may be thought of as a constrained
   version of the original SFC.  Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs may be associated with a single SFC.

SB> So a SFP is a specific instance of a member of the set of available SFCs
SB> chosen as a result of applying policy at one or points along the SFC?


   The architecture allows for the same SF to be reachable through
   multiple SFFs.  In these cases, some SFPs may constrain which SFF is
   used to reach which SF, while some SFPs may leave that decision to
   the SFF itself.

   Further, the architecture allows for two or more SFs to be attached
   to the same SFF, and possibly connected via internal means allowing
   more effective communication.  In these cases, some solutions or


Halpern & Pignataro      Expires March 24, 2015                 [Page 8]

Internet-Draft              SFC Architecture              September 2014


   deployments may choose to use some form of internal inter-process or
   inter-VM messaging (communication behind the virtual switching
   element) that is optimized for such an environment.  This must be
   coordinated with the SFF so that the service function forwarding can
   properly perform its job.  Implementation details of such mechanisms
   are considered out of scope for this document, and can include a
   spectrum of methods: for example situations including all next-hops
   explicitly, others where a list of possible next-hops is provided and
   the selection is local, or cases with just an identifier, where all
   resolution is local.

   This architecture also allows the same SF to be part of multiple
   SFPs.

SB> Didn't you just say that?

 3.  Architecture Principles

   Service function chaining is predicated on several key architectural
   principles:

   1.  Topological independence: no changes to the underlay network
       forwarding topology - implicit, or explicit - are needed to
       deploy and invoke SFs or SFCs.

   2.  Plane separation: dynamic realization of SFPs is separated from
       packet handling operations (e.g., packet forwarding).

   3.  Classification: traffic that satisfies classification rules is
       forwarded according to a specific SFP.  For example,
       classification can be as simple as an explicit forwarding entry
       that forwards all traffic from one address into the SFP.
       Multiple classification points are possible within an SFC (i.e.
       forming a service graph) thus enabling changes/updates to the SFC
       by SFs.

       Classification can occur at varying degrees of granularity; for
       example, classification can use a 5-tuple, a transport port or
       set of ports, part of the packet payload, or it can come from
       external systems.

SB> I think that it can surely be as a result of higher level inspections?

 4.  Shared Metadata: Metadata/context data can be shared amongst SFs
       and classifiers, between SFs, and between external systems and
       SFs (e.g., orchestration).

       Generally speaking, metadata can be thought of as providing and
       sharing the result of classification 

SB> Just classifications, or classifications and processing operations?
SB> There is gray zone between a packet forwarding system and
SB> a distributed computing system and I am not sure where SFC fits, 
SB> nor am I sure that it makes sense to be specific at this stage.
SB> It is entirely possible that an SFC consumes the packet/flow
SB> rather than only having the capability to forward it between 
SB> in ingress and egress.

      (that occurs within the SFC-
       enabled domain, or external to it) along an SFP.  For example, an
       external repository might provide user/subscriber information to
       a service chain classifier.  This classifier could in turn impose



Halpern & Pignataro      Expires March 24, 2015                 [Page 9]

Internet-Draft              SFC Architecture              September 2014


       that information in the SFC encapsulation for delivery to the
       requisite SFs.  The SFs could in turn utilize the user/subscriber
       information for local policy decisions.

   5.  Service definition independence: The SFC architecture does not
       depend on the details of SFs themselves.  Additionally, no IANA
       registry is required to store the list of SFs.

SB> Yes, but you should be careful not to preclude it.

  6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

SB> Yes and no. What about the resource implications?

 7.  Heterogeneous control/policy points: The architecture allows SFs
       to use independent mechanisms (out of scope for this document) to
       populate and resolve local policy and (if needed) local
       classification criteria.

4.  Core SFC Architecture Components

   At a very high level, the logical architecture of an SFC-enabled
   Domain comprises:

SB> A list would be handy rather than just a figure, and you need
SB> some text to expand on the figure.

      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .  +--------------+                  +------------------~~~
      .  |   Service    |       SFC        |  Service  +---+   +---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +---+   +---+
      .  +--------------+                  +------------------~~~
      . SFC-enabled Domain
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

               Figure 2: Service Function Chain Architecture


SB> This is a very confusing diagram
SB> Surely the SFC encap is attached to the packet
SB> The fig seems to confuse the the packets and the path.

   The following sub-sections provide details on each logical component
   that form the basis of the SFC architecture.  A detailed overview of
   how each of these architectural components interact is provided in
   Figure 3:


SB> Well maybe, but it's not quite obvious what you are showing. 
SB> some overview text would help before you get into the detail.











Halpern & Pignataro      Expires March 24, 2015                [Page 10]

Internet-Draft              SFC Architecture              September 2014


         +----------------+                        +----------------+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------+
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

         Figure 3: Service Function Chain Architecture Components


SB> Coming back here after reading a bit more. Is the SFF to be considered the
SB> hub in a hub and spoke processing model for a set of SFs? If so it would
SB> be useful to say that up front. However that raises the issue of whether
SB> the single network attachment point that you show is desirable. A standard
SB> firewall design would not mix dirty and clean traffic, and yet that is
SB> what the above appears to show.


 4.1.  SFC Encapsulation

   The SFC encapsulation enables service function path selection.  It
   also enables the sharing of metadata/context information when such
   metadata exchange is required.

SB> I don't think that is quite right. Surely the 
SB> SFC encapsulation enables <some component> to select the next
SB> element of the path?
 
   The SFC encapsulation provides explicit information used to identify
SB> Provides or carries?
   the SFP.  However, the SFC encapsulation is not a transport
   encapsulation itself: it is not used to forward packets within the
   network fabric.  
SB> ... but surely it is a shim layer of some sort?

   If packets need to flow between separate physical
   platforms, the SFC encapsulation therefore relies on an outer network
   transport.  
SB> Surely it is network layer header specific to the inter SFC
SB> transport?

   Transit forwarders -- such as router and switches --
   simply forward SFC encapsulated packets based on the outer (non-SFC)
   encapsulation.

SB> d/simply/



Halpern & Pignataro      Expires March 24, 2015                [Page 11]

Internet-Draft              SFC Architecture              September 2014


   One of the key architecture principles of SFC is that the SFC
   encapsulation remain transport independent.  As such any network
   transport protocol may be used to carry the SFC encapsulated traffic.

SB> Not sure I like "network transport protocol" since this is going
SB> to be confused with transport layer and I am not sure whether
SB> you would require a transport layer, indeed the SFE might will
SB> be considered a transport layer in the classical sense.

 4.2.  Service Function (SF)

   The concept of an SF evolves; rather than being viewed as a bump in
   the wire, an SF becomes a resource within a specified administrative
   domain that is available for consumption as part of a composite
   service.  SFs send/receive data to/from one or more SFFs.  SFC-aware
   SFs receive this traffic with the SFC encapsulation.

SB> I do not understand the above para.

   While the SFC architecture defines a new encapsulation - the SFC
   encapsulation - 

SB> no it does not - it is not defined in this memo. You introduce
SB> the concept and define some of the characteristics of it.


   and several logical components for the construction
   of SFCs, existing SF implementations may not have the capabilities to
   act upon or fully integrate with the new SFC encapsulation.  In order
   to provide a mechanism for such SFs to participate in the
   architecture, an SFC proxy function is defined (see Section 4.6).
   The SFC proxy acts as a gateway between the SFC encapsulation and
   SFC-unaware SFs.  The integration of SFC-unaware service functions is
   discussed in more detail in the SFC proxy section.

SB> The above is confusing. Do they participate in the architecture (this
SB> text)? I think that you mean that in order to employ SF instances
SB> that do not understand the SFE, a proxy as a gateway between the 
SB> the SFE aware domain and the non-SFE aware domain. Now if it is
SB> a gateway why is it not called a gateway rather than a proxy which
SB> is something that does something on behalf of something else.
SB> I would think that it might be a SFE proxy, but that is not quite
SB> right either.


 This architecture allows an SF to be part of multiple SFPs and SFCs.

SB> I am sure you said that before.

 4.3.  Service Function Forwarder (SFF)

   The SFF is responsible for forwarding packets and/or frames received
   from the network to one or more SFs associated with a given SFF using
   information conveyed in the SFC encapsulation.  Traffic from SFs
   eventually returns to the same SFF, which is responsible for
   injecting traffic back onto the network.

SB> It is not clear why it needs to be the exact same SFF

   The collection of SFFs and associated SFs creates a service plane
   overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
   Within this service plane, the SFF component connects different SFs
   that form a service function path.

SB> This conceptual model seems quite fundamental and this I 
SB> am surprised that it is not much earlier in the document.
SB> I have been wondering why the SFC system was not considered
SB> an overlay network of some sort, and was told by the authors
SB> that this was not possible. The above seems at odds with that
Sb> statement.

   SFFs maintain the requisite SFP forwarding information.  
SB> Maintain - as in being the control plane for this, or
SB> maintain as in store?
   SFP
   forwarding information is associated with a service path identifier
   that is used to uniquely identify an SFP.  The service forwarding
   state enables an SFF to identify which SFs of a given SFP should be
   applied, and in what order, as traffic flows through the associated
   SFP.  While there may appear to the SFF to be only one available way
   to deliver the given SF, there may also be multiple choices allowed
   by the constraints of the SFP.

   If there are multiple choices, the SFF needs to preserve the property
   that all packets of a given flow are handled the same way, since the



Halpern & Pignataro      Expires March 24, 2015                [Page 12]

Internet-Draft              SFC Architecture              September 2014


   SF may well be stateful.  Additionally, the SFF may preserve the
   handling of packets based on other properties on top of a flow, such
   as a subscriber, session, or application instance identification.

SB> I feel that the issue of handing higher order objects needs to have
SB> been introduced much earlier in the architecture.

   The SFF also has the information to allow it to forward packets to
   the next SFF after applying local service functions.  Again, while
   there may be only a single choice available, the architecture allows
   for multiple choices for the next SFF.  As with SFs, the solution
   needs to operate such that the behavior with regard to specific flows
   (see the Rendered Service Path) is stable.  The selection of
   available SFs and next SFFs may be interwoven when an SFF supports
   multiple distinct service functions and the same service function is
   available at multiple SFFs.  Solutions need to be clear about what is
   allowed in these cases.

   Even when the SFF supports and utilizes multiple choices, the
   decision as to whether to use flow-specific mechanisms or coarser
   grained means to ensure that the behavior of specific flows is stable
   is a matter for specific solutions and specific implementations.

   The SFF component has the following primary responsibilities:

   1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and if needed forwarded to
       another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path.  Related to this forwarding responsibility,
       an SFF should be able to interact with metadata.

   2.  Terminating SFPs : An SFC is completely executed when traffic has
       traversed all required SFs in a chain.  When traffic arrives at
       the SFF after the last SF has finished processing it, the final
       SFF knows from the service forwarding state that the SFC is
       complete.  The SFF removes the SFC encapsulation and delivers the
       packet back to the network for forwarding.

   3.  Maintaining flow state: In some cases, the SFF may be stateful.
       It creates flows and stores flow-centric information.  This state
       information may be used for a range of SFP-related tasks such as
       ensuring consistent treatment of all packets in a given flow,
       ensuring symmetry or for state-aware SFC Proxy functionality (see
       Section 4.8).





Halpern & Pignataro      Expires March 24, 2015                [Page 13]

Internet-Draft              SFC Architecture              September 2014


4.3.1.  Transport Derived SFF

   Service function forwarding, as described above, directly depends
   upon the use of the service path information contained in the SFC
   encapsulation.  However, existing implementations may not be able to
   act on the SFC encapsulation.  These platforms may opt to use
   existing transport information if it can be arranged to provide
   explicit service path information.

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

SB> The title does not seem quite right. What I think you have
SB> is a system in which you map an SFC onto an explicit path
SB> of some sort in the lower layers (I was going to say network layer
SB> but I am not sure if that is what you intend). So I am not sure 
SB> derived is the correct word. It would be closer to say "emulation
SB> of SFF using explicit network paths. Noting that these paths may
SB> be encoded in the packet or encoded in the FIB.

 4.4.  SFC-Enabled Domain

   Specific features may need to be enforced at the boundaries of an
   SFC-enabled domain, for example to avoid leaking SFC information.
   Using the term node to refer generically to an entity that is
   performing a set of functions, in this context, an SFC Boundary Node
   denotes a node that connects one SFC-enabled domain to a node either
   located in another SFC-enabled domain or in a domain that is SFC-
   unaware.

   An SFC Boundary node can act as egress or ingress.  
SB> do you mean or or and/or i.e. can it be both at the same time.
   An SFC Egress
   Node denotes a SFC Boundary Node that handles traffic leaving the
   SFC-enabled domain the Egress Node belongs to.  Such a node is
   required to remove any information specific to the SFC Domain,
   typically the SFC Encapsulation.  An SFC Ingress Node denotes an SFC
   Boundary Node that handles traffic entering the SFC-enabled domain.
   In most solutions and deployments this will need to include a
   classifier, and will be responsible for adding the SFC encapsulation
   to the packet.

SB> Logically doesn't it always include the classifier, where the set of
SB> classifier types includes the null classifier? The only exception
SB> I suppose is when you are receiving traffic from a trusted
SB> SFC aware peer, but it might be better to be more explicit
SB> about the normal case and then introduce the exception

 4.5.  Network Overlay and Network Components

   Underneath the SFF there are components responsible for performing
   the transport (overlay) forwarding.  They do not consult the SFC
   encapsulation or inner payload for performing this forwarding.  They
   only consult the outer-transport encapsulation for the transport
   (overlay) forwarding.

SB> This layer model needs to be brought out much earlier instead of 
SB> having the reader deduce it up to this point.
SB> Indeed the layering model makes for a better way of explaining
SB> the operation of the system.

 4.6.  SFC Proxy

   In order for the SFC architecture to support SFC-unaware SFs (e.g.,
   legacy service functions) a logical SFC proxy function may be used.

SB> Is it a logical proxy or a real proxy, and why only may, surely
SB> it *is* used.


Halpern & Pignataro      Expires March 24, 2015                [Page 14]

Internet-Draft              SFC Architecture              September 2014


   This function sits between an SFF and one or more SFs to which the
   SFF is directing traffic.

   The proxy accepts packets from the SFF on behalf of the SF.  It
   removes the SFC encapsulation, and then uses a local attachment
   circuit to deliver packets to SFC unaware SFs.  It also receives
   packets back from the SF, reapplies the SFC encapsulation, and
   returns them to the SFF for processing along the service function
   path.

   Thus, from the point of view of the SFF, the SFC proxy appears to be
   part of an SFC aware SF.

   Communication details between the SFF and the SFC Proxy are the same
   as those between the SFF and an SFC aware SF.  The details of that
   are not part of this architecture.  The details of the communication
   methods over the local attachment circuit between the SFC proxy and
   the SFC-unaware SF are dependent upon the specific behaviors and
   capabilities of that SFC-unaware SF, and thus are also out of scope
   for this architecture.

   Specifically, for traffic received from the SFF intended for the SF
   the proxy is representing, the SFC proxy:

   o  Removes the SFC encapsulation from SFC encapsulated packets.

   o  Identifies the required SF to be applied based on available
      information including that carried in the SFC encapsulation.

   o  Selects the appropriate outbound local attachment circuit through
      which the next SF for this SFP is reachable.  This is derived from
      the identification of the SF carried in the SFC encapsulation, and
      may include local techniques.  Examples of a local attachment
      circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3,
      GRE, VXLAN.

   o  Forwards the original payload via the selected local attachment
      circuit to the appropriate SF.

SB> I think you have missed the storage of the SFE and I am not
SB> sure how this gets back to the specific packet. This causes me
SB> wonder if it is the original payload or not since it may by
SB> now be SFC modified. It is surely the SFE payload that gets 
SB> passed up, and to re-attach the correct SFE afterwards, might
SB> you not have to modify it?


 When traffic is returned from the SF:

   o  Applies the required SFC encapsulation.  The determination of the
      encapsulation details may be inferred by the local attachment
      circuit through which the packet and/or frame was received, or via
      packet classification, or other local policy.  In some cases,
      packet ordering or modification by the SF may necessitate
      additional classification in order to re-apply the correct SFC
      encapsulation.

SB> This function is surely split between the outbound and inbound
SB> proxy functions.

 Halpern & Pignataro      Expires March 24, 2015                [Page 15]

Internet-Draft              SFC Architecture              September 2014


   o  Delivers the packet with the SFC Encapsulation to the SFF, as
      would happen with packets returned from an SFC-aware SF.

   Alternatively, a service provider may decide to exclude legacy
   service functions from an SFC domain.

SB> This might have been better expressed earlier in the text my noting
SB> that the proxy was optional, making the afterthought above redundant.


 4.7.  Classification

   Traffic from the network that satisfies classification criteria is
   directed into an SFP and forwarded to the requisite service
   function(s).  Classification is handled by a service classification
   function; initial classification occurs at the ingress to the SFC
   domain.  The granularity of the initial classification is determined
   by the capabilities of the classifier and the requirements of the SFC
   policy.  For instance, classification might be relatively coarse: all
   packets from this port are subject to SFC policy X and directed into
   SFP A, or quite granular: all packets matching this 5-tuple are
   subject to SFC policy Y and directed into SFP B.

   As a consequence of the classification decision, the appropriate SFC
   encapsulation is imposed on the data, and a suitable SFP is selected
   or created.  Classification results in attaching the traffic to a
   specific SFP.

SB> How about:

SFC domain ingress traffic is first processed by a classifier which
either rejects the traffic or prepares it for processing by the required
SFs. The classifier applies policy to the packet to determine the required
SFC, and then to map that to the required SFP. The classifier applies
the corresponding SFE and if necessary the appropriate network layer
encapsulation and forwards the packet to the first SFF on the chain.



 4.8.  Re-Classification and Branching

   The SFC architecture supports re-classification (or non-initial
   classification) as well.  

SB> This is interesting, surely the packet only enters the
SB> SFC when it has been been classified (including the null classification)
SB> and has the SFE applied?

   As packets traverse an SFP, re-
   classification may occur - typically performed by a classification
   function co-resident with a service function.  
SB> Architecturally you may always want to include a reclassifier
SB> on exit (and may be entry) to every SF. It may be null, but it's
SB> probably better that it is there.

   Reclassification may
   result in the selection of a new SFP, an update of the associated
   metadata, or both.  This is referred to as "branching".

   For example, an initial classification results in the selection of
   SFP A: DPI_1 --> SLB_8.  However, when the DPI service function is
   executed, attack traffic is detected at the application layer.  DPI_1
   re-classifies the traffic as attack and alters the service path to
   SFP B, to include a firewall for policy enforcement: dropping the
   traffic: DPI_1 --> FW_4.  Subsequent to FW_4, surviving traffic would
   be returned to the original SFF.  In this simple example, the DPI
   service function re-classifies the traffic based on local application
   layer classification capabilities (that were not available during the
   initial classification step).

   When traffic arrives after being steered through an SFC-unaware SF,
   the SFC Proxy must perform re-classification of traffic to determine
   the SFP.  The SFC Proxy is concerned with re-attaching information

SB> This should have been part of the earlier proxy functional definition.
SB> Maybe if you moved this up earlier before proxy it would all be clearer.


 Halpern & Pignataro      Expires March 24, 2015                [Page 16]

Internet-Draft              SFC Architecture              September 2014


   for SFC-unaware SFs, and a stateful SFC Proxy simplifies such
   classification to a flow lookup.

4.9.  Shared Metadata

SB> Isn't metadata always shared? If no one else sees it, there is
SB> no point in generating it.

   Sharing metadata allows the network to provide network-derived
   information to the SFs, SF-to-SF information exchange and the sharing
   of service-derived information to the network.  Some SFCs may not
   require metadata exchange.  SFC infrastructure enables the exchange
   of this shared data along the SFP.  The shared metadata serves
   several possible roles within the SFC architecture:

   o  Allows elements that typically operate as ships in the night to
      exchange information.

SB> That is a sort of tautology. If they share MD they are not true
SB> SITN. Surely this is about in band and outband state sharing.

   o  Encodes information about the network and/or data for post-
      service forwarding.

   o  Creates an identifier used for policy binding by SFs.

   Context information can be derived in several ways:

SB> This list does not scan properly from the intro fragment above.

   o  External sources

   o  Network node classification

   o  Service function classification



 5.  Additional Architectural Concepts

   There are a number of issues which solutions need to address, and
   which the architecture informs but does not determine.  This section
   lays out some of those concepts.

5.1.  The Role of Policy

   Much of the behavior of service chains is driven by operator and per-
   customer policy.  This architecture is structured to isolate the
   policy interactions from the data plane and control logic.

   Specifically, it is assumed that the service chaining control plane
   creates the service paths.  The service chaining data plane is used
   to deliver the classified packets along the service chains to the
   intended service functions.

   Policy, in contrast, interacts with the system in other places.
   Policies and policy engines may monitor service functions to decide
   if additional (or fewer) instances of services are needed.  

SB> This seems to be conflating policy and resource management, and
SB> I am not sure this is wise. The resource manager should consult
SB> policy, but the problems are distinct.

   When



Halpern & Pignataro      Expires March 24, 2015                [Page 17]

Internet-Draft              SFC Architecture              September 2014


   applicable, those decisions may in turn result in interactions that
   direct the control logic to change the SFP placement or packet
   classification rules.

   Similarly, operator service policy, often managed by operational or
   business support systems (OSS or BSS), will frequently determine what
   service functions are available.  Operator service policies also
   determine which sequences of functions are valid and are to be used
   or made available.

   The offering of service chains to customers, and the selection of
   which service chain a customer wishes to use, are driven by a
   combination of operator and customer policies using appropriate
   portals in conjunction with the OSS and BSS tools.  These selections
   then drive the service chaining control logic, which in turn
   establishes the appropriate packet classification rules.


SB> Didn't you just say the above. In any case it might be better in
SB> the form of an intro rather than a conclusion.

 5.2.  SFC Control Plane

   This is part of the overall architecture but outside the scope of
   this document.

SB> The specifics of the architecture of the CP may be out of scope
SB> but I cannot see how it can be out of scope of the main
SB> architecture, unless you want to reclassify this as the SFC packet
SB> plane architecture.
SB>
SB> As I read more of this text I am unclear why this in not promoted
SB> to the main body of the text.


    The SFC control plane is responsible for constructing SFPs,
   translating SFCs to forwarding paths and propagating path information
   to participating nodes to achieve requisite forwarding behavior to
   construct the service overlay.  For instance, an SFC construction may
   be static; selecting exactly which SFFs and which SFs from those SFFs
   are to be used, or it may be dynamic, allowing the network to perform
   some or all of the choices of SFF or SF to use to deliver the
   selected service chain within the constraints represented by the
   service path.

   In the SFC architecture, SFs are resources; 

SB> SFs or SF instances? I don't think it becomes an accountable 
SB> resource until it is instantiated.

   the control plane manages
   and communicates their capabilities, availability and location in
   fashions suitable for the transport and SFC operations in use.  The
   control plane is also responsible for the creation of the context
   (see below).  The control plane may be distributed (using new or
   existing control plane protocols), or be centralized, or a
   combination of the two.

   The SFC control plane provides the following functionality:

   1.  An SFC-enabled domain wide view of all available service function
       resources as well as the network locators through which they are
       reachable.

   2.  Uses SFC policy to construct service function chains, and
       associated service function paths.



Halpern & Pignataro      Expires March 24, 2015                [Page 18]

Internet-Draft              SFC Architecture              September 2014


   3.  Selection of specific SFs for a requested SFC, either statically
       (using specific SFs) or dynamically (using service explicit SFs
       at the time of delivering traffic to them).

   4.  Provides requisite SFC data plane information to the SFC
       architecture components, most notably the SFF.

   5.  Allocation of metadata associated with a given SFP and
       propagation of the metadata to relevant SFs and/or SFC
       encapsulation-proxies or their respective policy planes.

SB> I am not sure what it means to allocate metadata. Do you mean
SB> MD storage, or MD packet space?

 5.3.  Resource Control

   The SFC system may be responsible for managing all resources
   necessary for the SFC components to function.  This includes network
   constraints used to plan and choose network path(s) between service
   function forwarders, network communication paths between service
   function forwarders and their attached service functions,
   characteristics of the nodes themselves such as memory, number of
   virtual interfaces, routes, and instantiation, configuration, and
   deletion of SFs.

   The SFC system will also be required to reflect policy decisions
   about resource control, as expressed by other components in the
   system.

   While all of these aspects are part of the overall system, they are
   beyond the scope of this architecture.


SB> The relationship between the RC/RM and the CP seems unclear.

 5.4.  Infinite Loop Detection and Avoidance

   This SFC architecture is predicated on topological independence from
   the underlying forwarding topology.  Consequently, a service topology
   is created by Service Function Paths or by the local decisions of the
   Service Function Forwarders based on the constraints expressed in the
   SFP.  

SB> The concept of service topologies and overlays would be useful much earlier in the text.

   Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once.  The Service
   Chaining solution needs to permit these limited and policy-compliant
   loops.  At the same time, the solutions must ensure that indefinite
   and unbounded loops cannot be formed, as such would consume unbounded
   resources without delivering any value.

   In other words, this architecture prevents infinite Service Function
   Loops, even when Service Functions may be invoked multiple times in
   the same SFP.

SB> You say it does, but I don't see how it does it. Do you anticipate
SB> it happening in the CP or the DP or both?
SB> 



 Halpern & Pignataro      Expires March 24, 2015                [Page 19]

Internet-Draft              SFC Architecture              September 2014


5.5.  Load Balancing Considerations

   Supporting function elasticity and high-availability should not
   overly complicate SFC or lead to unnecessary scalability problems.

   In the simplest case, where there is only a single function in the
   SFP (the next hop is either the destination address of the flow or
   the appropriate next hop to that destination), one could argue that
   there may be no need for SFC.

SB> It is unusual to lead with the dejenerate case (i.e. no SFC)

   In the cases where the classifier is separate from the single
   function or a function at the terminal address may need sub-prefix or
   per-subscriber metadata, a single SFP exists (the metadata changes
   but the SFP does not), regardless of the number of potential terminal
   addresses for the flow.  This is the case of the simple load
   balancer.  See Figure 4.

                            +---+    +---++--->web server
                  source+-->|sff|+-->|sf1|+--->web server
                            +---+    +---++--->web server

                      Figure 4: Simple Load Balancing

   By extrapolation, in the case where intermediary functions within a
   chain had similar "elastic" behaviors, we do not need separate chains
   to account for this behavior - as long as the traffic coalesces to a
   common next-hop after the point of elasticity.

   In Figure 5, we have a chain of five service functions between the
   traffic source and its destination.

                +---+ +---+ +---+   +---+ +---+ +---+
                |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                +---+ +---+ +---+   +---+ +---+ +---+
                  |     |     |       |     |     |
                  +-----+-----+       +-----+-----+
                        |                   |
                        +                   +
             +---+    +---+     +---+     +---+    +---+
   source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
             +---+    +---+     +---+     +---+    +---+
               +                  +                  +
               |                  |                  |
             +---+              +---+              +---+
             |sf1|              |sf3|              |sf5|
             +---+              +---+              +---+

                         Figure 5: Load Balancing



Halpern & Pignataro      Expires March 24, 2015                [Page 20]

Internet-Draft              SFC Architecture              September 2014


   This would be represented as one service function path:
   sf1->sf2->sf3->sf4->sf5.  The SFF is a logical element, which may be
   made up of one or multiple components.  In this architecture, the SFF
   may handle load distribution based on policy.

   It can also be seen in the above that the same service function may
   be reachable through multiple SFFs, as discussed earlier.  The
   selection of which SFF to use to reach SF3 may be made by the control
   logic in defining the SFP, or may be left to the SFFs themselves,
   depending upon policy, solution, and deployment constraints.  In the
   latter case, it needs to be assured that exactly one SFF takes
   responsibility to steer traffic through SF3.


SB> Shouldn't the architecture lead with the general case and note
SB> that any function can be replaced with the null function.

 5.6.  MTU and Fragmentation Considerations

   This architecture prescribes additional information being added to
   packets to identify service function paths and often to represent
   metadata.  It also envisions adding transport information to carry
   packets along service function paths, at least between service
   function forwarders.  This added information increases the size of
   the packet to be carried by service chaining.  Such additions could
   potentially increase the packet size beyond the MTU supported on some
   or all of the media used in the service chaining domain.

   Such packet size increases can thus cause operational MTU problems.
   Requiring fragmentation and reassembly in an SFF would be a major
   processing increase, and might be impossible with some transports.

SB> Sure but the SFE is teh network layer of the SFC plane and could
SB> do this.

   Expecting service functions to deal with packets fragmented by the
   SFC function might be onerous even when such fragmentation was
   possible.  Thus, at the very least, solutions need to pay attention
   to the size cost of their approach.  There may be alternative or
   additional means available, although any solution needs to consider
   the tradeoffs.

   These considerations apply to any generic architecture that increases
   the header size.  There are also more specific MTU considerations:
   Effects on Path MTU Discovery (PMTUD) as well as deployment
   considerations.  Deployments within a single administrative control
   or even a single Data Center complex can afford more flexibility in
   dealing with larger packets, and deploying existing mitigations that
   decrease the likelihood of fragmentation or discard.

5.7.  SFC OAM

   Operations, Administration, and Maintenance (OAM) tools are an
   integral part of the architecture.  These serve various purposes,
   including fault detection and isolation, and performance management.
   For example, there are many advantages of SFP liveness detection,



Halpern & Pignataro      Expires March 24, 2015                [Page 21]

Internet-Draft              SFC Architecture              September 2014


   including status reporting, support for resiliency operations and
   policies, and an enhanced ability to balance load.

   Service Function Paths create a services topology, and OAM performs
   various functions within this service layer.  Furthermore, SFC OAM
   follows the same architectural principles of SFC in general.  For
   example, topological independence (including the ability to run OAM
   over various overlay technologies) and classification-based policy.

   We can subdivide the SFC OAM architecture in two parts:

   o  In-band: OAM packets follow the same path and share fate with user
      packets, within the service topology.  For this, they also follow
      the architectural principle of consistent policy identifiers, and
      use the same path IDs as the service chain data packets.  Load
      balancing and SFC encapsulation with packet forwarding are
      particularly important here.

   o  Out-of-band: reporting beyond the actual data plane.  An
      additional layer beyond the data-plane OAM allows for additional
      alerting and measurements.

   This architecture prescribes end-to-end SFP OAM functions, which
   implies SFF understanding of whether an in-band packet is an OAM or
   user packet.  However, service function validation is outside of the
   scope of this architecture, and application-level OAM is not what
   this architecture prescribes.

   Some of the detailed functions performed by SFC OAM include fault
   detection and isolation in a Service Function Path or a Service
   Function, verification that connectivity using SFPs is both effective
   and directing packets to the intended service functions, service path
   tracing, diagnostic and fault isolation, alarm reporting, performance
   measurement, locking and testing of service functions, validation
   with the control plane (see Section 5.2), and also allow for vendor-
   specific as well as experimental functions.  SFC should leverage, and
   if needed extend relevant existing OAM mechanisms.

5.8.  Resilience and Redundancy

   As a practical operational requirement, any service chaining solution
   needs to be able to respond effectively, and usually very quickly, to
   failure conditions.  These may be failures of connectivity in the
   network between SFFs, failures of SFFs, or failures of SFs.  Per-SF
   state, as for example stateful-firewall state, is the responsibility
   of the SF, and not addressed by this architecture.





Halpern & Pignataro      Expires March 24, 2015                [Page 22]

Internet-Draft              SFC Architecture              September 2014


   Multiple techniques are available to address this issue.  Solutions
   can describe both what they require and what they allow to address
   failure.  Solutions can make use of flexible specificity of service
   function paths, if the SFF can be given enough information in a
   timely fashion to do this.  Solutions can also make use of MAC or IP
   level redundancy mechanisms such as VRRP.  Also, particularly for SF
   failures, load balancers co-located with the SFF or as part of the
   service function delivery mechanism can provide such robustness.

   Similarly, operational requirements imply resilience in the face of
   load changes.  While mechanisms for managing (e.g., monitoring,
   instantiating, loading images, providing configuration to service
   function chaining control, deleting, etc.) virtual machines are out
   of scope for this architecture, solutions can and are aided by
   describing how they can make use of scaling mechanisms.


SB> Given that we are introducing a new network layer construct including
SB> something that is or is a very close cousin to a network layer, surely
SB> we are missing an opportunity by not including this on day one.


 6.  Security Considerations

   This document does not define a new protocol and therefore creates no
   new security issues.

   Security considerations apply to the realization of this
   architecture.  Such realization ought to provide means to protect the
   SFC-enabled domain and its borders against various forms of attacks,
   including DDoS attacks.  Further, SFC OAM Functions need to not
   negatively affect the security considerations of an SFC-enabled
   domain.  Additionally, all entities (software or hardware)
   interacting with the service chaining mechanisms need to provide
   means of security against malformed, poorly configured (deliberate or
   not) protocol constructs and loops.  These considerations are largely
   the same as those in any network, particularly an overlay network.


SB> I just don't buy this for a security analysis. The Architecture needs
SB> direct the compenent designers to look at security issues associated
SB> with the new components and functionality being introduced.
SB> For example the SFE will have special considerations, so will the 
SB> the path changes that you talk about earlier. Then there is resource
SB> conflicts and their impact as a security problem. Then there is the 
SB> issue of privacy. Really each component of the ach needs to be looked
SB> at from a security PoV and guidance provided to the component designer.

- Stewart
 
--------------090705070101090606030805-- From nobody Wed Nov 12 12:18:51 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1991A8864 for ; Wed, 12 Nov 2014 12:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZU7q5y4UMZ4 for ; Wed, 12 Nov 2014 12:18:27 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 299B71A8546 for ; Wed, 12 Nov 2014 12:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=144453; q=dns/txt; s=iport; t=1415823424; x=1417033024; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=bdRYrPISQFPEARAdB6eEi5WdN98PcUsV9GU6cXYXcUo=; b=c+lMCKL1gGPa2xz+XjqAtGuNxeMj1fjREcDFDcldG/cl3JvA+Bk78yYP 5BVbmfr9FZBnLLIcR7g2CRVja84rxgszXvHOLsMDTVUGzHptBLoBTPJ+0 o7VGKiO6HS4VQV0T3Z76Sg6wpDjm792eKVB+FpaNmVCEsletkv3GVfLKv Q=; X-IronPort-AV: E=Sophos; i="5.07,370,1413244800"; d="scan'208,217"; a="96007054" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 12 Nov 2014 20:17:03 +0000 Received: from [10.21.81.24] (sjc-vpn4-280.cisco.com [10.21.81.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sACKH2VB018258; Wed, 12 Nov 2014 20:17:02 GMT Message-ID: <5463C03D.3040202@cisco.com> Date: Wed, 12 Nov 2014 20:17:01 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: draft-ietf-sfc-architecture@tools.ietf.org References: <5463BD7D.6000007@cisco.com> In-Reply-To: <5463BD7D.6000007@cisco.com> Content-Type: multipart/alternative; boundary="------------060307070504000100010902" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/dc7rIlAPehaaeD5oA7MzyY5Le_Y Cc: "sfc@ietf.org" , sfc-chairs@tools.ietf.org Subject: Re: [sfc] Some concerns about draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2014 20:18:45 -0000 This is a multi-part message in MIME format. --------------060307070504000100010902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Correcting an error in the to list. On 12/11/2014 20:05, Stewart Bryant wrote: > SB> This document lacks the precision and that I would have hoped for > SB> in an architecture. I understand that the this was deliberate > SB> in order to allow implementation flexibility, but I don't > SB> buy that. > SB> > SB> What we have here is a type of layered network, and whilst > SB> verbal discussions have refuted that, you have many references > SB> to overlay topologies. > SB> > SB> This would be better understood if you described it as a layered > SB> system, if you only used generalized the components with fully > SB> functionality, and then explained which could be NULL. In the > SB> case of sub-functional components they should not be part of the > SB> core architecture, but the techniques used to create a full function > SB> component by assistance (the proxy) described outside the main > SB> architecture. > SB> > SB> I understand that in part the approach used here was to allow > SB> a mixture of implementation styles - the concept of explicit > SB> and implicit SFE - with network layer constructs supplying the > SB> implicit SFE. However it would be better to think of the use > SB> of implicit SFE as a type of network recursion in which the > SB> the encapsulator (which I think is distinct from the classifier) > SB> chooses how to encode the SFP on the packet. > SB> > SB> I have a nagging concern about the way that the terms packets is > SB> used in this text. The way it is used one would expect that there > SB> is a one for one mapping between input and output packets, but that > SB> is surely not the case. A trivial point is the case where an SF > SB> needs to defragment. Although at the physical layer the units are > SB> packets, there may surely be higher order constructs traveling > SB> between SFs. > > > Service Function Chaining (SFC) Architecture > draft-ietf-sfc-architecture-02 > > Abstract > > This document describes an architecture for the specification, > sb> an arch or THE arch? > 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. This document does not propose solutions, > protocols, or extensions to existing protocols. > > > > 1. Introduction > > This document describes an architecture used for the creation and > sb> and or THE > ongoing maintenance of Service Function Chains (SFC) in a network. > It includes architectural concepts, principles, and components. > > An overview of the issues associated with the deployment of end-to- > end service function chains, abstract sets of service functions and > their ordering constraints that create a composite service and the > subsequent "steering" of traffic flows through said service > functions, is described in [I-D.ietf-sfc-problem-statement]. > > This architecture presents a model addressing the problematic aspects > of existing service deployments, including topological independence > and configuration complexity. > > Service function chains enable composite services that are > constructed from one or more service functions. > > 1.1. Scope > > This document defines a framework to realize Service Function > Chaining (SFC) with minimum requirements on the physical topology of > the network. The proposed solution relies on initial packet > classification. Packets initially classified for handling by a set > of Service Functions (SFs) in the SFC-enabled domain are then > forwarded to that set of SFs for processing. > > SB> Are you allowed to reclassify, or do staged classification? > SB> Yes you are - you say so later - but that is not implied > SB> by the above. > > This document does not make any assumption on the deployment context. > The proposed framework covers both fixed and mobile networks. > > SB> Given that you make no deployment context assumption, surely > SB> the followup mobile/fixed specific is not relevant. > > The architecture described herein is assumed to be applicable to a > single network administrative domain. While it is possible for the > architectural principles and components to be applied to inter-domain > SFCs, these are left for future study. > > 1.2. Assumptions > > The following assumptions are made: > > o Not all SFs can be characterized with a standard definition in > terms of technical description, detailed specification, > configuration, etc. > > o There is no global or standard list of SFs enabled in a given > administrative domain. The set of SFs varies as a function of the > service to be provided and according to the networking > environment. > > o There is no global or standard SF chaining logic. The ordered set > of SFs that needs to be enabled to deliver a given service is > specific to each administrative entity. > > SB> Surely it is application specific even within an admistration? > > o The chaining of SFs and the criteria to invoke them are specific > to each administrative entity that operates an SF-enabled domain. > > SB? see previous > > > Halpern & Pignataro Expires March 24, 2015 [Page 3] > > Internet-Draft SFC Architecture September 2014 > > > o Several SF chaining policies can be simultaneously applied within > an administrative domain to meet various business requirements. > > o No assumption is made on how FIBs and RIBs of involved nodes are > populated. > > o How to bind traffic to a given SF chain is policy-based. > > 1.3. Definition of Terms > > Network Service: An offering provided by an operator that is > delivered using one or more service functions. This may also be > referred to as a composite service. The term "service" is used > to denote a "network service" in the context of this document. > > Note: Beyond this document, the term "service" is overloaded > with varying definitions. For example, to some a service is an > offering composed of several elements within the operator's > network, whereas for others a service, or more specifically a > network service, is a discrete element such as a firewall. > Traditionally, such services (in the latter sense) host a set of > service functions and have a network locator where the service > is hosted. > > SB> I think that you probably need an explicit definition of service. > SB> I find the text in the definition of NS self referential which is > SB> not helpful. > > > Classification: Locally instantiated policy and customer/network/ > service profile matching of traffic flows for identification of > appropriate outbound forwarding actions. > > SB> Isn't it really > > SB> Locally instantiated matching of traffic flows against policy for > SB> subsequent application of the required set of network service functions. > SB> The policy may be ustomer/network/service specific. > > > > > Classifier: An element that performs Classification. > > SB> A network element perhaps? > > Service Function Chain (SFC): A service function chain defines a set > of abstract service functions and ordering constraints that must > > SB> Isn't the SFC also ordered? > > be applied to packets and/or frames selected as a result of > classification. > SB> Packets, or higher order constructs like flows? You cannot > SB> do some of the SFs packet by packet > > The implied order may not be a linear > progression as the architecture allows for SFCs that copy to > more than one branch, and also allows for cases where there is > flexibility in the order in which service functions need to be > applied. The term service chain is often used as shorthand for > service function chain. > > SB> See my earlier not about the apparently more restricted definition > SB> I think that you need to make the generalization clearer earlier. > > Service Function (SF): A function that is responsible for specific > treatment of received packets. A Service Function can act at > various layers of a protocol stack (e.g., at the network layer > or other OSI layers). As a logical component, a Service > Function can be realized as a virtual element or be embedded in > a physical network element. One or multiple Service Functions > SB> multiple or more? > can be embedded in the same network element. Multiple > > > > > Halpern & Pignataro Expires March 24, 2015 [Page 4] > > Internet-Draft SFC Architecture September 2014 > > > occurrences of the Service Function can exist in the same > administrative domain. > > One or more Service Functions can be involved in the delivery of > added-value services. A non-exhaustive list of abstract Service > Functions includes: firewalls, WAN and application acceleration, > Deep Packet Inspection (DPI), LI (Lawful Intercept), server load > balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], > HOST_ID injection, HTTP Header Enrichment functions, TCP > optimizer. > > SB> Not sure those are abstract SFs, surely they are explicit? > > An SF may be SFC encapsulation aware, that is it receives and > acts on information in the SFC encapsulation, or unaware, in > which case data forwarded to the SF does not contain the SFC > encapsulation. > > Service Function Forwarder (SFF): A service function forwarder is > responsible for delivering traffic received from the network to > one or more connected service functions according to information > carried in the SFC encapsulation, as well as handling traffic > coming back from the SF. Additionally, a service function > forwarder is responsible for delivering traffic to a classifier > when needed and supported, mapping out traffic to another SFF > (in the same or different type of overlay), and terminating the > SFP. > > > SB> In these days of NFV it may not be received from the network. > SB> Surely the traffic is native until it gets to a classifier. The > SB> way you have it here it looks like the first element is the SFF > SB> but I am not sure that is the case. > SB> Perhaps: A service function forwarder is responsible for forwarding > SB> traffic between service functions. > > Metadata: provides the ability to exchange context information > between classifiers and SFs and among SFs. > > SB> I think the first noun is missing in the above, but in any case > SB> I think a more complete definition is needed. > > Service Function Path (SFP): The SFP provides a level of indirection > between the fully abstract notion of service chain as a sequence > of abstract service functions to be delivered, and the fully > specified notion of exactly which SFF/SFs the packet will visit > when it actually traverses the network. By allowing the control > components to specify this level of indirection, the operator > may control the degree of SFF/SF selection authority that is > delegated to the network. > > SB> You have not defined control components. > SB> I think "notion" is a redundant term. > SB> I am somewhat confused by your definition. > SB> Is this really about the mapping of packets between an arbitrary > SB> member of an SF to a specific instance of the SF? > > SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP > identification, and is used by the SFC-aware functions, such as > the SFF and SFC-aware SFs. The SFC Encapsulation is not used > for network packet forwarding. In addition to SFP > identification, the SFC encapsulation carries data plane context > information, also referred to as metadata. > > SB> Surely the "SFC E is used to attach the information needed to > SB> direct the packet through the ordered set of SFs, together with > SB> associated metadata. An additional network layer encapsulation is needed > SB> to carry the packet over the physical network. > > > Rendered Service Path (RSP): The Service Function Path is a > constrained specification of where packets using a certain > service chain must go. While it may be so constrained as to > > > > Halpern & Pignataro Expires March 24, 2015 [Page 5] > > Internet-Draft SFC Architecture September 2014 > > > identify the exact locations, it can also be less specific. > Packets themselves are of course transmitted from and to > specific places in the network, visiting a specific sequence of > SFFs and SFs. This sequence of actual visits by a packet to > specific SFFs and SFs in the network is known as the Rendered > Service Path (RSP). This definition is included here for use by > later documents, such as when solutions may need to discuss the > actual sequence of locations the packets visit. > > > SB> Not sure of the wisdom of including a definition for the future, since > SB> when you use it you may need to tune the definition. > > SFC-enabled Domain: A network or region of a network that implements > SFC. An SFC-enabled Domain is limited to a single network > administrative domain. > > SFC Proxy: Removes and inserts SFC encapsulation on behalf of an > SFC-unaware service function. SFC proxies are logical elements. > > SB> Not sure considering then as logical is quite right. It depends > SB> on the mapping of the operation to the physical. I could see > SB> cases where they are physical. Surely the point is that they > SB> may be co-located with another network function such as a router > SB> an operating system component such as a hypervisor. > > > 2. Architectural Concepts > > The following sections describe the foundational concepts of service > function chaining and the SFC architecture. > > Service Function Chaining enables the creation of composite (network) > services that consist of an ordered set of Service Functions (SF) > that must be applied to packets and/or frames selected as a result of > classification. Each SF is referenced using an identifier that is > unique within an SF-enabled domain. No IANA registry is required to > store the identity of SFs. > > > SB> I am still worried about using packets. Obviously we operate on > SB> pkts, but the operation may require the reconstuction of some > SB> packet grouping typically some element of a flow before the operation > SB> can be performed. A trivial example is defragmenting a packet group > SB> but since we are dealing with abstract SFs we cannot specify the > SB> the unit of operation. > > Service Function Chaining is a concept that provides for more than > just the application of an ordered set of SFs to selected traffic; > rather, it describes a method for deploying SFs in a way that enables > dynamic ordering and topological independence of those SFs as well as > the exchange of metadata between participating entities. > > SB> The above is a bit late in the text. I think it needs to go earlier. > > 2.1. Service Function Chains > > In most networks, services are constructed as abstract sequences of > SB> I don't think that are abstract in this context. > SB> Are you talking about traditional (current physically instantiated > SB> SFCs in the previous sentence? > > SFs that represent SFCs. At a high level, an SFC is an abstracted > view of a service that specifies the set of required SFs as well as > the order in which they must be executed. > > SB> Again I am not sure "abstrated view" is right here > > Graphs, as illustrated in > Figure 1, define an SFC, where each graph node represents the > required existence of at least one abstract SF. Such graph nodes > (SFs) can be part of zero, one, or many SFCs. A given graph node > (SF) can appear one time or multiple times in a given SFC. > > SB> Not sure that graphs is right, since you only show the case > SB> of a linear chain. The construct you are going to use is > SB> graph, but that is not what the figure shows. > > SFCs can start from the origination point of the service function > graph (i.e.: node 1 in Figure 1), or from any subsequent node in the > graph. > > SB> OK so are you trying to distinguish between physically and > SB> SFC (the new technology) instantiated SFCS? > > SFs may therefore become branching nodes in the graph, with > > > > Halpern & Pignataro Expires March 24, 2015 [Page 6] > > Internet-Draft SFC Architecture September 2014 > > > those SFs selecting edges that move traffic to one or more branches. > An SFC can have more than one terminus. > > > SB> Again that is not what your figure shows. > > ,-+-. ,---. ,---. ,---. > / \ / \ / \ / \ > ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) > \ / \ / \ / \ / > `---' `---' `---' `---' > > ,-+-. ,---. ,---. ,---. ,---. > / \ / \ / \ / \ / \ > ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) > \ / \ / \ / \ / \ / > `---' `---' `---' `---' `---' > > ,-+-. ,---. ,---. ,---. ,---. > / \ / \ / \ / \ / \ > ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) > \ / \ / \ / \ / \ / > `---' `---' `---' `---' `---' > > Figure 1: Service Function Chain Graphs > > 2.2. Service Function Chain Symmetry > > SFCs may be unidirectional or bidirectional. A unidirectional SFC > requires that traffic be forwarded through the ordered SFs in one > direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a > symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in > which the SF instances are the same in opposite directions. A hybrid > SFC has attributes of both unidirectional and bidirectional SFCs; > that is to say some SFs require symmetric traffic, whereas other SFs > do not process reverse traffic or are independent of the > corresponding forward traffic. > > SFCs may contain cycles; that is traffic may need to traverse one or > more SFs within an SFC more than once. Solutions will need to ensure > suitable disambiguation for such situations. > > The architectural allowance that is made for SFPs that delegate > choice to the network for which SFs and/or SFFs a packet will visit > creates potential issues here. A solution that allows such > delegation needs to also describe how the solution ensures that those > service chains that require service function chain symmetry can > achieve that. > > Further, there are state tradeoffs in symmetry. Symmetry may be > realized in several ways depending on the SFF and classifier > > > > Halpern & Pignataro Expires March 24, 2015 [Page 7] > > Internet-Draft SFC Architecture September 2014 > > > functionality. In some cases, "mirrored" classification (i.e., from > Source to Destination and from Destination to Source) policy may be > deployed, whereas in others shared state between classifiers may be > used to ensure that symmetric flows are correctly identified, then > steered along the required SFP. At a high level, there are various > common cases. In a non-exhaustive way, there can be for example: a > single classifier (or a small number of classifiers), in which case > both incoming and outgoing flows could be recognized at the same > classifier, so the synchronization would be feasible by internal > mechanisms internal to the classifier. Another case is the one of > stateful classifiers where several classifiers may be clustered and > share state. Lastly, another case entails fully distributed > classifiers, where synchronization needs to be provided through > unspecified means. This is a non-comprehensive list of common cases. > > SB> Isn't an important class of classifiers one that learns state from the > SB> egress packets/flows that is then used to provide state for the > SB> return packets/flow > > 2.3. Service Function Paths > > A service function path (SFP) is a mechanism used by service chaining > to express the result of applying more granular policy and > SB> Not sure "more granular" is needed. > > operational constraints to the abstract requirements of a service > SB> Not sure they are abstract requirements. When you apply them they > SB> are explicit. > > chain (SFC). This architecture does not mandate the degree of > specificity of the SFP. Architecturally, within the same SFC-enabled > domain, some SFPs may be fully specified, selecting exactly which SFF > and which SF are to be visited by packets using that SFP, while other > SFPs may be quite vague, deferring to the SFF the decisions about the > exact sequence of steps to be used to realize the SFC. The > specificity may be anywhere in between these extremes. > > As an example of such an intermediate specificity, there may be two > SFPs associated with a given SFC, where one SFP says essentially that > > SB> "says essentially is not a tight definition" > > any order of SFF and SF may be used as long as it is within data > center 1, and where the second SFP allows the same latitude, but only > within data center 2. > > Thus, the policies and logic of SFP selection or creation (depending > upon the solution) produce what may be thought of as a constrained > version of the original SFC. Since multiple policies may apply to > different traffic that uses the same SFC, it also follows that there > may be multiple SFPs may be associated with a single SFC. > > SB> So a SFP is a specific instance of a member of the set of available SFCs > SB> chosen as a result of applying policy at one or points along the SFC? > > > The architecture allows for the same SF to be reachable through > multiple SFFs. In these cases, some SFPs may constrain which SFF is > used to reach which SF, while some SFPs may leave that decision to > the SFF itself. > > Further, the architecture allows for two or more SFs to be attached > to the same SFF, and possibly connected via internal means allowing > more effective communication. In these cases, some solutions or > > > Halpern & Pignataro Expires March 24, 2015 [Page 8] > > Internet-Draft SFC Architecture September 2014 > > > deployments may choose to use some form of internal inter-process or > inter-VM messaging (communication behind the virtual switching > element) that is optimized for such an environment. This must be > coordinated with the SFF so that the service function forwarding can > properly perform its job. Implementation details of such mechanisms > are considered out of scope for this document, and can include a > spectrum of methods: for example situations including all next-hops > explicitly, others where a list of possible next-hops is provided and > the selection is local, or cases with just an identifier, where all > resolution is local. > > This architecture also allows the same SF to be part of multiple > SFPs. > > SB> Didn't you just say that? > > 3. Architecture Principles > > Service function chaining is predicated on several key architectural > principles: > > 1. Topological independence: no changes to the underlay network > forwarding topology - implicit, or explicit - are needed to > deploy and invoke SFs or SFCs. > > 2. Plane separation: dynamic realization of SFPs is separated from > packet handling operations (e.g., packet forwarding). > > 3. Classification: traffic that satisfies classification rules is > forwarded according to a specific SFP. For example, > classification can be as simple as an explicit forwarding entry > that forwards all traffic from one address into the SFP. > Multiple classification points are possible within an SFC (i.e. > forming a service graph) thus enabling changes/updates to the SFC > by SFs. > > Classification can occur at varying degrees of granularity; for > example, classification can use a 5-tuple, a transport port or > set of ports, part of the packet payload, or it can come from > external systems. > > SB> I think that it can surely be as a result of higher level inspections? > > 4. Shared Metadata: Metadata/context data can be shared amongst SFs > and classifiers, between SFs, and between external systems and > SFs (e.g., orchestration). > > Generally speaking, metadata can be thought of as providing and > sharing the result of classification > > SB> Just classifications, or classifications and processing operations? > SB> There is gray zone between a packet forwarding system and > SB> a distributed computing system and I am not sure where SFC fits, > SB> nor am I sure that it makes sense to be specific at this stage. > SB> It is entirely possible that an SFC consumes the packet/flow > SB> rather than only having the capability to forward it between > SB> in ingress and egress. > > (that occurs within the SFC- > enabled domain, or external to it) along an SFP. For example, an > external repository might provide user/subscriber information to > a service chain classifier. This classifier could in turn impose > > > > Halpern & Pignataro Expires March 24, 2015 [Page 9] > > Internet-Draft SFC Architecture September 2014 > > > that information in the SFC encapsulation for delivery to the > requisite SFs. The SFs could in turn utilize the user/subscriber > information for local policy decisions. > > 5. Service definition independence: The SFC architecture does not > depend on the details of SFs themselves. Additionally, no IANA > registry is required to store the list of SFs. > > SB> Yes, but you should be careful not to preclude it. > > 6. Service function chain independence: The creation, modification, > or deletion of an SFC has no impact on other SFCs. The same is > true for SFPs. > > SB> Yes and no. What about the resource implications? > > 7. Heterogeneous control/policy points: The architecture allows SFs > to use independent mechanisms (out of scope for this document) to > populate and resolve local policy and (if needed) local > classification criteria. > > 4. Core SFC Architecture Components > > At a very high level, the logical architecture of an SFC-enabled > Domain comprises: > > SB> A list would be handy rather than just a figure, and you need > SB> some text to expand on the figure. > > o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > . +--------------+ +------------------~~~ > . | Service | SFC | Service +---+ +---+ > . |Classification| Encapsulation | Function |sf1|...|sfn| > +---->| Function |+---------------->| Path +---+ +---+ > . +--------------+ +------------------~~~ > . SFC-enabled Domain > o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . > > Figure 2: Service Function Chain Architecture > > > SB> This is a very confusing diagram > SB> Surely the SFC encap is attached to the packet > SB> The fig seems to confuse the the packets and the path. > > The following sub-sections provide details on each logical component > that form the basis of the SFC architecture. A detailed overview of > how each of these architectural components interact is provided in > Figure 3: > > > SB> Well maybe, but it's not quite obvious what you are showing. > SB> some overview text would help before you get into the detail. > > > > > > > > > > > > Halpern & Pignataro Expires March 24, 2015 [Page 10] > > Internet-Draft SFC Architecture September 2014 > > > +----------------+ +----------------+ > | SFC-aware | | SFC-unaware | > |Service Function| |Service Function| > +-------+--------+ +-------+--------+ > | | > SFC Encapsulation No SFC Encapsulation > | SFC | > +---------+ +----------------+ Encapsulation +---------+ > |SFC-Aware|-----------------+ \ +------------|SFC Proxy| > | SF | ... ----------+ \ \ / +---------+ > +---------+ \ \ \ / > +-------+--------+ > | SF Forwarder | > | (SFF) | > +-------+--------+ > | > SFC Encapsulation > | > ... SFC-enabled Domain ... > | > Network Overlay Transport > | > _,....._ > ,-' `-. > / `. > | Network | > `. / > `.__ __,-' > `'''' > > Figure 3: Service Function Chain Architecture Components > > > SB> Coming back here after reading a bit more. Is the SFF to be considered the > SB> hub in a hub and spoke processing model for a set of SFs? If so it would > SB> be useful to say that up front. However that raises the issue of whether > SB> the single network attachment point that you show is desirable. A standard > SB> firewall design would not mix dirty and clean traffic, and yet that is > SB> what the above appears to show. > > > 4.1. SFC Encapsulation > > The SFC encapsulation enables service function path selection. It > also enables the sharing of metadata/context information when such > metadata exchange is required. > > SB> I don't think that is quite right. Surely the > SB> SFC encapsulation enables to select the next > SB> element of the path? > > The SFC encapsulation provides explicit information used to identify > SB> Provides or carries? > the SFP. However, the SFC encapsulation is not a transport > encapsulation itself: it is not used to forward packets within the > network fabric. > SB> ... but surely it is a shim layer of some sort? > > If packets need to flow between separate physical > platforms, the SFC encapsulation therefore relies on an outer network > transport. > SB> Surely it is network layer header specific to the inter SFC > SB> transport? > > Transit forwarders -- such as router and switches -- > simply forward SFC encapsulated packets based on the outer (non-SFC) > encapsulation. > > SB> d/simply/ > > > > Halpern & Pignataro Expires March 24, 2015 [Page 11] > > Internet-Draft SFC Architecture September 2014 > > > One of the key architecture principles of SFC is that the SFC > encapsulation remain transport independent. As such any network > transport protocol may be used to carry the SFC encapsulated traffic. > > SB> Not sure I like "network transport protocol" since this is going > SB> to be confused with transport layer and I am not sure whether > SB> you would require a transport layer, indeed the SFE might will > SB> be considered a transport layer in the classical sense. > > 4.2. Service Function (SF) > > The concept of an SF evolves; rather than being viewed as a bump in > the wire, an SF becomes a resource within a specified administrative > domain that is available for consumption as part of a composite > service. SFs send/receive data to/from one or more SFFs. SFC-aware > SFs receive this traffic with the SFC encapsulation. > > SB> I do not understand the above para. > > While the SFC architecture defines a new encapsulation - the SFC > encapsulation - > > SB> no it does not - it is not defined in this memo. You introduce > SB> the concept and define some of the characteristics of it. > > > and several logical components for the construction > of SFCs, existing SF implementations may not have the capabilities to > act upon or fully integrate with the new SFC encapsulation. In order > to provide a mechanism for such SFs to participate in the > architecture, an SFC proxy function is defined (see Section 4.6). > The SFC proxy acts as a gateway between the SFC encapsulation and > SFC-unaware SFs. The integration of SFC-unaware service functions is > discussed in more detail in the SFC proxy section. > > SB> The above is confusing. Do they participate in the architecture (this > SB> text)? I think that you mean that in order to employ SF instances > SB> that do not understand the SFE, a proxy as a gateway between the > SB> the SFE aware domain and the non-SFE aware domain. Now if it is > SB> a gateway why is it not called a gateway rather than a proxy which > SB> is something that does something on behalf of something else. > SB> I would think that it might be a SFE proxy, but that is not quite > SB> right either. > > > This architecture allows an SF to be part of multiple SFPs and SFCs. > > SB> I am sure you said that before. > > 4.3. Service Function Forwarder (SFF) > > The SFF is responsible for forwarding packets and/or frames received > from the network to one or more SFs associated with a given SFF using > information conveyed in the SFC encapsulation. Traffic from SFs > eventually returns to the same SFF, which is responsible for > injecting traffic back onto the network. > > SB> It is not clear why it needs to be the exact same SFF > > The collection of SFFs and associated SFs creates a service plane > overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. > Within this service plane, the SFF component connects different SFs > that form a service function path. > > SB> This conceptual model seems quite fundamental and this I > SB> am surprised that it is not much earlier in the document. > SB> I have been wondering why the SFC system was not considered > SB> an overlay network of some sort, and was told by the authors > SB> that this was not possible. The above seems at odds with that > Sb> statement. > > SFFs maintain the requisite SFP forwarding information. > SB> Maintain - as in being the control plane for this, or > SB> maintain as in store? > SFP > forwarding information is associated with a service path identifier > that is used to uniquely identify an SFP. The service forwarding > state enables an SFF to identify which SFs of a given SFP should be > applied, and in what order, as traffic flows through the associated > SFP. While there may appear to the SFF to be only one available way > to deliver the given SF, there may also be multiple choices allowed > by the constraints of the SFP. > > If there are multiple choices, the SFF needs to preserve the property > that all packets of a given flow are handled the same way, since the > > > > Halpern & Pignataro Expires March 24, 2015 [Page 12] > > Internet-Draft SFC Architecture September 2014 > > > SF may well be stateful. Additionally, the SFF may preserve the > handling of packets based on other properties on top of a flow, such > as a subscriber, session, or application instance identification. > > SB> I feel that the issue of handing higher order objects needs to have > SB> been introduced much earlier in the architecture. > > The SFF also has the information to allow it to forward packets to > the next SFF after applying local service functions. Again, while > there may be only a single choice available, the architecture allows > for multiple choices for the next SFF. As with SFs, the solution > needs to operate such that the behavior with regard to specific flows > (see the Rendered Service Path) is stable. The selection of > available SFs and next SFFs may be interwoven when an SFF supports > multiple distinct service functions and the same service function is > available at multiple SFFs. Solutions need to be clear about what is > allowed in these cases. > > Even when the SFF supports and utilizes multiple choices, the > decision as to whether to use flow-specific mechanisms or coarser > grained means to ensure that the behavior of specific flows is stable > is a matter for specific solutions and specific implementations. > > The SFF component has the following primary responsibilities: > > 1. SFP forwarding : Traffic arrives at an SFF from the network. The > SFF determines the appropriate SF the traffic should be forwarded > to via information contained in the SFC encapsulation. Post-SF, > the traffic is returned to the SFF, and if needed forwarded to > another SF associated with that SFF. If there is another non- > local (i.e., different SFF) hop in the SFP, the SFF further > encapsulates the traffic in the appropriate network transport > protocol and delivers it to the network for delivery to the next > SFF along the path. Related to this forwarding responsibility, > an SFF should be able to interact with metadata. > > 2. Terminating SFPs : An SFC is completely executed when traffic has > traversed all required SFs in a chain. When traffic arrives at > the SFF after the last SF has finished processing it, the final > SFF knows from the service forwarding state that the SFC is > complete. The SFF removes the SFC encapsulation and delivers the > packet back to the network for forwarding. > > 3. Maintaining flow state: In some cases, the SFF may be stateful. > It creates flows and stores flow-centric information. This state > information may be used for a range of SFP-related tasks such as > ensuring consistent treatment of all packets in a given flow, > ensuring symmetry or for state-aware SFC Proxy functionality (see > Section 4.8). > > > > > > Halpern & Pignataro Expires March 24, 2015 [Page 13] > > Internet-Draft SFC Architecture September 2014 > > > 4.3.1. Transport Derived SFF > > Service function forwarding, as described above, directly depends > upon the use of the service path information contained in the SFC > encapsulation. However, existing implementations may not be able to > act on the SFC encapsulation. These platforms may opt to use > existing transport information if it can be arranged to provide > explicit service path information. > > This results in the same architectural behavior and meaning for > service function forwarding and service function paths. It is the > responsibility of the control components to ensure that the transport > path executed in such a case is fully aligned with the path > identified by the information in the service chaining encapsulation. > > SB> The title does not seem quite right. What I think you have > SB> is a system in which you map an SFC onto an explicit path > SB> of some sort in the lower layers (I was going to say network layer > SB> but I am not sure if that is what you intend). So I am not sure > SB> derived is the correct word. It would be closer to say "emulation > SB> of SFF using explicit network paths. Noting that these paths may > SB> be encoded in the packet or encoded in the FIB. > > 4.4. SFC-Enabled Domain > > Specific features may need to be enforced at the boundaries of an > SFC-enabled domain, for example to avoid leaking SFC information. > Using the term node to refer generically to an entity that is > performing a set of functions, in this context, an SFC Boundary Node > denotes a node that connects one SFC-enabled domain to a node either > located in another SFC-enabled domain or in a domain that is SFC- > unaware. > > An SFC Boundary node can act as egress or ingress. > SB> do you mean or or and/or i.e. can it be both at the same time. > An SFC Egress > Node denotes a SFC Boundary Node that handles traffic leaving the > SFC-enabled domain the Egress Node belongs to. Such a node is > required to remove any information specific to the SFC Domain, > typically the SFC Encapsulation. An SFC Ingress Node denotes an SFC > Boundary Node that handles traffic entering the SFC-enabled domain. > In most solutions and deployments this will need to include a > classifier, and will be responsible for adding the SFC encapsulation > to the packet. > > SB> Logically doesn't it always include the classifier, where the set of > SB> classifier types includes the null classifier? The only exception > SB> I suppose is when you are receiving traffic from a trusted > SB> SFC aware peer, but it might be better to be more explicit > SB> about the normal case and then introduce the exception > > 4.5. Network Overlay and Network Components > > Underneath the SFF there are components responsible for performing > the transport (overlay) forwarding. They do not consult the SFC > encapsulation or inner payload for performing this forwarding. They > only consult the outer-transport encapsulation for the transport > (overlay) forwarding. > > SB> This layer model needs to be brought out much earlier instead of > SB> having the reader deduce it up to this point. > SB> Indeed the layering model makes for a better way of explaining > SB> the operation of the system. > > 4.6. SFC Proxy > > In order for the SFC architecture to support SFC-unaware SFs (e.g., > legacy service functions) a logical SFC proxy function may be used. > > SB> Is it a logical proxy or a real proxy, and why only may, surely > SB> it *is* used. > > > Halpern & Pignataro Expires March 24, 2015 [Page 14] > > Internet-Draft SFC Architecture September 2014 > > > This function sits between an SFF and one or more SFs to which the > SFF is directing traffic. > > The proxy accepts packets from the SFF on behalf of the SF. It > removes the SFC encapsulation, and then uses a local attachment > circuit to deliver packets to SFC unaware SFs. It also receives > packets back from the SF, reapplies the SFC encapsulation, and > returns them to the SFF for processing along the service function > path. > > Thus, from the point of view of the SFF, the SFC proxy appears to be > part of an SFC aware SF. > > Communication details between the SFF and the SFC Proxy are the same > as those between the SFF and an SFC aware SF. The details of that > are not part of this architecture. The details of the communication > methods over the local attachment circuit between the SFC proxy and > the SFC-unaware SF are dependent upon the specific behaviors and > capabilities of that SFC-unaware SF, and thus are also out of scope > for this architecture. > > Specifically, for traffic received from the SFF intended for the SF > the proxy is representing, the SFC proxy: > > o Removes the SFC encapsulation from SFC encapsulated packets. > > o Identifies the required SF to be applied based on available > information including that carried in the SFC encapsulation. > > o Selects the appropriate outbound local attachment circuit through > which the next SF for this SFP is reachable. This is derived from > the identification of the SF carried in the SFC encapsulation, and > may include local techniques. Examples of a local attachment > circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, > GRE, VXLAN. > > o Forwards the original payload via the selected local attachment > circuit to the appropriate SF. > > SB> I think you have missed the storage of the SFE and I am not > SB> sure how this gets back to the specific packet. This causes me > SB> wonder if it is the original payload or not since it may by > SB> now be SFC modified. It is surely the SFE payload that gets > SB> passed up, and to re-attach the correct SFE afterwards, might > SB> you not have to modify it? > > > When traffic is returned from the SF: > > o Applies the required SFC encapsulation. The determination of the > encapsulation details may be inferred by the local attachment > circuit through which the packet and/or frame was received, or via > packet classification, or other local policy. In some cases, > packet ordering or modification by the SF may necessitate > additional classification in order to re-apply the correct SFC > encapsulation. > > SB> This function is surely split between the outbound and inbound > SB> proxy functions. > > Halpern & Pignataro Expires March 24, 2015 [Page 15] > > Internet-Draft SFC Architecture September 2014 > > > o Delivers the packet with the SFC Encapsulation to the SFF, as > would happen with packets returned from an SFC-aware SF. > > Alternatively, a service provider may decide to exclude legacy > service functions from an SFC domain. > > SB> This might have been better expressed earlier in the text my noting > SB> that the proxy was optional, making the afterthought above redundant. > > > 4.7. Classification > > Traffic from the network that satisfies classification criteria is > directed into an SFP and forwarded to the requisite service > function(s). Classification is handled by a service classification > function; initial classification occurs at the ingress to the SFC > domain. The granularity of the initial classification is determined > by the capabilities of the classifier and the requirements of the SFC > policy. For instance, classification might be relatively coarse: all > packets from this port are subject to SFC policy X and directed into > SFP A, or quite granular: all packets matching this 5-tuple are > subject to SFC policy Y and directed into SFP B. > > As a consequence of the classification decision, the appropriate SFC > encapsulation is imposed on the data, and a suitable SFP is selected > or created. Classification results in attaching the traffic to a > specific SFP. > > SB> How about: > > SFC domain ingress traffic is first processed by a classifier which > either rejects the traffic or prepares it for processing by the required > SFs. The classifier applies policy to the packet to determine the required > SFC, and then to map that to the required SFP. The classifier applies > the corresponding SFE and if necessary the appropriate network layer > encapsulation and forwards the packet to the first SFF on the chain. > > > > 4.8. Re-Classification and Branching > > The SFC architecture supports re-classification (or non-initial > classification) as well. > > SB> This is interesting, surely the packet only enters the > SB> SFC when it has been been classified (including the null classification) > SB> and has the SFE applied? > > As packets traverse an SFP, re- > classification may occur - typically performed by a classification > function co-resident with a service function. > SB> Architecturally you may always want to include a reclassifier > SB> on exit (and may be entry) to every SF. It may be null, but it's > SB> probably better that it is there. > > Reclassification may > result in the selection of a new SFP, an update of the associated > metadata, or both. This is referred to as "branching". > > For example, an initial classification results in the selection of > SFP A: DPI_1 --> SLB_8. However, when the DPI service function is > executed, attack traffic is detected at the application layer. DPI_1 > re-classifies the traffic as attack and alters the service path to > SFP B, to include a firewall for policy enforcement: dropping the > traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would > be returned to the original SFF. In this simple example, the DPI > service function re-classifies the traffic based on local application > layer classification capabilities (that were not available during the > initial classification step). > > When traffic arrives after being steered through an SFC-unaware SF, > the SFC Proxy must perform re-classification of traffic to determine > the SFP. The SFC Proxy is concerned with re-attaching information > > SB> This should have been part of the earlier proxy functional definition. > SB> Maybe if you moved this up earlier before proxy it would all be clearer. > > > Halpern & Pignataro Expires March 24, 2015 [Page 16] > > Internet-Draft SFC Architecture September 2014 > > > for SFC-unaware SFs, and a stateful SFC Proxy simplifies such > classification to a flow lookup. > > 4.9. Shared Metadata > > SB> Isn't metadata always shared? If no one else sees it, there is > SB> no point in generating it. > > Sharing metadata allows the network to provide network-derived > information to the SFs, SF-to-SF information exchange and the sharing > of service-derived information to the network. Some SFCs may not > require metadata exchange. SFC infrastructure enables the exchange > of this shared data along the SFP. The shared metadata serves > several possible roles within the SFC architecture: > > o Allows elements that typically operate as ships in the night to > exchange information. > > SB> That is a sort of tautology. If they share MD they are not true > SB> SITN. Surely this is about in band and outband state sharing. > > o Encodes information about the network and/or data for post- > service forwarding. > > o Creates an identifier used for policy binding by SFs. > > Context information can be derived in several ways: > > SB> This list does not scan properly from the intro fragment above. > > o External sources > > o Network node classification > > o Service function classification > > > > 5. Additional Architectural Concepts > > There are a number of issues which solutions need to address, and > which the architecture informs but does not determine. This section > lays out some of those concepts. > > 5.1. The Role of Policy > > Much of the behavior of service chains is driven by operator and per- > customer policy. This architecture is structured to isolate the > policy interactions from the data plane and control logic. > > Specifically, it is assumed that the service chaining control plane > creates the service paths. The service chaining data plane is used > to deliver the classified packets along the service chains to the > intended service functions. > > Policy, in contrast, interacts with the system in other places. > Policies and policy engines may monitor service functions to decide > if additional (or fewer) instances of services are needed. > > SB> This seems to be conflating policy and resource management, and > SB> I am not sure this is wise. The resource manager should consult > SB> policy, but the problems are distinct. > > When > > > > Halpern & Pignataro Expires March 24, 2015 [Page 17] > > Internet-Draft SFC Architecture September 2014 > > > applicable, those decisions may in turn result in interactions that > direct the control logic to change the SFP placement or packet > classification rules. > > Similarly, operator service policy, often managed by operational or > business support systems (OSS or BSS), will frequently determine what > service functions are available. Operator service policies also > determine which sequences of functions are valid and are to be used > or made available. > > The offering of service chains to customers, and the selection of > which service chain a customer wishes to use, are driven by a > combination of operator and customer policies using appropriate > portals in conjunction with the OSS and BSS tools. These selections > then drive the service chaining control logic, which in turn > establishes the appropriate packet classification rules. > > > SB> Didn't you just say the above. In any case it might be better in > SB> the form of an intro rather than a conclusion. > > 5.2. SFC Control Plane > > This is part of the overall architecture but outside the scope of > this document. > > SB> The specifics of the architecture of the CP may be out of scope > SB> but I cannot see how it can be out of scope of the main > SB> architecture, unless you want to reclassify this as the SFC packet > SB> plane architecture. > SB> > SB> As I read more of this text I am unclear why this in not promoted > SB> to the main body of the text. > > > The SFC control plane is responsible for constructing SFPs, > translating SFCs to forwarding paths and propagating path information > to participating nodes to achieve requisite forwarding behavior to > construct the service overlay. For instance, an SFC construction may > be static; selecting exactly which SFFs and which SFs from those SFFs > are to be used, or it may be dynamic, allowing the network to perform > some or all of the choices of SFF or SF to use to deliver the > selected service chain within the constraints represented by the > service path. > > In the SFC architecture, SFs are resources; > > SB> SFs or SF instances? I don't think it becomes an accountable > SB> resource until it is instantiated. > > the control plane manages > and communicates their capabilities, availability and location in > fashions suitable for the transport and SFC operations in use. The > control plane is also responsible for the creation of the context > (see below). The control plane may be distributed (using new or > existing control plane protocols), or be centralized, or a > combination of the two. > > The SFC control plane provides the following functionality: > > 1. An SFC-enabled domain wide view of all available service function > resources as well as the network locators through which they are > reachable. > > 2. Uses SFC policy to construct service function chains, and > associated service function paths. > > > > Halpern & Pignataro Expires March 24, 2015 [Page 18] > > Internet-Draft SFC Architecture September 2014 > > > 3. Selection of specific SFs for a requested SFC, either statically > (using specific SFs) or dynamically (using service explicit SFs > at the time of delivering traffic to them). > > 4. Provides requisite SFC data plane information to the SFC > architecture components, most notably the SFF. > > 5. Allocation of metadata associated with a given SFP and > propagation of the metadata to relevant SFs and/or SFC > encapsulation-proxies or their respective policy planes. > > SB> I am not sure what it means to allocate metadata. Do you mean > SB> MD storage, or MD packet space? > > 5.3. Resource Control > > The SFC system may be responsible for managing all resources > necessary for the SFC components to function. This includes network > constraints used to plan and choose network path(s) between service > function forwarders, network communication paths between service > function forwarders and their attached service functions, > characteristics of the nodes themselves such as memory, number of > virtual interfaces, routes, and instantiation, configuration, and > deletion of SFs. > > The SFC system will also be required to reflect policy decisions > about resource control, as expressed by other components in the > system. > > While all of these aspects are part of the overall system, they are > beyond the scope of this architecture. > > > SB> The relationship between the RC/RM and the CP seems unclear. > > 5.4. Infinite Loop Detection and Avoidance > > This SFC architecture is predicated on topological independence from > the underlying forwarding topology. Consequently, a service topology > is created by Service Function Paths or by the local decisions of the > Service Function Forwarders based on the constraints expressed in the > SFP. > > SB> The concept of service topologies and overlays would be useful much earlier in the text. > > Due to the overlay constraints, the packet-forwarding path may > need to visit the same SFF multiple times, and in some less common > cases may even need to visit the same SF more than once. The Service > Chaining solution needs to permit these limited and policy-compliant > loops. At the same time, the solutions must ensure that indefinite > and unbounded loops cannot be formed, as such would consume unbounded > resources without delivering any value. > > In other words, this architecture prevents infinite Service Function > Loops, even when Service Functions may be invoked multiple times in > the same SFP. > > SB> You say it does, but I don't see how it does it. Do you anticipate > SB> it happening in the CP or the DP or both? > SB> > > > > Halpern & Pignataro Expires March 24, 2015 [Page 19] > > Internet-Draft SFC Architecture September 2014 > > > 5.5. Load Balancing Considerations > > Supporting function elasticity and high-availability should not > overly complicate SFC or lead to unnecessary scalability problems. > > In the simplest case, where there is only a single function in the > SFP (the next hop is either the destination address of the flow or > the appropriate next hop to that destination), one could argue that > there may be no need for SFC. > > SB> It is unusual to lead with the dejenerate case (i.e. no SFC) > > In the cases where the classifier is separate from the single > function or a function at the terminal address may need sub-prefix or > per-subscriber metadata, a single SFP exists (the metadata changes > but the SFP does not), regardless of the number of potential terminal > addresses for the flow. This is the case of the simple load > balancer. See Figure 4. > > +---+ +---++--->web server > source+-->|sff|+-->|sf1|+--->web server > +---+ +---++--->web server > > Figure 4: Simple Load Balancing > > By extrapolation, in the case where intermediary functions within a > chain had similar "elastic" behaviors, we do not need separate chains > to account for this behavior - as long as the traffic coalesces to a > common next-hop after the point of elasticity. > > In Figure 5, we have a chain of five service functions between the > traffic source and its destination. > > +---+ +---+ +---+ +---+ +---+ +---+ > |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| > +---+ +---+ +---+ +---+ +---+ +---+ > | | | | | | > +-----+-----+ +-----+-----+ > | | > + + > +---+ +---+ +---+ +---+ +---+ > source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination > +---+ +---+ +---+ +---+ +---+ > + + + > | | | > +---+ +---+ +---+ > |sf1| |sf3| |sf5| > +---+ +---+ +---+ > > Figure 5: Load Balancing > > > > Halpern & Pignataro Expires March 24, 2015 [Page 20] > > Internet-Draft SFC Architecture September 2014 > > > This would be represented as one service function path: > sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be > made up of one or multiple components. In this architecture, the SFF > may handle load distribution based on policy. > > It can also be seen in the above that the same service function may > be reachable through multiple SFFs, as discussed earlier. The > selection of which SFF to use to reach SF3 may be made by the control > logic in defining the SFP, or may be left to the SFFs themselves, > depending upon policy, solution, and deployment constraints. In the > latter case, it needs to be assured that exactly one SFF takes > responsibility to steer traffic through SF3. > > > SB> Shouldn't the architecture lead with the general case and note > SB> that any function can be replaced with the null function. > > 5.6. MTU and Fragmentation Considerations > > This architecture prescribes additional information being added to > packets to identify service function paths and often to represent > metadata. It also envisions adding transport information to carry > packets along service function paths, at least between service > function forwarders. This added information increases the size of > the packet to be carried by service chaining. Such additions could > potentially increase the packet size beyond the MTU supported on some > or all of the media used in the service chaining domain. > > Such packet size increases can thus cause operational MTU problems. > Requiring fragmentation and reassembly in an SFF would be a major > processing increase, and might be impossible with some transports. > > SB> Sure but the SFE is teh network layer of the SFC plane and could > SB> do this. > > Expecting service functions to deal with packets fragmented by the > SFC function might be onerous even when such fragmentation was > possible. Thus, at the very least, solutions need to pay attention > to the size cost of their approach. There may be alternative or > additional means available, although any solution needs to consider > the tradeoffs. > > These considerations apply to any generic architecture that increases > the header size. There are also more specific MTU considerations: > Effects on Path MTU Discovery (PMTUD) as well as deployment > considerations. Deployments within a single administrative control > or even a single Data Center complex can afford more flexibility in > dealing with larger packets, and deploying existing mitigations that > decrease the likelihood of fragmentation or discard. > > 5.7. SFC OAM > > Operations, Administration, and Maintenance (OAM) tools are an > integral part of the architecture. These serve various purposes, > including fault detection and isolation, and performance management. > For example, there are many advantages of SFP liveness detection, > > > > Halpern & Pignataro Expires March 24, 2015 [Page 21] > > Internet-Draft SFC Architecture September 2014 > > > including status reporting, support for resiliency operations and > policies, and an enhanced ability to balance load. > > Service Function Paths create a services topology, and OAM performs > various functions within this service layer. Furthermore, SFC OAM > follows the same architectural principles of SFC in general. For > example, topological independence (including the ability to run OAM > over various overlay technologies) and classification-based policy. > > We can subdivide the SFC OAM architecture in two parts: > > o In-band: OAM packets follow the same path and share fate with user > packets, within the service topology. For this, they also follow > the architectural principle of consistent policy identifiers, and > use the same path IDs as the service chain data packets. Load > balancing and SFC encapsulation with packet forwarding are > particularly important here. > > o Out-of-band: reporting beyond the actual data plane. An > additional layer beyond the data-plane OAM allows for additional > alerting and measurements. > > This architecture prescribes end-to-end SFP OAM functions, which > implies SFF understanding of whether an in-band packet is an OAM or > user packet. However, service function validation is outside of the > scope of this architecture, and application-level OAM is not what > this architecture prescribes. > > Some of the detailed functions performed by SFC OAM include fault > detection and isolation in a Service Function Path or a Service > Function, verification that connectivity using SFPs is both effective > and directing packets to the intended service functions, service path > tracing, diagnostic and fault isolation, alarm reporting, performance > measurement, locking and testing of service functions, validation > with the control plane (see Section 5.2), and also allow for vendor- > specific as well as experimental functions. SFC should leverage, and > if needed extend relevant existing OAM mechanisms. > > 5.8. Resilience and Redundancy > > As a practical operational requirement, any service chaining solution > needs to be able to respond effectively, and usually very quickly, to > failure conditions. These may be failures of connectivity in the > network between SFFs, failures of SFFs, or failures of SFs. Per-SF > state, as for example stateful-firewall state, is the responsibility > of the SF, and not addressed by this architecture. > > > > > > Halpern & Pignataro Expires March 24, 2015 [Page 22] > > Internet-Draft SFC Architecture September 2014 > > > Multiple techniques are available to address this issue. Solutions > can describe both what they require and what they allow to address > failure. Solutions can make use of flexible specificity of service > function paths, if the SFF can be given enough information in a > timely fashion to do this. Solutions can also make use of MAC or IP > level redundancy mechanisms such as VRRP. Also, particularly for SF > failures, load balancers co-located with the SFF or as part of the > service function delivery mechanism can provide such robustness. > > Similarly, operational requirements imply resilience in the face of > load changes. While mechanisms for managing (e.g., monitoring, > instantiating, loading images, providing configuration to service > function chaining control, deleting, etc.) virtual machines are out > of scope for this architecture, solutions can and are aided by > describing how they can make use of scaling mechanisms. > > > SB> Given that we are introducing a new network layer construct including > SB> something that is or is a very close cousin to a network layer, surely > SB> we are missing an opportunity by not including this on day one. > > > 6. Security Considerations > > This document does not define a new protocol and therefore creates no > new security issues. > > Security considerations apply to the realization of this > architecture. Such realization ought to provide means to protect the > SFC-enabled domain and its borders against various forms of attacks, > including DDoS attacks. Further, SFC OAM Functions need to not > negatively affect the security considerations of an SFC-enabled > domain. Additionally, all entities (software or hardware) > interacting with the service chaining mechanisms need to provide > means of security against malformed, poorly configured (deliberate or > not) protocol constructs and loops. These considerations are largely > the same as those in any network, particularly an overlay network. > > > SB> I just don't buy this for a security analysis. The Architecture needs > SB> direct the compenent designers to look at security issues associated > SB> with the new components and functionality being introduced. > SB> For example the SFE will have special considerations, so will the > SB> the path changes that you talk about earlier. Then there is resource > SB> conflicts and their impact as a security problem. Then there is the > SB> issue of privacy. Really each component of the ach needs to be looked > SB> at from a security PoV and guidance provided to the component designer. > > - Stewart > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------060307070504000100010902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Correcting an error in the to list.

On 12/11/2014 20:05, Stewart Bryant wrote:
SB> This document lacks the precision and that I would have hoped for 
SB> in an architecture. I understand that the this was deliberate 
SB> in order to allow implementation flexibility, but I don't 
SB> buy that.
SB>
SB> What we have here is a type of layered network, and whilst 
SB> verbal discussions have refuted that, you have many references
SB> to overlay topologies.
SB>
SB> This would be better understood if you described it as a layered
SB> system, if you only used generalized the components with fully
SB> functionality, and then explained which could be NULL. In the 
SB> case of sub-functional components they should not be part of the 
SB> core architecture, but the techniques used to create a full function
SB> component by assistance (the proxy) described outside the main
SB> architecture.
SB>
SB> I understand that in part the approach used here was to allow
SB> a mixture of implementation styles - the concept of explicit
SB> and implicit SFE - with network layer constructs supplying the 
SB> implicit SFE. However it would be better to think of the use
SB> of implicit SFE as a type of network recursion in which the 
SB> the encapsulator (which I think is distinct from the classifier)
SB> chooses how to encode the SFP on the packet.
SB>
SB> I have a nagging concern about the way that the terms packets is
SB> used in this text. The way it is used one would expect that there
SB> is a one for one mapping between input and output packets, but that
SB> is surely not the case. A trivial point is the case where an SF
SB> needs to defragment. Although at the physical layer the units are
SB> packets, there may surely be higher order constructs traveling
SB> between SFs. 


 Service Function Chaining (SFC) Architecture
                     draft-ietf-sfc-architecture-02

Abstract

   This document describes an architecture for the specification,
sb> an arch or THE arch?
   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.  This document does not propose solutions,
   protocols, or extensions to existing protocols.



1.  Introduction

   This document describes an architecture used for the creation and
sb> and or THE
   ongoing maintenance of Service Function Chains (SFC) in a network.
   It includes architectural concepts, principles, and components.

   An overview of the issues associated with the deployment of end-to-
   end service function chains, abstract sets of service functions and
   their ordering constraints that create a composite service and the
   subsequent "steering" of traffic flows through said service
   functions, is described in [I-D.ietf-sfc-problem-statement].

   This architecture presents a model addressing the problematic aspects
   of existing service deployments, including topological independence
   and configuration complexity.

   Service function chains enable composite services that are
   constructed from one or more service functions.

1.1.  Scope

   This document defines a framework to realize Service Function
   Chaining (SFC) with minimum requirements on the physical topology of
   the network.  The proposed solution relies on initial packet
   classification.  Packets initially classified for handling by a set
   of Service Functions (SFs) in the SFC-enabled domain are then
   forwarded to that set of SFs for processing.

SB> Are you allowed to reclassify, or do staged classification? 
SB> Yes you are - you say so later - but that is not implied
SB> by the above.

   This document does not make any assumption on the deployment context.
   The proposed framework covers both fixed and mobile networks.

SB> Given that you make no deployment context assumption, surely
SB> the followup mobile/fixed specific is not relevant.

   The architecture described herein is assumed to be applicable to a
   single network administrative domain.  While it is possible for the
   architectural principles and components to be applied to inter-domain
   SFCs, these are left for future study.

1.2.  Assumptions

   The following assumptions are made:

   o  Not all SFs can be characterized with a standard definition in
      terms of technical description, detailed specification,
      configuration, etc.

   o  There is no global or standard list of SFs enabled in a given
      administrative domain.  The set of SFs varies as a function of the
      service to be provided and according to the networking
      environment.

   o  There is no global or standard SF chaining logic.  The ordered set
      of SFs that needs to be enabled to deliver a given service is
      specific to each administrative entity.

SB> Surely it is application specific even within an admistration?

 o  The chaining of SFs and the criteria to invoke them are specific
      to each administrative entity that operates an SF-enabled domain.

SB? see previous


Halpern & Pignataro      Expires March 24, 2015                 [Page 3]

Internet-Draft              SFC Architecture              September 2014


   o  Several SF chaining policies can be simultaneously applied within
      an administrative domain to meet various business requirements.

   o  No assumption is made on how FIBs and RIBs of involved nodes are
      populated.

   o  How to bind traffic to a given SF chain is policy-based.

1.3.  Definition of Terms

   Network Service:  An offering provided by an operator that is
        delivered using one or more service functions.  This may also be
        referred to as a composite service.  The term "service" is used
        to denote a "network service" in the context of this document.

        Note: Beyond this document, the term "service" is overloaded
        with varying definitions.  For example, to some a service is an
        offering composed of several elements within the operator's
        network, whereas for others a service, or more specifically a
        network service, is a discrete element such as a firewall.
        Traditionally, such services (in the latter sense) host a set of
        service functions and have a network locator where the service
        is hosted.

SB> I think that you probably need an explicit definition of service.
SB> I find the text in the definition of NS self referential which is
SB> not helpful.


 Classification:  Locally instantiated policy and customer/network/
        service profile matching of traffic flows for identification of
        appropriate outbound forwarding actions.

SB> Isn't it really

SB> Locally instantiated matching of traffic flows against policy for
SB> subsequent application of the required set of network service functions. 
SB> The policy may be ustomer/network/service specific.




 Classifier:  An element that performs Classification.

SB> A network element perhaps?

 Service Function Chain (SFC):  A service function chain defines a set
        of abstract service functions and ordering constraints that must

SB> Isn't the SFC also ordered?

        be applied to packets and/or frames selected as a result of
        classification.  
SB> Packets, or higher order constructs like flows? You cannot
SB> do some of the SFs packet by packet

        The implied order may not be a linear
        progression as the architecture allows for SFCs that copy to
        more than one branch, and also allows for cases where there is
        flexibility in the order in which service functions need to be
        applied.  The term service chain is often used as shorthand for
        service function chain.

SB> See my earlier not about the apparently more restricted definition
SB> I think that you need to make the generalization clearer earlier.

 Service Function (SF):  A function that is responsible for specific
        treatment of received packets.  A Service Function can act at
        various layers of a protocol stack (e.g., at the network layer
        or other OSI layers).  As a logical component, a Service
        Function can be realized as a virtual element or be embedded in
        a physical network element.  One or multiple Service Functions
SB> multiple or more?
       can be embedded in the same network element.  Multiple




Halpern & Pignataro      Expires March 24, 2015                 [Page 4]

Internet-Draft              SFC Architecture              September 2014


        occurrences of the Service Function can exist in the same
        administrative domain.

        One or more Service Functions can be involved in the delivery of
        added-value services.  A non-exhaustive list of abstract Service
        Functions includes: firewalls, WAN and application acceleration,
        Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
        balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
        HOST_ID injection, HTTP Header Enrichment functions, TCP
        optimizer.

SB> Not sure those are abstract SFs, surely they are explicit?

        An SF may be SFC encapsulation aware, that is it receives and
        acts on information in the SFC encapsulation, or unaware, in
        which case data forwarded to the SF does not contain the SFC
        encapsulation.

   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as handling traffic
        coming back from the SF.  Additionally, a service function
        forwarder is responsible for delivering traffic to a classifier
        when needed and supported, mapping out traffic to another SFF
        (in the same or different type of overlay), and terminating the
        SFP.


SB> In these days of NFV it may not be received from the network.
SB> Surely the traffic is native until it gets to a classifier. The
SB> way you have it here it looks like the first element is the SFF
SB> but I am not sure that is the case.
SB> Perhaps: A service function forwarder is responsible for forwarding
SB> traffic between service functions. 

 Metadata:  provides the ability to exchange context information
        between classifiers and SFs and among SFs.

SB> I think the first noun is missing in the above, but in any case
SB> I think a more complete definition is needed.

 Service Function Path (SFP):  The SFP provides a level of indirection
        between the fully abstract notion of service chain as a sequence
        of abstract service functions to be delivered, and the fully
        specified notion of exactly which SFF/SFs the packet will visit
        when it actually traverses the network.  By allowing the control
        components to specify this level of indirection, the operator
        may control the degree of SFF/SF selection authority that is
        delegated to the network.

SB> You have not defined control components.
SB> I think "notion" is a redundant term.
SB> I am somewhat confused by your definition.
SB> Is this really about the mapping of packets between an arbitrary
SB> member of an SF to a specific instance of the SF?

 SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
        identification, and is used by the SFC-aware functions, such as
        the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
        for network packet forwarding.  In addition to SFP
        identification, the SFC encapsulation carries data plane context
        information, also referred to as metadata.

SB> Surely the "SFC E is used to attach the information needed to
SB> direct the packet through the ordered set of SFs, together with
SB> associated metadata. An additional  network layer encapsulation is needed
SB> to carry the packet over the physical network.


 Rendered Service Path (RSP):  The Service Function Path is a
        constrained specification of where packets using a certain
        service chain must go.  While it may be so constrained as to



Halpern & Pignataro      Expires March 24, 2015                 [Page 5]

Internet-Draft              SFC Architecture              September 2014


        identify the exact locations, it can also be less specific.
        Packets themselves are of course transmitted from and to
        specific places in the network, visiting a specific sequence of
        SFFs and SFs.  This sequence of actual visits by a packet to
        specific SFFs and SFs in the network is known as the Rendered
        Service Path (RSP).  This definition is included here for use by
        later documents, such as when solutions may need to discuss the
        actual sequence of locations the packets visit.


SB> Not sure of the wisdom of including a definition for the future, since
SB> when you use it you may need to tune the definition.

 SFC-enabled Domain:  A network or region of a network that implements
        SFC.  An SFC-enabled Domain is limited to a single network
        administrative domain.

   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
        SFC-unaware service function.  SFC proxies are logical elements.

SB> Not sure considering then as logical is quite right. It depends
SB> on the mapping of the operation to the physical. I could see
SB> cases where they are physical. Surely the point is that they
SB> may be co-located with another network function such as a router
SB> an operating system component such as a hypervisor.


 2.  Architectural Concepts

   The following sections describe the foundational concepts of service
   function chaining and the SFC architecture.

   Service Function Chaining enables the creation of composite (network)
   services that consist of an ordered set of Service Functions (SF)
   that must be applied to packets and/or frames selected as a result of
   classification.  Each SF is referenced using an identifier that is
   unique within an SF-enabled domain.  No IANA registry is required to
   store the identity of SFs.


SB> I am still worried about using packets. Obviously we operate on
SB> pkts, but the operation may require the reconstuction of some
SB> packet grouping typically some element of a flow before the operation
SB> can be performed. A trivial example is defragmenting a packet group
SB> but since we are dealing with abstract SFs we cannot specify the 
SB> the unit of operation.

    Service Function Chaining is a concept that provides for more than
   just the application of an ordered set of SFs to selected traffic;
   rather, it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities.

SB> The above is a bit late in the text. I think it needs to go earlier.

 2.1.  Service Function Chains

   In most networks, services are constructed as abstract sequences of
SB> I don't think that are abstract in this context.
SB> Are you talking about traditional (current physically instantiated
SB> SFCs in the previous sentence?

   SFs that represent SFCs.  At a high level, an SFC is an abstracted
   view of a service that specifies the set of required SFs as well as
   the order in which they must be executed.  

SB> Again I am not sure "abstrated view" is right here

   Graphs, as illustrated in
   Figure 1, define an SFC, where each graph node represents the
   required existence of at least one abstract SF.  Such graph nodes
   (SFs) can be part of zero, one, or many SFCs.  A given graph node
   (SF) can appear one time or multiple times in a given SFC.

SB> Not sure that graphs is right, since you only show the case
SB> of a linear chain. The construct you are going to use is
SB> graph, but that is not what the figure shows.

   SFCs can start from the origination point of the service function
   graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
   graph.  

SB> OK so are you trying to distinguish between physically and
SB> SFC (the new technology) instantiated SFCS?

   SFs may therefore become branching nodes in the graph, with



Halpern & Pignataro      Expires March 24, 2015                 [Page 6]

Internet-Draft              SFC Architecture              September 2014


   those SFs selecting edges that move traffic to one or more branches.
   An SFC can have more than one terminus.


SB> Again that is not what your figure shows.

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   6   )+---->(   8   )
    \     /       \     /        \     /        \     /
     `---'         `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   3   )+---->(   7   )+---->(   9   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   7   )+---->(   8   )+---->(   4   )+---->(   7   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

                  Figure 1: Service Function Chain Graphs

2.2.  Service Function Chain Symmetry

   SFCs may be unidirectional or bidirectional.  A unidirectional SFC
   requires that traffic be forwarded through the ordered SFs in one
   direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a
   symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in
   which the SF instances are the same in opposite directions.  A hybrid
   SFC has attributes of both unidirectional and bidirectional SFCs;
   that is to say some SFs require symmetric traffic, whereas other SFs
   do not process reverse traffic or are independent of the
   corresponding forward traffic.

   SFCs may contain cycles; that is traffic may need to traverse one or
   more SFs within an SFC more than once.  Solutions will need to ensure
   suitable disambiguation for such situations.

   The architectural allowance that is made for SFPs that delegate
   choice to the network for which SFs and/or SFFs a packet will visit
   creates potential issues here.  A solution that allows such
   delegation needs to also describe how the solution ensures that those
   service chains that require service function chain symmetry can
   achieve that.

   Further, there are state tradeoffs in symmetry.  Symmetry may be
   realized in several ways depending on the SFF and classifier



Halpern & Pignataro      Expires March 24, 2015                 [Page 7]

Internet-Draft              SFC Architecture              September 2014


   functionality.  In some cases, "mirrored" classification (i.e., from
   Source to Destination and from Destination to Source) policy may be
   deployed, whereas in others shared state between classifiers may be
   used to ensure that symmetric flows are correctly identified, then
   steered along the required SFP.  At a high level, there are various
   common cases.  In a non-exhaustive way, there can be for example: a
   single classifier (or a small number of classifiers), in which case
   both incoming and outgoing flows could be recognized at the same
   classifier, so the synchronization would be feasible by internal
   mechanisms internal to the classifier.  Another case is the one of
   stateful classifiers where several classifiers may be clustered and
   share state.  Lastly, another case entails fully distributed
   classifiers, where synchronization needs to be provided through
   unspecified means.  This is a non-comprehensive list of common cases.

SB> Isn't an important class of classifiers one that learns state from the 
SB> egress packets/flows that is then used to provide state for the 
SB> return packets/flow

 2.3.  Service Function Paths

   A service function path (SFP) is a mechanism used by service chaining
   to express the result of applying more granular policy and
SB> Not sure "more granular" is needed.

   operational constraints to the abstract requirements of a service
SB> Not sure they are abstract requirements. When you apply them they
SB> are explicit.

   chain (SFC).  This architecture does not mandate the degree of
   specificity of the SFP.  Architecturally, within the same SFC-enabled
   domain, some SFPs may be fully specified, selecting exactly which SFF
   and which SF are to be visited by packets using that SFP, while other
   SFPs may be quite vague, deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC.  The
   specificity may be anywhere in between these extremes.

   As an example of such an intermediate specificity, there may be two
   SFPs associated with a given SFC, where one SFP says essentially that

SB> "says essentially is not a tight definition"

   any order of SFF and SF may be used as long as it is within data
   center 1, and where the second SFP allows the same latitude, but only
   within data center 2.

   Thus, the policies and logic of SFP selection or creation (depending
   upon the solution) produce what may be thought of as a constrained
   version of the original SFC.  Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs may be associated with a single SFC.

SB> So a SFP is a specific instance of a member of the set of available SFCs
SB> chosen as a result of applying policy at one or points along the SFC?


   The architecture allows for the same SF to be reachable through
   multiple SFFs.  In these cases, some SFPs may constrain which SFF is
   used to reach which SF, while some SFPs may leave that decision to
   the SFF itself.

   Further, the architecture allows for two or more SFs to be attached
   to the same SFF, and possibly connected via internal means allowing
   more effective communication.  In these cases, some solutions or


Halpern & Pignataro      Expires March 24, 2015                 [Page 8]

Internet-Draft              SFC Architecture              September 2014


   deployments may choose to use some form of internal inter-process or
   inter-VM messaging (communication behind the virtual switching
   element) that is optimized for such an environment.  This must be
   coordinated with the SFF so that the service function forwarding can
   properly perform its job.  Implementation details of such mechanisms
   are considered out of scope for this document, and can include a
   spectrum of methods: for example situations including all next-hops
   explicitly, others where a list of possible next-hops is provided and
   the selection is local, or cases with just an identifier, where all
   resolution is local.

   This architecture also allows the same SF to be part of multiple
   SFPs.

SB> Didn't you just say that?

 3.  Architecture Principles

   Service function chaining is predicated on several key architectural
   principles:

   1.  Topological independence: no changes to the underlay network
       forwarding topology - implicit, or explicit - are needed to
       deploy and invoke SFs or SFCs.

   2.  Plane separation: dynamic realization of SFPs is separated from
       packet handling operations (e.g., packet forwarding).

   3.  Classification: traffic that satisfies classification rules is
       forwarded according to a specific SFP.  For example,
       classification can be as simple as an explicit forwarding entry
       that forwards all traffic from one address into the SFP.
       Multiple classification points are possible within an SFC (i.e.
       forming a service graph) thus enabling changes/updates to the SFC
       by SFs.

       Classification can occur at varying degrees of granularity; for
       example, classification can use a 5-tuple, a transport port or
       set of ports, part of the packet payload, or it can come from
       external systems.

SB> I think that it can surely be as a result of higher level inspections?

 4.  Shared Metadata: Metadata/context data can be shared amongst SFs
       and classifiers, between SFs, and between external systems and
       SFs (e.g., orchestration).

       Generally speaking, metadata can be thought of as providing and
       sharing the result of classification 

SB> Just classifications, or classifications and processing operations?
SB> There is gray zone between a packet forwarding system and
SB> a distributed computing system and I am not sure where SFC fits, 
SB> nor am I sure that it makes sense to be specific at this stage.
SB> It is entirely possible that an SFC consumes the packet/flow
SB> rather than only having the capability to forward it between 
SB> in ingress and egress.

      (that occurs within the SFC-
       enabled domain, or external to it) along an SFP.  For example, an
       external repository might provide user/subscriber information to
       a service chain classifier.  This classifier could in turn impose



Halpern & Pignataro      Expires March 24, 2015                 [Page 9]

Internet-Draft              SFC Architecture              September 2014


       that information in the SFC encapsulation for delivery to the
       requisite SFs.  The SFs could in turn utilize the user/subscriber
       information for local policy decisions.

   5.  Service definition independence: The SFC architecture does not
       depend on the details of SFs themselves.  Additionally, no IANA
       registry is required to store the list of SFs.

SB> Yes, but you should be careful not to preclude it.

  6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

SB> Yes and no. What about the resource implications?

 7.  Heterogeneous control/policy points: The architecture allows SFs
       to use independent mechanisms (out of scope for this document) to
       populate and resolve local policy and (if needed) local
       classification criteria.

4.  Core SFC Architecture Components

   At a very high level, the logical architecture of an SFC-enabled
   Domain comprises:

SB> A list would be handy rather than just a figure, and you need
SB> some text to expand on the figure.

      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .  +--------------+                  +------------------~~~
      .  |   Service    |       SFC        |  Service  +---+   +---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +---+   +---+
      .  +--------------+                  +------------------~~~
      . SFC-enabled Domain
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

               Figure 2: Service Function Chain Architecture


SB> This is a very confusing diagram
SB> Surely the SFC encap is attached to the packet
SB> The fig seems to confuse the the packets and the path.

   The following sub-sections provide details on each logical component
   that form the basis of the SFC architecture.  A detailed overview of
   how each of these architectural components interact is provided in
   Figure 3:


SB> Well maybe, but it's not quite obvious what you are showing. 
SB> some overview text would help before you get into the detail.











Halpern & Pignataro      Expires March 24, 2015                [Page 10]

Internet-Draft              SFC Architecture              September 2014


         +----------------+                        +----------------+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------+
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

         Figure 3: Service Function Chain Architecture Components


SB> Coming back here after reading a bit more. Is the SFF to be considered the
SB> hub in a hub and spoke processing model for a set of SFs? If so it would
SB> be useful to say that up front. However that raises the issue of whether
SB> the single network attachment point that you show is desirable. A standard
SB> firewall design would not mix dirty and clean traffic, and yet that is
SB> what the above appears to show.


 4.1.  SFC Encapsulation

   The SFC encapsulation enables service function path selection.  It
   also enables the sharing of metadata/context information when such
   metadata exchange is required.

SB> I don't think that is quite right. Surely the 
SB> SFC encapsulation enables <some component> to select the next
SB> element of the path?
 
   The SFC encapsulation provides explicit information used to identify
SB> Provides or carries?
   the SFP.  However, the SFC encapsulation is not a transport
   encapsulation itself: it is not used to forward packets within the
   network fabric.  
SB> ... but surely it is a shim layer of some sort?

   If packets need to flow between separate physical
   platforms, the SFC encapsulation therefore relies on an outer network
   transport.  
SB> Surely it is network layer header specific to the inter SFC
SB> transport?

   Transit forwarders -- such as router and switches --
   simply forward SFC encapsulated packets based on the outer (non-SFC)
   encapsulation.

SB> d/simply/



Halpern & Pignataro      Expires March 24, 2015                [Page 11]

Internet-Draft              SFC Architecture              September 2014


   One of the key architecture principles of SFC is that the SFC
   encapsulation remain transport independent.  As such any network
   transport protocol may be used to carry the SFC encapsulated traffic.

SB> Not sure I like "network transport protocol" since this is going
SB> to be confused with transport layer and I am not sure whether
SB> you would require a transport layer, indeed the SFE might will
SB> be considered a transport layer in the classical sense.

 4.2.  Service Function (SF)

   The concept of an SF evolves; rather than being viewed as a bump in
   the wire, an SF becomes a resource within a specified administrative
   domain that is available for consumption as part of a composite
   service.  SFs send/receive data to/from one or more SFFs.  SFC-aware
   SFs receive this traffic with the SFC encapsulation.

SB> I do not understand the above para.

   While the SFC architecture defines a new encapsulation - the SFC
   encapsulation - 

SB> no it does not - it is not defined in this memo. You introduce
SB> the concept and define some of the characteristics of it.


   and several logical components for the construction
   of SFCs, existing SF implementations may not have the capabilities to
   act upon or fully integrate with the new SFC encapsulation.  In order
   to provide a mechanism for such SFs to participate in the
   architecture, an SFC proxy function is defined (see Section 4.6).
   The SFC proxy acts as a gateway between the SFC encapsulation and
   SFC-unaware SFs.  The integration of SFC-unaware service functions is
   discussed in more detail in the SFC proxy section.

SB> The above is confusing. Do they participate in the architecture (this
SB> text)? I think that you mean that in order to employ SF instances
SB> that do not understand the SFE, a proxy as a gateway between the 
SB> the SFE aware domain and the non-SFE aware domain. Now if it is
SB> a gateway why is it not called a gateway rather than a proxy which
SB> is something that does something on behalf of something else.
SB> I would think that it might be a SFE proxy, but that is not quite
SB> right either.


 This architecture allows an SF to be part of multiple SFPs and SFCs.

SB> I am sure you said that before.

 4.3.  Service Function Forwarder (SFF)

   The SFF is responsible for forwarding packets and/or frames received
   from the network to one or more SFs associated with a given SFF using
   information conveyed in the SFC encapsulation.  Traffic from SFs
   eventually returns to the same SFF, which is responsible for
   injecting traffic back onto the network.

SB> It is not clear why it needs to be the exact same SFF

   The collection of SFFs and associated SFs creates a service plane
   overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
   Within this service plane, the SFF component connects different SFs
   that form a service function path.

SB> This conceptual model seems quite fundamental and this I 
SB> am surprised that it is not much earlier in the document.
SB> I have been wondering why the SFC system was not considered
SB> an overlay network of some sort, and was told by the authors
SB> that this was not possible. The above seems at odds with that
Sb> statement.

   SFFs maintain the requisite SFP forwarding information.  
SB> Maintain - as in being the control plane for this, or
SB> maintain as in store?
   SFP
   forwarding information is associated with a service path identifier
   that is used to uniquely identify an SFP.  The service forwarding
   state enables an SFF to identify which SFs of a given SFP should be
   applied, and in what order, as traffic flows through the associated
   SFP.  While there may appear to the SFF to be only one available way
   to deliver the given SF, there may also be multiple choices allowed
   by the constraints of the SFP.

   If there are multiple choices, the SFF needs to preserve the property
   that all packets of a given flow are handled the same way, since the



Halpern & Pignataro      Expires March 24, 2015                [Page 12]

Internet-Draft              SFC Architecture              September 2014


   SF may well be stateful.  Additionally, the SFF may preserve the
   handling of packets based on other properties on top of a flow, such
   as a subscriber, session, or application instance identification.

SB> I feel that the issue of handing higher order objects needs to have
SB> been introduced much earlier in the architecture.

   The SFF also has the information to allow it to forward packets to
   the next SFF after applying local service functions.  Again, while
   there may be only a single choice available, the architecture allows
   for multiple choices for the next SFF.  As with SFs, the solution
   needs to operate such that the behavior with regard to specific flows
   (see the Rendered Service Path) is stable.  The selection of
   available SFs and next SFFs may be interwoven when an SFF supports
   multiple distinct service functions and the same service function is
   available at multiple SFFs.  Solutions need to be clear about what is
   allowed in these cases.

   Even when the SFF supports and utilizes multiple choices, the
   decision as to whether to use flow-specific mechanisms or coarser
   grained means to ensure that the behavior of specific flows is stable
   is a matter for specific solutions and specific implementations.

   The SFF component has the following primary responsibilities:

   1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and if needed forwarded to
       another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path.  Related to this forwarding responsibility,
       an SFF should be able to interact with metadata.

   2.  Terminating SFPs : An SFC is completely executed when traffic has
       traversed all required SFs in a chain.  When traffic arrives at
       the SFF after the last SF has finished processing it, the final
       SFF knows from the service forwarding state that the SFC is
       complete.  The SFF removes the SFC encapsulation and delivers the
       packet back to the network for forwarding.

   3.  Maintaining flow state: In some cases, the SFF may be stateful.
       It creates flows and stores flow-centric information.  This state
       information may be used for a range of SFP-related tasks such as
       ensuring consistent treatment of all packets in a given flow,
       ensuring symmetry or for state-aware SFC Proxy functionality (see
       Section 4.8).





Halpern & Pignataro      Expires March 24, 2015                [Page 13]

Internet-Draft              SFC Architecture              September 2014


4.3.1.  Transport Derived SFF

   Service function forwarding, as described above, directly depends
   upon the use of the service path information contained in the SFC
   encapsulation.  However, existing implementations may not be able to
   act on the SFC encapsulation.  These platforms may opt to use
   existing transport information if it can be arranged to provide
   explicit service path information.

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

SB> The title does not seem quite right. What I think you have
SB> is a system in which you map an SFC onto an explicit path
SB> of some sort in the lower layers (I was going to say network layer
SB> but I am not sure if that is what you intend). So I am not sure 
SB> derived is the correct word. It would be closer to say "emulation
SB> of SFF using explicit network paths. Noting that these paths may
SB> be encoded in the packet or encoded in the FIB.

 4.4.  SFC-Enabled Domain

   Specific features may need to be enforced at the boundaries of an
   SFC-enabled domain, for example to avoid leaking SFC information.
   Using the term node to refer generically to an entity that is
   performing a set of functions, in this context, an SFC Boundary Node
   denotes a node that connects one SFC-enabled domain to a node either
   located in another SFC-enabled domain or in a domain that is SFC-
   unaware.

   An SFC Boundary node can act as egress or ingress.  
SB> do you mean or or and/or i.e. can it be both at the same time.
   An SFC Egress
   Node denotes a SFC Boundary Node that handles traffic leaving the
   SFC-enabled domain the Egress Node belongs to.  Such a node is
   required to remove any information specific to the SFC Domain,
   typically the SFC Encapsulation.  An SFC Ingress Node denotes an SFC
   Boundary Node that handles traffic entering the SFC-enabled domain.
   In most solutions and deployments this will need to include a
   classifier, and will be responsible for adding the SFC encapsulation
   to the packet.

SB> Logically doesn't it always include the classifier, where the set of
SB> classifier types includes the null classifier? The only exception
SB> I suppose is when you are receiving traffic from a trusted
SB> SFC aware peer, but it might be better to be more explicit
SB> about the normal case and then introduce the exception

 4.5.  Network Overlay and Network Components

   Underneath the SFF there are components responsible for performing
   the transport (overlay) forwarding.  They do not consult the SFC
   encapsulation or inner payload for performing this forwarding.  They
   only consult the outer-transport encapsulation for the transport
   (overlay) forwarding.

SB> This layer model needs to be brought out much earlier instead of 
SB> having the reader deduce it up to this point.
SB> Indeed the layering model makes for a better way of explaining
SB> the operation of the system.

 4.6.  SFC Proxy

   In order for the SFC architecture to support SFC-unaware SFs (e.g.,
   legacy service functions) a logical SFC proxy function may be used.

SB> Is it a logical proxy or a real proxy, and why only may, surely
SB> it *is* used.


Halpern & Pignataro      Expires March 24, 2015                [Page 14]

Internet-Draft              SFC Architecture              September 2014


   This function sits between an SFF and one or more SFs to which the
   SFF is directing traffic.

   The proxy accepts packets from the SFF on behalf of the SF.  It
   removes the SFC encapsulation, and then uses a local attachment
   circuit to deliver packets to SFC unaware SFs.  It also receives
   packets back from the SF, reapplies the SFC encapsulation, and
   returns them to the SFF for processing along the service function
   path.

   Thus, from the point of view of the SFF, the SFC proxy appears to be
   part of an SFC aware SF.

   Communication details between the SFF and the SFC Proxy are the same
   as those between the SFF and an SFC aware SF.  The details of that
   are not part of this architecture.  The details of the communication
   methods over the local attachment circuit between the SFC proxy and
   the SFC-unaware SF are dependent upon the specific behaviors and
   capabilities of that SFC-unaware SF, and thus are also out of scope
   for this architecture.

   Specifically, for traffic received from the SFF intended for the SF
   the proxy is representing, the SFC proxy:

   o  Removes the SFC encapsulation from SFC encapsulated packets.

   o  Identifies the required SF to be applied based on available
      information including that carried in the SFC encapsulation.

   o  Selects the appropriate outbound local attachment circuit through
      which the next SF for this SFP is reachable.  This is derived from
      the identification of the SF carried in the SFC encapsulation, and
      may include local techniques.  Examples of a local attachment
      circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3,
      GRE, VXLAN.

   o  Forwards the original payload via the selected local attachment
      circuit to the appropriate SF.

SB> I think you have missed the storage of the SFE and I am not
SB> sure how this gets back to the specific packet. This causes me
SB> wonder if it is the original payload or not since it may by
SB> now be SFC modified. It is surely the SFE payload that gets 
SB> passed up, and to re-attach the correct SFE afterwards, might
SB> you not have to modify it?


 When traffic is returned from the SF:

   o  Applies the required SFC encapsulation.  The determination of the
      encapsulation details may be inferred by the local attachment
      circuit through which the packet and/or frame was received, or via
      packet classification, or other local policy.  In some cases,
      packet ordering or modification by the SF may necessitate
      additional classification in order to re-apply the correct SFC
      encapsulation.

SB> This function is surely split between the outbound and inbound
SB> proxy functions.

 Halpern & Pignataro      Expires March 24, 2015                [Page 15]

Internet-Draft              SFC Architecture              September 2014


   o  Delivers the packet with the SFC Encapsulation to the SFF, as
      would happen with packets returned from an SFC-aware SF.

   Alternatively, a service provider may decide to exclude legacy
   service functions from an SFC domain.

SB> This might have been better expressed earlier in the text my noting
SB> that the proxy was optional, making the afterthought above redundant.


 4.7.  Classification

   Traffic from the network that satisfies classification criteria is
   directed into an SFP and forwarded to the requisite service
   function(s).  Classification is handled by a service classification
   function; initial classification occurs at the ingress to the SFC
   domain.  The granularity of the initial classification is determined
   by the capabilities of the classifier and the requirements of the SFC
   policy.  For instance, classification might be relatively coarse: all
   packets from this port are subject to SFC policy X and directed into
   SFP A, or quite granular: all packets matching this 5-tuple are
   subject to SFC policy Y and directed into SFP B.

   As a consequence of the classification decision, the appropriate SFC
   encapsulation is imposed on the data, and a suitable SFP is selected
   or created.  Classification results in attaching the traffic to a
   specific SFP.

SB> How about:

SFC domain ingress traffic is first processed by a classifier which
either rejects the traffic or prepares it for processing by the required
SFs. The classifier applies policy to the packet to determine the required
SFC, and then to map that to the required SFP. The classifier applies
the corresponding SFE and if necessary the appropriate network layer
encapsulation and forwards the packet to the first SFF on the chain.



 4.8.  Re-Classification and Branching

   The SFC architecture supports re-classification (or non-initial
   classification) as well.  

SB> This is interesting, surely the packet only enters the
SB> SFC when it has been been classified (including the null classification)
SB> and has the SFE applied?

   As packets traverse an SFP, re-
   classification may occur - typically performed by a classification
   function co-resident with a service function.  
SB> Architecturally you may always want to include a reclassifier
SB> on exit (and may be entry) to every SF. It may be null, but it's
SB> probably better that it is there.

   Reclassification may
   result in the selection of a new SFP, an update of the associated
   metadata, or both.  This is referred to as "branching".

   For example, an initial classification results in the selection of
   SFP A: DPI_1 --> SLB_8.  However, when the DPI service function is
   executed, attack traffic is detected at the application layer.  DPI_1
   re-classifies the traffic as attack and alters the service path to
   SFP B, to include a firewall for policy enforcement: dropping the
   traffic: DPI_1 --> FW_4.  Subsequent to FW_4, surviving traffic would
   be returned to the original SFF.  In this simple example, the DPI
   service function re-classifies the traffic based on local application
   layer classification capabilities (that were not available during the
   initial classification step).

   When traffic arrives after being steered through an SFC-unaware SF,
   the SFC Proxy must perform re-classification of traffic to determine
   the SFP.  The SFC Proxy is concerned with re-attaching information

SB> This should have been part of the earlier proxy functional definition.
SB> Maybe if you moved this up earlier before proxy it would all be clearer.


 Halpern & Pignataro      Expires March 24, 2015                [Page 16]

Internet-Draft              SFC Architecture              September 2014


   for SFC-unaware SFs, and a stateful SFC Proxy simplifies such
   classification to a flow lookup.

4.9.  Shared Metadata

SB> Isn't metadata always shared? If no one else sees it, there is
SB> no point in generating it.

   Sharing metadata allows the network to provide network-derived
   information to the SFs, SF-to-SF information exchange and the sharing
   of service-derived information to the network.  Some SFCs may not
   require metadata exchange.  SFC infrastructure enables the exchange
   of this shared data along the SFP.  The shared metadata serves
   several possible roles within the SFC architecture:

   o  Allows elements that typically operate as ships in the night to
      exchange information.

SB> That is a sort of tautology. If they share MD they are not true
SB> SITN. Surely this is about in band and outband state sharing.

   o  Encodes information about the network and/or data for post-
      service forwarding.

   o  Creates an identifier used for policy binding by SFs.

   Context information can be derived in several ways:

SB> This list does not scan properly from the intro fragment above.

   o  External sources

   o  Network node classification

   o  Service function classification



 5.  Additional Architectural Concepts

   There are a number of issues which solutions need to address, and
   which the architecture informs but does not determine.  This section
   lays out some of those concepts.

5.1.  The Role of Policy

   Much of the behavior of service chains is driven by operator and per-
   customer policy.  This architecture is structured to isolate the
   policy interactions from the data plane and control logic.

   Specifically, it is assumed that the service chaining control plane
   creates the service paths.  The service chaining data plane is used
   to deliver the classified packets along the service chains to the
   intended service functions.

   Policy, in contrast, interacts with the system in other places.
   Policies and policy engines may monitor service functions to decide
   if additional (or fewer) instances of services are needed.  

SB> This seems to be conflating policy and resource management, and
SB> I am not sure this is wise. The resource manager should consult
SB> policy, but the problems are distinct.

   When



Halpern & Pignataro      Expires March 24, 2015                [Page 17]

Internet-Draft              SFC Architecture              September 2014


   applicable, those decisions may in turn result in interactions that
   direct the control logic to change the SFP placement or packet
   classification rules.

   Similarly, operator service policy, often managed by operational or
   business support systems (OSS or BSS), will frequently determine what
   service functions are available.  Operator service policies also
   determine which sequences of functions are valid and are to be used
   or made available.

   The offering of service chains to customers, and the selection of
   which service chain a customer wishes to use, are driven by a
   combination of operator and customer policies using appropriate
   portals in conjunction with the OSS and BSS tools.  These selections
   then drive the service chaining control logic, which in turn
   establishes the appropriate packet classification rules.


SB> Didn't you just say the above. In any case it might be better in
SB> the form of an intro rather than a conclusion.

 5.2.  SFC Control Plane

   This is part of the overall architecture but outside the scope of
   this document.

SB> The specifics of the architecture of the CP may be out of scope
SB> but I cannot see how it can be out of scope of the main
SB> architecture, unless you want to reclassify this as the SFC packet
SB> plane architecture.
SB>
SB> As I read more of this text I am unclear why this in not promoted
SB> to the main body of the text.


    The SFC control plane is responsible for constructing SFPs,
   translating SFCs to forwarding paths and propagating path information
   to participating nodes to achieve requisite forwarding behavior to
   construct the service overlay.  For instance, an SFC construction may
   be static; selecting exactly which SFFs and which SFs from those SFFs
   are to be used, or it may be dynamic, allowing the network to perform
   some or all of the choices of SFF or SF to use to deliver the
   selected service chain within the constraints represented by the
   service path.

   In the SFC architecture, SFs are resources; 

SB> SFs or SF instances? I don't think it becomes an accountable 
SB> resource until it is instantiated.

   the control plane manages
   and communicates their capabilities, availability and location in
   fashions suitable for the transport and SFC operations in use.  The
   control plane is also responsible for the creation of the context
   (see below).  The control plane may be distributed (using new or
   existing control plane protocols), or be centralized, or a
   combination of the two.

   The SFC control plane provides the following functionality:

   1.  An SFC-enabled domain wide view of all available service function
       resources as well as the network locators through which they are
       reachable.

   2.  Uses SFC policy to construct service function chains, and
       associated service function paths.



Halpern & Pignataro      Expires March 24, 2015                [Page 18]

Internet-Draft              SFC Architecture              September 2014


   3.  Selection of specific SFs for a requested SFC, either statically
       (using specific SFs) or dynamically (using service explicit SFs
       at the time of delivering traffic to them).

   4.  Provides requisite SFC data plane information to the SFC
       architecture components, most notably the SFF.

   5.  Allocation of metadata associated with a given SFP and
       propagation of the metadata to relevant SFs and/or SFC
       encapsulation-proxies or their respective policy planes.

SB> I am not sure what it means to allocate metadata. Do you mean
SB> MD storage, or MD packet space?

 5.3.  Resource Control

   The SFC system may be responsible for managing all resources
   necessary for the SFC components to function.  This includes network
   constraints used to plan and choose network path(s) between service
   function forwarders, network communication paths between service
   function forwarders and their attached service functions,
   characteristics of the nodes themselves such as memory, number of
   virtual interfaces, routes, and instantiation, configuration, and
   deletion of SFs.

   The SFC system will also be required to reflect policy decisions
   about resource control, as expressed by other components in the
   system.

   While all of these aspects are part of the overall system, they are
   beyond the scope of this architecture.


SB> The relationship between the RC/RM and the CP seems unclear.

 5.4.  Infinite Loop Detection and Avoidance

   This SFC architecture is predicated on topological independence from
   the underlying forwarding topology.  Consequently, a service topology
   is created by Service Function Paths or by the local decisions of the
   Service Function Forwarders based on the constraints expressed in the
   SFP.  

SB> The concept of service topologies and overlays would be useful much earlier in the text.

   Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once.  The Service
   Chaining solution needs to permit these limited and policy-compliant
   loops.  At the same time, the solutions must ensure that indefinite
   and unbounded loops cannot be formed, as such would consume unbounded
   resources without delivering any value.

   In other words, this architecture prevents infinite Service Function
   Loops, even when Service Functions may be invoked multiple times in
   the same SFP.

SB> You say it does, but I don't see how it does it. Do you anticipate
SB> it happening in the CP or the DP or both?
SB> 



 Halpern & Pignataro      Expires March 24, 2015                [Page 19]

Internet-Draft              SFC Architecture              September 2014


5.5.  Load Balancing Considerations

   Supporting function elasticity and high-availability should not
   overly complicate SFC or lead to unnecessary scalability problems.

   In the simplest case, where there is only a single function in the
   SFP (the next hop is either the destination address of the flow or
   the appropriate next hop to that destination), one could argue that
   there may be no need for SFC.

SB> It is unusual to lead with the dejenerate case (i.e. no SFC)

   In the cases where the classifier is separate from the single
   function or a function at the terminal address may need sub-prefix or
   per-subscriber metadata, a single SFP exists (the metadata changes
   but the SFP does not), regardless of the number of potential terminal
   addresses for the flow.  This is the case of the simple load
   balancer.  See Figure 4.

                            +---+    +---++--->web server
                  source+-->|sff|+-->|sf1|+--->web server
                            +---+    +---++--->web server

                      Figure 4: Simple Load Balancing

   By extrapolation, in the case where intermediary functions within a
   chain had similar "elastic" behaviors, we do not need separate chains
   to account for this behavior - as long as the traffic coalesces to a
   common next-hop after the point of elasticity.

   In Figure 5, we have a chain of five service functions between the
   traffic source and its destination.

                +---+ +---+ +---+   +---+ +---+ +---+
                |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                +---+ +---+ +---+   +---+ +---+ +---+
                  |     |     |       |     |     |
                  +-----+-----+       +-----+-----+
                        |                   |
                        +                   +
             +---+    +---+     +---+     +---+    +---+
   source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination
             +---+    +---+     +---+     +---+    +---+
               +                  +                  +
               |                  |                  |
             +---+              +---+              +---+
             |sf1|              |sf3|              |sf5|
             +---+              +---+              +---+

                         Figure 5: Load Balancing



Halpern & Pignataro      Expires March 24, 2015                [Page 20]

Internet-Draft              SFC Architecture              September 2014


   This would be represented as one service function path:
   sf1->sf2->sf3->sf4->sf5.  The SFF is a logical element, which may be
   made up of one or multiple components.  In this architecture, the SFF
   may handle load distribution based on policy.

   It can also be seen in the above that the same service function may
   be reachable through multiple SFFs, as discussed earlier.  The
   selection of which SFF to use to reach SF3 may be made by the control
   logic in defining the SFP, or may be left to the SFFs themselves,
   depending upon policy, solution, and deployment constraints.  In the
   latter case, it needs to be assured that exactly one SFF takes
   responsibility to steer traffic through SF3.


SB> Shouldn't the architecture lead with the general case and note
SB> that any function can be replaced with the null function.

 5.6.  MTU and Fragmentation Considerations

   This architecture prescribes additional information being added to
   packets to identify service function paths and often to represent
   metadata.  It also envisions adding transport information to carry
   packets along service function paths, at least between service
   function forwarders.  This added information increases the size of
   the packet to be carried by service chaining.  Such additions could
   potentially increase the packet size beyond the MTU supported on some
   or all of the media used in the service chaining domain.

   Such packet size increases can thus cause operational MTU problems.
   Requiring fragmentation and reassembly in an SFF would be a major
   processing increase, and might be impossible with some transports.

SB> Sure but the SFE is teh network layer of the SFC plane and could
SB> do this.

   Expecting service functions to deal with packets fragmented by the
   SFC function might be onerous even when such fragmentation was
   possible.  Thus, at the very least, solutions need to pay attention
   to the size cost of their approach.  There may be alternative or
   additional means available, although any solution needs to consider
   the tradeoffs.

   These considerations apply to any generic architecture that increases
   the header size.  There are also more specific MTU considerations:
   Effects on Path MTU Discovery (PMTUD) as well as deployment
   considerations.  Deployments within a single administrative control
   or even a single Data Center complex can afford more flexibility in
   dealing with larger packets, and deploying existing mitigations that
   decrease the likelihood of fragmentation or discard.

5.7.  SFC OAM

   Operations, Administration, and Maintenance (OAM) tools are an
   integral part of the architecture.  These serve various purposes,
   including fault detection and isolation, and performance management.
   For example, there are many advantages of SFP liveness detection,



Halpern & Pignataro      Expires March 24, 2015                [Page 21]

Internet-Draft              SFC Architecture              September 2014


   including status reporting, support for resiliency operations and
   policies, and an enhanced ability to balance load.

   Service Function Paths create a services topology, and OAM performs
   various functions within this service layer.  Furthermore, SFC OAM
   follows the same architectural principles of SFC in general.  For
   example, topological independence (including the ability to run OAM
   over various overlay technologies) and classification-based policy.

   We can subdivide the SFC OAM architecture in two parts:

   o  In-band: OAM packets follow the same path and share fate with user
      packets, within the service topology.  For this, they also follow
      the architectural principle of consistent policy identifiers, and
      use the same path IDs as the service chain data packets.  Load
      balancing and SFC encapsulation with packet forwarding are
      particularly important here.

   o  Out-of-band: reporting beyond the actual data plane.  An
      additional layer beyond the data-plane OAM allows for additional
      alerting and measurements.

   This architecture prescribes end-to-end SFP OAM functions, which
   implies SFF understanding of whether an in-band packet is an OAM or
   user packet.  However, service function validation is outside of the
   scope of this architecture, and application-level OAM is not what
   this architecture prescribes.

   Some of the detailed functions performed by SFC OAM include fault
   detection and isolation in a Service Function Path or a Service
   Function, verification that connectivity using SFPs is both effective
   and directing packets to the intended service functions, service path
   tracing, diagnostic and fault isolation, alarm reporting, performance
   measurement, locking and testing of service functions, validation
   with the control plane (see Section 5.2), and also allow for vendor-
   specific as well as experimental functions.  SFC should leverage, and
   if needed extend relevant existing OAM mechanisms.

5.8.  Resilience and Redundancy

   As a practical operational requirement, any service chaining solution
   needs to be able to respond effectively, and usually very quickly, to
   failure conditions.  These may be failures of connectivity in the
   network between SFFs, failures of SFFs, or failures of SFs.  Per-SF
   state, as for example stateful-firewall state, is the responsibility
   of the SF, and not addressed by this architecture.





Halpern & Pignataro      Expires March 24, 2015                [Page 22]

Internet-Draft              SFC Architecture              September 2014


   Multiple techniques are available to address this issue.  Solutions
   can describe both what they require and what they allow to address
   failure.  Solutions can make use of flexible specificity of service
   function paths, if the SFF can be given enough information in a
   timely fashion to do this.  Solutions can also make use of MAC or IP
   level redundancy mechanisms such as VRRP.  Also, particularly for SF
   failures, load balancers co-located with the SFF or as part of the
   service function delivery mechanism can provide such robustness.

   Similarly, operational requirements imply resilience in the face of
   load changes.  While mechanisms for managing (e.g., monitoring,
   instantiating, loading images, providing configuration to service
   function chaining control, deleting, etc.) virtual machines are out
   of scope for this architecture, solutions can and are aided by
   describing how they can make use of scaling mechanisms.


SB> Given that we are introducing a new network layer construct including
SB> something that is or is a very close cousin to a network layer, surely
SB> we are missing an opportunity by not including this on day one.


 6.  Security Considerations

   This document does not define a new protocol and therefore creates no
   new security issues.

   Security considerations apply to the realization of this
   architecture.  Such realization ought to provide means to protect the
   SFC-enabled domain and its borders against various forms of attacks,
   including DDoS attacks.  Further, SFC OAM Functions need to not
   negatively affect the security considerations of an SFC-enabled
   domain.  Additionally, all entities (software or hardware)
   interacting with the service chaining mechanisms need to provide
   means of security against malformed, poorly configured (deliberate or
   not) protocol constructs and loops.  These considerations are largely
   the same as those in any network, particularly an overlay network.


SB> I just don't buy this for a security analysis. The Architecture needs
SB> direct the compenent designers to look at security issues associated
SB> with the new components and functionality being introduced.
SB> For example the SFE will have special considerations, so will the 
SB> the path changes that you talk about earlier. Then there is resource
SB> conflicts and their impact as a security problem. Then there is the 
SB> issue of privacy. Really each component of the ach needs to be looked
SB> at from a security PoV and guidance provided to the component designer.

- Stewart
 


-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------060307070504000100010902-- From nobody Wed Nov 12 16:45:18 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFF11A0151 for ; Wed, 12 Nov 2014 16:45:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGdRiIQwwnCv for ; Wed, 12 Nov 2014 16:44:55 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07A341A00A6 for ; Wed, 12 Nov 2014 16:44:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=145670; q=dns/txt; s=iport; t=1415839495; x=1417049095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=j3p466T8XdiqEj1Pbpad/qwiZ3iXk9MeM0vfUP+yVcI=; b=ETT7ceO7N7fpKv1YqlxI7n23r6Pfe42A+zVArdPSk24nOb8yvm2QjUY3 n+xPhvXKKmZ6b0Cc2b5pPDoLBKwBBIDjDakQHUd4LrIuVkeV61XA1Pi55 jFfTGFFqC/egaQEENgPvm1FvoLB2M1JDU7FKg3P3mWh1j3YzR/3qNKehH 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0FAFr+Y1StJA2E/2dsb2JhbABRAQMGgmsjVE4LBMw+h08CgR0WAQEBAQF9hAMBAQQODAEMPgILAgUQAgEIEhsLAQYHMhQDDgIEDgMCG4gmAQzQEwEBAQEBAQEBAQEBAQEBAQEBAQEBAReKeIU4AgYBAwcBBwY+BQcKgyOBHgWEb4FNhRGESYIkhxuCBIJYgTSHBIZ5gyyECoN8QSwBgQUBAQcXBhyBAwEBAQ X-IronPort-AV: E=Sophos; i="5.07,372,1413244800"; d="scan'208,217"; a="96091326" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-3.cisco.com with ESMTP; 13 Nov 2014 00:44:50 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sAD0in3a009667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 00:44:49 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 12 Nov 2014 18:44:49 -0600 From: "Carlos Pignataro (cpignata)" To: "Stewart Bryant (stbryant)" Thread-Topic: Some concerns about draft-ietf-sfc-architecture Thread-Index: AQHP/rWshxQ4ady89E6q0aScYPtEIpxeHTWA Date: Thu, 13 Nov 2014 00:44:48 +0000 Message-ID: <8360A86F-CD1D-42DD-98FA-E3124818A6DA@cisco.com> References: <5463BD7D.6000007@cisco.com> <5463C03D.3040202@cisco.com> In-Reply-To: <5463C03D.3040202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.236.26] Content-Type: multipart/alternative; boundary="_000_8360A86FCD1D42DD98FAE3124818A6DAciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/tk-73HxhqCz9K6qs4A907hXIXOY Cc: "draft-ietf-sfc-architecture@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Some concerns about draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Nov 2014 00:45:13 -0000 --_000_8360A86FCD1D42DD98FAE3124818A6DAciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stewart, Thanks for a very long set of comments right after WGLC finished :-) This is a top-post response only, to Ack your email and to make a couple hi= gh-level comments about it. Neither Joel nor I will have immediate time thi= s/early next week to respond to each individual comment (although we will a= s soon as we can), and we did not want your note to go unanswered. First, many of your comments are conclusions from trying to model the SFC a= rchitecture as a layer network, where in fact that is not what we are doing= or how things operate in this context. This architecture is not creating h= ard demarcations or modeling SFCs as a layer network. And second, much of what you call 'lack of precision' is a feature and not = a bug -- the realm of applications, deployments is rich in diversity and he= nce flexibility is a higher goal, while surgical doctoral precision would m= ake the architecture brittle and would effectively make real deployment cas= es not be covered or represented by the architecture. That said, you do make some points that are valid and we need to address --= we will be responding point-by-point soon. Thanks again for taking the time to review and sending these detailed comme= nts! Carlos. On Nov 12, 2014, at 10:17 AM, Stewart Bryant (stbryant) > wrote: Correcting an error in the to list. On 12/11/2014 20:05, Stewart Bryant wrote: SB> This document lacks the precision and that I would have hoped for SB> in an architecture. I understand that the this was deliberate SB> in order to allow implementation flexibility, but I don't SB> buy that. SB> SB> What we have here is a type of layered network, and whilst SB> verbal discussions have refuted that, you have many references SB> to overlay topologies. SB> SB> This would be better understood if you described it as a layered SB> system, if you only used generalized the components with fully SB> functionality, and then explained which could be NULL. In the SB> case of sub-functional components they should not be part of the SB> core architecture, but the techniques used to create a full function SB> component by assistance (the proxy) described outside the main SB> architecture. SB> SB> I understand that in part the approach used here was to allow SB> a mixture of implementation styles - the concept of explicit SB> and implicit SFE - with network layer constructs supplying the SB> implicit SFE. However it would be better to think of the use SB> of implicit SFE as a type of network recursion in which the SB> the encapsulator (which I think is distinct from the classifier) SB> chooses how to encode the SFP on the packet. SB> SB> I have a nagging concern about the way that the terms packets is SB> used in this text. The way it is used one would expect that there SB> is a one for one mapping between input and output packets, but that SB> is surely not the case. A trivial point is the case where an SF SB> needs to defragment. Although at the physical layer the units are SB> packets, there may surely be higher order constructs traveling SB> between SFs. Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-02 Abstract This document describes an architecture for the specification, sb> an arch or THE arch? 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. This document does not propose solutions, protocols, or extensions to existing protocols. 1. Introduction This document describes an architecture used for the creation and sb> and or THE ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components. An overview of the issues associated with the deployment of end-to- end service function chains, abstract sets of service functions and their ordering constraints that create a composite service and the subsequent "steering" of traffic flows through said service functions, is described in [I-D.ietf-sfc-problem-statement]. This architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity. Service function chains enable composite services that are constructed from one or more service functions. 1.1. Scope This document defines a framework to realize Service Function Chaining (SFC) with minimum requirements on the physical topology of the network. The proposed solution relies on initial packet classification. Packets initially classified for handling by a set of Service Functions (SFs) in the SFC-enabled domain are then forwarded to that set of SFs for processing. SB> Are you allowed to reclassify, or do staged classification? SB> Yes you are - you say so later - but that is not implied SB> by the above. This document does not make any assumption on the deployment context. The proposed framework covers both fixed and mobile networks. SB> Given that you make no deployment context assumption, surely SB> the followup mobile/fixed specific is not relevant. The architecture described herein is assumed to be applicable to a single network administrative domain. While it is possible for the architectural principles and components to be applied to inter-domain SFCs, these are left for future study. 1.2. Assumptions The following assumptions are made: o Not all SFs can be characterized with a standard definition in terms of technical description, detailed specification, configuration, etc. o There is no global or standard list of SFs enabled in a given administrative domain. The set of SFs varies as a function of the service to be provided and according to the networking environment. o There is no global or standard SF chaining logic. The ordered set of SFs that needs to be enabled to deliver a given service is specific to each administrative entity. SB> Surely it is application specific even within an admistration? o The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain. SB? see previous Halpern & Pignataro Expires March 24, 2015 [Page 3] Internet-Draft SFC Architecture September 2014 o Several SF chaining policies can be simultaneously applied within an administrative domain to meet various business requirements. o No assumption is made on how FIBs and RIBs of involved nodes are populated. o How to bind traffic to a given SF chain is policy-based. 1.3. Definition of Terms Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a firewall. Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted. SB> I think that you probably need an explicit definition of service. SB> I find the text in the definition of NS self referential which is SB> not helpful. Classification: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. SB> Isn't it really SB> Locally instantiated matching of traffic flows against policy for SB> subsequent application of the required set of network service functions= . SB> The policy may be ustomer/network/service specific. Classifier: An element that performs Classification. SB> A network element perhaps? Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints that must SB> Isn't the SFC also ordered? be applied to packets and/or frames selected as a result of classification. SB> Packets, or higher order constructs like flows? You cannot SB> do some of the SFs packet by packet The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. SB> See my earlier not about the apparently more restricted definition SB> I think that you need to make the generalization clearer earlier. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a Service Function can be realized as a virtual element or be embedded in a physical network element. One or multiple Service Functions SB> multiple or more? can be embedded in the same network element. Multiple Halpern & Pignataro Expires March 24, 2015 [Page 4] Internet-Draft SFC Architecture September 2014 occurrences of the Service Function can exist in the same administrative domain. One or more Service Functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract Service Functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), LI (Lawful Intercept), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer. SB> Not sure those are abstract SFs, surely they are explicit? An SF may be SFC encapsulation aware, that is it receives and acts on information in the SFC encapsulation, or unaware, in which case data forwarded to the SF does not contain the SFC encapsulation. Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, a service function forwarder is responsible for delivering traffic to a classifier when needed and supported, mapping out traffic to another SFF (in the same or different type of overlay), and terminating the SFP. SB> In these days of NFV it may not be received from the network. SB> Surely the traffic is native until it gets to a classifier. The SB> way you have it here it looks like the first element is the SFF SB> but I am not sure that is the case. SB> Perhaps: A service function forwarder is responsible for forwarding SB> traffic between service functions. Metadata: provides the ability to exchange context information between classifiers and SFs and among SFs. SB> I think the first noun is missing in the above, but in any case SB> I think a more complete definition is needed. Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network. SB> You have not defined control components. SB> I think "notion" is a redundant term. SB> I am somewhat confused by your definition. SB> Is this really about the mapping of packets between an arbitrary SB> member of an SF to a specific instance of the SF? SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC Encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries data plane context information, also referred to as metadata. SB> Surely the "SFC E is used to attach the information needed to SB> direct the packet through the ordered set of SFs, together with SB> associated metadata. An additional network layer encapsulation is need= ed SB> to carry the packet over the physical network. Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to Halpern & Pignataro Expires March 24, 2015 [Page 5] Internet-Draft SFC Architecture September 2014 identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. SB> Not sure of the wisdom of including a definition for the future, since SB> when you use it you may need to tune the definition. SFC-enabled Domain: A network or region of a network that implements SFC. An SFC-enabled Domain is limited to a single network administrative domain. SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements. SB> Not sure considering then as logical is quite right. It depends SB> on the mapping of the operation to the physical. I could see SB> cases where they are physical. Surely the point is that they SB> may be co-located with another network function such as a router SB> an operating system component such as a hypervisor. 2. Architectural Concepts The following sections describe the foundational concepts of service function chaining and the SFC architecture. Service Function Chaining enables the creation of composite (network) services that consist of an ordered set of Service Functions (SF) that must be applied to packets and/or frames selected as a result of classification. Each SF is referenced using an identifier that is unique within an SF-enabled domain. No IANA registry is required to store the identity of SFs. SB> I am still worried about using packets. Obviously we operate on SB> pkts, but the operation may require the reconstuction of some SB> packet grouping typically some element of a flow before the operation SB> can be performed. A trivial example is defragmenting a packet group SB> but since we are dealing with abstract SFs we cannot specify the SB> the unit of operation. Service Function Chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. SB> The above is a bit late in the text. I think it needs to go earlier. 2.1. Service Function Chains In most networks, services are constructed as abstract sequences of SB> I don't think that are abstract in this context. SB> Are you talking about traditional (current physically instantiated SB> SFCs in the previous sentence? SFs that represent SFCs. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed. SB> Again I am not sure "abstrated view" is right here Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF. Such graph nodes (SFs) can be part of zero, one, or many SFCs. A given graph node (SF) can appear one time or multiple times in a given SFC. SB> Not sure that graphs is right, since you only show the case SB> of a linear chain. The construct you are going to use is SB> graph, but that is not what the figure shows. SFCs can start from the origination point of the service function graph (i.e.: node 1 in Figure 1), or from any subsequent node in the graph. SB> OK so are you trying to distinguish between physically and SB> SFC (the new technology) instantiated SFCS? SFs may therefore become branching nodes in the graph, with Halpern & Pignataro Expires March 24, 2015 [Page 6] Internet-Draft SFC Architecture September 2014 those SFs selecting edges that move traffic to one or more branches. An SFC can have more than one terminus. SB> Again that is not what your figure shows. ,-+-. ,---. ,---. ,---. / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) \ / \ / \ / \ / `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' Figure 1: Service Function Chain Graphs 2.2. Service Function Chain Symmetry SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic. SFCs may contain cycles; that is traffic may need to traverse one or more SFs within an SFC more than once. Solutions will need to ensure suitable disambiguation for such situations. The architectural allowance that is made for SFPs that delegate choice to the network for which SFs and/or SFFs a packet will visit creates potential issues here. A solution that allows such delegation needs to also describe how the solution ensures that those service chains that require service function chain symmetry can achieve that. Further, there are state tradeoffs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier Halpern & Pignataro Expires March 24, 2015 [Page 7] Internet-Draft SFC Architecture September 2014 functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example: a single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier. Another case is the one of stateful classifiers where several classifiers may be clustered and share state. Lastly, another case entails fully distributed classifiers, where synchronization needs to be provided through unspecified means. This is a non-comprehensive list of common cases. SB> Isn't an important class of classifiers one that learns state from the SB> egress packets/flows that is then used to provide state for the SB> return packets/flow 2.3. Service Function Paths A service function path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and SB> Not sure "more granular" is needed. operational constraints to the abstract requirements of a service SB> Not sure they are abstract requirements. When you apply them they SB> are explicit. chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes. As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP says essentially that SB> "says essentially is not a tight definition" any order of SFF and SF may be used as long as it is within data center 1, and where the second SFP allows the same latitude, but only within data center 2. Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs may be associated with a single SFC. SB> So a SFP is a specific instance of a member of the set of available SFC= s SB> chosen as a result of applying policy at one or points along the SFC? The architecture allows for the same SF to be reachable through multiple SFFs. In these cases, some SFPs may constrain which SFF is used to reach which SF, while some SFPs may leave that decision to the SFF itself. Further, the architecture allows for two or more SFs to be attached to the same SFF, and possibly connected via internal means allowing more effective communication. In these cases, some solutions or Halpern & Pignataro Expires March 24, 2015 [Page 8] Internet-Draft SFC Architecture September 2014 deployments may choose to use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for such an environment. This must be coordinated with the SFF so that the service function forwarding can properly perform its job. Implementation details of such mechanisms are considered out of scope for this document, and can include a spectrum of methods: for example situations including all next-hops explicitly, others where a list of possible next-hops is provided and the selection is local, or cases with just an identifier, where all resolution is local. This architecture also allows the same SF to be part of multiple SFPs. SB> Didn't you just say that? 3. Architecture Principles Service function chaining is predicated on several key architectural principles: 1. Topological independence: no changes to the underlay network forwarding topology - implicit, or explicit - are needed to deploy and invoke SFs or SFCs. 2. Plane separation: dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding). 3. Classification: traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e. forming a service graph) thus enabling changes/updates to the SFC by SFs. Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, or it can come from external systems. SB> I think that it can surely be as a result of higher level inspections? 4. Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration). Generally speaking, metadata can be thought of as providing and sharing the result of classification SB> Just classifications, or classifications and processing operations? SB> There is gray zone between a packet forwarding system and SB> a distributed computing system and I am not sure where SFC fits, SB> nor am I sure that it makes sense to be specific at this stage. SB> It is entirely possible that an SFC consumes the packet/flow SB> rather than only having the capability to forward it between SB> in ingress and egress. (that occurs within the SFC- enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose Halpern & Pignataro Expires March 24, 2015 [Page 9] Internet-Draft SFC Architecture September 2014 that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. 5. Service definition independence: The SFC architecture does not depend on the details of SFs themselves. Additionally, no IANA registry is required to store the list of SFs. SB> Yes, but you should be careful not to preclude it. 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. SB> Yes and no. What about the resource implications? 7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria. 4. Core SFC Architecture Components At a very high level, the logical architecture of an SFC-enabled Domain comprises: SB> A list would be handy rather than just a figure, and you need SB> some text to expand on the figure. o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: Service Function Chain Architecture SB> This is a very confusing diagram SB> Surely the SFC encap is attached to the packet SB> The fig seems to confuse the the packets and the path. The following sub-sections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how each of these architectural components interact is provided in Figure 3: SB> Well maybe, but it's not quite obvious what you are showing. SB> some overview text would help before you get into the detail. Halpern & Pignataro Expires March 24, 2015 [Page 10] Internet-Draft SFC Architecture September 2014 +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation | SFC | +---------+ +----------------+ Encapsulation +---------+ |SFC-Aware|-----------------+ \ +------------|SFC Proxy| | SF | ... ----------+ \ \ / +---------+ +---------+ \ \ \ / +-------+--------+ | SF Forwarder | | (SFF) | +-------+--------+ | SFC Encapsulation | ... SFC-enabled Domain ... | Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ __,-' `'''' Figure 3: Service Function Chain Architecture Components SB> Coming back here after reading a bit more. Is the SFF to be considered = the SB> hub in a hub and spoke processing model for a set of SFs? If so it woul= d SB> be useful to say that up front. However that raises the issue of whethe= r SB> the single network attachment point that you show is desirable. A stand= ard SB> firewall design would not mix dirty and clean traffic, and yet that is SB> what the above appears to show. 4.1. SFC Encapsulation The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required. SB> I don't think that is quite right. Surely the SB> SFC encapsulation enables to select the next SB> element of the path? The SFC encapsulation provides explicit information used to identify SB> Provides or carries? the SFP. However, the SFC encapsulation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. SB> ... but surely it is a shim layer of some sort? If packets need to flow between separate physical platforms, the SFC encapsulation therefore relies on an outer network transport. SB> Surely it is network layer header specific to the inter SFC SB> transport? Transit forwarders -- such as router and switches -- simply forward SFC encapsulated packets based on the outer (non-SFC) encapsulation. SB> d/simply/ Halpern & Pignataro Expires March 24, 2015 [Page 11] Internet-Draft SFC Architecture September 2014 One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such any network transport protocol may be used to carry the SFC encapsulated traffic. SB> Not sure I like "network transport protocol" since this is going SB> to be confused with transport layer and I am not sure whether SB> you would require a transport layer, indeed the SFE might will SB> be considered a transport layer in the classical sense. 4.2. Service Function (SF) The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation. SB> I do not understand the above para. While the SFC architecture defines a new encapsulation - the SFC encapsulation - SB> no it does not - it is not defined in this memo. You introduce SB> the concept and define some of the characteristics of it. and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6). The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section. SB> The above is confusing. Do they participate in the architecture (this SB> text)? I think that you mean that in order to employ SF instances SB> that do not understand the SFE, a proxy as a gateway between the SB> the SFE aware domain and the non-SFE aware domain. Now if it is SB> a gateway why is it not called a gateway rather than a proxy which SB> is something that does something on behalf of something else. SB> I would think that it might be a SFE proxy, but that is not quite SB> right either. This architecture allows an SF to be part of multiple SFPs and SFCs. SB> I am sure you said that before. 4.3. Service Function Forwarder (SFF) The SFF is responsible for forwarding packets and/or frames received from the network to one or more SFs associated with a given SFF using information conveyed in the SFC encapsulation. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. SB> It is not clear why it needs to be the exact same SFF The collection of SFFs and associated SFs creates a service plane overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this service plane, the SFF component connects different SFs that form a service function path. SB> This conceptual model seems quite fundamental and this I SB> am surprised that it is not much earlier in the document. SB> I have been wondering why the SFC system was not considered SB> an overlay network of some sort, and was told by the authors SB> that this was not possible. The above seems at odds with that Sb> statement. SFFs maintain the requisite SFP forwarding information. SB> Maintain - as in being the control plane for this, or SB> maintain as in store? SFP forwarding information is associated with a service path identifier that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed by the constraints of the SFP. If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the Halpern & Pignataro Expires March 24, 2015 [Page 12] Internet-Draft SFC Architecture September 2014 SF may well be stateful. Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification. SB> I feel that the issue of handing higher order objects needs to have SB> been introduced much earlier in the architecture. The SFF also has the information to allow it to forward packets to the next SFF after applying local service functions. Again, while there may be only a single choice available, the architecture allows for multiple choices for the next SFF. As with SFs, the solution needs to operate such that the behavior with regard to specific flows (see the Rendered Service Path) is stable. The selection of available SFs and next SFFs may be interwoven when an SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what is allowed in these cases. Even when the SFF supports and utilizes multiple choices, the decision as to whether to use flow-specific mechanisms or coarser grained means to ensure that the behavior of specific flows is stable is a matter for specific solutions and specific implementations. The SFF component has the following primary responsibilities: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and if needed forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata. 2. Terminating SFPs : An SFC is completely executed when traffic has traversed all required SFs in a chain. When traffic arrives at the SFF after the last SF has finished processing it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and delivers the packet back to the network for forwarding. 3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. This state information may be used for a range of SFP-related tasks such as ensuring consistent treatment of all packets in a given flow, ensuring symmetry or for state-aware SFC Proxy functionality (see Section 4.8). Halpern & Pignataro Expires March 24, 2015 [Page 13] Internet-Draft SFC Architecture September 2014 4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information if it can be arranged to provide explicit service path information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. SB> The title does not seem quite right. What I think you have SB> is a system in which you map an SFC onto an explicit path SB> of some sort in the lower layers (I was going to say network layer SB> but I am not sure if that is what you intend). So I am not sure SB> derived is the correct word. It would be closer to say "emulation SB> of SFF using explicit network paths. Noting that these paths may SB> be encoded in the packet or encoded in the FIB. 4.4. SFC-Enabled Domain Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information. Using the term node to refer generically to an entity that is performing a set of functions, in this context, an SFC Boundary Node denotes a node that connects one SFC-enabled domain to a node either located in another SFC-enabled domain or in a domain that is SFC- unaware. An SFC Boundary node can act as egress or ingress. SB> do you mean or or and/or i.e. can it be both at the same time. An SFC Egress Node denotes a SFC Boundary Node that handles traffic leaving the SFC-enabled domain the Egress Node belongs to. Such a node is required to remove any information specific to the SFC Domain, typically the SFC Encapsulation. An SFC Ingress Node denotes an SFC Boundary Node that handles traffic entering the SFC-enabled domain. In most solutions and deployments this will need to include a classifier, and will be responsible for adding the SFC encapsulation to the packet. SB> Logically doesn't it always include the classifier, where the set of SB> classifier types includes the null classifier? The only exception SB> I suppose is when you are receiving traffic from a trusted SB> SFC aware peer, but it might be better to be more explicit SB> about the normal case and then introduce the exception 4.5. Network Overlay and Network Components Underneath the SFF there are components responsible for performing the transport (overlay) forwarding. They do not consult the SFC encapsulation or inner payload for performing this forwarding. They only consult the outer-transport encapsulation for the transport (overlay) forwarding. SB> This layer model needs to be brought out much earlier instead of SB> having the reader deduce it up to this point. SB> Indeed the layering model makes for a better way of explaining SB> the operation of the system. 4.6. SFC Proxy In order for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions) a logical SFC proxy function may be used. SB> Is it a logical proxy or a real proxy, and why only may, surely SB> it *is* used. Halpern & Pignataro Expires March 24, 2015 [Page 14] Internet-Draft SFC Architecture September 2014 This function sits between an SFF and one or more SFs to which the SFF is directing traffic. The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path. Thus, from the point of view of the SFF, the SFC proxy appears to be part of an SFC aware SF. Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC aware SF. The details of that are not part of this architecture. The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF are dependent upon the specific behaviors and capabilities of that SFC-unaware SF, and thus are also out of scope for this architecture. Specifically, for traffic received from the SFF intended for the SF the proxy is representing, the SFC proxy: o Removes the SFC encapsulation from SFC encapsulated packets. o Identifies the required SF to be applied based on available information including that carried in the SFC encapsulation. o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, GRE, VXLAN. o Forwards the original payload via the selected local attachment circuit to the appropriate SF. SB> I think you have missed the storage of the SFE and I am not SB> sure how this gets back to the specific packet. This causes me SB> wonder if it is the original payload or not since it may by SB> now be SFC modified. It is surely the SFE payload that gets SB> passed up, and to re-attach the correct SFE afterwards, might SB> you not have to modify it? When traffic is returned from the SF: o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to re-apply the correct SFC encapsulation. SB> This function is surely split between the outbound and inbound SB> proxy functions. Halpern & Pignataro Expires March 24, 2015 [Page 15] Internet-Draft SFC Architecture September 2014 o Delivers the packet with the SFC Encapsulation to the SFF, as would happen with packets returned from an SFC-aware SF. Alternatively, a service provider may decide to exclude legacy service functions from an SFC domain. SB> This might have been better expressed earlier in the text my noting SB> that the proxy was optional, making the afterthought above redundant. 4.7. Classification Traffic from the network that satisfies classification criteria is directed into an SFP and forwarded to the requisite service function(s). Classification is handled by a service classification function; initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier and the requirements of the SFC policy. For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A, or quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B. As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created. Classification results in attaching the traffic to a specific SFP. SB> How about: SFC domain ingress traffic is first processed by a classifier which either rejects the traffic or prepares it for processing by the required SFs. The classifier applies policy to the packet to determine the required SFC, and then to map that to the required SFP. The classifier applies the corresponding SFE and if necessary the appropriate network layer encapsulation and forwards the packet to the first SFF on the chain. 4.8. Re-Classification and Branching The SFC architecture supports re-classification (or non-initial classification) as well. SB> This is interesting, surely the packet only enters the SB> SFC when it has been been classified (including the null classification= ) SB> and has the SFE applied? As packets traverse an SFP, re- classification may occur - typically performed by a classification function co-resident with a service function. SB> Architecturally you may always want to include a reclassifier SB> on exit (and may be entry) to every SF. It may be null, but it's SB> probably better that it is there. Reclassification may result in the selection of a new SFP, an update of the associated metadata, or both. This is referred to as "branching". For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. However, when the DPI service function is executed, attack traffic is detected at the application layer. DPI_1 re-classifies the traffic as attack and alters the service path to SFP B, to include a firewall for policy enforcement: dropping the traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would be returned to the original SFF. In this simple example, the DPI service function re-classifies the traffic based on local application layer classification capabilities (that were not available during the initial classification step). When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform re-classification of traffic to determine the SFP. The SFC Proxy is concerned with re-attaching information SB> This should have been part of the earlier proxy functional definition. SB> Maybe if you moved this up earlier before proxy it would all be clearer= . Halpern & Pignataro Expires March 24, 2015 [Page 16] Internet-Draft SFC Architecture September 2014 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such classification to a flow lookup. 4.9. Shared Metadata SB> Isn't metadata always shared? If no one else sees it, there is SB> no point in generating it. Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange and the sharing of service-derived information to the network. Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture: o Allows elements that typically operate as ships in the night to exchange information. SB> That is a sort of tautology. If they share MD they are not true SB> SITN. Surely this is about in band and outband state sharing. o Encodes information about the network and/or data for post- service forwarding. o Creates an identifier used for policy binding by SFs. Context information can be derived in several ways: SB> This list does not scan properly from the intro fragment above. o External sources o Network node classification o Service function classification 5. Additional Architectural Concepts There are a number of issues which solutions need to address, and which the architecture informs but does not determine. This section lays out some of those concepts. 5.1. The Role of Policy Much of the behavior of service chains is driven by operator and per- customer policy. This architecture is structured to isolate the policy interactions from the data plane and control logic. Specifically, it is assumed that the service chaining control plane creates the service paths. The service chaining data plane is used to deliver the classified packets along the service chains to the intended service functions. Policy, in contrast, interacts with the system in other places. Policies and policy engines may monitor service functions to decide if additional (or fewer) instances of services are needed. SB> This seems to be conflating policy and resource management, and SB> I am not sure this is wise. The resource manager should consult SB> policy, but the problems are distinct. When Halpern & Pignataro Expires March 24, 2015 [Page 17] Internet-Draft SFC Architecture September 2014 applicable, those decisions may in turn result in interactions that direct the control logic to change the SFP placement or packet classification rules. Similarly, operator service policy, often managed by operational or business support systems (OSS or BSS), will frequently determine what service functions are available. Operator service policies also determine which sequences of functions are valid and are to be used or made available. The offering of service chains to customers, and the selection of which service chain a customer wishes to use, are driven by a combination of operator and customer policies using appropriate portals in conjunction with the OSS and BSS tools. These selections then drive the service chaining control logic, which in turn establishes the appropriate packet classification rules. SB> Didn't you just say the above. In any case it might be better in SB> the form of an intro rather than a conclusion. 5.2. SFC Control Plane This is part of the overall architecture but outside the scope of this document. SB> The specifics of the architecture of the CP may be out of scope SB> but I cannot see how it can be out of scope of the main SB> architecture, unless you want to reclassify this as the SFC packet SB> plane architecture. SB> SB> As I read more of this text I am unclear why this in not promoted SB> to the main body of the text. The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay. For instance, an SFC construction may be static; selecting exactly which SFFs and which SFs from those SFFs are to be used, or it may be dynamic, allowing the network to perform some or all of the choices of SFF or SF to use to deliver the selected service chain within the constraints represented by the service path. In the SFC architecture, SFs are resources; SB> SFs or SF instances? I don't think it becomes an accountable SB> resource until it is instantiated. the control plane manages and communicates their capabilities, availability and location in fashions suitable for the transport and SFC operations in use. The control plane is also responsible for the creation of the context (see below). The control plane may be distributed (using new or existing control plane protocols), or be centralized, or a combination of the two. The SFC control plane provides the following functionality: 1. An SFC-enabled domain wide view of all available service function resources as well as the network locators through which they are reachable. 2. Uses SFC policy to construct service function chains, and associated service function paths. Halpern & Pignataro Expires March 24, 2015 [Page 18] Internet-Draft SFC Architecture September 2014 3. Selection of specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the time of delivering traffic to them). 4. Provides requisite SFC data plane information to the SFC architecture components, most notably the SFF. 5. Allocation of metadata associated with a given SFP and propagation of the metadata to relevant SFs and/or SFC encapsulation-proxies or their respective policy planes. SB> I am not sure what it means to allocate metadata. Do you mean SB> MD storage, or MD packet space? 5.3. Resource Control The SFC system may be responsible for managing all resources necessary for the SFC components to function. This includes network constraints used to plan and choose network path(s) between service function forwarders, network communication paths between service function forwarders and their attached service functions, characteristics of the nodes themselves such as memory, number of virtual interfaces, routes, and instantiation, configuration, and deletion of SFs. The SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system. While all of these aspects are part of the overall system, they are beyond the scope of this architecture. SB> The relationship between the RC/RM and the CP seems unclear. 5.4. Infinite Loop Detection and Avoidance This SFC architecture is predicated on topological independence from the underlying forwarding topology. Consequently, a service topology is created by Service Function Paths or by the local decisions of the Service Function Forwarders based on the constraints expressed in the SFP. SB> The concept of service topologies and overlays would be useful much ear= lier in the text. Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once. The Service Chaining solution needs to permit these limited and policy-compliant loops. At the same time, the solutions must ensure that indefinite and unbounded loops cannot be formed, as such would consume unbounded resources without delivering any value. In other words, this architecture prevents infinite Service Function Loops, even when Service Functions may be invoked multiple times in the same SFP. SB> You say it does, but I don't see how it does it. Do you anticipate SB> it happening in the CP or the DP or both? SB> Halpern & Pignataro Expires March 24, 2015 [Page 19] Internet-Draft SFC Architecture September 2014 5.5. Load Balancing Considerations Supporting function elasticity and high-availability should not overly complicate SFC or lead to unnecessary scalability problems. In the simplest case, where there is only a single function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. SB> It is unusual to lead with the dejenerate case (i.e. no SFC) In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SFP exists (the metadata changes but the SFP does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4. +---+ +---++--->web server source+-->|sff|+-->|sf1|+--->web server +---+ +---++--->web server Figure 4: Simple Load Balancing By extrapolation, in the case where intermediary functions within a chain had similar "elastic" behaviors, we do not need separate chains to account for this behavior - as long as the traffic coalesces to a common next-hop after the point of elasticity. In Figure 5, we have a chain of five service functions between the traffic source and its destination. +---+ +---+ +---+ +---+ +---+ +---+ |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | +-----+-----+ +-----+-----+ | | + + +---+ +---+ +---+ +---+ +---+ source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination +---+ +---+ +---+ +---+ +---+ + + + | | | +---+ +---+ +---+ |sf1| |sf3| |sf5| +---+ +---+ +---+ Figure 5: Load Balancing Halpern & Pignataro Expires March 24, 2015 [Page 20] Internet-Draft SFC Architecture September 2014 This would be represented as one service function path: sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be made up of one or multiple components. In this architecture, the SFF may handle load distribution based on policy. It can also be seen in the above that the same service function may be reachable through multiple SFFs, as discussed earlier. The selection of which SFF to use to reach SF3 may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints. In the latter case, it needs to be assured that exactly one SFF takes responsibility to steer traffic through SF3. SB> Shouldn't the architecture lead with the general case and note SB> that any function can be replaced with the null function. 5.6. MTU and Fragmentation Considerations This architecture prescribes additional information being added to packets to identify service function paths and often to represent metadata. It also envisions adding transport information to carry packets along service function paths, at least between service function forwarders. This added information increases the size of the packet to be carried by service chaining. Such additions could potentially increase the packet size beyond the MTU supported on some or all of the media used in the service chaining domain. Such packet size increases can thus cause operational MTU problems. Requiring fragmentation and reassembly in an SFF would be a major processing increase, and might be impossible with some transports. SB> Sure but the SFE is teh network layer of the SFC plane and could SB> do this. Expecting service functions to deal with packets fragmented by the SFC function might be onerous even when such fragmentation was possible. Thus, at the very least, solutions need to pay attention to the size cost of their approach. There may be alternative or additional means available, although any solution needs to consider the tradeoffs. These considerations apply to any generic architecture that increases the header size. There are also more specific MTU considerations: Effects on Path MTU Discovery (PMTUD) as well as deployment considerations. Deployments within a single administrative control or even a single Data Center complex can afford more flexibility in dealing with larger packets, and deploying existing mitigations that decrease the likelihood of fragmentation or discard. 5.7. SFC OAM Operations, Administration, and Maintenance (OAM) tools are an integral part of the architecture. These serve various purposes, including fault detection and isolation, and performance management. For example, there are many advantages of SFP liveness detection, Halpern & Pignataro Expires March 24, 2015 [Page 21] Internet-Draft SFC Architecture September 2014 including status reporting, support for resiliency operations and policies, and an enhanced ability to balance load. Service Function Paths create a services topology, and OAM performs various functions within this service layer. Furthermore, SFC OAM follows the same architectural principles of SFC in general. For example, topological independence (including the ability to run OAM over various overlay technologies) and classification-based policy. We can subdivide the SFC OAM architecture in two parts: o In-band: OAM packets follow the same path and share fate with user packets, within the service topology. For this, they also follow the architectural principle of consistent policy identifiers, and use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are particularly important here. o Out-of-band: reporting beyond the actual data plane. An additional layer beyond the data-plane OAM allows for additional alerting and measurements. This architecture prescribes end-to-end SFP OAM functions, which implies SFF understanding of whether an in-band packet is an OAM or user packet. However, service function validation is outside of the scope of this architecture, and application-level OAM is not what this architecture prescribes. Some of the detailed functions performed by SFC OAM include fault detection and isolation in a Service Function Path or a Service Function, verification that connectivity using SFPs is both effective and directing packets to the intended service functions, service path tracing, diagnostic and fault isolation, alarm reporting, performance measurement, locking and testing of service functions, validation with the control plane (see Section 5.2), and also allow for vendor- specific as well as experimental functions. SFC should leverage, and if needed extend relevant existing OAM mechanisms. 5.8. Resilience and Redundancy As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These may be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state, as for example stateful-firewall state, is the responsibility of the SF, and not addressed by this architecture. Halpern & Pignataro Expires March 24, 2015 [Page 22] Internet-Draft SFC Architecture September 2014 Multiple techniques are available to address this issue. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this. Solutions can also make use of MAC or IP level redundancy mechanisms such as VRRP. Also, particularly for SF failures, load balancers co-located with the SFF or as part of the service function delivery mechanism can provide such robustness. Similarly, operational requirements imply resilience in the face of load changes. While mechanisms for managing (e.g., monitoring, instantiating, loading images, providing configuration to service function chaining control, deleting, etc.) virtual machines are out of scope for this architecture, solutions can and are aided by describing how they can make use of scaling mechanisms. SB> Given that we are introducing a new network layer construct including SB> something that is or is a very close cousin to a network layer, surely SB> we are missing an opportunity by not including this on day one. 6. Security Considerations This document does not define a new protocol and therefore creates no new security issues. Security considerations apply to the realization of this architecture. Such realization ought to provide means to protect the SFC-enabled domain and its borders against various forms of attacks, including DDoS attacks. Further, SFC OAM Functions need to not negatively affect the security considerations of an SFC-enabled domain. Additionally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed, poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network. SB> I just don't buy this for a security analysis. The Architecture needs SB> direct the compenent designers to look at security issues associated SB> with the new components and functionality being introduced. SB> For example the SFE will have special considerations, so will the SB> the path changes that you talk about earlier. Then there is resource SB> conflicts and their impact as a security problem. Then there is the SB> issue of privacy. Really each component of the ach needs to be looked SB> at from a security PoV and guidance provided to the component designer. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_8360A86FCD1D42DD98FAE3124818A6DAciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0DFEAAA47082ED4EA95CC76CFEE8BEE3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Stewart,

Thanks for a very long set of comments right after WGLC fin= ished :-)

This is a top-post response only, to Ack your email and to = make a couple high-level comments about it. Neither Joel nor I will have im= mediate time this/early next week to respond to each individual comment (al= though we will as soon as we can), and we did not want your note to go unanswered.

First, many of your comments are conclusions from trying to= model the SFC architecture as a layer network, where in fact that is not w= hat we are doing or how things operate in this context. This architecture i= s not creating hard demarcations or modeling SFCs as a layer network.

And second, much of what you call 'lack of precision' is a = feature and not a bug -- the realm of applications, deployments is rich in = diversity and hence flexibility is a higher goal, while surgical doctoral p= recision would make the architecture brittle and would effectively make real deployment cases not be covered or= represented by the architecture.

That said, you do make some points that are valid and we ne= ed to address -- we will be responding point-by-point soon.

Thanks again for taking the time to review and sending thes= e detailed comments!

Carlos.

On Nov 12, 2014, at 10:17 AM, Stewart Bryant (stbryant) <= ;stbryant@cisco.com>= ; wrote:

Correcting an error in the to list.

On 12/11/2014 20:05, Stewart Bryant wrote:
SB> This document lacks the precision and that I would h=
ave hoped for=20
SB> in an architecture. I understand that the this was deliberate=20
SB> in order to allow implementation flexibility, but I don't=20
SB> buy that.
SB>
SB> What we have here is a type of layered network, and whilst=20
SB> verbal discussions have refuted that, you have many references
SB> to overlay topologies.
SB>
SB> This would be better understood if you described it as a layered
SB> system, if you only used generalized the components with fully
SB> functionality, and then explained which could be NULL. In the=20
SB> case of sub-functional components they should not be part of the=20
SB> core architecture, but the techniques used to create a full function
SB> component by assistance (the proxy) described outside the main
SB> architecture.
SB>
SB> I understand that in part the approach used here was to allow
SB> a mixture of implementation styles - the concept of explicit
SB> and implicit SFE - with network layer constructs supplying the=20
SB> implicit SFE. However it would be better to think of the use
SB> of implicit SFE as a type of network recursion in which the=20
SB> the encapsulator (which I think is distinct from the classifier)
SB> chooses how to encode the SFP on the packet.
SB>
SB> I have a nagging concern about the way that the terms packets is
SB> used in this text. The way it is used one would expect that there
SB> is a one for one mapping between input and output packets, but that
SB> is surely not the case. A trivial point is the case where an SF
SB> needs to defragment. Although at the physical layer the units are
SB> packets, there may surely be higher order constructs traveling
SB> between SFs.=20


 Service Function Chaining (SFC) Architecture
                     draft-ietf-sfc-architecture-02

Abstract

   This document describes an architecture for the specification,
sb> an arch or THE arch?
   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.  This document does not propose solutions,
   protocols, or extensions to existing protocols.



1.  Introduction

   This document describes an architecture used for the creation and
sb> and or THE
   ongoing maintenance of Service Function Chains (SFC) in a network.
   It includes architectural concepts, principles, and components.

   An overview of the issues associated with the deployment of end-to-
   end service function chains, abstract sets of service functions and
   their ordering constraints that create a composite service and the
   subsequent "steering" of traffic flows through said service
   functions, is described in [I-D.ietf-sfc-problem-statement].

   This architecture presents a model addressing the problematic aspects
   of existing service deployments, including topological independence
   and configuration complexity.

   Service function chains enable composite services that are
   constructed from one or more service functions.

1.1.  Scope

   This document defines a framework to realize Service Function
   Chaining (SFC) with minimum requirements on the physical topology of
   the network.  The proposed solution relies on initial packet
   classification.  Packets initially classified for handling by a set
   of Service Functions (SFs) in the SFC-enabled domain are then
   forwarded to that set of SFs for processing.

SB> Are you allowed to reclassify, or do staged classification?=20
SB> Yes you are - you say so later - but that is not implied
SB> by the above.

   This document does not make any assumption on the deployment contex=
t.
   The proposed framework covers both fixed and mobile networks.

SB> Given that you make no deployment context assumption, surely
SB> the followup mobile/fixed specific is not relevant.

   The architecture described herein is assumed to be applicable to a
   single network administrative domain.  While it is possible for the
   architectural principles and components to be applied to inter-domain
   SFCs, these are left for future study.

1.2.  Assumptions

   The following assumptions are made:

   o  Not all SFs can be characterized with a standard definition in
      terms of technical description, detailed specification,
      configuration, etc.

   o  There is no global or standard list of SFs enabled in a given
      administrative domain.  The set of SFs varies as a function of the
      service to be provided and according to the networking
      environment.

   o  There is no global or standard SF chaining logic.  The ordered set
      of SFs that needs to be enabled to deliver a given service is
      specific to each administrative entity.

SB> Surely it is application specific even within an admistration?

 o  The chaining of SFs and the criteria to invoke them are specific
      to each administrative entity that operates an SF-enabled domain.

SB? see previous


Halpern & Pignataro      Expires March 24, 2015                 [Page 3=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   o  Several SF chaining policies can be simultaneously applied within
      an administrative domain to meet various business requirements.

   o  No assumption is made on how FIBs and RIBs of involved nodes are
      populated.

   o  How to bind traffic to a given SF chain is policy-based.

1.3.  Definition of Terms

   Network Service:  An offering provided by an operator that is
        delivered using one or more service functions.  This may also be
        referred to as a composite service.  The term "service" i=
s used
        to denote a "network service" in the context of this docu=
ment.

        Note: Beyond this document, the term "service" is overloa=
ded
        with varying definitions.  For example, to some a service is an
        offering composed of several elements within the operator's
        network, whereas for others a service, or more specifically a
        network service, is a discrete element such as a firewall.
        Traditionally, such services (in the latter sense) host a set of
        service functions and have a network locator where the service
        is hosted.

SB> I think that you probably need an explicit definition of service.
SB> I find the text in the definition of NS self referential which is
SB> not helpful.


 Classification:  Locally instantiated policy and customer/network/
        service profile matching of traffic flows for identification of
        appropriate outbound forwarding actions.

SB> Isn't it really

SB> Locally instantiated matching of traffic flows against policy for
SB> subsequent application of the required set of network service functi=
ons.=20
SB> The policy may be ustomer/network/service specific.




 Classifier:  An element that performs Classification.

SB> A network element perhaps?

 Service Function Chain (SFC):  A service function chain defines a set
        of abstract service functions and ordering constraints that must

SB> Isn't the SFC also ordered?

        be applied to packets and/or frames selected as a result of
        classification. =20
SB> Packets, or higher order constructs like flows? You cannot
SB> do some of the SFs packet by packet

        The implied order may not be a linear
        progression as the architecture allows for SFCs that copy to
        more than one branch, and also allows for cases where there is
        flexibility in the order in which service functions need to be
        applied.  The term service chain is often used as shorthand for
        service function chain.

SB> See my earlier not about the apparently more restricted definition
SB> I think that you need to make the generalization clearer earlier.

 Service Function (SF):  A function that is responsible for specific
        treatment of received packets.  A Service Function can act at
        various layers of a protocol stack (e.g., at the network layer
        or other OSI layers).  As a logical component, a Service
        Function can be realized as a virtual element or be embedded in
        a physical network element.  One or multiple Service Functions
SB> multiple or more?
       can be embedded in the same network element.  Multiple




Halpern & Pignataro      Expires March 24, 2015                 [Page 4=
]
=0C
Internet-Draft              SFC Architecture              September 2014


        occurrences of the Service Function can exist in the same
        administrative domain.

        One or more Service Functions can be involved in the delivery of
        added-value services.  A non-exhaustive list of abstract Service
        Functions includes: firewalls, WAN and application acceleration,
        Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
        balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
        HOST_ID injection, HTTP Header Enrichment functions, TCP
        optimizer.

SB> Not sure those are abstract SFs, surely they are explicit?

        An SF may be SFC encapsulation aware, that is it receives and
        acts on information in the SFC encapsulation, or unaware, in
        which case data forwarded to the SF does not contain the SFC
        encapsulation.

   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as handling traffic
        coming back from the SF.  Additionally, a service function
        forwarder is responsible for delivering traffic to a classifier
        when needed and supported, mapping out traffic to another SFF
        (in the same or different type of overlay), and terminating the
        SFP.


SB> In these days of NFV it may not be received from the network.
SB> Surely the traffic is native until it gets to a classifier. The
SB> way you have it here it looks like the first element is the SFF
SB> but I am not sure that is the case.
SB> Perhaps: A service function forwarder is responsible for forwarding
SB> traffic between service functions.=20

 Metadata:  provides the ability to exchange context information
        between classifiers and SFs and among SFs.

SB> I think the first noun is missing in the above, but in any case
SB> I think a more complete definition is needed.

 Service Function Path (SFP):  The SFP provides a level of indirection
        between the fully abstract notion of service chain as a sequence
        of abstract service functions to be delivered, and the fully
        specified notion of exactly which SFF/SFs the packet will visit
        when it actually traverses the network.  By allowing the control
        components to specify this level of indirection, the operator
        may control the degree of SFF/SF selection authority that is
        delegated to the network.

SB> You have not defined control components.
SB> I think "notion" is a redundant term.
SB> I am somewhat confused by your definition.
SB> Is this really about the mapping of packets between an arbitrary
SB> member of an SF to a specific instance of the SF?

 SFC Encapsulation:  The SFC Encapsulation provides at a minimum SFP
        identification, and is used by the SFC-aware functions, such as
        the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
        for network packet forwarding.  In addition to SFP
        identification, the SFC encapsulation carries data plane context
        information, also referred to as metadata.

SB> Surely the "SFC E is used to attach the information needed to
SB> direct the packet through the ordered set of SFs, together with
SB> associated metadata. An additional  network layer encapsulation is n=
eeded
SB> to carry the packet over the physical network.


 Rendered Service Path (RSP):  The Service Function Path is a
        constrained specification of where packets using a certain
        service chain must go.  While it may be so constrained as to



Halpern & Pignataro      Expires March 24, 2015                 [Page 5=
]
=0C
Internet-Draft              SFC Architecture              September 2014


        identify the exact locations, it can also be less specific.
        Packets themselves are of course transmitted from and to
        specific places in the network, visiting a specific sequence of
        SFFs and SFs.  This sequence of actual visits by a packet to
        specific SFFs and SFs in the network is known as the Rendered
        Service Path (RSP).  This definition is included here for use by
        later documents, such as when solutions may need to discuss the
        actual sequence of locations the packets visit.


SB> Not sure of the wisdom of including a definition for the future, sin=
ce
SB> when you use it you may need to tune the definition.

 SFC-enabled Domain:  A network or region of a network that implements
        SFC.  An SFC-enabled Domain is limited to a single network
        administrative domain.

   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
        SFC-unaware service function.  SFC proxies are logical elements.

SB> Not sure considering then as logical is quite right. It depends
SB> on the mapping of the operation to the physical. I could see
SB> cases where they are physical. Surely the point is that they
SB> may be co-located with another network function such as a router
SB> an operating system component such as a hypervisor.


 2.  Architectural Concepts

   The following sections describe the foundational concepts of service
   function chaining and the SFC architecture.

   Service Function Chaining enables the creation of composite (network)
   services that consist of an ordered set of Service Functions (SF)
   that must be applied to packets and/or frames selected as a result of
   classification.  Each SF is referenced using an identifier that is
   unique within an SF-enabled domain.  No IANA registry is required to
   store the identity of SFs.


SB> I am still worried about using packets. Obviously we operate on
SB> pkts, but the operation may require the reconstuction of some
SB> packet grouping typically some element of a flow before the operatio=
n
SB> can be performed. A trivial example is defragmenting a packet group
SB> but since we are dealing with abstract SFs we cannot specify the=20
SB> the unit of operation.

    Service Function Chaining is a concept that provides for more than
   just the application of an ordered set of SFs to selected traffic;
   rather, it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities.

SB> The above is a bit late in the text. I think it needs to go earlier.

 2.1.  Service Function Chains

   In most networks, services are constructed as abstract sequences of
SB> I don't think that are abstract in this context.
SB> Are you talking about traditional (current physically instantiated
SB> SFCs in the previous sentence?

   SFs that represent SFCs.  At a high level, an SFC is an abstracted
   view of a service that specifies the set of required SFs as well as
   the order in which they must be executed. =20

SB> Again I am not sure "abstrated view" is right here

   Graphs, as illustrated in
   Figure 1, define an SFC, where each graph node represents the
   required existence of at least one abstract SF.  Such graph nodes
   (SFs) can be part of zero, one, or many SFCs.  A given graph node
   (SF) can appear one time or multiple times in a given SFC.

SB> Not sure that graphs is right, since you only show the case
SB> of a linear chain. The construct you are going to use is
SB> graph, but that is not what the figure shows.

   SFCs can start from the origination point of the service function
   graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
   graph. =20

SB> OK so are you trying to distinguish between physically and
SB> SFC (the new technology) instantiated SFCS?

   SFs may therefore become branching nodes in the graph, with



Halpern & Pignataro      Expires March 24, 2015                 [Page 6=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   those SFs selecting edges that move traffic to one or more branches.
   An SFC can have more than one terminus.


SB> Again that is not what your figure shows.

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   6   )+---->(   8  =
 )
    \     /       \     /        \     /        \     /
     `---'         `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   3   )+---->(   7  =
 )+---->(   9   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   7   )+---->(   8   )+---->(   4  =
 )+---->(   7   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

                  Figure 1: Service Function Chain Graphs

2.2.  Service Function Chain Symmetry

   SFCs may be unidirectional or bidirectional.  A unidirectional SFC
   requires that traffic be forwarded through the ordered SFs in one
   direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC require=
s a
   symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), an=
d in
   which the SF instances are the same in opposite directions.  A hybrid
   SFC has attributes of both unidirectional and bidirectional SFCs;
   that is to say some SFs require symmetric traffic, whereas other SFs
   do not process reverse traffic or are independent of the
   corresponding forward traffic.

   SFCs may contain cycles; that is traffic may need to traverse one or
   more SFs within an SFC more than once.  Solutions will need to ensure
   suitable disambiguation for such situations.

   The architectural allowance that is made for SFPs that delegate
   choice to the network for which SFs and/or SFFs a packet will visit
   creates potential issues here.  A solution that allows such
   delegation needs to also describe how the solution ensures that those
   service chains that require service function chain symmetry can
   achieve that.

   Further, there are state tradeoffs in symmetry.  Symmetry may be
   realized in several ways depending on the SFF and classifier



Halpern & Pignataro      Expires March 24, 2015                 [Page 7=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   functionality.  In some cases, "mirrored" classification (i.e.=
, from
   Source to Destination and from Destination to Source) policy may be
   deployed, whereas in others shared state between classifiers may be
   used to ensure that symmetric flows are correctly identified, then
   steered along the required SFP.  At a high level, there are various
   common cases.  In a non-exhaustive way, there can be for example: a
   single classifier (or a small number of classifiers), in which case
   both incoming and outgoing flows could be recognized at the same
   classifier, so the synchronization would be feasible by internal
   mechanisms internal to the classifier.  Another case is the one of
   stateful classifiers where several classifiers may be clustered and
   share state.  Lastly, another case entails fully distributed
   classifiers, where synchronization needs to be provided through
   unspecified means.  This is a non-comprehensive list of common cases.

SB> Isn't an important class of classifiers one that learns state from t=
he=20
SB> egress packets/flows that is then used to provide state for the=20
SB> return packets/flow

 2.3.  Service Function Paths

   A service function path (SFP) is a mechanism used by service chaining
   to express the result of applying more granular policy and
SB> Not sure "more granular" is needed.

   operational constraints to the abstract requirements of a service
SB> Not sure they are abstract requirements. When you apply them they
SB> are explicit.

   chain (SFC).  This architecture does not mandate the degree of
   specificity of the SFP.  Architecturally, within the same SFC-enabled
   domain, some SFPs may be fully specified, selecting exactly which SFF
   and which SF are to be visited by packets using that SFP, while other
   SFPs may be quite vague, deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC.  The
   specificity may be anywhere in between these extremes.

   As an example of such an intermediate specificity, there may be two
   SFPs associated with a given SFC, where one SFP says essentially that

SB> "says essentially is not a tight definition"

   any order of SFF and SF may be used as long as it is within data
   center 1, and where the second SFP allows the same latitude, but only
   within data center 2.

   Thus, the policies and logic of SFP selection or creation (depending
   upon the solution) produce what may be thought of as a constrained
   version of the original SFC.  Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs may be associated with a single SFC.

SB> So a SFP is a specific instance of a member of the set of available =
SFCs
SB> chosen as a result of applying policy at one or points along the SFC=
?


   The architecture allows for the same SF to be reachable through
   multiple SFFs.  In these cases, some SFPs may constrain which SFF is
   used to reach which SF, while some SFPs may leave that decision to
   the SFF itself.

   Further, the architecture allows for two or more SFs to be attached
   to the same SFF, and possibly connected via internal means allowing
   more effective communication.  In these cases, some solutions or


Halpern & Pignataro      Expires March 24, 2015                 [Page 8=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   deployments may choose to use some form of internal inter-process or
   inter-VM messaging (communication behind the virtual switching
   element) that is optimized for such an environment.  This must be
   coordinated with the SFF so that the service function forwarding can
   properly perform its job.  Implementation details of such mechanisms
   are considered out of scope for this document, and can include a
   spectrum of methods: for example situations including all next-hops
   explicitly, others where a list of possible next-hops is provided and
   the selection is local, or cases with just an identifier, where all
   resolution is local.

   This architecture also allows the same SF to be part of multiple
   SFPs.

SB> Didn't you just say that?

 3.  Architecture Principles

   Service function chaining is predicated on several key architectural
   principles:

   1.  Topological independence: no changes to the underlay network
       forwarding topology - implicit, or explicit - are needed to
       deploy and invoke SFs or SFCs.

   2.  Plane separation: dynamic realization of SFPs is separated from
       packet handling operations (e.g., packet forwarding).

   3.  Classification: traffic that satisfies classification rules is
       forwarded according to a specific SFP.  For example,
       classification can be as simple as an explicit forwarding entry
       that forwards all traffic from one address into the SFP.
       Multiple classification points are possible within an SFC (i.e.
       forming a service graph) thus enabling changes/updates to the SFC
       by SFs.

       Classification can occur at varying degrees of granularity; for
       example, classification can use a 5-tuple, a transport port or
       set of ports, part of the packet payload, or it can come from
       external systems.

SB> I think that it can surely be as a result of higher level inspection=
s?

 4.  Shared Metadata: Metadata/context data can be shared amongst SFs
       and classifiers, between SFs, and between external systems and
       SFs (e.g., orchestration).

       Generally speaking, metadata can be thought of as providing and
       sharing the result of classification=20

SB> Just classifications, or classifications and processing operations?
SB> There is gray zone between a packet forwarding system and
SB> a distributed computing system and I am not sure where SFC fits,=20
SB> nor am I sure that it makes sense to be specific at this stage.
SB> It is entirely possible that an SFC consumes the packet/flow
SB> rather than only having the capability to forward it between=20
SB> in ingress and egress.

      (that occurs within the SFC-
       enabled domain, or external to it) along an SFP.  For example, an
       external repository might provide user/subscriber information to
       a service chain classifier.  This classifier could in turn impose



Halpern & Pignataro      Expires March 24, 2015                 [Page 9=
]
=0C
Internet-Draft              SFC Architecture              September 2014


       that information in the SFC encapsulation for delivery to the
       requisite SFs.  The SFs could in turn utilize the user/subscriber
       information for local policy decisions.

   5.  Service definition independence: The SFC architecture does not
       depend on the details of SFs themselves.  Additionally, no IANA
       registry is required to store the list of SFs.

SB> Yes, but you should be careful not to preclude it.

  6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

SB> Yes and no. What about the resource implications?

 7.  Heterogeneous control/policy points: The architecture allows SFs
       to use independent mechanisms (out of scope for this document) to
       populate and resolve local policy and (if needed) local
       classification criteria.

4.  Core SFC Architecture Components

   At a very high level, the logical architecture of an SFC-enabled
   Domain comprises:

SB> A list would be handy rather than just a figure, and you need
SB> some text to expand on the figure.

      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . =
.
      .  +--------------+                  +------------------~=
~~
      .  |   Service    |       SFC        |  Service  +---+   +=
;---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +-=
--+   +---+
      .  +--------------+                  +------------------~=
~~
      . SFC-enabled Domain
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

               Figure 2: Service Function Chain Architecture


SB> This is a very confusing diagram
SB> Surely the SFC encap is attached to the packet
SB> The fig seems to confuse the the packets and the path.

   The following sub-sections provide details on each logical component
   that form the basis of the SFC architecture.  A detailed overview of
   how each of these architectural components interact is provided in
   Figure 3:


SB> Well maybe, but it's not quite obvious what you are showing.=20
SB> some overview text would help before you get into the detail.











Halpern & Pignataro      Expires March 24, 2015                [Page 10=
]
=0C
Internet-Draft              SFC Architecture              September 2014


         +----------------+                        +-----------=
-----+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------=
+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +=
---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------=
3;
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

         Figure 3: Service Function Chain Architecture Components


SB> Coming back here after reading a bit more. Is the SFF to be consider=
ed the
SB> hub in a hub and spoke processing model for a set of SFs? If so it w=
ould
SB> be useful to say that up front. However that raises the issue of whe=
ther
SB> the single network attachment point that you show is desirable. A st=
andard
SB> firewall design would not mix dirty and clean traffic, and yet that =
is
SB> what the above appears to show.


 4.1.  SFC Encapsulation

   The SFC encapsulation enables service function path selection.  It
   also enables the sharing of metadata/context information when such
   metadata exchange is required.

SB> I don't think that is quite right. Surely the=20
SB> SFC encapsulation enables <some component> to select the next
SB> element of the path?
 
   The SFC encapsulation provides explicit information used to identif=
y
SB> Provides or carries?
   the SFP.  However, the SFC encapsulation is not a transport
   encapsulation itself: it is not used to forward packets within the
   network fabric. =20
SB> ... but surely it is a shim layer of some sort?

   If packets need to flow between separate physical
   platforms, the SFC encapsulation therefore relies on an outer network
   transport. =20
SB> Surely it is network layer header specific to the inter SFC
SB> transport?

   Transit forwarders -- such as router and switches --
   simply forward SFC encapsulated packets based on the outer (non-SFC)
   encapsulation.

SB> d/simply/



Halpern & Pignataro      Expires March 24, 2015                [Page 11=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   One of the key architecture principles of SFC is that the SFC
   encapsulation remain transport independent.  As such any network
   transport protocol may be used to carry the SFC encapsulated traffic.

SB> Not sure I like "network transport protocol" since this is=
 going
SB> to be confused with transport layer and I am not sure whether
SB> you would require a transport layer, indeed the SFE might will
SB> be considered a transport layer in the classical sense.

 4.2.  Service Function (SF)

   The concept of an SF evolves; rather than being viewed as a bump in
   the wire, an SF becomes a resource within a specified administrative
   domain that is available for consumption as part of a composite
   service.  SFs send/receive data to/from one or more SFFs.  SFC-aware
   SFs receive this traffic with the SFC encapsulation.

SB> I do not understand the above para.

   While the SFC architecture defines a new encapsulation - the SFC
   encapsulation -=20

SB> no it does not - it is not defined in this memo. You introduce
SB> the concept and define some of the characteristics of it.


   and several logical components for the construction
   of SFCs, existing SF implementations may not have the capabilities to
   act upon or fully integrate with the new SFC encapsulation.  In order
   to provide a mechanism for such SFs to participate in the
   architecture, an SFC proxy function is defined (see Section 4.6).
   The SFC proxy acts as a gateway between the SFC encapsulation and
   SFC-unaware SFs.  The integration of SFC-unaware service functions is
   discussed in more detail in the SFC proxy section.

SB> The above is confusing. Do they participate in the architecture (thi=
s
SB> text)? I think that you mean that in order to employ SF instances
SB> that do not understand the SFE, a proxy as a gateway between the=20
SB> the SFE aware domain and the non-SFE aware domain. Now if it is
SB> a gateway why is it not called a gateway rather than a proxy which
SB> is something that does something on behalf of something else.
SB> I would think that it might be a SFE proxy, but that is not quite
SB> right either.


 This architecture allows an SF to be part of multiple SFPs and SFCs.

SB> I am sure you said that before.

 4.3.  Service Function Forwarder (SFF)

   The SFF is responsible for forwarding packets and/or frames received
   from the network to one or more SFs associated with a given SFF using
   information conveyed in the SFC encapsulation.  Traffic from SFs
   eventually returns to the same SFF, which is responsible for
   injecting traffic back onto the network.

SB> It is not clear why it needs to be the exact same SFF

   The collection of SFFs and associated SFs creates a service plane
   overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
   Within this service plane, the SFF component connects different SFs
   that form a service function path.

SB> This conceptual model seems quite fundamental and this I=20
SB> am surprised that it is not much earlier in the document.
SB> I have been wondering why the SFC system was not considered
SB> an overlay network of some sort, and was told by the authors
SB> that this was not possible. The above seems at odds with that
Sb> statement.

   SFFs maintain the requisite SFP forwarding information. =20
SB> Maintain - as in being the control plane for this, or
SB> maintain as in store?
   SFP
   forwarding information is associated with a service path identifier
   that is used to uniquely identify an SFP.  The service forwarding
   state enables an SFF to identify which SFs of a given SFP should be
   applied, and in what order, as traffic flows through the associated
   SFP.  While there may appear to the SFF to be only one available way
   to deliver the given SF, there may also be multiple choices allowed
   by the constraints of the SFP.

   If there are multiple choices, the SFF needs to preserve the property
   that all packets of a given flow are handled the same way, since the



Halpern & Pignataro      Expires March 24, 2015                [Page 12=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   SF may well be stateful.  Additionally, the SFF may preserve the
   handling of packets based on other properties on top of a flow, such
   as a subscriber, session, or application instance identification.

SB> I feel that the issue of handing higher order objects needs to have
SB> been introduced much earlier in the architecture.

   The SFF also has the information to allow it to forward packets to
   the next SFF after applying local service functions.  Again, while
   there may be only a single choice available, the architecture allows
   for multiple choices for the next SFF.  As with SFs, the solution
   needs to operate such that the behavior with regard to specific flows
   (see the Rendered Service Path) is stable.  The selection of
   available SFs and next SFFs may be interwoven when an SFF supports
   multiple distinct service functions and the same service function is
   available at multiple SFFs.  Solutions need to be clear about what is
   allowed in these cases.

   Even when the SFF supports and utilizes multiple choices, the
   decision as to whether to use flow-specific mechanisms or coarser
   grained means to ensure that the behavior of specific flows is stable
   is a matter for specific solutions and specific implementations.

   The SFF component has the following primary responsibilities:

   1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and if needed forwarded to
       another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path.  Related to this forwarding responsibility,
       an SFF should be able to interact with metadata.

   2.  Terminating SFPs : An SFC is completely executed when traffic has
       traversed all required SFs in a chain.  When traffic arrives at
       the SFF after the last SF has finished processing it, the final
       SFF knows from the service forwarding state that the SFC is
       complete.  The SFF removes the SFC encapsulation and delivers the
       packet back to the network for forwarding.

   3.  Maintaining flow state: In some cases, the SFF may be stateful.
       It creates flows and stores flow-centric information.  This state
       information may be used for a range of SFP-related tasks such as
       ensuring consistent treatment of all packets in a given flow,
       ensuring symmetry or for state-aware SFC Proxy functionality (see
       Section 4.8).





Halpern & Pignataro      Expires March 24, 2015                [Page 13=
]
=0C
Internet-Draft              SFC Architecture              September 2014


4.3.1.  Transport Derived SFF

   Service function forwarding, as described above, directly depends
   upon the use of the service path information contained in the SFC
   encapsulation.  However, existing implementations may not be able to
   act on the SFC encapsulation.  These platforms may opt to use
   existing transport information if it can be arranged to provide
   explicit service path information.

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

SB> The title does not seem quite right. What I think you have
SB> is a system in which you map an SFC onto an explicit path
SB> of some sort in the lower layers (I was going to say network layer
SB> but I am not sure if that is what you intend). So I am not sure=20
SB> derived is the correct word. It would be closer to say "emulati=
on
SB> of SFF using explicit network paths. Noting that these paths may
SB> be encoded in the packet or encoded in the FIB.

 4.4.  SFC-Enabled Domain

   Specific features may need to be enforced at the boundaries of an
   SFC-enabled domain, for example to avoid leaking SFC information.
   Using the term node to refer generically to an entity that is
   performing a set of functions, in this context, an SFC Boundary Node
   denotes a node that connects one SFC-enabled domain to a node either
   located in another SFC-enabled domain or in a domain that is SFC-
   unaware.

   An SFC Boundary node can act as egress or ingress. =20
SB> do you mean or or and/or i.e. can it be both at the same time.
   An SFC Egress
   Node denotes a SFC Boundary Node that handles traffic leaving the
   SFC-enabled domain the Egress Node belongs to.  Such a node is
   required to remove any information specific to the SFC Domain,
   typically the SFC Encapsulation.  An SFC Ingress Node denotes an SFC
   Boundary Node that handles traffic entering the SFC-enabled domain.
   In most solutions and deployments this will need to include a
   classifier, and will be responsible for adding the SFC encapsulation
   to the packet.

SB> Logically doesn't it always include the classifier, where the set of
SB> classifier types includes the null classifier? The only exception
SB> I suppose is when you are receiving traffic from a trusted
SB> SFC aware peer, but it might be better to be more explicit
SB> about the normal case and then introduce the exception

 4.5.  Network Overlay and Network Components

   Underneath the SFF there are components responsible for performing
   the transport (overlay) forwarding.  They do not consult the SFC
   encapsulation or inner payload for performing this forwarding.  They
   only consult the outer-transport encapsulation for the transport
   (overlay) forwarding.

SB> This layer model needs to be brought out much earlier instead of=20
SB> having the reader deduce it up to this point.
SB> Indeed the layering model makes for a better way of explaining
SB> the operation of the system.

 4.6.  SFC Proxy

   In order for the SFC architecture to support SFC-unaware SFs (e.g.,
   legacy service functions) a logical SFC proxy function may be used.

SB> Is it a logical proxy or a real proxy, and why only may, surely
SB> it *is* used.


Halpern & Pignataro      Expires March 24, 2015                [Page 14=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   This function sits between an SFF and one or more SFs to which the
   SFF is directing traffic.

   The proxy accepts packets from the SFF on behalf of the SF.  It
   removes the SFC encapsulation, and then uses a local attachment
   circuit to deliver packets to SFC unaware SFs.  It also receives
   packets back from the SF, reapplies the SFC encapsulation, and
   returns them to the SFF for processing along the service function
   path.

   Thus, from the point of view of the SFF, the SFC proxy appears to be
   part of an SFC aware SF.

   Communication details between the SFF and the SFC Proxy are the same
   as those between the SFF and an SFC aware SF.  The details of that
   are not part of this architecture.  The details of the communication
   methods over the local attachment circuit between the SFC proxy and
   the SFC-unaware SF are dependent upon the specific behaviors and
   capabilities of that SFC-unaware SF, and thus are also out of scope
   for this architecture.

   Specifically, for traffic received from the SFF intended for the SF
   the proxy is representing, the SFC proxy:

   o  Removes the SFC encapsulation from SFC encapsulated packets.

   o  Identifies the required SF to be applied based on available
      information including that carried in the SFC encapsulation.

   o  Selects the appropriate outbound local attachment circuit through
      which the next SF for this SFP is reachable.  This is derived from
      the identification of the SF carried in the SFC encapsulation, and
      may include local techniques.  Examples of a local attachment
      circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3,
      GRE, VXLAN.

   o  Forwards the original payload via the selected local attachment
      circuit to the appropriate SF.

SB> I think you have missed the storage of the SFE and I am not
SB> sure how this gets back to the specific packet. This causes me
SB> wonder if it is the original payload or not since it may by
SB> now be SFC modified. It is surely the SFE payload that gets=20
SB> passed up, and to re-attach the correct SFE afterwards, might
SB> you not have to modify it?


 When traffic is returned from the SF:

   o  Applies the required SFC encapsulation.  The determination of the
      encapsulation details may be inferred by the local attachment
      circuit through which the packet and/or frame was received, or via
      packet classification, or other local policy.  In some cases,
      packet ordering or modification by the SF may necessitate
      additional classification in order to re-apply the correct SFC
      encapsulation.

SB> This function is surely split between the outbound and inbound
SB> proxy functions.

 Halpern & Pignataro      Expires March 24, 2015                [P=
age 15]
=0C
Internet-Draft              SFC Architecture              September 2014


   o  Delivers the packet with the SFC Encapsulation to the SFF, as
      would happen with packets returned from an SFC-aware SF.

   Alternatively, a service provider may decide to exclude legacy
   service functions from an SFC domain.

SB> This might have been better expressed earlier in the text my noting
SB> that the proxy was optional, making the afterthought above redundant=
.


 4.7.  Classification

   Traffic from the network that satisfies classification criteria is
   directed into an SFP and forwarded to the requisite service
   function(s).  Classification is handled by a service classification
   function; initial classification occurs at the ingress to the SFC
   domain.  The granularity of the initial classification is determined
   by the capabilities of the classifier and the requirements of the SFC
   policy.  For instance, classification might be relatively coarse: all
   packets from this port are subject to SFC policy X and directed into
   SFP A, or quite granular: all packets matching this 5-tuple are
   subject to SFC policy Y and directed into SFP B.

   As a consequence of the classification decision, the appropriate SFC
   encapsulation is imposed on the data, and a suitable SFP is selected
   or created.  Classification results in attaching the traffic to a
   specific SFP.

SB> How about:

SFC domain ingress traffic is first processed by a classifier which
either rejects the traffic or prepares it for processing by the required
SFs. The classifier applies policy to the packet to determine the required
SFC, and then to map that to the required SFP. The classifier applies
the corresponding SFE and if necessary the appropriate network layer
encapsulation and forwards the packet to the first SFF on the chain.



 4.8.  Re-Classification and Branching

   The SFC architecture supports re-classification (or non-initial
   classification) as well. =20

SB> This is interesting, surely the packet only enters the
SB> SFC when it has been been classified (including the null classificat=
ion)
SB> and has the SFE applied?

   As packets traverse an SFP, re-
   classification may occur - typically performed by a classification
   function co-resident with a service function. =20
SB> Architecturally you may always want to include a reclassifier
SB> on exit (and may be entry) to every SF. It may be null, but it's
SB> probably better that it is there.

   Reclassification may
   result in the selection of a new SFP, an update of the associated
   metadata, or both.  This is referred to as "branching".

   For example, an initial classification results in the selection of
   SFP A: DPI_1 --> SLB_8.  However, when the DPI service function is
   executed, attack traffic is detected at the application layer.  DPI_1
   re-classifies the traffic as attack and alters the service path to
   SFP B, to include a firewall for policy enforcement: dropping the
   traffic: DPI_1 --> FW_4.  Subsequent to FW_4, surviving traffic would
   be returned to the original SFF.  In this simple example, the DPI
   service function re-classifies the traffic based on local application
   layer classification capabilities (that were not available during the
   initial classification step).

   When traffic arrives after being steered through an SFC-unaware SF,
   the SFC Proxy must perform re-classification of traffic to determine
   the SFP.  The SFC Proxy is concerned with re-attaching information

SB> This should have been part of the earlier proxy functional definitio=
n.
SB> Maybe if you moved this up earlier before proxy it would all be clea=
rer.


 Halpern & Pignataro      Expires March 24, 2015                [P=
age 16]
=0C
Internet-Draft              SFC Architecture              September 2014


   for SFC-unaware SFs, and a stateful SFC Proxy simplifies such
   classification to a flow lookup.

4.9.  Shared Metadata

SB> Isn't metadata always shared? If no one else sees it, there is
SB> no point in generating it.

   Sharing metadata allows the network to provide network-derived
   information to the SFs, SF-to-SF information exchange and the sharing
   of service-derived information to the network.  Some SFCs may not
   require metadata exchange.  SFC infrastructure enables the exchange
   of this shared data along the SFP.  The shared metadata serves
   several possible roles within the SFC architecture:

   o  Allows elements that typically operate as ships in the night to
      exchange information.

SB> That is a sort of tautology. If they share MD they are not true
SB> SITN. Surely this is about in band and outband state sharing.

   o  Encodes information about the network and/or data for post-
      service forwarding.

   o  Creates an identifier used for policy binding by SFs.

   Context information can be derived in several ways:

SB> This list does not scan properly from the intro fragment above.

   o  External sources

   o  Network node classification

   o  Service function classification



 5.  Additional Architectural Concepts

   There are a number of issues which solutions need to address, and
   which the architecture informs but does not determine.  This section
   lays out some of those concepts.

5.1.  The Role of Policy

   Much of the behavior of service chains is driven by operator and per-
   customer policy.  This architecture is structured to isolate the
   policy interactions from the data plane and control logic.

   Specifically, it is assumed that the service chaining control plane
   creates the service paths.  The service chaining data plane is used
   to deliver the classified packets along the service chains to the
   intended service functions.

   Policy, in contrast, interacts with the system in other places.
   Policies and policy engines may monitor service functions to decide
   if additional (or fewer) instances of services are needed. =20

SB> This seems to be conflating policy and resource management, and
SB> I am not sure this is wise. The resource manager should consult
SB> policy, but the problems are distinct.

   When



Halpern & Pignataro      Expires March 24, 2015                [Page 17=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   applicable, those decisions may in turn result in interactions that
   direct the control logic to change the SFP placement or packet
   classification rules.

   Similarly, operator service policy, often managed by operational or
   business support systems (OSS or BSS), will frequently determine what
   service functions are available.  Operator service policies also
   determine which sequences of functions are valid and are to be used
   or made available.

   The offering of service chains to customers, and the selection of
   which service chain a customer wishes to use, are driven by a
   combination of operator and customer policies using appropriate
   portals in conjunction with the OSS and BSS tools.  These selections
   then drive the service chaining control logic, which in turn
   establishes the appropriate packet classification rules.


SB> Didn't you just say the above. In any case it might be better in
SB> the form of an intro rather than a conclusion.

 5.2.  SFC Control Plane

   This is part of the overall architecture but outside the scope of
   this document.

SB> The specifics of the architecture of the CP may be out of scope
SB> but I cannot see how it can be out of scope of the main
SB> architecture, unless you want to reclassify this as the SFC packet
SB> plane architecture.
SB>
SB> As I read more of this text I am unclear why this in not promoted
SB> to the main body of the text.


    The SFC control plane is responsible for constructing SFPs,
   translating SFCs to forwarding paths and propagating path information
   to participating nodes to achieve requisite forwarding behavior to
   construct the service overlay.  For instance, an SFC construction may
   be static; selecting exactly which SFFs and which SFs from those SFFs
   are to be used, or it may be dynamic, allowing the network to perform
   some or all of the choices of SFF or SF to use to deliver the
   selected service chain within the constraints represented by the
   service path.

   In the SFC architecture, SFs are resources;=20

SB> SFs or SF instances? I don't think it becomes an accountable=20
SB> resource until it is instantiated.

   the control plane manages
   and communicates their capabilities, availability and location in
   fashions suitable for the transport and SFC operations in use.  The
   control plane is also responsible for the creation of the context
   (see below).  The control plane may be distributed (using new or
   existing control plane protocols), or be centralized, or a
   combination of the two.

   The SFC control plane provides the following functionality:

   1.  An SFC-enabled domain wide view of all available service function
       resources as well as the network locators through which they are
       reachable.

   2.  Uses SFC policy to construct service function chains, and
       associated service function paths.



Halpern & Pignataro      Expires March 24, 2015                [Page 18=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   3.  Selection of specific SFs for a requested SFC, either statically
       (using specific SFs) or dynamically (using service explicit SFs
       at the time of delivering traffic to them).

   4.  Provides requisite SFC data plane information to the SFC
       architecture components, most notably the SFF.

   5.  Allocation of metadata associated with a given SFP and
       propagation of the metadata to relevant SFs and/or SFC
       encapsulation-proxies or their respective policy planes.

SB> I am not sure what it means to allocate metadata. Do you mean
SB> MD storage, or MD packet space?

 5.3.  Resource Control

   The SFC system may be responsible for managing all resources
   necessary for the SFC components to function.  This includes network
   constraints used to plan and choose network path(s) between service
   function forwarders, network communication paths between service
   function forwarders and their attached service functions,
   characteristics of the nodes themselves such as memory, number of
   virtual interfaces, routes, and instantiation, configuration, and
   deletion of SFs.

   The SFC system will also be required to reflect policy decisions
   about resource control, as expressed by other components in the
   system.

   While all of these aspects are part of the overall system, they are
   beyond the scope of this architecture.


SB> The relationship between the RC/RM and the CP seems unclear.

 5.4.  Infinite Loop Detection and Avoidance

   This SFC architecture is predicated on topological independence from
   the underlying forwarding topology.  Consequently, a service topology
   is created by Service Function Paths or by the local decisions of the
   Service Function Forwarders based on the constraints expressed in the
   SFP. =20

SB> The concept of service topologies and overlays would be useful much =
earlier in the text.

   Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once.  The Service
   Chaining solution needs to permit these limited and policy-compliant
   loops.  At the same time, the solutions must ensure that indefinite
   and unbounded loops cannot be formed, as such would consume unbounded
   resources without delivering any value.

   In other words, this architecture prevents infinite Service Function
   Loops, even when Service Functions may be invoked multiple times in
   the same SFP.

SB> You say it does, but I don't see how it does it. Do you anticipate
SB> it happening in the CP or the DP or both?
SB>=20



 Halpern & Pignataro      Expires March 24, 2015                [P=
age 19]
=0C
Internet-Draft              SFC Architecture              September 2014


5.5.  Load Balancing Considerations

   Supporting function elasticity and high-availability should not
   overly complicate SFC or lead to unnecessary scalability problems.

   In the simplest case, where there is only a single function in the
   SFP (the next hop is either the destination address of the flow or
   the appropriate next hop to that destination), one could argue that
   there may be no need for SFC.

SB> It is unusual to lead with the dejenerate case (i.e. no SFC)

   In the cases where the classifier is separate from the single
   function or a function at the terminal address may need sub-prefix or
   per-subscriber metadata, a single SFP exists (the metadata changes
   but the SFP does not), regardless of the number of potential terminal
   addresses for the flow.  This is the case of the simple load
   balancer.  See Figure 4.

                            +---+    +---++--->web s=
erver
                  source+-->|sff|+-->|sf1|+--->web ser=
ver
                            +---+    +---++--->web s=
erver

                      Figure 4: Simple Load Balancing

   By extrapolation, in the case where intermediary functions within a
   chain had similar "elastic" behaviors, we do not need separate=
 chains
   to account for this behavior - as long as the traffic coalesces to a
   common next-hop after the point of elasticity.

   In Figure 5, we have a chain of five service functions between the
   traffic source and its destination.

                +---+ +---+ +---+   +---+ &=
#43;---+ +---+
                |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                +---+ +---+ +---+   +---+ &=
#43;---+ +---+
                  |     |     |       |     |     |
                  +-----+-----+       +-----+-----+
                        |                   |
                        +                   +
             +---+    +---+     +---+     +---&=
#43;    +---+
   source+-->|sff|+-->|sff|+--->|sff|+--->|sff|=
+-->|sff|+-->destination
             +---+    +---+     +---+     +---&=
#43;    +---+
               +                  +                  +
               |                  |                  |
             +---+              +---+              +---=
+
             |sf1|              |sf3|              |sf5|
             +---+              +---+              +---=
+

                         Figure 5: Load Balancing



Halpern & Pignataro      Expires March 24, 2015                [Page 20=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   This would be represented as one service function path:
   sf1->sf2->sf3->sf4->sf5.  The SFF is a logical element, whic=
h may be
   made up of one or multiple components.  In this architecture, the SFF
   may handle load distribution based on policy.

   It can also be seen in the above that the same service function may
   be reachable through multiple SFFs, as discussed earlier.  The
   selection of which SFF to use to reach SF3 may be made by the control
   logic in defining the SFP, or may be left to the SFFs themselves,
   depending upon policy, solution, and deployment constraints.  In the
   latter case, it needs to be assured that exactly one SFF takes
   responsibility to steer traffic through SF3.


SB> Shouldn't the architecture lead with the general case and note
SB> that any function can be replaced with the null function.

 5.6.  MTU and Fragmentation Considerations

   This architecture prescribes additional information being added to
   packets to identify service function paths and often to represent
   metadata.  It also envisions adding transport information to carry
   packets along service function paths, at least between service
   function forwarders.  This added information increases the size of
   the packet to be carried by service chaining.  Such additions could
   potentially increase the packet size beyond the MTU supported on some
   or all of the media used in the service chaining domain.

   Such packet size increases can thus cause operational MTU problems.
   Requiring fragmentation and reassembly in an SFF would be a major
   processing increase, and might be impossible with some transports.

SB> Sure but the SFE is teh network layer of the SFC plane and could
SB> do this.

   Expecting service functions to deal with packets fragmented by the
   SFC function might be onerous even when such fragmentation was
   possible.  Thus, at the very least, solutions need to pay attention
   to the size cost of their approach.  There may be alternative or
   additional means available, although any solution needs to consider
   the tradeoffs.

   These considerations apply to any generic architecture that increases
   the header size.  There are also more specific MTU considerations:
   Effects on Path MTU Discovery (PMTUD) as well as deployment
   considerations.  Deployments within a single administrative control
   or even a single Data Center complex can afford more flexibility in
   dealing with larger packets, and deploying existing mitigations that
   decrease the likelihood of fragmentation or discard.

5.7.  SFC OAM

   Operations, Administration, and Maintenance (OAM) tools are an
   integral part of the architecture.  These serve various purposes,
   including fault detection and isolation, and performance management.
   For example, there are many advantages of SFP liveness detection,



Halpern & Pignataro      Expires March 24, 2015                [Page 21=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   including status reporting, support for resiliency operations and
   policies, and an enhanced ability to balance load.

   Service Function Paths create a services topology, and OAM performs
   various functions within this service layer.  Furthermore, SFC OAM
   follows the same architectural principles of SFC in general.  For
   example, topological independence (including the ability to run OAM
   over various overlay technologies) and classification-based policy.

   We can subdivide the SFC OAM architecture in two parts:

   o  In-band: OAM packets follow the same path and share fate with user
      packets, within the service topology.  For this, they also follow
      the architectural principle of consistent policy identifiers, and
      use the same path IDs as the service chain data packets.  Load
      balancing and SFC encapsulation with packet forwarding are
      particularly important here.

   o  Out-of-band: reporting beyond the actual data plane.  An
      additional layer beyond the data-plane OAM allows for additional
      alerting and measurements.

   This architecture prescribes end-to-end SFP OAM functions, which
   implies SFF understanding of whether an in-band packet is an OAM or
   user packet.  However, service function validation is outside of the
   scope of this architecture, and application-level OAM is not what
   this architecture prescribes.

   Some of the detailed functions performed by SFC OAM include fault
   detection and isolation in a Service Function Path or a Service
   Function, verification that connectivity using SFPs is both effective
   and directing packets to the intended service functions, service path
   tracing, diagnostic and fault isolation, alarm reporting, performance
   measurement, locking and testing of service functions, validation
   with the control plane (see Section 5.2), and also allow for vendor-
   specific as well as experimental functions.  SFC should leverage, and
   if needed extend relevant existing OAM mechanisms.

5.8.  Resilience and Redundancy

   As a practical operational requirement, any service chaining solution
   needs to be able to respond effectively, and usually very quickly, to
   failure conditions.  These may be failures of connectivity in the
   network between SFFs, failures of SFFs, or failures of SFs.  Per-SF
   state, as for example stateful-firewall state, is the responsibility
   of the SF, and not addressed by this architecture.





Halpern & Pignataro      Expires March 24, 2015                [Page 22=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   Multiple techniques are available to address this issue.  Solutions
   can describe both what they require and what they allow to address
   failure.  Solutions can make use of flexible specificity of service
   function paths, if the SFF can be given enough information in a
   timely fashion to do this.  Solutions can also make use of MAC or IP
   level redundancy mechanisms such as VRRP.  Also, particularly for SF
   failures, load balancers co-located with the SFF or as part of the
   service function delivery mechanism can provide such robustness.

   Similarly, operational requirements imply resilience in the face of
   load changes.  While mechanisms for managing (e.g., monitoring,
   instantiating, loading images, providing configuration to service
   function chaining control, deleting, etc.) virtual machines are out
   of scope for this architecture, solutions can and are aided by
   describing how they can make use of scaling mechanisms.


SB> Given that we are introducing a new network layer construct includin=
g
SB> something that is or is a very close cousin to a network layer, sure=
ly
SB> we are missing an opportunity by not including this on day one.


 6.  Security Considerations

   This document does not define a new protocol and therefore creates no
   new security issues.

   Security considerations apply to the realization of this
   architecture.  Such realization ought to provide means to protect the
   SFC-enabled domain and its borders against various forms of attacks,
   including DDoS attacks.  Further, SFC OAM Functions need to not
   negatively affect the security considerations of an SFC-enabled
   domain.  Additionally, all entities (software or hardware)
   interacting with the service chaining mechanisms need to provide
   means of security against malformed, poorly configured (deliberate or
   not) protocol constructs and loops.  These considerations are largely
   the same as those in any network, particularly an overlay network.


SB> I just don't buy this for a security analysis. The Architecture need=
s
SB> direct the compenent designers to look at security issues associated
SB> with the new components and functionality being introduced.
SB> For example the SFE will have special considerations, so will the=20
SB> the path changes that you talk about earlier. Then there is resource
SB> conflicts and their impact as a security problem. Then there is the=
=20
SB> issue of privacy. Really each component of the ach needs to be looke=
d
SB> at from a security PoV and guidance provided to the component design=
er.

- Stewart
 


--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_bu=
siness/legal/cri/index.html

--_000_8360A86FCD1D42DD98FAE3124818A6DAciscocom_-- From nobody Wed Nov 12 20:07:55 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B8C1A1B57 for ; Wed, 12 Nov 2014 20:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ue3qs35-cw_7 for ; Wed, 12 Nov 2014 20:07:46 -0800 (PST) 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 62BB71A1B53 for ; Wed, 12 Nov 2014 20:07:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLO56646; Thu, 13 Nov 2014 04:07:36 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Nov 2014 04:07:34 +0000 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.21]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Thu, 13 Nov 2014 12:07:30 +0800 From: "Songhaibin (A)" To: Ron Parker , "huang@sce.carleton.ca" , "'Thomas Narten'" Thread-Topic: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP/IzhfXKlyZeB6UeBCwDsehdmW5xZcHOAgACIv4CAA/xScA== Date: Thu, 13 Nov 2014 04:07:29 +0000 Message-ID: References: <034801cffcf7$d549d0e0$7fdd72a0$@carleton.ca> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.49] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Sk333DJIiMnSgZTfFUKkOQyEd-0 Cc: "sfc@ietf.org" Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 13 Nov 2014 04:07:52 -0000 Agree with Ron here. Best Regards! -Haibin > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Ron Parker > Sent: Tuesday, November 11, 2014 7:15 AM > To: huang@sce.carleton.ca; 'Thomas Narten' > Cc: sfc@ietf.org > Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt >=20 > Chang, >=20 > I agree that after all is said and done with SFC, it will make much more = sense > for a reader to view a single use case document to provide the context as= to > why the architecture and protocols turned out the way they did. >=20 > Ron >=20 >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Changcheng Huang > Sent: Monday, November 10, 2014 10:06 AM > To: 'Thomas Narten' > Cc: sfc@ietf.org > Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt >=20 > Hi Thomas, >=20 > I appreciate that you clearly state your questions and concerns. This wil= l be > very helpful for the working group to move forward. With due respect, I h= ave > some brief comments. >=20 > 1. The WG has approved three use case documents as internet-draft. Howeve= r > there were still some heated discussions about service path forking, whic= h has > not been clearly addressed by the three use case documents. This leads to= a > question about whether we have really understood all important use cases = and > their impacts. I share your comments on IETF's reluctance to pass a large > number of low quality RFCs. There is very little chance that these three = use > cases will all become RFCs. It will also look strange for a reader outsid= e the WG > to read three use case documents instead of one. IMHO, the WG should > generate a merged use case document that gets the supports across the > working group. To this end, this draft use case document in question can = be a > good starting point. I hope, as the chair, you can help lead the WG to re= ach > consensus rather than majority votes as the WG has been doing. >=20 > 2. About Item 6 in your email, I know the WG has limited its scope to a s= ingle > administrative domain. This is fine if the protocols developed by this wo= rking > group can be easily extended to multiple domains in future. > However, some of the existing protocol proposals in the WG are quite rigi= d and > hard to extend. This will likely make those protocols short-lived. As you= said in > the earlier email, it is in the best interest of this WG to develop good = quality > protocols that can stand the test of time. In Section > 2.9 of the problem statement document that is currently being approved by > IETF, crossing administrative boundaries is considered important for prov= iding > end-to-end service visibility. This is a good comment for taking the big = picture > into account. More information about recursive SFC can be found in > draft-huang-sfc-use-case-recursive-service-00. >=20 > Best regards, >=20 > Chang >=20 > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > Sent: Sunday, November 09, 2014 9:18 PM > To: sfc@ietf.org > Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt >=20 > Note: chair hat off. >=20 > I have a number of concerns with the document, including: >=20 > 1) I don't see what significant content it has beyond what the other WG u= se > case documents contain. >=20 > 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this = section is > trying to say. Is it saying SFC needs TE? Or TE needs SFC? And how is th= at a > "use case"? TE already exists. Does the addition of SFC somehow change > things? >=20 > 3) Section 4.4 seems to simply say that some SFC flows are bi-directional= . > That has been an assumption in SFC from the start. Doesn't the problem > statement/architecture say as much? >=20 > 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm n= ot sure > what use case has Ethernet in it or why that is called out. SFC can run o= ver > Ethernet so long as it is also an IP subnet. Or is this section trying to= say > something else? If so, what? >=20 > 5) Section 4.6 talks about service path forking. The WG has discussed "fo= rking" > multiple times, and it's a basic part of SFC. So what exactly is this sec= tion that > isn't covered elsewhere? >=20 > 6) I don't follow or understand the "recursive SFC" section. When it talk= s about > different service providers, I have to wonder how that applies to SFC, g= iven > our scope is restricted to a single administrative domain. But more to th= e point, > how does "recursive" > differ from straightforward SFC usage, where different subscribers use > different service chains? >=20 > Thomas >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Thu Nov 13 11:27:11 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0E61ACD5B for ; Thu, 13 Nov 2014 11:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KQjWBPnTRgLe for ; Thu, 13 Nov 2014 11:27:04 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0791.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:791]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7270A1ACD4D for ; Thu, 13 Nov 2014 11:24:20 -0800 (PST) Received: from BLUPR05MB385.namprd05.prod.outlook.com (10.141.26.11) by BLUPR05MB149.namprd05.prod.outlook.com (10.255.190.150) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 19:23:58 +0000 Received: from BLUPR05MB386.namprd05.prod.outlook.com (10.141.26.20) by BLUPR05MB385.namprd05.prod.outlook.com (10.141.26.11) with Microsoft SMTP Server (TLS) id 15.1.16.15; Thu, 13 Nov 2014 19:23:56 +0000 Received: from BLUPR05MB386.namprd05.prod.outlook.com ([169.254.5.244]) by BLUPR05MB386.namprd05.prod.outlook.com ([169.254.5.244]) with mapi id 15.01.0016.006; Thu, 13 Nov 2014 19:23:56 +0000 From: Sankar Ramamoorthi To: "sfc@ietf.org" Thread-Topic: SF and SFC awareness Thread-Index: AQHP/3dbosJys//B9EKh88oBvcseuA== Date: Thu, 13 Nov 2014 19:23:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB385;UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB385; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(106116001)(107886001)(2351001)(87936001)(101416001)(74316001)(107046002)(54356999)(229853001)(95666004)(99286002)(19580395003)(50986999)(106356001)(86362001)(2656002)(105586002)(46102003)(21056001)(76576001)(122556002)(2501002)(99396003)(62966003)(110136001)(77156002)(66066001)(77096003)(4396001)(108616004)(450100001)(33646002)(97736003)(20776003)(120916001)(64706001)(40100003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB385; H:BLUPR05MB386.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB149; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/aSyra0VDoeoGidT10s4W7x_6E2Y Subject: [sfc] SF and SFC awareness X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 13 Nov 2014 19:27:06 -0000 Hi, I just recently joined the SFC mailing list and catching up on SFC drafts. Please bear with me if these questions have been already discussed. A basic question on SFC architecture (draft-ietf-sfc-architecture-02.txt) To what extent an SF should be aware of SFC or SFP. The possible scenarios I see are a) SF is completely unaware of SFC/SFP that it is participating in. Many e= xisting SF functions may fall in this category. b) SF is aware of SFP to the extent that it can support a simple construct= such an interface-pair per SFP (left interface, right interface), where SF= will take responsibility to ensure packets arriving on the left interface = will be sent to right interface and vice-versa. SF itself is not aware of S= FP beyond following the rules of the simple construct (interface-pair). c) SF is aware of SFP by being able to parse and preserve a special heade= r (nsh) to gleam information about the SFP it is participating in and refle= cting it back to SFF when transmitting the packets. d) SF is aware of SFC as a opaque entity through OAM and can pick an SFC (o= paque value) through policy decisions.=20 e) SF is aware of SFC details through OAM and can influence the selection = of next SF through policy decisions.=20 The question I have is - Is there a need for option e) where SF is aware of next SF in SFC? Should= just treating SFC as a opaque value is sufficient? If these points are already described in some draft please point me to it. Thanks, Sankar From nobody Fri Nov 14 14:50:58 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DD31AD2DF for ; Fri, 14 Nov 2014 14:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 ENyWkApg-VzT for ; Fri, 14 Nov 2014 14:50:52 -0800 (PST) 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 1FF041AD151 for ; Fri, 14 Nov 2014 14:50:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOU56364; Fri, 14 Nov 2014 22:50:50 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Nov 2014 22:50:50 +0000 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 14:50:40 -0800 From: Henry Fourie To: "Paul Quinn (paulq)" , Cathy Zhang Thread-Topic: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQgAFqM4CABPPScA== Date: Fri, 14 Nov 2014 22:50:40 +0000 Message-ID: <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com> In-Reply-To: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.75] Content-Type: multipart/alternative; boundary="_000_0F8583BBE82FA449A8B78417CC07559AAA75F9SJCEML701CHMchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/bH6iGofoK_0shV0XknfU0Az0A1A Cc: "Dolganow, Andrew \(Andrew\)" , "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 14 Nov 2014 22:50:56 -0000 --_000_0F8583BBE82FA449A8B78417CC07559AAA75F9SJCEML701CHMchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Paul, Ron Parker and I met with Surendra Kumar and Jim Guichard in Honolulu to di= scuss the merge of the NSH and SCH drafts. There was agreement on the base header that contains the SFP ID. The meeting was productive and the differences between the two drafts were = discussed including options for handling the mandatory fields in the NSH. Jim stated that he wants the authors of both drafts to work together and re= ach agreement on a single merged draft before the next IETF meeting in Dallas. There was = agreement for the authors of both drafts to work together to resolve differences and = create a unified draft. Surendra, Ron, Jim, please add any further comments. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 11, 2014 5:15 AM To: Cathy Zhang Cc: Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context H= eaders remains the only option for NSH Cathy, We need to be accurate here: there was no "conclusion" to merge drafts, rat= her your co-author presented some slides that highlighted what you and your= co-authors feels are areas of similarity and suggested that a merge should= occur. We - the NSH co-authors - are happy to discuss this with you (and = are actively doing so) to see if we can reach an agreement on joint text in= order to ensure that we meet the WG goals" Thanks Paul On Nov 10, 2014, at 4:49 PM, Cathy Zhang > wrote: Hi Andrew, Thanks for bringing this up. As authors of another service chain header dra= ft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your= proposal. Your proposal is in sync with our service chain header draft, i.e., besides= the base header and path header, all other information can be expressed as= optional metadata in TLV format. Last IETF meeting's conclusion is to merge the two header drafts----NSH dra= ft and SCH draft. We have reached out to the NSH authors about doing the m= erging as well as addressing the comments/opinions voiced in the Toronto IE= TF meeting and email alias. Thanks, SCH authors From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andr= ew) Sent: Tuesday, November 04, 2014 8:12 AM To: sfc@ietf.org Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Heade= rs remains the only option for NSH During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_0F8583BBE82FA449A8B78417CC07559AAA75F9SJCEML701CHMchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Paul,

Ron Parker and I met with Surendra Kumar and Jim Gui= chard in Honolulu to discuss

the merge of the NSH and SCH drafts.

 

There was agreement on the base header that contains= the SFP ID.

 

The meeting was productive and the differences betwe= en the two drafts were discussed

including options for handling the mandatory fields = in the NSH.

 

Jim stated that he wants the authors of both drafts = to work together and reach agreement

on a single merged draft before the next IETF meetin= g in Dallas. There was agreement

for the authors of both drafts to work together to r= esolve differences and create

a unified draft.

 

Surendra, Ron, Jim, please add any further comments.=

 

-       = ;   Louis

 <= /p>

 <= /p>

From: sfc [mai= lto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 11, 2014 5:15 AM
To: Cathy Zhang
Cc: Dolganow, Andrew (Andrew); sfc@ietf.org
Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Ma= ndatory Context Headers remains the only option for NSH

 

Cathy, 

We need to be accurate here: there was no “conclusion” to merge= drafts, rather your co-author presented some slides that highlighted what = you and your co-authors feels are areas of similarity and suggested that a = merge should occur.  We — the NSH co-authors — are happy to discuss this with you (and are actively doing so) to = see if we can reach an agreement on joint text in order to ensure that we m= eet the WG goals”

Thanks
Paul

 

 

On Nov 10, 2014, at 4:49 PM, Cathy Zhang <Cathy.H.Zhang@huawei.com> wrote= :



Hi Andrew,

 

Thanks for bringing this = up. As authors of another service chain header draft (https://datatracker.ietf.org/doc/draft-zha= ng-sfc-sch/), we support your proposal.

Your proposal is in sync = with our service chain header draft, i.e., besides the base header and path= header, all other information can be expressed as optional metadata in TLV format.

 

Last IETF meeting’s= conclusion is to merge the two header drafts----NSH draft and SCH draft. &= nbsp;We have reached out to the NSH authors about doing the merging as well as addressing the comments/opinions voiced in the Toronto IETF mee= ting and email alias.  

 

Thanks,

SCH authors

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Dolganow, Andrew (Andrew)
Sent: Tuesday, Nov= ember 04, 2014 8:12 AM
To: sfc@ietf.org
Subject: [sfc] dra= ft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remai= ns the only option for NSH

 

During the last IETF there were several= attendees (including myself) who voice strong opinion against mandatory th= e inclusion of the information beyond based header and service path header. Not all applications require the extra overhead. A discussion= on the list followed (see attached email that initiated that discussion) o= n alternative encodings including mechanisms like use of one of the reserve= d bit or using another MD Type value to represent header without Mandatory Context Headers.

 

Can the authors comment on whether they= are strongly opposed to include in their draft a proposal that has an opti= on to encode the NSH without the Mandatory Context Headers? I am OK with an encoding that either:

  • make= s  Mandatory Context Headers optional or
  • Has two types of NSG MD Type 0x1 - the mandatory context headers a= re present, 0x2 the mandatory context header are not included  (option= al variable length metadata could still be used in that type  of header)=

 

Andrew

 

 

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

 

--_000_0F8583BBE82FA449A8B78417CC07559AAA75F9SJCEML701CHMchina_-- From nobody Fri Nov 14 15:47:24 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005101A88B6 for ; Fri, 14 Nov 2014 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0gJguDdolMl for ; Fri, 14 Nov 2014 15:47:06 -0800 (PST) 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 EBDB11ACF8B for ; Fri, 14 Nov 2014 15:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22576; q=dns/txt; s=iport; t=1416008824; x=1417218424; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=sz2UuUZCs7yPOpQTB1cnL+2v2yC3RnDHMGU+X6z5TyM=; b=GzZ3VfX83gtYyaQdQj5JGCt/30DTKQPawgD/VDFIKO3uMAKxxTEBzJMA LSrCbbAlg0s4u4ronBnwVx+IwuTlHmLF+NTpck+54z5DQBJ0VXP90peYY 7Gr4BPhzRtG1jh3TaexhSgi73jjKtPRrVGZIap/E+Ko8k+a8gT+5HiuTa A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAI+TZlStJA2B/2dsb2JhbABbgkhGVVnMewEJh04CgRsWAQEBAQF9hAIBAQEEAQEBKkELEAIBCA4DBAEBIQMEBycLFAkIAgQOBYhBDdF2AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSQQBEBLCAEBgECgyuBHgWQH4IohFuCS4RfgTSDVI1ohAqCNoFGbQGBDoE8AQEB X-IronPort-AV: E=Sophos;i="5.07,388,1413244800"; d="scan'208,217";a="372369847" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-8.cisco.com with ESMTP; 14 Nov 2014 23:47:02 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id sAENl2iH031153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Nov 2014 23:47:02 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.165]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Fri, 14 Nov 2014 17:47:02 -0600 From: "Jim Guichard (jguichar)" To: Henry Fourie Thread-Topic: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQgAFqM4CABPPScIAAEDkE Date: Fri, 14 Nov 2014 23:47:01 +0000 Message-ID: References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com>, <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> In-Reply-To: <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D31A63DB6E5E413F8714A10036A6D8A7ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/NRvXzHKX7K0DLGUrBAuRSDTM2X0 Cc: "Dolganow, Andrew \(Andrew\)" , Cathy Zhang , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 14 Nov 2014 23:47:14 -0000 --_000_D31A63DB6E5E413F8714A10036A6D8A7ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Just to clarify the expectation of the chairs; what we want to see is a res= olution of any differences so that we can move forward with the SFC encapsu= lation. Jim Sent from my iPhone On Nov 14, 2014, at 12:51 PM, "Henry Fourie" > wrote: Paul, Ron Parker and I met with Surendra Kumar and Jim Guichard in Honolulu to di= scuss the merge of the NSH and SCH drafts. There was agreement on the base header that contains the SFP ID. The meeting was productive and the differences between the two drafts were = discussed including options for handling the mandatory fields in the NSH. Jim stated that he wants the authors of both drafts to work together and re= ach agreement on a single merged draft before the next IETF meeting in Dallas. There was = agreement for the authors of both drafts to work together to resolve differences and = create a unified draft. Surendra, Ron, Jim, please add any further comments. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 11, 2014 5:15 AM To: Cathy Zhang Cc: Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context H= eaders remains the only option for NSH Cathy, We need to be accurate here: there was no =93conclusion=94 to merge drafts,= rather your co-author presented some slides that highlighted what you and = your co-authors feels are areas of similarity and suggested that a merge sh= ould occur. We =97 the NSH co-authors =97 are happy to discuss this with y= ou (and are actively doing so) to see if we can reach an agreement on joint= text in order to ensure that we meet the WG goals=94 Thanks Paul On Nov 10, 2014, at 4:49 PM, Cathy Zhang > wrote: Hi Andrew, Thanks for bringing this up. As authors of another service chain header dra= ft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your= proposal. Your proposal is in sync with our service chain header draft, i.e., besides= the base header and path header, all other information can be expressed as= optional metadata in TLV format. Last IETF meeting=92s conclusion is to merge the two header drafts----NSH d= raft and SCH draft. We have reached out to the NSH authors about doing the= merging as well as addressing the comments/opinions voiced in the Toronto = IETF meeting and email alias. Thanks, SCH authors From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andr= ew) Sent: Tuesday, November 04, 2014 8:12 AM To: sfc@ietf.org Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Heade= rs remains the only option for NSH During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_D31A63DB6E5E413F8714A10036A6D8A7ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Just to clarify the expectation of the chairs; what we want to see is = a resolution of any differences so that we can move forward with the SFC en= capsulation. 

Jim

Sent from my iPhone

On Nov 14, 2014, at 12:51 PM, "Henry Fourie" <louis.fourie@huawei.com> wrote:

Paul,

Ron Parker and I met with Surendra Kumar and Jim Gui= chard in Honolulu to discuss

the merge of the NSH and SCH drafts.

 

There was agreement on the base header that contains= the SFP ID.

 

The meeting was productive and the differences betwe= en the two drafts were discussed

including options for handling the mandatory fields = in the NSH.

 

Jim stated that he wants the authors of both drafts = to work together and reach agreement

on a single merged draft before the next IETF meetin= g in Dallas. There was agreement

for the authors of both drafts to work together to r= esolve differences and create

a unified draft.

 

Surendra, Ron, Jim, please add any further comments.=

 

-      &= nbsp;   Louis

 <= /p>

 <= /p>

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 11, 2014 5:15 AM
To: Cathy Zhang
Cc: Dolganow, Andrew (Andrew); sfc@i= etf.org
Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Ma= ndatory Context Headers remains the only option for NSH

 

Cathy, 

We need to be accurate here: there was no =93conclusion=94 to merge drafts,= rather your co-author presented some slides that highlighted what you and = your co-authors feels are areas of similarity and suggested that a merge sh= ould occur.  We =97 the NSH co-authors =97 are happy to discuss this with you (and are actively doing so) to see = if we can reach an agreement on joint text in order to ensure that we meet = the WG goals=94

Thanks
Paul

 

 

On Nov 10, 2014, at 4:49 PM, Cathy Zhang <Cathy.H.Zhang@huawei.com> wrote= :



Hi Andrew,

 

Thanks for bringing this = up. As authors of another service chain header draft (https://datatracker.ietf.org/doc/draft-zha= ng-sfc-sch/), we support your proposal.

Your proposal is in sync = with our service chain header draft, i.e., besides the base header and path= header, all other information can be expressed as optional metadata in TLV format.

 

Last IETF meeting=92s con= clusion is to merge the two header drafts----NSH draft and SCH draft.  = ;We have reached out to the NSH authors about doing the merging as well as addressing the comments/opinions voiced in the Toronto IETF mee= ting and email alias.  

 

Thanks,

SCH authors

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Dolganow, Andrew (Andrew)
Sent: Tuesday, Nov= ember 04, 2014 8:12 AM
To: sfc@ietf.org
Subject: [sfc] dra= ft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remai= ns the only option for NSH

 

During the last IETF there were several= attendees (including myself) who voice strong opinion against mandatory th= e inclusion of the information beyond based header and service path header. Not all applications require the extra overhead. A discussion= on the list followed (see attached email that initiated that discussion) o= n alternative encodings including mechanisms like use of one of the reserve= d bit or using another MD Type value to represent header without Mandatory Context Headers.

 

Can the authors comment on whether they= are strongly opposed to include in their draft a proposal that has an opti= on to encode the NSH without the Mandatory Context Headers? I am OK with an encoding that either:

  • make= s  Mandatory Context Headers optional or
  • Has two types of NSG MD Type 0x1 - the mandatory context headers a= re present, 0x2 the mandatory context header are not included  (option= al variable length metadata could still be used in that type  of header)=

 

Andrew

 

 

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

 

_______________________________________________
sfc mailing list
sfc@ietf.org
https://www.iet= f.org/mailman/listinfo/sfc
--_000_D31A63DB6E5E413F8714A10036A6D8A7ciscocom_-- From nobody Fri Nov 14 19:37:28 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A141A1A60 for ; Fri, 14 Nov 2014 19:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqi_bmBV0JuZ for ; Fri, 14 Nov 2014 19:37:23 -0800 (PST) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10581A1A46 for ; Fri, 14 Nov 2014 19:37:22 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0174.001; Fri, 14 Nov 2014 19:37:22 -0800 From: Ron Parker To: "Jim Guichard (jguichar)" , Henry Fourie Thread-Topic: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQgAFqM4CABPPScIAAEDkEgAA/wWA= Date: Sat, 15 Nov 2014 03:37:21 +0000 Message-ID: References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com>, <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.137.59] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7613CCMBX021W3CA2exch_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/ns7MwkDmZ5Vatl-bHktmwA3BddA Cc: Cathy Zhang , "Dolganow, Andrew \(Andrew\)" , "Paul Quinn \(paulq\)" , "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 15 Nov 2014 03:37:27 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7613CCMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll add that Surendra graciously agreed to re-read the SCH proposal and pr= ovide comments back to the SCH authors. Ron From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar= ) Sent: Friday, November 14, 2014 6:47 PM To: Henry Fourie Cc: Dolganow, Andrew (Andrew); Cathy Zhang; Paul Quinn (paulq); sfc@ietf.or= g Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context H= eaders remains the only option for NSH Just to clarify the expectation of the chairs; what we want to see is a res= olution of any differences so that we can move forward with the SFC encapsu= lation. Jim Sent from my iPhone On Nov 14, 2014, at 12:51 PM, "Henry Fourie" > wrote: Paul, Ron Parker and I met with Surendra Kumar and Jim Guichard in Honolulu to di= scuss the merge of the NSH and SCH drafts. There was agreement on the base header that contains the SFP ID. The meeting was productive and the differences between the two drafts were = discussed including options for handling the mandatory fields in the NSH. Jim stated that he wants the authors of both drafts to work together and re= ach agreement on a single merged draft before the next IETF meeting in Dallas. There was = agreement for the authors of both drafts to work together to resolve differences and = create a unified draft. Surendra, Ron, Jim, please add any further comments. - Louis From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq) Sent: Tuesday, November 11, 2014 5:15 AM To: Cathy Zhang Cc: Dolganow, Andrew (Andrew); sfc@ietf.org Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context H= eaders remains the only option for NSH Cathy, We need to be accurate here: there was no "conclusion" to merge drafts, rat= her your co-author presented some slides that highlighted what you and your= co-authors feels are areas of similarity and suggested that a merge should= occur. We - the NSH co-authors - are happy to discuss this with you (and = are actively doing so) to see if we can reach an agreement on joint text in= order to ensure that we meet the WG goals" Thanks Paul On Nov 10, 2014, at 4:49 PM, Cathy Zhang > wrote: Hi Andrew, Thanks for bringing this up. As authors of another service chain header dra= ft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your= proposal. Your proposal is in sync with our service chain header draft, i.e., besides= the base header and path header, all other information can be expressed as= optional metadata in TLV format. Last IETF meeting's conclusion is to merge the two header drafts----NSH dra= ft and SCH draft. We have reached out to the NSH authors about doing the m= erging as well as addressing the comments/opinions voiced in the Toronto IE= TF meeting and email alias. Thanks, SCH authors From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Dolganow, Andrew (Andr= ew) Sent: Tuesday, November 04, 2014 8:12 AM To: sfc@ietf.org Subject: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Heade= rs remains the only option for NSH During the last IETF there were several attendees (including myself) who vo= ice strong opinion against mandatory the inclusion of the information beyon= d based header and service path header. Not all applications require the ex= tra overhead. A discussion on the list followed (see attached email that in= itiated that discussion) on alternative encodings including mechanisms like= use of one of the reserved bit or using another MD Type value to represent= header without Mandatory Context Headers. Can the authors comment on whether they are strongly opposed to include in = their draft a proposal that has an option to encode the NSH without the Man= datory Context Headers? I am OK with an encoding that either: * makes Mandatory Context Headers optional or * Has two types of NSG MD Type 0x1 - the mandatory context headers are = present, 0x2 the mandatory context header are not included (optional varia= ble length metadata could still be used in that type of header) Andrew _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc _______________________________________________ sfc mailing list sfc@ietf.org https://www.ietf.org/mailman/listinfo/sfc --_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7613CCMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll add that Surendra gracious= ly agreed to re-read the SCH proposal and provide comments back to the SCH = authors.

 

    Ron

 

&nbs= p;

From: sfc [mailto:sfc-bounces@ietf.o= rg] On Behalf Of Jim Guichard (jguichar)
Sent: Friday, November 14, 2014 6:47 PM
To: Henry Fourie
Cc: Dolganow, Andrew (Andrew); Cathy Zhang; Paul Quinn (paulq); sfc@= ietf.org
Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Ma= ndatory Context Headers remains the only option for NSH

 

Just to clarify the expectation of the chairs; what = we want to see is a resolution of any differences so that we can move forwa= rd with the SFC encapsulation. 

 

Jim

Sent from my iPhone


On Nov 14, 2014, at 12:51 PM, "Henry Fourie" <louis.fourie@huawei.com> wrote:

Paul,

Ron Parker and I met with Surendra Kumar and Jim Gui= chard in Honolulu to discuss

the merge of the NSH and SCH drafts.

 

There was agreement on the base header that contains= the SFP ID.

 

The meeting was productive and the differences betwe= en the two drafts were discussed

including options for handling the mandatory fields = in the NSH.

 

Jim stated that he wants the authors of both drafts = to work together and reach agreement

on a single merged draft before the next IETF meetin= g in Dallas. There was agreement

for the authors of both drafts to work together to r= esolve differences and create

a unified draft.

 

Surendra, Ron, Jim, please add any further comments.=

 

-       = ; Louis

 

 

From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Paul Quinn (paulq)
Sent: Tuesday, November 11, 2014 5:15 AM
To: Cathy Zhang
Cc: Dolganow, Andrew (Andrew); sfc@i= etf.org
Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Ma= ndatory Context Headers remains the only option for NSH

 

Cathy, 

We need to be accurate here: there was no “conclusion” to merge= drafts, rather your co-author presented some slides that highlighted what = you and your co-authors feels are areas of similarity and suggested that a = merge should occur.  We — the NSH co-authors — are happy to discuss this with you (and are actively doing so) to = see if we can reach an agreement on joint text in order to ensure that we m= eet the WG goals”

Thanks
Paul

 

 

On Nov 10, 2014, at 4:49 PM, Cathy Zhang <Cathy.H.Zhang@huawei.com> wrote= :




Hi Andrew,

 

Thanks for bringing this up. As autho= rs of another service chain header draft (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support your proposal.

Your proposal is in sync with our ser= vice chain header draft, i.e., besides the base header and path header, all= other information can be expressed as optional metadata in TLV format.

 

Last IETF meeting’s conclusion = is to merge the two header drafts----NSH draft and SCH draft.  We have= reached out to the NSH authors about doing the merging as well as addressing the comments/opinions voiced in the Toronto IETF meetin= g and email alias.  

 

Thanks,

SCH authors

 

 

From: sfc [mail= to:sfc-bounces@ietf.org]&n= bsp;On Behalf Of Dolganow, Andrew (Andrew)
Sent: Tuesday, Nov= ember 04, 2014 8:12 AM
To: sfc@ietf.org
Subject: [sfc] dra= ft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remai= ns the only option for NSH

 

During the last IETF there were several attendees (= including myself) who voice strong opinion against mandatory the inclusion = of the information beyond based header and service path header. Not all applications require the extra overhead. A discussion= on the list followed (see attached email that initiated that discussion) o= n alternative encodings including mechanisms like use of one of the reserve= d bit or using another MD Type value to represent header without Mandatory Context Headers.

 

Can the authors comment on whether they are strongl= y opposed to include in their draft a proposal that has an option to encode= the NSH without the Mandatory Context Headers? I am OK with an encoding that either:

  • makes  Mand= atory Context Headers optional or
  • Has two types of NSG MD Type 0x1 - = the mandatory context headers are present, 0x2 the mandatory context header= are not included  (optional variable length metadata could still be used in that type  of header)=

 

Andrew

 

 

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

 

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

--_000_CDF2F015F4429F458815ED2A6C2B6B0B2E7613CCMBX021W3CA2exch_-- From nobody Sat Nov 15 13:39:35 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8536B1A87CD for ; Sat, 15 Nov 2014 13:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ig4VsBqiiMXK for ; Sat, 15 Nov 2014 13:39:32 -0800 (PST) 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 A55691A87A1 for ; Sat, 15 Nov 2014 13:39:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1407; q=dns/txt; s=iport; t=1416087571; x=1417297171; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bOQi+mbf37YTRA6/Vh/TqiHIgnNcvUD0bbs0XHFhnIM=; b=HHbKnTsFVvfYvhupYEmeKbOmE3FrlLGjdCp2Ft3JgL6xqEU1A/3DwAHi evphzRdEavdiiW5bpeIY+aXSfgw336+K16CfiKrrlRql/qXLggKAoJXxH fgzgvTlxsEPjTgbB1tQvYS1pRkgbETfALqYy8iwsN8SGCBohteQ8y3XTO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAIbHZ1StJA2L/2dsb2JhbABbgw5VWQTNF4dMAoESFgEBAQEBcguEAwEBBDo9EgIBCDYQMhsBBgMCBBMJiDgN0F4BAQEBAQEEAQEBAQEBARuRKYRLBZJHhFuHKoE0PYMXkXKCNoFGbYFIgQMBAQE X-IronPort-AV: E=Sophos;i="5.07,392,1413244800"; d="scan'208";a="96996366" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP; 15 Nov 2014 21:39:30 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sAFLdUMX028268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 15 Nov 2014 21:39:30 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Sat, 15 Nov 2014 15:39:30 -0600 From: "Surendra Kumar (smkumar)" To: "sfc@ietf.org" Thread-Topic: New Version Notification for draft-napper-sfc-nsh-mobility-allocation-00.txt Thread-Index: AQHP/4tp7oghfgtOWkG+NSQtp5nvzpxiGKUA Date: Sat, 15 Nov 2014 21:39:30 +0000 Message-ID: References: <20141113214712.28259.39214.idtracker@ietfa.amsl.com> In-Reply-To: <20141113214712.28259.39214.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.21.66.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <633542DCFEBC964F8473F878BE95BD96@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/BnjD4FEnje3b_qjBHStbFmuHOY8 Subject: [sfc] FW: New Version Notification for draft-napper-sfc-nsh-mobility-allocation-00.txt X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 21:39:33 -0000 I did not see Jeff forward it; just an FYI. Thanks, Surendra. On 11/13/14 11:47 AM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-napper-sfc-nsh-mobility-allocation-00.txt >has been successfully submitted by Jeffrey Napper and posted to the >IETF repository. > >Name: draft-napper-sfc-nsh-mobility-allocation >Revision: 00 >Title: NSH Context Header Allocation -- Mobility >Document date: 2014-11-13 >Group: Individual Submission >Pages: 5 >URL: =20 >http://www.ietf.org/internet-drafts/draft-napper-sfc-nsh-mobility-allocati >on-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-napper-sfc-nsh-mobility-allocation/ >Htmlized: =20 >http://tools.ietf.org/html/draft-napper-sfc-nsh-mobility-allocation-00 > > >Abstract: > This document provides a recommended allocation of the mandatory > fixed context headers for a Network Service Header (NSH) within the > mobility service provider network context. NSH is described in > detail in [quinn-sfc-nsh]. This allocation is intended to support > uses cases as defined in [ietf-sfc-use-case-mobility]. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Tue Nov 18 04:22:43 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A161A0369 for ; Tue, 18 Nov 2014 04:22:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.013 X-Spam-Level: ** X-Spam-Status: No, score=2.013 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJszA92ZrKL8 for ; Tue, 18 Nov 2014 04:22:39 -0800 (PST) Received: from tama500.ecl.ntt.co.jp (tama500.ecl.ntt.co.jp [129.60.39.148]) by ietfa.amsl.com (Postfix) with ESMTP id 54BE51A0364 for ; Tue, 18 Nov 2014 04:22:32 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama500.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id sAICMVjR027022 for ; Tue, 18 Nov 2014 21:22:31 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 55BC3E00B3 for ; Tue, 18 Nov 2014 21:22:31 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 4A732E00AD for ; Tue, 18 Nov 2014 21:22:31 +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 sAICM1m3020113 for ; Tue, 18 Nov 2014 21:22:31 +0900 Message-ID: <546B3A1A.2070105@lab.ntt.co.jp> Date: Tue, 18 Nov 2014 21:22:50 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com>, <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: sfc@ietf.org X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/2pXtxauCtCXD24pOpZcWMY8bXwE Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Nov 2014 12:22:41 -0000 Hi, I think that we should clarify the merits of SFC encapsulation (e.g. NSH, SCH) without metadata firstly if the context headers are optional. There are several methods to achieve Service Chaining, and SFC is one of them. As one of SFC users, I would like to clarify the motivation to use SFC encapsulation without metadata. In my opinion, scalability is one of the important point of SFC encapsulation, and I summarized the analysis into the following draft. https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/ If you have any other opinions, please let me know. Cheers, Shunsuke (2014/11/15 12:37), Ron Parker wrote: > I’ll add that Surendra graciously agreed to re-read the SCH proposal and > provide comments back to the SCH authors. > > Ron > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard > (jguichar) > *Sent:* Friday, November 14, 2014 6:47 PM > *To:* Henry Fourie > *Cc:* Dolganow, Andrew (Andrew); Cathy Zhang; Paul Quinn (paulq); > sfc@ietf.org > *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory > Context Headers remains the only option for NSH > > Just to clarify the expectation of the chairs; what we want to see is a > resolution of any differences so that we can move forward with the SFC > encapsulation. > > Jim > > Sent from my iPhone > > > On Nov 14, 2014, at 12:51 PM, "Henry Fourie" > wrote: > > Paul, > > Ron Parker and I met with Surendra Kumar and Jim Guichard in > Honolulu to discuss > > the merge of the NSH and SCH drafts. > > There was agreement on the base header that contains the SFP ID. > > The meeting was productive and the differences between the two > drafts were discussed > > including options for handling the mandatory fields in the NSH. > > Jim stated that he wants the authors of both drafts to work together > and reach agreement > > on a single merged draft before the next IETF meeting in Dallas. > There was agreement > > for the authors of both drafts to work together to resolve > differences and create > > a unified draft. > > Surendra, Ron, Jim, please add any further comments. > > -Louis > > *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn > (paulq) > *Sent:* Tuesday, November 11, 2014 5:15 AM > *To:* Cathy Zhang > *Cc:* Dolganow, Andrew (Andrew); sfc@ietf.org > *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory > Context Headers remains the only option for NSH > > Cathy, > > We need to be accurate here: there was no “conclusion” to merge > drafts, rather your co-author presented some slides that highlighted > what you and your co-authors feels are areas of similarity and > suggested that a merge should occur. We — the NSH co-authors — are > happy to discuss this with you (and are actively doing so) to see if > we can reach an agreement on joint text in order to ensure that we > meet the WG goals” > > Thanks > Paul > > On Nov 10, 2014, at 4:49 PM, Cathy Zhang > wrote: > > > > > Hi Andrew, > > Thanks for bringing this up. As authors of another service chain > header draft > (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support > your proposal. > > Your proposal is in sync with our service chain header draft, i.e., > besides the base header and path header, all other information can > be expressed as optional metadata in TLV format. > > Last IETF meeting’s conclusion is to merge the two header > drafts----NSH draft and SCH draft. We have reached out to the NSH > authors about doing the merging as well as addressing the > comments/opinions voiced in the Toronto IETF meeting and email alias. > > Thanks, > > SCH authors > > *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf Of*Dolganow, > Andrew (Andrew) > *Sent:*Tuesday, November 04, 2014 8:12 AM > *To:*sfc@ietf.org > *Subject:*[sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory > Context Headers remains the only option for NSH > > During the last IETF there were several attendees (including myself) > who voice strong opinion against mandatory the inclusion of the > information beyond based header and service path header. Not all > applications require the extra overhead. A discussion on the list > followed (see attached email that initiated that discussion) on > alternative encodings including mechanisms like use of one of the > reserved bit or using another MD Type value to represent header > without Mandatory Context Headers. > > Can the authors comment on whether they are strongly opposed to > include in their draft a proposal that has an option to encode the > NSH without the Mandatory Context Headers? I am OK with an encoding > that either: > > * makes Mandatory Context Headers optional or > * Has two types of NSG MD Type 0x1 - the mandatory context headers > are present, 0x2 the mandatory context header are not included > (optional variable length metadata could still be used in that > type of header) > > Andrew > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > > > > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Tue Nov 18 07:25:00 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E928F1A19E9 for ; Tue, 18 Nov 2014 07:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_28=0.6, 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 BXFdkZLdlcE8 for ; Tue, 18 Nov 2014 07:24:54 -0800 (PST) Received: from hub021-ca-2.exch021.serverdata.net (hub021-ca-2.exch021.serverdata.net [64.78.22.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B09AC1A03FF for ; Tue, 18 Nov 2014 07:24:54 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-2.exch021.domain.local ([10.254.4.33]) with mapi id 14.03.0174.001; Tue, 18 Nov 2014 07:24:53 -0800 From: Ron Parker To: Shunsuke Homma Thread-Topic: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH Thread-Index: AQHP+EoMWv68deqlC0OK9xcMDhwVwpxaa8AQgAFqM4CABPPScIAAEDkEgAA/wWCABdCFAP//rMKm Date: Tue, 18 Nov 2014 15:24:53 +0000 Message-ID: References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com>, <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> , <546B3A1A.2070105@lab.ntt.co.jp> In-Reply-To: <546B3A1A.2070105@lab.ntt.co.jp> 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: http://mailarchive.ietf.org/arch/msg/sfc/FYWzBFG4-ibOYt2INCxp_65mm_0 Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 18 Nov 2014 15:24:58 -0000 Shinsuke-san, One of the goals of SFC is to create a transport-independent service overla= y. This has the effect of reducing the transport visibility to node-to-no= de, only (ie classifier to SFF or SFF to SFF). The SFC header, therefore= , must contain a field of fields that are used for the end to end chain/pat= h forwarding decision.=20 Ron > On Nov 18, 2014, at 7:22 AM, Shunsuke Homma wrote: >=20 > Hi, >=20 > I think that we should clarify the merits of SFC encapsulation (e.g. NSH,= SCH) without metadata firstly if the context headers are optional. >=20 > There are several methods to achieve Service Chaining, and SFC is one of = them. As one of SFC users, I would like to clarify the motivation to use SF= C encapsulation without metadata. >=20 > In my opinion, scalability is one of the important point of SFC encapsul= ation, and I summarized the analysis into the following draft. >=20 > https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analy= sis/ >=20 > If you have any other opinions, please let me know. >=20 > Cheers, > Shunsuke >=20 > (2014/11/15 12:37), Ron Parker wrote: >> I=92ll add that Surendra graciously agreed to re-read the SCH proposal a= nd >> provide comments back to the SCH authors. >>=20 >> Ron >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >> (jguichar) >> *Sent:* Friday, November 14, 2014 6:47 PM >> *To:* Henry Fourie >> *Cc:* Dolganow, Andrew (Andrew); Cathy Zhang; Paul Quinn (paulq); >> sfc@ietf.org >> *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >> Context Headers remains the only option for NSH >>=20 >> Just to clarify the expectation of the chairs; what we want to see is a >> resolution of any differences so that we can move forward with the SFC >> encapsulation. >>=20 >> Jim >>=20 >> Sent from my iPhone >>=20 >>=20 >> On Nov 14, 2014, at 12:51 PM, "Henry Fourie" > > wrote: >>=20 >> Paul, >>=20 >> Ron Parker and I met with Surendra Kumar and Jim Guichard in >> Honolulu to discuss >>=20 >> the merge of the NSH and SCH drafts. >>=20 >> There was agreement on the base header that contains the SFP ID. >>=20 >> The meeting was productive and the differences between the two >> drafts were discussed >>=20 >> including options for handling the mandatory fields in the NSH. >>=20 >> Jim stated that he wants the authors of both drafts to work together >> and reach agreement >>=20 >> on a single merged draft before the next IETF meeting in Dallas. >> There was agreement >>=20 >> for the authors of both drafts to work together to resolve >> differences and create >>=20 >> a unified draft. >>=20 >> Surendra, Ron, Jim, please add any further comments. >>=20 >> -Louis >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >> (paulq) >> *Sent:* Tuesday, November 11, 2014 5:15 AM >> *To:* Cathy Zhang >> *Cc:* Dolganow, Andrew (Andrew); sfc@ietf.org >> *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >> Context Headers remains the only option for NSH >>=20 >> Cathy, >>=20 >> We need to be accurate here: there was no =93conclusion=94 to merge >> drafts, rather your co-author presented some slides that highlighted >> what you and your co-authors feels are areas of similarity and >> suggested that a merge should occur. We =97 the NSH co-authors =97 a= re >> happy to discuss this with you (and are actively doing so) to see if >> we can reach an agreement on joint text in order to ensure that we >> meet the WG goals=94 >>=20 >> Thanks >> Paul >>=20 >> On Nov 10, 2014, at 4:49 PM, Cathy Zhang > > wrote: >>=20 >>=20 >>=20 >>=20 >> Hi Andrew, >>=20 >> Thanks for bringing this up. As authors of another service chain >> header draft >> (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support >> your proposal. >>=20 >> Your proposal is in sync with our service chain header draft, i.e., >> besides the base header and path header, all other information can >> be expressed as optional metadata in TLV format. >>=20 >> Last IETF meeting=92s conclusion is to merge the two header >> drafts----NSH draft and SCH draft. We have reached out to the NSH >> authors about doing the merging as well as addressing the >> comments/opinions voiced in the Toronto IETF meeting and email alias. >>=20 >> Thanks, >>=20 >> SCH authors >>=20 >> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf Of*Dolganow, >> Andrew (Andrew) >> *Sent:*Tuesday, November 04, 2014 8:12 AM >> *To:*sfc@ietf.org >> *Subject:*[sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >> Context Headers remains the only option for NSH >>=20 >> During the last IETF there were several attendees (including myself) >> who voice strong opinion against mandatory the inclusion of the >> information beyond based header and service path header. Not all >> applications require the extra overhead. A discussion on the list >> followed (see attached email that initiated that discussion) on >> alternative encodings including mechanisms like use of one of the >> reserved bit or using another MD Type value to represent header >> without Mandatory Context Headers. >>=20 >> Can the authors comment on whether they are strongly opposed to >> include in their draft a proposal that has an option to encode the >> NSH without the Mandatory Context Headers? I am OK with an encoding >> that either: >>=20 >> * makes Mandatory Context Headers optional or >> * Has two types of NSG MD Type 0x1 - the mandatory context headers >> are present, 0x2 the mandatory context header are not included >> (optional variable length metadata could still be used in that >> type of header) >>=20 >> Andrew >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >>=20 >>=20 >>=20 >> _______________________________________________ >> sfc mailing list >> sfc@ietf.org >> https://www.ietf.org/mailman/listinfo/sfc >=20 >=20 > --=20 > ---------------------------------- > Shunsuke Homma > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 >=20 > NTT Network Service System Labs. > Musashino city, Tokyo, Japan > ---------------------------------- >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Tue Nov 18 10:39:59 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC771A6EE7 for ; Tue, 18 Nov 2014 10:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.094 X-Spam-Level: X-Spam-Status: No, score=-15.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohpPlLSPSwhW for ; Tue, 18 Nov 2014 10:39:49 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B21B11A6EE2 for ; Tue, 18 Nov 2014 10:39:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6186; q=dns/txt; s=iport; t=1416335988; x=1417545588; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=etFkKh3WDpgg48RX3Ezycze/eEJneC6kH+P4Oc+O3pg=; b=CdffOvIV/ZKUWSxinpwgdbTs+h6RkBwdQJtWmkyQB7nbZ35VpChR3O4H SfH25AWdYU+HR9Q0/+ILcK1tFtlu9yyHMGE7E7QxWZbKjtEkuDDqSVRd6 VvY2xf0ZErPBdnm9ANu0BDq/R4TLyKnP/3c2o7nzXDclLrHPIG8zMj9YF Q=; X-IronPort-AV: E=Sophos;i="5.07,411,1413244800"; d="scan'208,217";a="239377618" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 18 Nov 2014 18:39:44 +0000 Received: from [64.103.108.118] (dhcp-bdlk10-data-vlan301-64-103-108-118.cisco.com [64.103.108.118]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id sAIIdhTr002277; Tue, 18 Nov 2014 18:39:43 GMT Message-ID: <546B926F.1070503@cisco.com> Date: Tue, 18 Nov 2014 18:39:43 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <5463BD7D.6000007@cisco.com> <5463C03D.3040202@cisco.com> <8360A86F-CD1D-42DD-98FA-E3124818A6DA@cisco.com> In-Reply-To: <8360A86F-CD1D-42DD-98FA-E3124818A6DA@cisco.com> Content-Type: multipart/alternative; boundary="------------080707070405020308040502" Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/o98YHutAu0qFxgIuFIBurYFp7Bg Cc: "draft-ietf-sfc-architecture@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Some concerns about draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: stbryant@cisco.com List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:39:53 -0000 This is a multi-part message in MIME format. --------------080707070405020308040502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13/11/2014 00:44, Carlos Pignataro (cpignata) wrote: > Stewart, > > Thanks for a very long set of comments right after WGLC finished :-) SB> Please consider them as early IETF LC comments, or pre-telechat SB> comments direct to the IESG if you prefer :) > > This is a top-post response only, to Ack your email and to make a > couple high-level comments about it. Neither Joel nor I will have > immediate time this/early next week to respond to each individual > comment (although we will as soon as we can), and we did not want your > note to go unanswered. > > First, many of your comments are conclusions from trying to model the > SFC architecture as a layer network, where in fact that is not what we > are doing or how things operate in this context. This architecture is > not creating hard demarcations or modeling SFCs as a layer network. SB> So I am curious as to what the right model is then. Certainly in practice SB> appliances are usually connected together via cables an VLANs to SB> set up service flow and from an applications perspective there is SB> a topology. I am sure you use that expression in your text. SB> SB> Anyway it would be useful to me and many other readers if you shared the SB> correct mental model of an SFC. Hopefully this is something more ordered SB> than a plate of spaghetti. > > And second, much of what you call 'lack of precision' is a feature and > not a bug -- the realm of applications, deployments is rich in > diversity and hence flexibility is a higher goal, while surgical > doctoral precision would make the architecture brittle and would > effectively make real deployment cases not be covered or represented > by the architecture. SB> Good architectures are usually crisp. They go soft when the you are SB> working with the wrong model and need to put stuff in to fix it up. SB> It therefore worries me that you have a soft model as a feature since SB> it is going to be very hard to determine the invariants necessary to SB> independently design the components in such a way that it fits SB> together as a whole. SB> SB> Does the softness perhaps occur as a result of a lack of agreement SB> on the invariants? - Stewart --------------080707070405020308040502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 13/11/2014 00:44, Carlos Pignataro (cpignata) wrote:
Stewart,

Thanks for a very long set of comments right after WGLC finished :-)
SB> Please consider them as early IETF LC comments, or pre-telechat
SB> comments direct to the IESG if you prefer :)

This is a top-post response only, to Ack your email and to make a couple high-level comments about it. Neither Joel nor I will have immediate time this/early next week to respond to each individual comment (although we will as soon as we can), and we did not want your note to go unanswered.

First, many of your comments are conclusions from trying to model the SFC architecture as a layer network, where in fact that is not what we are doing or how things operate in this context. This architecture is not creating hard demarcations or modeling SFCs as a layer network.

SB> So I am curious as to what the right model is then. Certainly in practice
SB> appliances are usually connected together via cables an VLANs to
SB> set up service flow and from an applications perspective there is
SB> a topology. I am sure you use that expression in your text.
SB>
SB> Anyway it would be useful to me and many other readers if you shared the
SB> correct mental model of an SFC. Hopefully this is something more ordered
SB> than a plate of spaghetti.

And second, much of what you call 'lack of precision' is a feature and not a bug -- the realm of applications, deployments is rich in diversity and hence flexibility is a higher goal, while surgical doctoral precision would make the architecture brittle and would effectively make real deployment cases not be covered or represented by the architecture.
SB> Good architectures are usually crisp. They go soft when the you are
SB> working with the wrong model and need to put stuff in to fix it up.
SB> It therefore worries me that you have a soft model as a feature since
SB> it is going to be very hard to determine the invariants necessary to
SB> independently design the components in such a way that it fits
SB> together as a whole.
SB>
SB> Does the softness perhaps occur as a result of a lack of agreement
SB> on the invariants?

- Stewart

--------------080707070405020308040502-- From nobody Tue Nov 18 19:25:05 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 417881ACF6B for ; Tue, 18 Nov 2014 19:25:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.213 X-Spam-Level: * X-Spam-Status: No, score=1.213 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_28=0.6, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za7dmH9eXzOT for ; Tue, 18 Nov 2014 19:25:01 -0800 (PST) Received: from tama50.ecl.ntt.co.jp (tama50.ecl.ntt.co.jp [129.60.39.147]) by ietfa.amsl.com (Postfix) with ESMTP id 87CC51ACF68 for ; Tue, 18 Nov 2014 19:25:01 -0800 (PST) Received: from mfs5.rdh.ecl.ntt.co.jp (mfs5.rdh.ecl.ntt.co.jp [129.60.39.144]) by tama50.ecl.ntt.co.jp (8.13.8/8.13.8) with ESMTP id sAJ3OuWj007433; Wed, 19 Nov 2014 12:24:56 +0900 Received: from mfs5.rdh.ecl.ntt.co.jp (localhost.localdomain [127.0.0.1]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 31B29E009A; Wed, 19 Nov 2014 12:24:56 +0900 (JST) Received: from imail3.m.ecl.ntt.co.jp (imail3.m.ecl.ntt.co.jp [129.60.5.248]) by mfs5.rdh.ecl.ntt.co.jp (Postfix) with ESMTP id 25827E005A; Wed, 19 Nov 2014 12:24:56 +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 sAJ3Ola9009147; Wed, 19 Nov 2014 12:24:56 +0900 Message-ID: <546C0DB1.4080104@lab.ntt.co.jp> Date: Wed, 19 Nov 2014 12:25:37 +0900 From: Shunsuke Homma User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 References: <55741672-D88A-4138-A79C-D5B1F8A83A86@cisco.com>, <0F8583BBE82FA449A8B78417CC07559AAA75F9@SJCEML701-CHM.china.huawei.com> , <546B3A1A.2070105@lab.ntt.co.jp> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit To: Ron Parker X-TM-AS-MML: disable Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Z9bLbotYg9YGo1LUXZeIVBllbHY Cc: "sfc@ietf.org" Subject: Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory Context Headers remains the only option for NSH X-BeenThere: sfc@ietf.org X-Mailman-Version: 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, 19 Nov 2014 03:25:04 -0000 Hi Ron, Thank you for replying. I agree with your opinion, creating a transport-independent service overlay is one of the most important factor of SFC. However, other SDN technologies may also enable to create an overlay independent of underlay-networks. For example, a combination of OpenFlow and an existing transport header (e.g. GRE) enables to achieve an overlay. What are the differences of SFC and the alternatives? IMO, one of the differences is that SFC header can convey Service(or Chain) information over multiple components as logical information. And, it will lead to advantage of scalability. Shunsuke (2014/11/19 0:24), Ron Parker wrote: > Shinsuke-san, > > One of the goals of SFC is to create a transport-independent service overlay. This has the effect of reducing the transport visibility to node-to-node, only (ie classifier to SFF or SFF to SFF). The SFC header, therefore, must contain a field of fields that are used for the end to end chain/path forwarding decision. > > Ron > > >> On Nov 18, 2014, at 7:22 AM, Shunsuke Homma wrote: >> >> Hi, >> >> I think that we should clarify the merits of SFC encapsulation (e.g. NSH, SCH) without metadata firstly if the context headers are optional. >> >> There are several methods to achieve Service Chaining, and SFC is one of them. As one of SFC users, I would like to clarify the motivation to use SFC encapsulation without metadata. >> >> In my opinion, scalability is one of the important point of SFC encapsulation, and I summarized the analysis into the following draft. >> >> https://datatracker.ietf.org/doc/draft-homma-sfc-forwarding-methods-analysis/ >> >> If you have any other opinions, please let me know. >> >> Cheers, >> Shunsuke >> >> (2014/11/15 12:37), Ron Parker wrote: >>> I’ll add that Surendra graciously agreed to re-read the SCH proposal and >>> provide comments back to the SCH authors. >>> >>> Ron >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Jim Guichard >>> (jguichar) >>> *Sent:* Friday, November 14, 2014 6:47 PM >>> *To:* Henry Fourie >>> *Cc:* Dolganow, Andrew (Andrew); Cathy Zhang; Paul Quinn (paulq); >>> sfc@ietf.org >>> *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >>> Context Headers remains the only option for NSH >>> >>> Just to clarify the expectation of the chairs; what we want to see is a >>> resolution of any differences so that we can move forward with the SFC >>> encapsulation. >>> >>> Jim >>> >>> Sent from my iPhone >>> >>> >>> On Nov 14, 2014, at 12:51 PM, "Henry Fourie" >> > wrote: >>> >>> Paul, >>> >>> Ron Parker and I met with Surendra Kumar and Jim Guichard in >>> Honolulu to discuss >>> >>> the merge of the NSH and SCH drafts. >>> >>> There was agreement on the base header that contains the SFP ID. >>> >>> The meeting was productive and the differences between the two >>> drafts were discussed >>> >>> including options for handling the mandatory fields in the NSH. >>> >>> Jim stated that he wants the authors of both drafts to work together >>> and reach agreement >>> >>> on a single merged draft before the next IETF meeting in Dallas. >>> There was agreement >>> >>> for the authors of both drafts to work together to resolve >>> differences and create >>> >>> a unified draft. >>> >>> Surendra, Ron, Jim, please add any further comments. >>> >>> -Louis >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org] *On Behalf Of *Paul Quinn >>> (paulq) >>> *Sent:* Tuesday, November 11, 2014 5:15 AM >>> *To:* Cathy Zhang >>> *Cc:* Dolganow, Andrew (Andrew); sfc@ietf.org >>> *Subject:* Re: [sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >>> Context Headers remains the only option for NSH >>> >>> Cathy, >>> >>> We need to be accurate here: there was no “conclusion” to merge >>> drafts, rather your co-author presented some slides that highlighted >>> what you and your co-authors feels are areas of similarity and >>> suggested that a merge should occur. We — the NSH co-authors — are >>> happy to discuss this with you (and are actively doing so) to see if >>> we can reach an agreement on joint text in order to ensure that we >>> meet the WG goals” >>> >>> Thanks >>> Paul >>> >>> On Nov 10, 2014, at 4:49 PM, Cathy Zhang >> > wrote: >>> >>> >>> >>> >>> Hi Andrew, >>> >>> Thanks for bringing this up. As authors of another service chain >>> header draft >>> (https://datatracker.ietf.org/doc/draft-zhang-sfc-sch/), we support >>> your proposal. >>> >>> Your proposal is in sync with our service chain header draft, i.e., >>> besides the base header and path header, all other information can >>> be expressed as optional metadata in TLV format. >>> >>> Last IETF meeting’s conclusion is to merge the two header >>> drafts----NSH draft and SCH draft. We have reached out to the NSH >>> authors about doing the merging as well as addressing the >>> comments/opinions voiced in the Toronto IETF meeting and email alias. >>> >>> Thanks, >>> >>> SCH authors >>> >>> *From:*sfc [mailto:sfc-bounces@ietf.org]*On Behalf Of*Dolganow, >>> Andrew (Andrew) >>> *Sent:*Tuesday, November 04, 2014 8:12 AM >>> *To:*sfc@ietf.org >>> *Subject:*[sfc] draft-quinn-sfc-nsh-03 - " MUST" for Mandatory >>> Context Headers remains the only option for NSH >>> >>> During the last IETF there were several attendees (including myself) >>> who voice strong opinion against mandatory the inclusion of the >>> information beyond based header and service path header. Not all >>> applications require the extra overhead. A discussion on the list >>> followed (see attached email that initiated that discussion) on >>> alternative encodings including mechanisms like use of one of the >>> reserved bit or using another MD Type value to represent header >>> without Mandatory Context Headers. >>> >>> Can the authors comment on whether they are strongly opposed to >>> include in their draft a proposal that has an option to encode the >>> NSH without the Mandatory Context Headers? I am OK with an encoding >>> that either: >>> >>> * makes Mandatory Context Headers optional or >>> * Has two types of NSG MD Type 0x1 - the mandatory context headers >>> are present, 0x2 the mandatory context header are not included >>> (optional variable length metadata could still be used in that >>> type of header) >>> >>> Andrew >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >>> >>> >>> >>> _______________________________________________ >>> sfc mailing list >>> sfc@ietf.org >>> https://www.ietf.org/mailman/listinfo/sfc >> >> >> -- >> ---------------------------------- >> 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 > > -- ---------------------------------- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service System Labs. Musashino city, Tokyo, Japan ---------------------------------- From nobody Thu Nov 20 09:26:37 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4EE1A1BF1 for ; Thu, 20 Nov 2014 09:26:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, 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 g85PuTMt9EtY for ; Thu, 20 Nov 2014 09:26:32 -0800 (PST) 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 89D251A1BD4 for ; Thu, 20 Nov 2014 09:26:26 -0800 (PST) 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 BLW00171; Thu, 20 Nov 2014 17:26:24 +0000 (GMT) Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 20 Nov 2014 17:26:24 +0000 Received: from SZXEMA509-MBS.china.huawei.com ([169.254.2.166]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Fri, 21 Nov 2014 01:26:20 +0800 From: "Liushucheng (Will)" To: Thomas Narten , "sfc@ietf.org" Thread-Topic: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt Thread-Index: AQHP/Izgk+Dhn+fWbE+D82qtDZNn1Jxp0AJA Date: Thu, 20 Nov 2014 17:26:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.158.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/PDuRK3PKVuZTOcgxbfomhhPm6Fc Subject: Re: [sfc] Concerns with draft-liu-sfc-use-cases-08.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, 20 Nov 2014 17:26:36 -0000 Hi Thomas, Thank you for your comments. Please see my reply to part of your comments i= nline below. Cheers, Will > -----Original Message----- > From: sfc [mailto:sfc-bounces@ietf.org] On Behalf Of Thomas Narten > Sent: Sunday, November 09, 2014 7:18 PM > To: sfc@ietf.org > Subject: [sfc] Concerns with draft-liu-sfc-use-cases-08.txt >=20 > Note: chair hat off. >=20 > I have a number of concerns with the document, including: >=20 > 1) I don't see what significant content it has beyond what the other WG u= se > case documents contain. >=20 > 2) Section 4.3 Talks about SFC and TE, but it is unclear to me what this = section is > trying to say. Is it saying SFC needs TE? Or TE needs SFC? And how is th= at a > "use case"? TE already exists. Does the addition of SFC somehow change > things? >=20 > 3) Section 4.4 seems to simply say that some SFC flows are bi-directional= . That > has been an assumption in SFC from the start. Doesn't the problem > statement/architecture say as much? >=20 > 4) I don't understand Section 4.4. SFC operates over IP. Full stop. I'm n= ot sure > what use case has Ethernet in it or why that is called out. SFC can run o= ver > Ethernet so long as it is also an IP subnet. Or is this section trying to= say > something else? If so, what? >=20 > 5) Section 4.6 talks about service path forking. The WG has discussed "fo= rking" > multiple times, and it's a basic part of SFC. So what exactly is this sec= tion that > isn't covered elsewhere? [Will] Given the forking case is a basic one in our group, IMHO, we may nee= d to show it in our output to those who were not in this group from the ver= y beginning and missed the discussion. WGs of IETF conclude and we cannot e= xpect the future readers go through the mailing list. We've checked draft-i= etf-sfc-dc-use-cases-01 and draft-ietf-sfc-use-case-mobility-01, however, i= t seems that the forking case has not been fully covered yet. Fig 6 in mobi= lity draft only touched a little about this, however, it failed in explaini= ng the details of forking to readers. Another thing that should be point out, which is not mentioned in this thre= ad, is the SFC over Multiple Underlay Networks case has not been covered ye= t in any of the existing WG use case drafts. >=20 > 6) I don't follow or understand the "recursive SFC" section. When it talk= s about > different service providers, I have to wonder how that applies to SFC, g= iven > our scope is restricted to a single administrative domain. But more to th= e point, > how does "recursive" > differ from straightforward SFC usage, where different subscribers use > different service chains? >=20 > Thomas >=20 > _______________________________________________ > sfc mailing list > sfc@ietf.org > https://www.ietf.org/mailman/listinfo/sfc From nobody Sun Nov 30 19:52:38 2014 Return-Path: X-Original-To: sfc@ietfa.amsl.com Delivered-To: sfc@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F31E1A0393 for ; Sun, 30 Nov 2014 19:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.81 X-Spam-Level: X-Spam-Status: No, score=-11.81 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 VSgKt1yStCff for ; Sun, 30 Nov 2014 19:52:17 -0800 (PST) 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 D5E5A1A0119 for ; Sun, 30 Nov 2014 19:52:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=165890; q=dns/txt; s=iport; t=1417405937; x=1418615537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3PuAqufHXQtn0z7/TIrFnNkKOsHDw77QB/O3Zbe9VzY=; b=j2TocQxFEL8aAdqzhdTJQo3DJ2RpqBE6iO3RnvVImCSAXtiJsiFQ1cvx Og3BHZYEEwq9mCYeZF5E4gqnGYlM6xY1oVbkDmik4rEKoiXYLuy+WD1r5 5+2GbNMVHxCN07T9WODpY7cPCBvEVcR9fZQaUr6kmxAPugQwvFGgX/zMJ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAPfke1StJV2Q/2dsb2JhbABRAQMGgmMjUU0LBMRUgiiGTgKBDhYBAQEBAX2EAwEBBA4MAQw+AgsCBRACAQgSGwsBBgcyFAMOAgQOAwIbiCUBDNIBAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4pphS4IAQMBDgY+BQcKgx+BHwWEPIFHiHqCCIZBSYF0gkSBLoM7gyCGMIMIhAKDe0MsAYEDAQEeBhyBAQEBAQ X-IronPort-AV: E=Sophos;i="5.07,489,1413244800"; d="scan'208,217";a="101325504" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP; 01 Dec 2014 03:52:12 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id sB13qCa1013092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Dec 2014 03:52:12 GMT Received: from xmb-aln-x02.cisco.com ([fe80::8c1c:7b85:56de:ffd1]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Sun, 30 Nov 2014 21:52:11 -0600 From: "Carlos Pignataro (cpignata)" To: "Stewart Bryant (stbryant)" Thread-Topic: Some concerns about draft-ietf-sfc-architecture Thread-Index: AQHP/rWshxQ4ady89E6q0aScYPtEIpx6m4aA Date: Mon, 1 Dec 2014 03:52:10 +0000 Message-ID: References: <5463BD7D.6000007@cisco.com> <5463C03D.3040202@cisco.com> In-Reply-To: <5463C03D.3040202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.217.178] Content-Type: multipart/alternative; boundary="_000_D8D13D2266C742499AEE2E681BE1739Bciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/sfc/Au0ExzBe0tdrs7EJkIfvJxqRIs0 Cc: "draft-ietf-sfc-architecture@tools.ietf.org" , "sfc@ietf.org" , "sfc-chairs@tools.ietf.org" Subject: Re: [sfc] Some concerns about draft-ietf-sfc-architecture X-BeenThere: sfc@ietf.org X-Mailman-Version: 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 Dec 2014 03:52:35 -0000 --_000_D8D13D2266C742499AEE2E681BE1739Bciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Stewart, Thanks again for your comments, and apologies for the delay =97 please find= some responses inline. On Nov 12, 2014, at 3:17 PM, Stewart Bryant (stbryant) > wrote: Correcting an error in the to list. On 12/11/2014 20:05, Stewart Bryant wrote: SB> This document lacks the precision and that I would have hoped for SB> in an architecture. I understand that the this was deliberate SB> in order to allow implementation flexibility, but I don't SB> buy that. SB> SB> What we have here is a type of layered network, and whilst SB> verbal discussions have refuted that, you have many references SB> to overlay topologies. SB> SB> This would be better understood if you described it as a layered SB> system, As mentioned before (and verbally in your reference above), that=92s what w= e do not want to do. More below. if you only used generalized the components with fully SB> functionality, and then explained which could be NULL. In the SB> case of sub-functional components they should not be part of the SB> core architecture, but the techniques used to create a full function SB> component by assistance (the proxy) described outside the main SB> architecture. Within the context of SFC, it is important that the architecture describes = the proxy =97 as we are living in a world in which we want to include legac= y and not craft an fully functional architecture that ignores it. SB> SB> I understand that in part the approach used here was to allow SB> a mixture of implementation styles - the concept of explicit SB> and implicit SFE - with network layer constructs supplying the SB> implicit SFE. However it would be better to think of the use SB> of implicit SFE as a type of network recursion in which the SB> the encapsulator (which I think is distinct from the classifier) SB> chooses how to encode the SFP on the packet. SB> We can overcomplicate it in many different ways, but let=92s not. We can th= ink of it differently, I agree; but this is the way the WG thought about it= . SB> I have a nagging concern about the way that the terms packets is SB> used in this text. The way it is used one would expect that there SB> is a one for one mapping between input and output packets, but that SB> is surely not the case. A trivial point is the case where an SF SB> needs to defragment. Although at the physical layer the units are SB> packets, there may surely be higher order constructs traveling SB> between SFs. I think this is a good point, more inline. Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-02 Abstract This document describes an architecture for the specification, sb> an arch or THE arch? Updated to =93the=94. Thanks. 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. This document does not propose solutions, protocols, or extensions to existing protocols. 1. Introduction This document describes an architecture used for the creation and sb> and or THE Ditto. ongoing maintenance of Service Function Chains (SFC) in a network. It includes architectural concepts, principles, and components. An overview of the issues associated with the deployment of end-to- end service function chains, abstract sets of service functions and their ordering constraints that create a composite service and the subsequent "steering" of traffic flows through said service functions, is described in [I-D.ietf-sfc-problem-statement]. This architecture presents a model addressing the problematic aspects of existing service deployments, including topological independence and configuration complexity. Service function chains enable composite services that are constructed from one or more service functions. 1.1. Scope This document defines a framework to realize Service Function Chaining (SFC) with minimum requirements on the physical topology of the network. The proposed solution relies on initial packet classification. Packets initially classified for handling by a set of Service Functions (SFs) in the SFC-enabled domain are then forwarded to that set of SFs for processing. SB> Are you allowed to reclassify, or do staged classification? SB> Yes you are - you say so later - but that is not implied SB> by the above. Trying to explain branching here would likely create more confusion to the = reader. This document does not make any assumption on the deployment context. The proposed framework covers both fixed and mobile networks. SB> Given that you make no deployment context assumption, surely SB> the followup mobile/fixed specific is not relevant. I disagree =97 it is very relevant to be explicit about the scope for both = fixed and mobile. It=92s not redundant with no deployment context assumptio= n, it is just a more explicit and precise set of details. This is, again, b= ecause these details are relevant to real SFC deployments based on this arc= hitecture. The architecture described herein is assumed to be applicable to a single network administrative domain. While it is possible for the architectural principles and components to be applied to inter-domain SFCs, these are left for future study. 1.2. Assumptions The following assumptions are made: o Not all SFs can be characterized with a standard definition in terms of technical description, detailed specification, configuration, etc. o There is no global or standard list of SFs enabled in a given administrative domain. The set of SFs varies as a function of the service to be provided and according to the networking environment. o There is no global or standard SF chaining logic. The ordered set of SFs that needs to be enabled to deliver a given service is specific to each administrative entity. SB> Surely it is application specific even within an admistration? What is =93application specific=94 in the context of a chained set of appli= cations? o The chaining of SFs and the criteria to invoke them are specific to each administrative entity that operates an SF-enabled domain. SB? see previous See previous. Halpern & Pignataro Expires March 24, 2015 [Page 3] Internet-Draft SFC Architecture September 2014 o Several SF chaining policies can be simultaneously applied within an administrative domain to meet various business requirements. o No assumption is made on how FIBs and RIBs of involved nodes are populated. o How to bind traffic to a given SF chain is policy-based. 1.3. Definition of Terms Network Service: An offering provided by an operator that is delivered using one or more service functions. This may also be referred to as a composite service. The term "service" is used to denote a "network service" in the context of this document. Note: Beyond this document, the term "service" is overloaded with varying definitions. For example, to some a service is an offering composed of several elements within the operator's network, whereas for others a service, or more specifically a network service, is a discrete element such as a firewall. Traditionally, such services (in the latter sense) host a set of service functions and have a network locator where the service is hosted. SB> I think that you probably need an explicit definition of service. SB> I find the text in the definition of NS self referential which is SB> not helpful. It is not self-referential, but yes, the WG struggled a bit with how to def= ine something so overloaded. I did at least. You can check the SFC charter = for a different way of dancing around it. If you have specific text suggestions, by all means, please do share. Classification: Locally instantiated policy and customer/network/ service profile matching of traffic flows for identification of appropriate outbound forwarding actions. SB> Isn't it really SB> Locally instantiated matching of traffic flows against policy for SB> subsequent application of the required set of network service functions= . SB> The policy may be ustomer/network/service specific. Yes, I think this is a good change. WG, any concerns? Classifier: An element that performs Classification. SB> A network element perhaps? An element sounds good to me. Any particular reason why you=92d constrain i= t? Service Function Chain (SFC): A service function chain defines a set of abstract service functions and ordering constraints that must SB> Isn't the SFC also ordered? be applied to packets and/or frames selected as a result of classification. SB> Packets, or higher order constructs like flows? You cannot SB> do some of the SFs packet by packet I agree with adding =93flows=94. The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term service chain is often used as shorthand for service function chain. SB> See my earlier not about the apparently more restricted definition SB> I think that you need to make the generalization clearer earlier. See above. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a Service Function can be realized as a virtual element or be embedded in a physical network element. One or multiple Service Functions SB> multiple or more? I guess =93one or more=94. can be embedded in the same network element. Multiple Halpern & Pignataro Expires March 24, 2015 [Page 4] Internet-Draft SFC Architecture September 2014 occurrences of the Service Function can exist in the same administrative domain. One or more Service Functions can be involved in the delivery of added-value services. A non-exhaustive list of abstract Service Functions includes: firewalls, WAN and application acceleration, Deep Packet Inspection (DPI), LI (Lawful Intercept), server load balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], HOST_ID injection, HTTP Header Enrichment functions, TCP optimizer. SB> Not sure those are abstract SFs, surely they are explicit? A firewall is an abstract SF, specific rules / policy makes it specific/con= crete/explicit. An SF may be SFC encapsulation aware, that is it receives and acts on information in the SFC encapsulation, or unaware, in which case data forwarded to the SF does not contain the SFC encapsulation. Service Function Forwarder (SFF): A service function forwarder is responsible for delivering traffic received from the network to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, a service function forwarder is responsible for delivering traffic to a classifier when needed and supported, mapping out traffic to another SFF (in the same or different type of overlay), and terminating the SFP. SB> In these days of NFV it may not be received from the network. SB> Surely the traffic is native until it gets to a classifier. The SB> way you have it here it looks like the first element is the SFF SB> but I am not sure that is the case. SB> Perhaps: A service function forwarder is responsible for forwarding SB> traffic between service functions. =93The network=94 is not =93the network=94 that you are thinking, I suspect= . I think the proposed change removes important detail =97 we could remove = =93from the network=94. Metadata: provides the ability to exchange context information between classifiers and SFs and among SFs. SB> I think the first noun is missing in the above, but in any case SB> I think a more complete definition is needed. Text? Service Function Path (SFP): The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF/SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF/SF selection authority that is delegated to the network. SB> You have not defined control components. SB> I think "notion" is a redundant term. SB> I am somewhat confused by your definition. SB> Is this really about the mapping of packets between an arbitrary SB> member of an SF to a specific instance of the SF? This one took the WG a lot of editing=85 SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP identification, and is used by the SFC-aware functions, such as the SFF and SFC-aware SFs. The SFC Encapsulation is not used for network packet forwarding. In addition to SFP identification, the SFC encapsulation carries data plane context information, also referred to as metadata. SB> Surely the "SFC E is used to attach the information needed to SB> direct the packet through the ordered set of SFs, together with SB> associated metadata. An additional network layer encapsulation is need= ed SB> to carry the packet over the physical network. What is wrong with the current definition? Again, the WG invested much (on = list and in person) time to get to these. I am happy to make changes that improve the document, but I am not sure I u= nderstand the guiding force other than personal preference. Rendered Service Path (RSP): The Service Function Path is a constrained specification of where packets using a certain service chain must go. While it may be so constrained as to Halpern & Pignataro Expires March 24, 2015 [Page 5] Internet-Draft SFC Architecture September 2014 identify the exact locations, it can also be less specific. Packets themselves are of course transmitted from and to specific places in the network, visiting a specific sequence of SFFs and SFs. This sequence of actual visits by a packet to specific SFFs and SFs in the network is known as the Rendered Service Path (RSP). This definition is included here for use by later documents, such as when solutions may need to discuss the actual sequence of locations the packets visit. SB> Not sure of the wisdom of including a definition for the future, since SB> when you use it you may need to tune the definition. OK, thanks. We want to capture the definition as part of the architecture = =97 not sure of the wisdom if we do not capture it. SFC-enabled Domain: A network or region of a network that implements SFC. An SFC-enabled Domain is limited to a single network administrative domain. SFC Proxy: Removes and inserts SFC encapsulation on behalf of an SFC-unaware service function. SFC proxies are logical elements. SB> Not sure considering then as logical is quite right. It depends SB> on the mapping of the operation to the physical. I could see SB> cases where they are physical. Surely the point is that they SB> may be co-located with another network function such as a router SB> an operating system component such as a hypervisor. If they are physical, the logical-physical mapping is 1:1. 2. Architectural Concepts The following sections describe the foundational concepts of service function chaining and the SFC architecture. Service Function Chaining enables the creation of composite (network) services that consist of an ordered set of Service Functions (SF) that must be applied to packets and/or frames selected as a result of classification. Each SF is referenced using an identifier that is unique within an SF-enabled domain. No IANA registry is required to store the identity of SFs. SB> I am still worried about using packets. Need to fix this as well =97 part of the same comment. Thanks. Obviously we operate on SB> pkts, but the operation may require the reconstuction of some SB> packet grouping typically some element of a flow before the operation SB> can be performed. A trivial example is defragmenting a packet group SB> but since we are dealing with abstract SFs we cannot specify the SB> the unit of operation. Service Function Chaining is a concept that provides for more than just the application of an ordered set of SFs to selected traffic; rather, it describes a method for deploying SFs in a way that enables dynamic ordering and topological independence of those SFs as well as the exchange of metadata between participating entities. SB> The above is a bit late in the text. I think it needs to go earlier. It=92s in the architectural concepts. 2.1. Service Function Chains In most networks, services are constructed as abstract sequences of SB> I don't think that are abstract in this context. SB> Are you talking about traditional (current physically instantiated SB> SFCs in the previous sentence? See above. SFs that represent SFCs. At a high level, an SFC is an abstracted view of a service that specifies the set of required SFs as well as the order in which they must be executed. SB> Again I am not sure "abstrated view" is right here Graphs, as illustrated in Figure 1, define an SFC, where each graph node represents the required existence of at least one abstract SF. Such graph nodes (SFs) can be part of zero, one, or many SFCs. A given graph node (SF) can appear one time or multiple times in a given SFC. SB> Not sure that graphs is right, since you only show the case SB> of a linear chain. The construct you are going to use is SB> graph, but that is not what the figure shows. The figure does show a graph. SFCs can start from the origination point of the service function graph (i.e.: node 1 in Figure 1), or from any subsequent node in the graph. SB> OK so are you trying to distinguish between physically and SB> SFC (the new technology) instantiated SFCS? SFs may therefore become branching nodes in the graph, with Halpern & Pignataro Expires March 24, 2015 [Page 6] Internet-Draft SFC Architecture September 2014 those SFs selecting edges that move traffic to one or more branches. An SFC can have more than one terminus. SB> Again that is not what your figure shows. ,-+-. ,---. ,---. ,---. / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 6 )+---->( 8 ) \ / \ / \ / \ / `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 2 )+---->( 3 )+---->( 7 )+---->( 9 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' ,-+-. ,---. ,---. ,---. ,---. / \ / \ / \ / \ / \ ( 1 )+--->( 7 )+---->( 8 )+---->( 4 )+---->( 7 ) \ / \ / \ / \ / \ / `---' `---' `---' `---' `---' Figure 1: Service Function Chain Graphs 2.2. Service Function Chain Symmetry SFCs may be unidirectional or bidirectional. A unidirectional SFC requires that traffic be forwarded through the ordered SFs in one direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC requires a symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), and in which the SF instances are the same in opposite directions. A hybrid SFC has attributes of both unidirectional and bidirectional SFCs; that is to say some SFs require symmetric traffic, whereas other SFs do not process reverse traffic or are independent of the corresponding forward traffic. SFCs may contain cycles; that is traffic may need to traverse one or more SFs within an SFC more than once. Solutions will need to ensure suitable disambiguation for such situations. The architectural allowance that is made for SFPs that delegate choice to the network for which SFs and/or SFFs a packet will visit creates potential issues here. A solution that allows such delegation needs to also describe how the solution ensures that those service chains that require service function chain symmetry can achieve that. Further, there are state tradeoffs in symmetry. Symmetry may be realized in several ways depending on the SFF and classifier Halpern & Pignataro Expires March 24, 2015 [Page 7] Internet-Draft SFC Architecture September 2014 functionality. In some cases, "mirrored" classification (i.e., from Source to Destination and from Destination to Source) policy may be deployed, whereas in others shared state between classifiers may be used to ensure that symmetric flows are correctly identified, then steered along the required SFP. At a high level, there are various common cases. In a non-exhaustive way, there can be for example: a single classifier (or a small number of classifiers), in which case both incoming and outgoing flows could be recognized at the same classifier, so the synchronization would be feasible by internal mechanisms internal to the classifier. Another case is the one of stateful classifiers where several classifiers may be clustered and share state. Lastly, another case entails fully distributed classifiers, where synchronization needs to be provided through unspecified means. This is a non-comprehensive list of common cases. SB> Isn't an important class of classifiers one that learns state from the SB> egress packets/flows that is then used to provide state for the SB> return packets/flow Isn=92t that a way to provide synchronization? 2.3. Service Function Paths A service function path (SFP) is a mechanism used by service chaining to express the result of applying more granular policy and SB> Not sure "more granular" is needed. operational constraints to the abstract requirements of a service SB> Not sure they are abstract requirements. When you apply them they SB> are explicit. abstract adjective 1. thought of apart from concrete realities, specific objects, or actual in= stances. chain (SFC). This architecture does not mandate the degree of specificity of the SFP. Architecturally, within the same SFC-enabled domain, some SFPs may be fully specified, selecting exactly which SFF and which SF are to be visited by packets using that SFP, while other SFPs may be quite vague, deferring to the SFF the decisions about the exact sequence of steps to be used to realize the SFC. The specificity may be anywhere in between these extremes. As an example of such an intermediate specificity, there may be two SFPs associated with a given SFC, where one SFP says essentially that SB> "says essentially is not a tight definition=94 Substituted with =93specifies=94. any order of SFF and SF may be used as long as it is within data center 1, and where the second SFP allows the same latitude, but only within data center 2. Thus, the policies and logic of SFP selection or creation (depending upon the solution) produce what may be thought of as a constrained version of the original SFC. Since multiple policies may apply to different traffic that uses the same SFC, it also follows that there may be multiple SFPs may be associated with a single SFC. SB> So a SFP is a specific instance of a member of the set of available SFC= s SB> chosen as a result of applying policy at one or points along the SFC? The architecture allows for the same SF to be reachable through multiple SFFs. In these cases, some SFPs may constrain which SFF is used to reach which SF, while some SFPs may leave that decision to the SFF itself. Further, the architecture allows for two or more SFs to be attached to the same SFF, and possibly connected via internal means allowing more effective communication. In these cases, some solutions or Halpern & Pignataro Expires March 24, 2015 [Page 8] Internet-Draft SFC Architecture September 2014 deployments may choose to use some form of internal inter-process or inter-VM messaging (communication behind the virtual switching element) that is optimized for such an environment. This must be coordinated with the SFF so that the service function forwarding can properly perform its job. Implementation details of such mechanisms are considered out of scope for this document, and can include a spectrum of methods: for example situations including all next-hops explicitly, others where a list of possible next-hops is provided and the selection is local, or cases with just an identifier, where all resolution is local. This architecture also allows the same SF to be part of multiple SFPs. SB> Didn't you just say that? 3. Architecture Principles Service function chaining is predicated on several key architectural principles: 1. Topological independence: no changes to the underlay network forwarding topology - implicit, or explicit - are needed to deploy and invoke SFs or SFCs. 2. Plane separation: dynamic realization of SFPs is separated from packet handling operations (e.g., packet forwarding). 3. Classification: traffic that satisfies classification rules is forwarded according to a specific SFP. For example, classification can be as simple as an explicit forwarding entry that forwards all traffic from one address into the SFP. Multiple classification points are possible within an SFC (i.e. forming a service graph) thus enabling changes/updates to the SFC by SFs. Classification can occur at varying degrees of granularity; for example, classification can use a 5-tuple, a transport port or set of ports, part of the packet payload, or it can come from external systems. SB> I think that it can surely be as a result of higher level inspections? OK, added. 4. Shared Metadata: Metadata/context data can be shared amongst SFs and classifiers, between SFs, and between external systems and SFs (e.g., orchestration). Generally speaking, metadata can be thought of as providing and sharing the result of classification SB> Just classifications, or classifications and processing operations? SB> There is gray zone between a packet forwarding system and SB> a distributed computing system and I am not sure where SFC fits, SB> nor am I sure that it makes sense to be specific at this stage. SB> It is entirely possible that an SFC consumes the packet/flow SB> rather than only having the capability to forward it between SB> in ingress and egress. (that occurs within the SFC- enabled domain, or external to it) along an SFP. For example, an external repository might provide user/subscriber information to a service chain classifier. This classifier could in turn impose Halpern & Pignataro Expires March 24, 2015 [Page 9] Internet-Draft SFC Architecture September 2014 that information in the SFC encapsulation for delivery to the requisite SFs. The SFs could in turn utilize the user/subscriber information for local policy decisions. 5. Service definition independence: The SFC architecture does not depend on the details of SFs themselves. Additionally, no IANA registry is required to store the list of SFs. SB> Yes, but you should be careful not to preclude it. Nothing is precluding it. 6. Service function chain independence: The creation, modification, or deletion of an SFC has no impact on other SFCs. The same is true for SFPs. SB> Yes and no. What about the resource implications? 7. Heterogeneous control/policy points: The architecture allows SFs to use independent mechanisms (out of scope for this document) to populate and resolve local policy and (if needed) local classification criteria. 4. Core SFC Architecture Components At a very high level, the logical architecture of an SFC-enabled Domain comprises: SB> A list would be handy rather than just a figure, and you need SB> some text to expand on the figure. o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +--------------+ +------------------~~~ . | Service | SFC | Service +---+ +---+ . |Classification| Encapsulation | Function |sf1|...|sfn| +---->| Function |+---------------->| Path +---+ +---+ . +--------------+ +------------------~~~ . SFC-enabled Domain o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Figure 2: Service Function Chain Architecture SB> This is a very confusing diagram SB> Surely the SFC encap is attached to the packet SB> The fig seems to confuse the the packets and the path. It could be the reader that is confusing a nice figure :-) I am not sure I see what you see =97 suggestions? The following sub-sections provide details on each logical component that form the basis of the SFC architecture. A detailed overview of how each of these architectural components interact is provided in Figure 3: SB> Well maybe, but it's not quite obvious what you are showing. SB> some overview text would help before you get into the detail. Halpern & Pignataro Expires March 24, 2015 [Page 10] Internet-Draft SFC Architecture September 2014 +----------------+ +----------------+ | SFC-aware | | SFC-unaware | |Service Function| |Service Function| +-------+--------+ +-------+--------+ | | SFC Encapsulation No SFC Encapsulation | SFC | +---------+ +----------------+ Encapsulation +---------+ |SFC-Aware|-----------------+ \ +------------|SFC Proxy| | SF | ... ----------+ \ \ / +---------+ +---------+ \ \ \ / +-------+--------+ | SF Forwarder | | (SFF) | +-------+--------+ | SFC Encapsulation | ... SFC-enabled Domain ... | Network Overlay Transport | _,....._ ,-' `-. / `. | Network | `. / `.__ __,-' `'''' Figure 3: Service Function Chain Architecture Components SB> Coming back here after reading a bit more. Is the SFF to be considered = the SB> hub in a hub and spoke processing model for a set of SFs? If so it woul= d SB> be useful to say that up front. However that raises the issue of whethe= r SB> the single network attachment point that you show is desirable. A stand= ard SB> firewall design would not mix dirty and clean traffic, and yet that is SB> what the above appears to show. 4.1. SFC Encapsulation The SFC encapsulation enables service function path selection. It also enables the sharing of metadata/context information when such metadata exchange is required. SB> I don't think that is quite right. Surely the SB> SFC encapsulation enables to select the next SB> element of the path? The SFC encapsulation provides explicit information used to identify SB> Provides or carries? Carries. the SFP. However, the SFC encapsulation is not a transport encapsulation itself: it is not used to forward packets within the network fabric. SB> ... but surely it is a shim layer of some sort? If packets need to flow between separate physical platforms, the SFC encapsulation therefore relies on an outer network transport. SB> Surely it is network layer header specific to the inter SFC SB> transport? Transit forwarders -- such as router and switches -- simply forward SFC encapsulated packets based on the outer (non-SFC) encapsulation. SB> d/simply/ OK Halpern & Pignataro Expires March 24, 2015 [Page 11] Internet-Draft SFC Architecture September 2014 One of the key architecture principles of SFC is that the SFC encapsulation remain transport independent. As such any network transport protocol may be used to carry the SFC encapsulated traffic. SB> Not sure I like "network transport protocol" since this is going SB> to be confused with transport layer and I am not sure whether SB> you would require a transport layer, indeed the SFE might will SB> be considered a transport layer in the classical sense. 4.2. Service Function (SF) The concept of an SF evolves; rather than being viewed as a bump in the wire, an SF becomes a resource within a specified administrative domain that is available for consumption as part of a composite service. SFs send/receive data to/from one or more SFFs. SFC-aware SFs receive this traffic with the SFC encapsulation. SB> I do not understand the above para. While the SFC architecture defines a new encapsulation - the SFC encapsulation - SB> no it does not - it is not defined in this memo. You introduce SB> the concept and define some of the characteristics of it. OK, fixed. and several logical components for the construction of SFCs, existing SF implementations may not have the capabilities to act upon or fully integrate with the new SFC encapsulation. In order to provide a mechanism for such SFs to participate in the architecture, an SFC proxy function is defined (see Section 4.6). The SFC proxy acts as a gateway between the SFC encapsulation and SFC-unaware SFs. The integration of SFC-unaware service functions is discussed in more detail in the SFC proxy section. SB> The above is confusing. Do they participate in the architecture (this SB> text)? I think that you mean that in order to employ SF instances SB> that do not understand the SFE, a proxy as a gateway between the SB> the SFE aware domain and the non-SFE aware domain. Now if it is SB> a gateway why is it not called a gateway rather than a proxy which SB> is something that does something on behalf of something else. SB> I would think that it might be a SFE proxy, but that is not quite SB> right either. This architecture allows an SF to be part of multiple SFPs and SFCs. SB> I am sure you said that before. 4.3. Service Function Forwarder (SFF) The SFF is responsible for forwarding packets and/or frames received from the network to one or more SFs associated with a given SFF using information conveyed in the SFC encapsulation. Traffic from SFs eventually returns to the same SFF, which is responsible for injecting traffic back onto the network. SB> It is not clear why it needs to be the exact same SFF Because otherwise the SF would be an SFF. The collection of SFFs and associated SFs creates a service plane overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. Within this service plane, the SFF component connects different SFs that form a service function path. SB> This conceptual model seems quite fundamental and this I SB> am surprised that it is not much earlier in the document. SB> I have been wondering why the SFC system was not considered SB> an overlay network of some sort, and was told by the authors SB> that this was not possible. The above seems at odds with that Sb> statement. SFFs maintain the requisite SFP forwarding information. SB> Maintain - as in being the control plane for this, or SB> maintain as in store? SFP forwarding information is associated with a service path identifier that is used to uniquely identify an SFP. The service forwarding state enables an SFF to identify which SFs of a given SFP should be applied, and in what order, as traffic flows through the associated SFP. While there may appear to the SFF to be only one available way to deliver the given SF, there may also be multiple choices allowed by the constraints of the SFP. If there are multiple choices, the SFF needs to preserve the property that all packets of a given flow are handled the same way, since the Halpern & Pignataro Expires March 24, 2015 [Page 12] Internet-Draft SFC Architecture September 2014 SF may well be stateful. Additionally, the SFF may preserve the handling of packets based on other properties on top of a flow, such as a subscriber, session, or application instance identification. SB> I feel that the issue of handing higher order objects needs to have SB> been introduced much earlier in the architecture. I agree it would help =97 do you have a specific text addition and location= ? The SFF also has the information to allow it to forward packets to the next SFF after applying local service functions. Again, while there may be only a single choice available, the architecture allows for multiple choices for the next SFF. As with SFs, the solution needs to operate such that the behavior with regard to specific flows (see the Rendered Service Path) is stable. The selection of available SFs and next SFFs may be interwoven when an SFF supports multiple distinct service functions and the same service function is available at multiple SFFs. Solutions need to be clear about what is allowed in these cases. Even when the SFF supports and utilizes multiple choices, the decision as to whether to use flow-specific mechanisms or coarser grained means to ensure that the behavior of specific flows is stable is a matter for specific solutions and specific implementations. The SFF component has the following primary responsibilities: 1. SFP forwarding : Traffic arrives at an SFF from the network. The SFF determines the appropriate SF the traffic should be forwarded to via information contained in the SFC encapsulation. Post-SF, the traffic is returned to the SFF, and if needed forwarded to another SF associated with that SFF. If there is another non- local (i.e., different SFF) hop in the SFP, the SFF further encapsulates the traffic in the appropriate network transport protocol and delivers it to the network for delivery to the next SFF along the path. Related to this forwarding responsibility, an SFF should be able to interact with metadata. 2. Terminating SFPs : An SFC is completely executed when traffic has traversed all required SFs in a chain. When traffic arrives at the SFF after the last SF has finished processing it, the final SFF knows from the service forwarding state that the SFC is complete. The SFF removes the SFC encapsulation and delivers the packet back to the network for forwarding. 3. Maintaining flow state: In some cases, the SFF may be stateful. It creates flows and stores flow-centric information. This state information may be used for a range of SFP-related tasks such as ensuring consistent treatment of all packets in a given flow, ensuring symmetry or for state-aware SFC Proxy functionality (see Section 4.8). Halpern & Pignataro Expires March 24, 2015 [Page 13] Internet-Draft SFC Architecture September 2014 4.3.1. Transport Derived SFF Service function forwarding, as described above, directly depends upon the use of the service path information contained in the SFC encapsulation. However, existing implementations may not be able to act on the SFC encapsulation. These platforms may opt to use existing transport information if it can be arranged to provide explicit service path information. This results in the same architectural behavior and meaning for service function forwarding and service function paths. It is the responsibility of the control components to ensure that the transport path executed in such a case is fully aligned with the path identified by the information in the service chaining encapsulation. SB> The title does not seem quite right. What I think you have SB> is a system in which you map an SFC onto an explicit path SB> of some sort in the lower layers (I was going to say network layer SB> but I am not sure if that is what you intend). So I am not sure SB> derived is the correct word. It would be closer to say "emulation SB> of SFF using explicit network paths. Noting that these paths may SB> be encoded in the packet or encoded in the FIB. Derived is not as precise as desired perhaps, but I think =91emulation=92 i= s worst. Others? 4.4. SFC-Enabled Domain Specific features may need to be enforced at the boundaries of an SFC-enabled domain, for example to avoid leaking SFC information. Using the term node to refer generically to an entity that is performing a set of functions, in this context, an SFC Boundary Node denotes a node that connects one SFC-enabled domain to a node either located in another SFC-enabled domain or in a domain that is SFC- unaware. An SFC Boundary node can act as egress or ingress. SB> do you mean or or and/or i.e. can it be both at the same time. Yes. An SFC Egress Node denotes a SFC Boundary Node that handles traffic leaving the SFC-enabled domain the Egress Node belongs to. Such a node is required to remove any information specific to the SFC Domain, typically the SFC Encapsulation. An SFC Ingress Node denotes an SFC Boundary Node that handles traffic entering the SFC-enabled domain. In most solutions and deployments this will need to include a classifier, and will be responsible for adding the SFC encapsulation to the packet. SB> Logically doesn't it always include the classifier, where the set of SB> classifier types includes the null classifier? The only exception SB> I suppose is when you are receiving traffic from a trusted SB> SFC aware peer, but it might be better to be more explicit SB> about the normal case and then introduce the exception 4.5. Network Overlay and Network Components Underneath the SFF there are components responsible for performing the transport (overlay) forwarding. They do not consult the SFC encapsulation or inner payload for performing this forwarding. They only consult the outer-transport encapsulation for the transport (overlay) forwarding. SB> This layer model needs to be brought out much earlier instead of SB> having the reader deduce it up to this point. SB> Indeed the layering model makes for a better way of explaining SB> the operation of the system. Better for readers that think in terms of and are used to seeing layer mode= ls. As explained, that=92s not how we want to limit this architecture. 4.6. SFC Proxy In order for the SFC architecture to support SFC-unaware SFs (e.g., legacy service functions) a logical SFC proxy function may be used. SB> Is it a logical proxy or a real proxy, and why only may, surely SB> it *is* used. Halpern & Pignataro Expires March 24, 2015 [Page 14] Internet-Draft SFC Architecture September 2014 This function sits between an SFF and one or more SFs to which the SFF is directing traffic. The proxy accepts packets from the SFF on behalf of the SF. It removes the SFC encapsulation, and then uses a local attachment circuit to deliver packets to SFC unaware SFs. It also receives packets back from the SF, reapplies the SFC encapsulation, and returns them to the SFF for processing along the service function path. Thus, from the point of view of the SFF, the SFC proxy appears to be part of an SFC aware SF. Communication details between the SFF and the SFC Proxy are the same as those between the SFF and an SFC aware SF. The details of that are not part of this architecture. The details of the communication methods over the local attachment circuit between the SFC proxy and the SFC-unaware SF are dependent upon the specific behaviors and capabilities of that SFC-unaware SF, and thus are also out of scope for this architecture. Specifically, for traffic received from the SFF intended for the SF the proxy is representing, the SFC proxy: o Removes the SFC encapsulation from SFC encapsulated packets. o Identifies the required SF to be applied based on available information including that carried in the SFC encapsulation. o Selects the appropriate outbound local attachment circuit through which the next SF for this SFP is reachable. This is derived from the identification of the SF carried in the SFC encapsulation, and may include local techniques. Examples of a local attachment circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3, GRE, VXLAN. o Forwards the original payload via the selected local attachment circuit to the appropriate SF. SB> I think you have missed the storage of the SFE and I am not SB> sure how this gets back to the specific packet. This causes me SB> wonder if it is the original payload or not since it may by SB> now be SFC modified. It is surely the SFE payload that gets SB> passed up, and to re-attach the correct SFE afterwards, might SB> you not have to modify it? When traffic is returned from the SF: o Applies the required SFC encapsulation. The determination of the encapsulation details may be inferred by the local attachment circuit through which the packet and/or frame was received, or via packet classification, or other local policy. In some cases, packet ordering or modification by the SF may necessitate additional classification in order to re-apply the correct SFC encapsulation. SB> This function is surely split between the outbound and inbound SB> proxy functions. Halpern & Pignataro Expires March 24, 2015 [Page 15] Internet-Draft SFC Architecture September 2014 o Delivers the packet with the SFC Encapsulation to the SFF, as would happen with packets returned from an SFC-aware SF. Alternatively, a service provider may decide to exclude legacy service functions from an SFC domain. SB> This might have been better expressed earlier in the text my noting SB> that the proxy was optional, making the afterthought above redundant. 4.7. Classification Traffic from the network that satisfies classification criteria is directed into an SFP and forwarded to the requisite service function(s). Classification is handled by a service classification function; initial classification occurs at the ingress to the SFC domain. The granularity of the initial classification is determined by the capabilities of the classifier and the requirements of the SFC policy. For instance, classification might be relatively coarse: all packets from this port are subject to SFC policy X and directed into SFP A, or quite granular: all packets matching this 5-tuple are subject to SFC policy Y and directed into SFP B. As a consequence of the classification decision, the appropriate SFC encapsulation is imposed on the data, and a suitable SFP is selected or created. Classification results in attaching the traffic to a specific SFP. SB> How about: SFC domain ingress traffic is first processed by a classifier which either rejects the traffic or prepares it for processing by the required SFs. The classifier applies policy to the packet to determine the required SFC, and then to map that to the required SFP. The classifier applies the corresponding SFE and if necessary the appropriate network layer encapsulation and forwards the packet to the first SFF on the chain. This seems to leave out and awful set of details. And why first either reje= cts or prepares? 4.8. Re-Classification and Branching The SFC architecture supports re-classification (or non-initial classification) as well. SB> This is interesting, surely the packet only enters the SB> SFC when it has been been classified (including the null classification= ) SB> and has the SFE applied? As packets traverse an SFP, re- classification may occur - typically performed by a classification function co-resident with a service function. SB> Architecturally you may always want to include a reclassifier SB> on exit (and may be entry) to every SF. It may be null, but it's SB> probably better that it is there. Reclassification may result in the selection of a new SFP, an update of the associated metadata, or both. This is referred to as "branching". For example, an initial classification results in the selection of SFP A: DPI_1 --> SLB_8. However, when the DPI service function is executed, attack traffic is detected at the application layer. DPI_1 re-classifies the traffic as attack and alters the service path to SFP B, to include a firewall for policy enforcement: dropping the traffic: DPI_1 --> FW_4. Subsequent to FW_4, surviving traffic would be returned to the original SFF. In this simple example, the DPI service function re-classifies the traffic based on local application layer classification capabilities (that were not available during the initial classification step). When traffic arrives after being steered through an SFC-unaware SF, the SFC Proxy must perform re-classification of traffic to determine the SFP. The SFC Proxy is concerned with re-attaching information SB> This should have been part of the earlier proxy functional definition. SB> Maybe if you moved this up earlier before proxy it would all be clearer= . Halpern & Pignataro Expires March 24, 2015 [Page 16] Internet-Draft SFC Architecture September 2014 for SFC-unaware SFs, and a stateful SFC Proxy simplifies such classification to a flow lookup. 4.9. Shared Metadata SB> Isn't metadata always shared? If no one else sees it, there is SB> no point in generating it. It describes a key characteristic. Like saying =93differentiated strategy= =94 =97 isn=92t it always? This improves the text with appropriate qualifie= rs. Sharing metadata allows the network to provide network-derived information to the SFs, SF-to-SF information exchange and the sharing of service-derived information to the network. Some SFCs may not require metadata exchange. SFC infrastructure enables the exchange of this shared data along the SFP. The shared metadata serves several possible roles within the SFC architecture: o Allows elements that typically operate as ships in the night to exchange information. SB> That is a sort of tautology. If they share MD they are not true SB> SITN. Surely this is about in band and outband state sharing. I think you missed the =93typically=94. o Encodes information about the network and/or data for post- service forwarding. o Creates an identifier used for policy binding by SFs. Context information can be derived in several ways: SB> This list does not scan properly from the intro fragment above. o External sources o Network node classification o Service function classification 5. Additional Architectural Concepts There are a number of issues which solutions need to address, and which the architecture informs but does not determine. This section lays out some of those concepts. 5.1. The Role of Policy Much of the behavior of service chains is driven by operator and per- customer policy. This architecture is structured to isolate the policy interactions from the data plane and control logic. Specifically, it is assumed that the service chaining control plane creates the service paths. The service chaining data plane is used to deliver the classified packets along the service chains to the intended service functions. Policy, in contrast, interacts with the system in other places. Policies and policy engines may monitor service functions to decide if additional (or fewer) instances of services are needed. SB> This seems to be conflating policy and resource management, and SB> I am not sure this is wise. The resource manager should consult SB> policy, but the problems are distinct. When Halpern & Pignataro Expires March 24, 2015 [Page 17] Internet-Draft SFC Architecture September 2014 applicable, those decisions may in turn result in interactions that direct the control logic to change the SFP placement or packet classification rules. Similarly, operator service policy, often managed by operational or business support systems (OSS or BSS), will frequently determine what service functions are available. Operator service policies also determine which sequences of functions are valid and are to be used or made available. The offering of service chains to customers, and the selection of which service chain a customer wishes to use, are driven by a combination of operator and customer policies using appropriate portals in conjunction with the OSS and BSS tools. These selections then drive the service chaining control logic, which in turn establishes the appropriate packet classification rules. SB> Didn't you just say the above. In any case it might be better in SB> the form of an intro rather than a conclusion. 5.2. SFC Control Plane This is part of the overall architecture but outside the scope of this document. SB> The specifics of the architecture of the CP may be out of scope SB> but I cannot see how it can be out of scope of the main SB> architecture, unless you want to reclassify this as the SFC packet SB> plane architecture. SB> SB> As I read more of this text I am unclear why this in not promoted SB> to the main body of the text. The SFC control plane is responsible for constructing SFPs, translating SFCs to forwarding paths and propagating path information to participating nodes to achieve requisite forwarding behavior to construct the service overlay. For instance, an SFC construction may be static; selecting exactly which SFFs and which SFs from those SFFs are to be used, or it may be dynamic, allowing the network to perform some or all of the choices of SFF or SF to use to deliver the selected service chain within the constraints represented by the service path. In the SFC architecture, SFs are resources; SB> SFs or SF instances? I don't think it becomes an accountable SB> resource until it is instantiated. the control plane manages and communicates their capabilities, availability and location in fashions suitable for the transport and SFC operations in use. The control plane is also responsible for the creation of the context (see below). The control plane may be distributed (using new or existing control plane protocols), or be centralized, or a combination of the two. The SFC control plane provides the following functionality: 1. An SFC-enabled domain wide view of all available service function resources as well as the network locators through which they are reachable. 2. Uses SFC policy to construct service function chains, and associated service function paths. Halpern & Pignataro Expires March 24, 2015 [Page 18] Internet-Draft SFC Architecture September 2014 3. Selection of specific SFs for a requested SFC, either statically (using specific SFs) or dynamically (using service explicit SFs at the time of delivering traffic to them). 4. Provides requisite SFC data plane information to the SFC architecture components, most notably the SFF. 5. Allocation of metadata associated with a given SFP and propagation of the metadata to relevant SFs and/or SFC encapsulation-proxies or their respective policy planes. SB> I am not sure what it means to allocate metadata. Do you mean SB> MD storage, or MD packet space? Neither =97 defining what is relevant MD for a given SFP. 5.3. Resource Control The SFC system may be responsible for managing all resources necessary for the SFC components to function. This includes network constraints used to plan and choose network path(s) between service function forwarders, network communication paths between service function forwarders and their attached service functions, characteristics of the nodes themselves such as memory, number of virtual interfaces, routes, and instantiation, configuration, and deletion of SFs. The SFC system will also be required to reflect policy decisions about resource control, as expressed by other components in the system. While all of these aspects are part of the overall system, they are beyond the scope of this architecture. SB> The relationship between the RC/RM and the CP seems unclear. 5.4. Infinite Loop Detection and Avoidance This SFC architecture is predicated on topological independence from the underlying forwarding topology. Consequently, a service topology is created by Service Function Paths or by the local decisions of the Service Function Forwarders based on the constraints expressed in the SFP. SB> The concept of service topologies and overlays would be useful much ear= lier in the text. Due to the overlay constraints, the packet-forwarding path may need to visit the same SFF multiple times, and in some less common cases may even need to visit the same SF more than once. The Service Chaining solution needs to permit these limited and policy-compliant loops. At the same time, the solutions must ensure that indefinite and unbounded loops cannot be formed, as such would consume unbounded resources without delivering any value. In other words, this architecture prevents infinite Service Function Loops, even when Service Functions may be invoked multiple times in the same SFP. SB> You say it does, but I don't see how it does it. Do you anticipate SB> it happening in the CP or the DP or both? SB> Both. Halpern & Pignataro Expires March 24, 2015 [Page 19] Internet-Draft SFC Architecture September 2014 5.5. Load Balancing Considerations Supporting function elasticity and high-availability should not overly complicate SFC or lead to unnecessary scalability problems. In the simplest case, where there is only a single function in the SFP (the next hop is either the destination address of the flow or the appropriate next hop to that destination), one could argue that there may be no need for SFC. SB> It is unusual to lead with the dejenerate case (i.e. no SFC) Noted. It=92s going from simple to complex. In the cases where the classifier is separate from the single function or a function at the terminal address may need sub-prefix or per-subscriber metadata, a single SFP exists (the metadata changes but the SFP does not), regardless of the number of potential terminal addresses for the flow. This is the case of the simple load balancer. See Figure 4. +---+ +---++--->web server source+-->|sff|+-->|sf1|+--->web server +---+ +---++--->web server Figure 4: Simple Load Balancing By extrapolation, in the case where intermediary functions within a chain had similar "elastic" behaviors, we do not need separate chains to account for this behavior - as long as the traffic coalesces to a common next-hop after the point of elasticity. In Figure 5, we have a chain of five service functions between the traffic source and its destination. +---+ +---+ +---+ +---+ +---+ +---+ |sf2| |sf2| |sf3| |sf3| |sf4| |sf4| +---+ +---+ +---+ +---+ +---+ +---+ | | | | | | +-----+-----+ +-----+-----+ | | + + +---+ +---+ +---+ +---+ +---+ source+-->|sff|+-->|sff|+--->|sff|+--->|sff|+-->|sff|+-->destination +---+ +---+ +---+ +---+ +---+ + + + | | | +---+ +---+ +---+ |sf1| |sf3| |sf5| +---+ +---+ +---+ Figure 5: Load Balancing Halpern & Pignataro Expires March 24, 2015 [Page 20] Internet-Draft SFC Architecture September 2014 This would be represented as one service function path: sf1->sf2->sf3->sf4->sf5. The SFF is a logical element, which may be made up of one or multiple components. In this architecture, the SFF may handle load distribution based on policy. It can also be seen in the above that the same service function may be reachable through multiple SFFs, as discussed earlier. The selection of which SFF to use to reach SF3 may be made by the control logic in defining the SFP, or may be left to the SFFs themselves, depending upon policy, solution, and deployment constraints. In the latter case, it needs to be assured that exactly one SFF takes responsibility to steer traffic through SF3. SB> Shouldn't the architecture lead with the general case and note SB> that any function can be replaced with the null function. 5.6. MTU and Fragmentation Considerations This architecture prescribes additional information being added to packets to identify service function paths and often to represent metadata. It also envisions adding transport information to carry packets along service function paths, at least between service function forwarders. This added information increases the size of the packet to be carried by service chaining. Such additions could potentially increase the packet size beyond the MTU supported on some or all of the media used in the service chaining domain. Such packet size increases can thus cause operational MTU problems. Requiring fragmentation and reassembly in an SFF would be a major processing increase, and might be impossible with some transports. SB> Sure but the SFE is teh network layer of the SFC plane and could SB> do this. Expecting service functions to deal with packets fragmented by the SFC function might be onerous even when such fragmentation was possible. Thus, at the very least, solutions need to pay attention to the size cost of their approach. There may be alternative or additional means available, although any solution needs to consider the tradeoffs. These considerations apply to any generic architecture that increases the header size. There are also more specific MTU considerations: Effects on Path MTU Discovery (PMTUD) as well as deployment considerations. Deployments within a single administrative control or even a single Data Center complex can afford more flexibility in dealing with larger packets, and deploying existing mitigations that decrease the likelihood of fragmentation or discard. 5.7. SFC OAM Operations, Administration, and Maintenance (OAM) tools are an integral part of the architecture. These serve various purposes, including fault detection and isolation, and performance management. For example, there are many advantages of SFP liveness detection, Halpern & Pignataro Expires March 24, 2015 [Page 21] Internet-Draft SFC Architecture September 2014 including status reporting, support for resiliency operations and policies, and an enhanced ability to balance load. Service Function Paths create a services topology, and OAM performs various functions within this service layer. Furthermore, SFC OAM follows the same architectural principles of SFC in general. For example, topological independence (including the ability to run OAM over various overlay technologies) and classification-based policy. We can subdivide the SFC OAM architecture in two parts: o In-band: OAM packets follow the same path and share fate with user packets, within the service topology. For this, they also follow the architectural principle of consistent policy identifiers, and use the same path IDs as the service chain data packets. Load balancing and SFC encapsulation with packet forwarding are particularly important here. o Out-of-band: reporting beyond the actual data plane. An additional layer beyond the data-plane OAM allows for additional alerting and measurements. This architecture prescribes end-to-end SFP OAM functions, which implies SFF understanding of whether an in-band packet is an OAM or user packet. However, service function validation is outside of the scope of this architecture, and application-level OAM is not what this architecture prescribes. Some of the detailed functions performed by SFC OAM include fault detection and isolation in a Service Function Path or a Service Function, verification that connectivity using SFPs is both effective and directing packets to the intended service functions, service path tracing, diagnostic and fault isolation, alarm reporting, performance measurement, locking and testing of service functions, validation with the control plane (see Section 5.2), and also allow for vendor- specific as well as experimental functions. SFC should leverage, and if needed extend relevant existing OAM mechanisms. 5.8. Resilience and Redundancy As a practical operational requirement, any service chaining solution needs to be able to respond effectively, and usually very quickly, to failure conditions. These may be failures of connectivity in the network between SFFs, failures of SFFs, or failures of SFs. Per-SF state, as for example stateful-firewall state, is the responsibility of the SF, and not addressed by this architecture. Halpern & Pignataro Expires March 24, 2015 [Page 22] Internet-Draft SFC Architecture September 2014 Multiple techniques are available to address this issue. Solutions can describe both what they require and what they allow to address failure. Solutions can make use of flexible specificity of service function paths, if the SFF can be given enough information in a timely fashion to do this. Solutions can also make use of MAC or IP level redundancy mechanisms such as VRRP. Also, particularly for SF failures, load balancers co-located with the SFF or as part of the service function delivery mechanism can provide such robustness. Similarly, operational requirements imply resilience in the face of load changes. While mechanisms for managing (e.g., monitoring, instantiating, loading images, providing configuration to service function chaining control, deleting, etc.) virtual machines are out of scope for this architecture, solutions can and are aided by describing how they can make use of scaling mechanisms. SB> Given that we are introducing a new network layer construct including SB> something that is or is a very close cousin to a network layer, surely SB> we are missing an opportunity by not including this on day one. 6. Security Considerations This document does not define a new protocol and therefore creates no new security issues. Security considerations apply to the realization of this architecture. Such realization ought to provide means to protect the SFC-enabled domain and its borders against various forms of attacks, including DDoS attacks. Further, SFC OAM Functions need to not negatively affect the security considerations of an SFC-enabled domain. Additionally, all entities (software or hardware) interacting with the service chaining mechanisms need to provide means of security against malformed, poorly configured (deliberate or not) protocol constructs and loops. These considerations are largely the same as those in any network, particularly an overlay network. SB> I just don't buy this for a security analysis. The Architecture needs SB> direct the compenent designers to look at security issues associated SB> with the new components and functionality being introduced. SB> For example the SFE will have special considerations, so will the SB> the path changes that you talk about earlier. Then there is resource SB> conflicts and their impact as a security problem. Then there is the SB> issue of privacy. Really each component of the ach needs to be looked SB> at from a security PoV and guidance provided to the component designer. Text? Thanks, Carlos. - Stewart -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --_000_D8D13D2266C742499AEE2E681BE1739Bciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Stewart,

Thanks again for your comments, and apologies for the delay= =97 please find some responses inline.

On Nov 12, 2014, at 3:17 PM, Stewart Bryant (stbryant) <= stbryant@cisco.com>= wrote:

Correcting an error in the to list.

On 12/11/2014 20:05, Stewart Bryant wrote:
SB> This document lacks the precision and that I would h=
ave hoped for=20
SB> in an architecture. I understand that the this was deliberate=20
SB> in order to allow implementation flexibility, but I don't=20
SB> buy that.
SB>
SB> What we have here is a type of layered network, and whilst=20
SB> verbal discussions have refuted that, you have many references
SB> to overlay topologies.
SB>
SB> This would be better understood if you described it as a layered
SB> system,
As mentioned before (and verbally in your reference above), that=92s w= hat we do not want to do. More below.
 if you only used generalized the components with fully
SB> functionality, and then explained which could be NULL. In the=20
SB> case of sub-functional components they should not be part of the=20
SB> core architecture, but the techniques used to create a full function
SB> component by assistance (the proxy) described outside the main
SB> architecture.
Within the context of SFC, it is important that the architecture descr= ibes the proxy =97 as we are living in a world in which we want to include = legacy and not craft an fully functional architecture that ignores it. 
SB>
SB> I understand that in part the approach used here was to allow
SB> a mixture of implementation styles - the concept of explicit
SB> and implicit SFE - with network layer constructs supplying the=20
SB> implicit SFE. However it would be better to think of the use
SB> of implicit SFE as a type of network recursion in which the=20
SB> the encapsulator (which I think is distinct from the classifier)
SB> chooses how to encode the SFP on the packet.
SB>
We can overcomplicate it in many different ways, but let=92s not. We c= an think of it differently, I agree; but this is the way the WG thought abo= ut it.
SB> I have a nagging concern about the way that the term=
s packets is
SB> used in this text. The way it is used one would expect that there
SB> is a one for one mapping between input and output packets, but that
SB> is surely not the case. A trivial point is the case where an SF
SB> needs to defragment. Although at the physical layer the units are
SB> packets, there may surely be higher order constructs traveling
SB> between SFs.=20

I think this is a good point, more inline.

 Service Function Chaining (SFC) Architecture
                     draft-ietf-sfc-architecture-02

Abstract

   This document describes an architecture for the specification,
sb> an arch or THE arch?
Updated to =93the=94. Thanks.
   creation, and ongoing maintenance of Service Functi=
on Chains (SFC) in
   a network.  It includes architectural concepts, principles, and
   components used in the construction of composite services through
   deployment of SFCs.  This document does not propose solutions,
   protocols, or extensions to existing protocols.



1.  Introduction

   This document describes an architecture used for the creation and
sb> and or THE
Ditto.
   ongoing maintenance of Service Function Chains (SFC=
) in a network.
   It includes architectural concepts, principles, and components.

   An overview of the issues associated with the deployment of end-to-
   end service function chains, abstract sets of service functions and
   their ordering constraints that create a composite service and the
   subsequent "steering" of traffic flows through said service
   functions, is described in [I-D.ietf-sfc-problem-statement].

   This architecture presents a model addressing the problematic aspects
   of existing service deployments, including topological independence
   and configuration complexity.

   Service function chains enable composite services that are
   constructed from one or more service functions.

1.1.  Scope

   This document defines a framework to realize Service Function
   Chaining (SFC) with minimum requirements on the physical topology of
   the network.  The proposed solution relies on initial packet
   classification.  Packets initially classified for handling by a set
   of Service Functions (SFs) in the SFC-enabled domain are then
   forwarded to that set of SFs for processing.

SB> Are you allowed to reclassify, or do staged classification?=20
SB> Yes you are - you say so later - but that is not implied
SB> by the above.
Trying to explain branching here would likely create more confusion to= the reader.
   This document does not make any assumption on the d=
eployment context.
   The proposed framework covers both fixed and mobile networks.

SB> Given that you make no deployment context assumption, surely
SB> the followup mobile/fixed specific is not relevant.

I disagree =97 it is very relevant to be explicit about the scope for both = fixed and mobile. It=92s not redundant with no deployment context assumptio= n, it is just a more explicit and precise set of details. This is, again, b= ecause these details are relevant to real SFC deployments based on this architecture.
   The architecture described herein is assumed to be =
applicable to a
   single network administrative domain.  While it is possible for the
   architectural principles and components to be applied to inter-domain
   SFCs, these are left for future study.

1.2.  Assumptions

   The following assumptions are made:

   o  Not all SFs can be characterized with a standard definition in
      terms of technical description, detailed specification,
      configuration, etc.

   o  There is no global or standard list of SFs enabled in a given
      administrative domain.  The set of SFs varies as a function of the
      service to be provided and according to the networking
      environment.

   o  There is no global or standard SF chaining logic.  The ordered set
      of SFs that needs to be enabled to deliver a given service is
      specific to each administrative entity.

SB> Surely it is application specific even within an admistration?

What is =93application specific=94 in the context of a chained set of appli= cations?
 o  The chaining of SFs and the criteria to invoke them are specific
      to each administrative entity that operates an SF-enabled domain.

SB? see previous

See previous.

Halpern & Pignataro      Expires March 24, 2015                 [Page 3=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   o  Several SF chaining policies can be simultaneously applied within
      an administrative domain to meet various business requirements.

   o  No assumption is made on how FIBs and RIBs of involved nodes are
      populated.

   o  How to bind traffic to a given SF chain is policy-based.

1.3.  Definition of Terms

   Network Service:  An offering provided by an operator that is
        delivered using one or more service functions.  This may also be
        referred to as a composite service.  The term "service" i=
s used
        to denote a "network service" in the context of this docu=
ment.

        Note: Beyond this document, the term "service" is overloa=
ded
        with varying definitions.  For example, to some a service is an
        offering composed of several elements within the operator's
        network, whereas for others a service, or more specifically a
        network service, is a discrete element such as a firewall.
        Traditionally, such services (in the latter sense) host a set of
        service functions and have a network locator where the service
        is hosted.

SB> I think that you probably need an explicit definition of service.
SB> I find the text in the definition of NS self referential which is
SB> not helpful.
It is not self-referential, but yes, the WG struggled a bit with how to def= ine something so overloaded. I did at least. You can check the SFC charter = for a different way of dancing around it.

If you have specific text suggestions, by all means, please do share.<= br class=3D""> 

 Classification:  Locally instantiated policy and customer/network/
        service profile matching of traffic flows for identification of
        appropriate outbound forwarding actions.

SB> Isn't it really

SB> Locally instantiated matching of traffic flows against policy for
SB> subsequent application of the required set of network service functi=
ons.=20
SB> The policy may be ustomer/network/service specific.

Yes, I think this is a good change. 

WG, any concerns? 

 Classifier:  An element that performs Classification.

SB> A network element perhaps?

An element sounds good to me. Any particular reason why you=92d constrain i= t?
 Service Function Chain (SFC):  A service function chain defines a set
        of abstract service functions and ordering constraints that must

SB> Isn't the SFC also ordered?

        be applied to packets and/or frames selected as a result of
        classification. =20
SB> Packets, or higher order constructs like flows? You cannot
SB> do some of the SFs packet by packet

I agree with adding =93flows=94.
        The implied order may not be a linear
        progression as the architecture allows for SFCs that copy to
        more than one branch, and also allows for cases where there is
        flexibility in the order in which service functions need to be
        applied.  The term service chain is often used as shorthand for
        service function chain.

SB> See my earlier not about the apparently more restricted definition
SB> I think that you need to make the generalization clearer earlier.

See above.
 Service Function (SF):  A function that is responsibl=
e for specific
        treatment of received packets.  A Service Function can act at
        various layers of a protocol stack (e.g., at the network layer
        or other OSI layers).  As a logical component, a Service
        Function can be realized as a virtual element or be embedded in
        a physical network element.  One or multiple Service Functions
SB> multiple or more?
I guess =93one or more=94.
       can be embedded in the same network element.  M=
ultiple




Halpern & Pignataro      Expires March 24, 2015                 [Page 4=
]
=0C
Internet-Draft              SFC Architecture              September 2014


        occurrences of the Service Function can exist in the same
        administrative domain.

        One or more Service Functions can be involved in the delivery of
        added-value services.  A non-exhaustive list of abstract Service
        Functions includes: firewalls, WAN and application acceleration,
        Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
        balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
        HOST_ID injection, HTTP Header Enrichment functions, TCP
        optimizer.

SB> Not sure those are abstract SFs, surely they are explicit?
A firewall is an abstract SF, specific rules / policy makes it specific/con= crete/explicit.
        An SF may be SFC encapsulation aware, that is it receives and
        acts on information in the SFC encapsulation, or unaware, in
        which case data forwarded to the SF does not contain the SFC
        encapsulation.

   Service Function Forwarder (SFF):  A service function forwarder is
        responsible for delivering traffic received from the network to
        one or more connected service functions according to information
        carried in the SFC encapsulation, as well as handling traffic
        coming back from the SF.  Additionally, a service function
        forwarder is responsible for delivering traffic to a classifier
        when needed and supported, mapping out traffic to another SFF
        (in the same or different type of overlay), and terminating the
        SFP.


SB> In these days of NFV it may not be received from the network.
SB> Surely the traffic is native until it gets to a classifier. The
SB> way you have it here it looks like the first element is the SFF
SB> but I am not sure that is the case.
SB> Perhaps: A service function forwarder is responsible for forwarding
SB> traffic between service functions.=20
=93The network=94 is not =93the network=94 that you are thinking, I su= spect.

I think the proposed change removes important detail =97 we could remo= ve =93from the network=94.
 Metadata:  provides the ability to exchange context information
        between classifiers and SFs and among SFs.

SB> I think the first noun is missing in the above, but in any case
SB> I think a more complete definition is needed.

Text?
 Service Function Path (SFP):  The SFP provides a leve=
l of indirection
        between the fully abstract notion of service chain as a sequence
        of abstract service functions to be delivered, and the fully
        specified notion of exactly which SFF/SFs the packet will visit
        when it actually traverses the network.  By allowing the control
        components to specify this level of indirection, the operator
        may control the degree of SFF/SF selection authority that is
        delegated to the network.

SB> You have not defined control components.
SB> I think "notion" is a redundant term.
SB> I am somewhat confused by your definition.
SB> Is this really about the mapping of packets between an arbitrary
SB> member of an SF to a specific instance of the SF?

This one took the WG a lot of editing=85 
 SFC Encapsulation:  The SFC Encapsulation provides at=
 a minimum SFP
        identification, and is used by the SFC-aware functions, such as
        the SFF and SFC-aware SFs.  The SFC Encapsulation is not used
        for network packet forwarding.  In addition to SFP
        identification, the SFC encapsulation carries data plane context
        information, also referred to as metadata.

SB> Surely the "SFC E is used to attach the information needed to
SB> direct the packet through the ordered set of SFs, together with
SB> associated metadata. An additional  network layer encapsulation is n=
eeded
SB> to carry the packet over the physical network.

What is wrong with the current definition? Again, the WG invested much (on = list and in person) time to get to these.

I am happy to make changes that improve the document, but I am not sur= e I understand the guiding force other than personal preference.
 Rendered Service Path (RSP):  The Service Function Pa=
th is a
        constrained specification of where packets using a certain
        service chain must go.  While it may be so constrained as to



Halpern & Pignataro      Expires March 24, 2015                 [Page 5=
]
=0C
Internet-Draft              SFC Architecture              September 2014


        identify the exact locations, it can also be less specific.
        Packets themselves are of course transmitted from and to
        specific places in the network, visiting a specific sequence of
        SFFs and SFs.  This sequence of actual visits by a packet to
        specific SFFs and SFs in the network is known as the Rendered
        Service Path (RSP).  This definition is included here for use by
        later documents, such as when solutions may need to discuss the
        actual sequence of locations the packets visit.


SB> Not sure of the wisdom of including a definition for the future, sin=
ce
SB> when you use it you may need to tune the definition.

OK, thanks. We want to capture the definition as part of the architecture = =97 not sure of the wisdom if we do not capture it.
 SFC-enabled Domain:  A network or region of a network=
 that implements
        SFC.  An SFC-enabled Domain is limited to a single network
        administrative domain.

   SFC Proxy:  Removes and inserts SFC encapsulation on behalf of an
        SFC-unaware service function.  SFC proxies are logical elements.

SB> Not sure considering then as logical is quite right. It depends
SB> on the mapping of the operation to the physical. I could see
SB> cases where they are physical. Surely the point is that they
SB> may be co-located with another network function such as a router
SB> an operating system component such as a hypervisor.

If they are physical, the logical-physical mapping is 1:1.

 2.  Architectural Concepts

   The following sections describe the foundational concepts of service
   function chaining and the SFC architecture.

   Service Function Chaining enables the creation of composite (network)
   services that consist of an ordered set of Service Functions (SF)
   that must be applied to packets and/or frames selected as a result of
   classification.  Each SF is referenced using an identifier that is
   unique within an SF-enabled domain.  No IANA registry is required to
   store the identity of SFs.


SB> I am still worried about using packets.

Need to fix this as well =97 part of the same comment. Thanks.
 Obviously we operate on
SB> pkts, but the operation may require the reconstuction of some
SB> packet grouping typically some element of a flow before the operatio=
n
SB> can be performed. A trivial example is defragmenting a packet group
SB> but since we are dealing with abstract SFs we cannot specify the=20
SB> the unit of operation.

    Service Function Chaining is a concept that provides for more than
   just the application of an ordered set of SFs to selected traffic;
   rather, it describes a method for deploying SFs in a way that enables
   dynamic ordering and topological independence of those SFs as well as
   the exchange of metadata between participating entities.

SB> The above is a bit late in the text. I think it needs to go earlier.

It=92s in the architectural concepts.
 2.1.  Service Function Chains

   In most networks, services are constructed as abstract sequences of
SB> I don't think that are abstract in this context.
SB> Are you talking about traditional (current physically instantiated
SB> SFCs in the previous sentence?

See above.
   SFs that represent SFCs.  At a high level, an SFC is an abstracted
   view of a service that specifies the set of required SFs as well as
   the order in which they must be executed. =20

SB> Again I am not sure "abstrated view" is right here

   Graphs, as illustrated in
   Figure 1, define an SFC, where each graph node represents the
   required existence of at least one abstract SF.  Such graph nodes
   (SFs) can be part of zero, one, or many SFCs.  A given graph node
   (SF) can appear one time or multiple times in a given SFC.

SB> Not sure that graphs is right, since you only show the case
SB> of a linear chain. The construct you are going to use is
SB> graph, but that is not what the figure shows.

The figure does show a graph.
   SFCs can start from the origination point of the service function
   graph (i.e.: node 1 in Figure 1), or from any subsequent node in the
   graph. =20

SB> OK so are you trying to distinguish between physically and
SB> SFC (the new technology) instantiated SFCS?

   SFs may therefore become branching nodes in the graph, with



Halpern & Pignataro      Expires March 24, 2015                 [Page 6=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   those SFs selecting edges that move traffic to one or more branches.
   An SFC can have more than one terminus.


SB> Again that is not what your figure shows.

     ,-+-.         ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   6   )+---->(   8  =
 )
    \     /       \     /        \     /        \     /
     `---'         `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   2   )+---->(   3   )+---->(   7  =
 )+---->(   9   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

     ,-+-.         ,---.          ,---.          ,---.          ,---.
    /     \       /     \        /     \        /     \        /     \
   (   1   )+--->(   7   )+---->(   8   )+---->(   4  =
 )+---->(   7   )
    \     /       \     /        \     /        \     /        \     /
     `---'         `---'          `---'          `---'          `---'

                  Figure 1: Service Function Chain Graphs

2.2.  Service Function Chain Symmetry

   SFCs may be unidirectional or bidirectional.  A unidirectional SFC
   requires that traffic be forwarded through the ordered SFs in one
   direction (SF1 -> SF2 -> SF3), whereas a bidirectional SFC require=
s a
   symmetric path (SF1 -> SF2 -> SF3 and SF3 -> SF2 -> SF1), an=
d in
   which the SF instances are the same in opposite directions.  A hybrid
   SFC has attributes of both unidirectional and bidirectional SFCs;
   that is to say some SFs require symmetric traffic, whereas other SFs
   do not process reverse traffic or are independent of the
   corresponding forward traffic.

   SFCs may contain cycles; that is traffic may need to traverse one or
   more SFs within an SFC more than once.  Solutions will need to ensure
   suitable disambiguation for such situations.

   The architectural allowance that is made for SFPs that delegate
   choice to the network for which SFs and/or SFFs a packet will visit
   creates potential issues here.  A solution that allows such
   delegation needs to also describe how the solution ensures that those
   service chains that require service function chain symmetry can
   achieve that.

   Further, there are state tradeoffs in symmetry.  Symmetry may be
   realized in several ways depending on the SFF and classifier



Halpern & Pignataro      Expires March 24, 2015                 [Page 7=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   functionality.  In some cases, "mirrored" classification (i.e.=
, from
   Source to Destination and from Destination to Source) policy may be
   deployed, whereas in others shared state between classifiers may be
   used to ensure that symmetric flows are correctly identified, then
   steered along the required SFP.  At a high level, there are various
   common cases.  In a non-exhaustive way, there can be for example: a
   single classifier (or a small number of classifiers), in which case
   both incoming and outgoing flows could be recognized at the same
   classifier, so the synchronization would be feasible by internal
   mechanisms internal to the classifier.  Another case is the one of
   stateful classifiers where several classifiers may be clustered and
   share state.  Lastly, another case entails fully distributed
   classifiers, where synchronization needs to be provided through
   unspecified means.  This is a non-comprehensive list of common cases.

SB> Isn't an important class of classifiers one that learns state from t=
he=20
SB> egress packets/flows that is then used to provide state for the=20
SB> return packets/flow

Isn=92t that a way to provide synchronization?
 2.3.  Service Function Paths

   A service function path (SFP) is a mechanism used by service chaining
   to express the result of applying more granular policy and
SB> Not sure "more granular" is needed.

   operational constraints to the abstract requirements of a service
SB> Not sure they are abstract requirements. When you apply them they
SB> are explicit.

abstract
adject= ive
1.&nbs= p;thought of apart= from concrete realities, specific objects, or actual instances.
   chain (SFC).  This architecture does not mandate the degree of
   specificity of the SFP.  Architecturally, within the same SFC-enabled
   domain, some SFPs may be fully specified, selecting exactly which SFF
   and which SF are to be visited by packets using that SFP, while other
   SFPs may be quite vague, deferring to the SFF the decisions about the
   exact sequence of steps to be used to realize the SFC.  The
   specificity may be anywhere in between these extremes.

   As an example of such an intermediate specificity, there may be two
   SFPs associated with a given SFC, where one SFP says essentially that

SB> "says essentially is not a tight definition=94

Substituted with =93specifies=94.
   any order of SFF and SF may be used as long as it is within data
   center 1, and where the second SFP allows the same latitude, but only
   within data center 2.

   Thus, the policies and logic of SFP selection or creation (depending
   upon the solution) produce what may be thought of as a constrained
   version of the original SFC.  Since multiple policies may apply to
   different traffic that uses the same SFC, it also follows that there
   may be multiple SFPs may be associated with a single SFC.

SB> So a SFP is a specific instance of a member of the set of available =
SFCs
SB> chosen as a result of applying policy at one or points along the SFC=
?


   The architecture allows for the same SF to be reachable through
   multiple SFFs.  In these cases, some SFPs may constrain which SFF is
   used to reach which SF, while some SFPs may leave that decision to
   the SFF itself.

   Further, the architecture allows for two or more SFs to be attached
   to the same SFF, and possibly connected via internal means allowing
   more effective communication.  In these cases, some solutions or


Halpern & Pignataro      Expires March 24, 2015                 [Page 8=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   deployments may choose to use some form of internal inter-process or
   inter-VM messaging (communication behind the virtual switching
   element) that is optimized for such an environment.  This must be
   coordinated with the SFF so that the service function forwarding can
   properly perform its job.  Implementation details of such mechanisms
   are considered out of scope for this document, and can include a
   spectrum of methods: for example situations including all next-hops
   explicitly, others where a list of possible next-hops is provided and
   the selection is local, or cases with just an identifier, where all
   resolution is local.

   This architecture also allows the same SF to be part of multiple
   SFPs.

SB> Didn't you just say that?

 3.  Architecture Principles

   Service function chaining is predicated on several key architectural
   principles:

   1.  Topological independence: no changes to the underlay network
       forwarding topology - implicit, or explicit - are needed to
       deploy and invoke SFs or SFCs.

   2.  Plane separation: dynamic realization of SFPs is separated from
       packet handling operations (e.g., packet forwarding).

   3.  Classification: traffic that satisfies classification rules is
       forwarded according to a specific SFP.  For example,
       classification can be as simple as an explicit forwarding entry
       that forwards all traffic from one address into the SFP.
       Multiple classification points are possible within an SFC (i.e.
       forming a service graph) thus enabling changes/updates to the SFC
       by SFs.

       Classification can occur at varying degrees of granularity; for
       example, classification can use a 5-tuple, a transport port or
       set of ports, part of the packet payload, or it can come from
       external systems.

SB> I think that it can surely be as a result of higher level inspection=
s?
OK, added.

 4.  Shared Metadata: Metadata/context data can be sha=
red amongst SFs
       and classifiers, between SFs, and between external systems and
       SFs (e.g., orchestration).

       Generally speaking, metadata can be thought of as providing and
       sharing the result of classification=20

SB> Just classifications, or classifications and processing operations?
SB> There is gray zone between a packet forwarding system and
SB> a distributed computing system and I am not sure where SFC fits,=20
SB> nor am I sure that it makes sense to be specific at this stage.
SB> It is entirely possible that an SFC consumes the packet/flow
SB> rather than only having the capability to forward it between=20
SB> in ingress and egress.

      (that occurs within the SFC-
       enabled domain, or external to it) along an SFP.  For example, an
       external repository might provide user/subscriber information to
       a service chain classifier.  This classifier could in turn impose



Halpern & Pignataro      Expires March 24, 2015                 [Page 9=
]
=0C
Internet-Draft              SFC Architecture              September 2014


       that information in the SFC encapsulation for delivery to the
       requisite SFs.  The SFs could in turn utilize the user/subscriber
       information for local policy decisions.

   5.  Service definition independence: The SFC architecture does not
       depend on the details of SFs themselves.  Additionally, no IANA
       registry is required to store the list of SFs.

SB> Yes, but you should be careful not to preclude it.

Nothing is precluding it.
  6.  Service function chain independence: The creation, modification,
       or deletion of an SFC has no impact on other SFCs.  The same is
       true for SFPs.

SB> Yes and no. What about the resource implications?

 7.  Heterogeneous control/policy points: The architecture allows SFs
       to use independent mechanisms (out of scope for this document) to
       populate and resolve local policy and (if needed) local
       classification criteria.

4.  Core SFC Architecture Components

   At a very high level, the logical architecture of an SFC-enabled
   Domain comprises:

SB> A list would be handy rather than just a figure, and you need
SB> some text to expand on the figure.

      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . =
.
      .  +--------------+                  +------------------~=
~~
      .  |   Service    |       SFC        |  Service  +---+   +=
;---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +-=
--+   +---+
      .  +--------------+                  +------------------~=
~~
      . SFC-enabled Domain
      o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

               Figure 2: Service Function Chain Architecture


SB> This is a very confusing diagram
SB> Surely the SFC encap is attached to the packet
SB> The fig seems to confuse the the packets and the path.

It could be the reader that is confusing a nice figure :-)

I am not sure I see what you see =97 suggestions?
   The following sub-sections provide details on each logical component
   that form the basis of the SFC architecture.  A detailed overview of
   how each of these architectural components interact is provided in
   Figure 3:


SB> Well maybe, but it's not quite obvious what you are showing.=20
SB> some overview text would help before you get into the detail.











Halpern & Pignataro      Expires March 24, 2015                [Page 10=
]
=0C
Internet-Draft              SFC Architecture              September 2014


         +----------------+                        +-----------=
-----+
         |   SFC-aware    |                        |  SFC-unaware   |
         |Service Function|                        |Service Function|
         +-------+--------+                        +-------=
+--------+
                 |                                         |
           SFC Encapsulation                       No SFC Encapsulation
                 |                  SFC                    |
    +---------+  +----------------+ Encapsulation     +=
---------+
    |SFC-Aware|-----------------+  \     +------------|SFC Proxy|
    |    SF   | ... ----------+  \  \   /             +---------=
3;
    +---------+                \  \  \ /
                              +-------+--------+
                              |   SF Forwarder |
                              |      (SFF)     |
                              +-------+--------+
                                      |
                              SFC Encapsulation
                                      |
                          ... SFC-enabled Domain ...
                                      |
                          Network Overlay Transport
                                      |
                                  _,....._
                               ,-'        `-.
                              /              `.
                             |     Network    |
                             `.              /
                               `.__     __,-'
                                   `''''

         Figure 3: Service Function Chain Architecture Components


SB> Coming back here after reading a bit more. Is the SFF to be consider=
ed the
SB> hub in a hub and spoke processing model for a set of SFs? If so it w=
ould
SB> be useful to say that up front. However that raises the issue of whe=
ther
SB> the single network attachment point that you show is desirable. A st=
andard
SB> firewall design would not mix dirty and clean traffic, and yet that =
is
SB> what the above appears to show.


 4.1.  SFC Encapsulation

   The SFC encapsulation enables service function path selection.  It
   also enables the sharing of metadata/context information when such
   metadata exchange is required.

SB> I don't think that is quite right. Surely the=20
SB> SFC encapsulation enables <some component> to select the next
SB> element of the path?
 
   The SFC encapsulation provides explicit information used to identif=
y
SB> Provides or carries?

Carries.
   the SFP.  However, the SFC encapsulation is not a t=
ransport
   encapsulation itself: it is not used to forward packets within the
   network fabric. =20
SB> ... but surely it is a shim layer of some sort?

   If packets need to flow between separate physical
   platforms, the SFC encapsulation therefore relies on an outer network
   transport. =20
SB> Surely it is network layer header specific to the inter SFC
SB> transport?

   Transit forwarders -- such as router and switches --
   simply forward SFC encapsulated packets based on the outer (non-SFC)
   encapsulation.

SB> d/simply/
OK

Halpern & Pignataro      Expires March 24, 2015                [Page 11=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   One of the key architecture principles of SFC is that the SFC
   encapsulation remain transport independent.  As such any network
   transport protocol may be used to carry the SFC encapsulated traffic.

SB> Not sure I like "network transport protocol" since this is=
 going
SB> to be confused with transport layer and I am not sure whether
SB> you would require a transport layer, indeed the SFE might will
SB> be considered a transport layer in the classical sense.

 4.2.  Service Function (SF)

   The concept of an SF evolves; rather than being viewed as a bump in
   the wire, an SF becomes a resource within a specified administrative
   domain that is available for consumption as part of a composite
   service.  SFs send/receive data to/from one or more SFFs.  SFC-aware
   SFs receive this traffic with the SFC encapsulation.

SB> I do not understand the above para.

   While the SFC architecture defines a new encapsulation - the SFC
   encapsulation -=20

SB> no it does not - it is not defined in this memo. You introduce
SB> the concept and define some of the characteristics of it.

OK, fixed.

   and several logical components for the construction
   of SFCs, existing SF implementations may not have the capabilities to
   act upon or fully integrate with the new SFC encapsulation.  In order
   to provide a mechanism for such SFs to participate in the
   architecture, an SFC proxy function is defined (see Section 4.6).
   The SFC proxy acts as a gateway between the SFC encapsulation and
   SFC-unaware SFs.  The integration of SFC-unaware service functions is
   discussed in more detail in the SFC proxy section.

SB> The above is confusing. Do they participate in the architecture (thi=
s
SB> text)? I think that you mean that in order to employ SF instances
SB> that do not understand the SFE, a proxy as a gateway between the=20
SB> the SFE aware domain and the non-SFE aware domain. Now if it is
SB> a gateway why is it not called a gateway rather than a proxy which
SB> is something that does something on behalf of something else.
SB> I would think that it might be a SFE proxy, but that is not quite
SB> right either.


 This architecture allows an SF to be part of multiple SFPs and SFCs.

SB> I am sure you said that before.

 4.3.  Service Function Forwarder (SFF)

   The SFF is responsible for forwarding packets and/or frames received
   from the network to one or more SFs associated with a given SFF using
   information conveyed in the SFC encapsulation.  Traffic from SFs
   eventually returns to the same SFF, which is responsible for
   injecting traffic back onto the network.

SB> It is not clear why it needs to be the exact same SFF
Because otherwise the SF would be an SFF.
   The collection of SFFs and associated SFs creates a service plane
   overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
   Within this service plane, the SFF component connects different SFs
   that form a service function path.

SB> This conceptual model seems quite fundamental and this I=20
SB> am surprised that it is not much earlier in the document.
SB> I have been wondering why the SFC system was not considered
SB> an overlay network of some sort, and was told by the authors
SB> that this was not possible. The above seems at odds with that
Sb> statement.

   SFFs maintain the requisite SFP forwarding information. =20
SB> Maintain - as in being the control plane for this, or
SB> maintain as in store?
   SFP
   forwarding information is associated with a service path identifier
   that is used to uniquely identify an SFP.  The service forwarding
   state enables an SFF to identify which SFs of a given SFP should be
   applied, and in what order, as traffic flows through the associated
   SFP.  While there may appear to the SFF to be only one available way
   to deliver the given SF, there may also be multiple choices allowed
   by the constraints of the SFP.

   If there are multiple choices, the SFF needs to preserve the property
   that all packets of a given flow are handled the same way, since the



Halpern & Pignataro      Expires March 24, 2015                [Page 12=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   SF may well be stateful.  Additionally, the SFF may preserve the
   handling of packets based on other properties on top of a flow, such
   as a subscriber, session, or application instance identification.

SB> I feel that the issue of handing higher order objects needs to have
SB> been introduced much earlier in the architecture.
I agree it would help =97 do you have a specific text addition and location= ?
   The SFF also has the information to allow it to for=
ward packets to
   the next SFF after applying local service functions.  Again, while
   there may be only a single choice available, the architecture allows
   for multiple choices for the next SFF.  As with SFs, the solution
   needs to operate such that the behavior with regard to specific flows
   (see the Rendered Service Path) is stable.  The selection of
   available SFs and next SFFs may be interwoven when an SFF supports
   multiple distinct service functions and the same service function is
   available at multiple SFFs.  Solutions need to be clear about what is
   allowed in these cases.

   Even when the SFF supports and utilizes multiple choices, the
   decision as to whether to use flow-specific mechanisms or coarser
   grained means to ensure that the behavior of specific flows is stable
   is a matter for specific solutions and specific implementations.

   The SFF component has the following primary responsibilities:

   1.  SFP forwarding : Traffic arrives at an SFF from the network.  The
       SFF determines the appropriate SF the traffic should be forwarded
       to via information contained in the SFC encapsulation.  Post-SF,
       the traffic is returned to the SFF, and if needed forwarded to
       another SF associated with that SFF.  If there is another non-
       local (i.e., different SFF) hop in the SFP, the SFF further
       encapsulates the traffic in the appropriate network transport
       protocol and delivers it to the network for delivery to the next
       SFF along the path.  Related to this forwarding responsibility,
       an SFF should be able to interact with metadata.

   2.  Terminating SFPs : An SFC is completely executed when traffic has
       traversed all required SFs in a chain.  When traffic arrives at
       the SFF after the last SF has finished processing it, the final
       SFF knows from the service forwarding state that the SFC is
       complete.  The SFF removes the SFC encapsulation and delivers the
       packet back to the network for forwarding.

   3.  Maintaining flow state: In some cases, the SFF may be stateful.
       It creates flows and stores flow-centric information.  This state
       information may be used for a range of SFP-related tasks such as
       ensuring consistent treatment of all packets in a given flow,
       ensuring symmetry or for state-aware SFC Proxy functionality (see
       Section 4.8).





Halpern & Pignataro      Expires March 24, 2015                [Page 13=
]
=0C
Internet-Draft              SFC Architecture              September 2014


4.3.1.  Transport Derived SFF

   Service function forwarding, as described above, directly depends
   upon the use of the service path information contained in the SFC
   encapsulation.  However, existing implementations may not be able to
   act on the SFC encapsulation.  These platforms may opt to use
   existing transport information if it can be arranged to provide
   explicit service path information.

   This results in the same architectural behavior and meaning for
   service function forwarding and service function paths.  It is the
   responsibility of the control components to ensure that the transport
   path executed in such a case is fully aligned with the path
   identified by the information in the service chaining encapsulation.

SB> The title does not seem quite right. What I think you have
SB> is a system in which you map an SFC onto an explicit path
SB> of some sort in the lower layers (I was going to say network layer
SB> but I am not sure if that is what you intend). So I am not sure=20
SB> derived is the correct word. It would be closer to say "emulati=
on
SB> of SFF using explicit network paths. Noting that these paths may
SB> be encoded in the packet or encoded in the FIB.
Derived is not as precise as desired perhaps, but I think =91emulation=92 i= s worst. Others?
 4.4.  SFC-Enabled Domain

   Specific features may need to be enforced at the boundaries of an
   SFC-enabled domain, for example to avoid leaking SFC information.
   Using the term node to refer generically to an entity that is
   performing a set of functions, in this context, an SFC Boundary Node
   denotes a node that connects one SFC-enabled domain to a node either
   located in another SFC-enabled domain or in a domain that is SFC-
   unaware.

   An SFC Boundary node can act as egress or ingress. =20
SB> do you mean or or and/or i.e. can it be both at the same time.

Yes.
   An SFC Egress
   Node denotes a SFC Boundary Node that handles traffic leaving the
   SFC-enabled domain the Egress Node belongs to.  Such a node is
   required to remove any information specific to the SFC Domain,
   typically the SFC Encapsulation.  An SFC Ingress Node denotes an SFC
   Boundary Node that handles traffic entering the SFC-enabled domain.
   In most solutions and deployments this will need to include a
   classifier, and will be responsible for adding the SFC encapsulation
   to the packet.

SB> Logically doesn't it always include the classifier, where the set of
SB> classifier types includes the null classifier? The only exception
SB> I suppose is when you are receiving traffic from a trusted
SB> SFC aware peer, but it might be better to be more explicit
SB> about the normal case and then introduce the exception

 4.5.  Network Overlay and Network Components

   Underneath the SFF there are components responsible for performing
   the transport (overlay) forwarding.  They do not consult the SFC
   encapsulation or inner payload for performing this forwarding.  They
   only consult the outer-transport encapsulation for the transport
   (overlay) forwarding.

SB> This layer model needs to be brought out much earlier instead of=20
SB> having the reader deduce it up to this point.
SB> Indeed the layering model makes for a better way of explaining
SB> the operation of the system.

Better for readers that think in terms of and are used to seeing layer mode= ls. As explained, that=92s not how we want to limit this architecture.
 4.6.  SFC Proxy

   In order for the SFC architecture to support SFC-unaware SFs (e.g.,
   legacy service functions) a logical SFC proxy function may be used.

SB> Is it a logical proxy or a real proxy, and why only may, surely
SB> it *is* used.


Halpern & Pignataro      Expires March 24, 2015                [Page 14=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   This function sits between an SFF and one or more SFs to which the
   SFF is directing traffic.

   The proxy accepts packets from the SFF on behalf of the SF.  It
   removes the SFC encapsulation, and then uses a local attachment
   circuit to deliver packets to SFC unaware SFs.  It also receives
   packets back from the SF, reapplies the SFC encapsulation, and
   returns them to the SFF for processing along the service function
   path.

   Thus, from the point of view of the SFF, the SFC proxy appears to be
   part of an SFC aware SF.

   Communication details between the SFF and the SFC Proxy are the same
   as those between the SFF and an SFC aware SF.  The details of that
   are not part of this architecture.  The details of the communication
   methods over the local attachment circuit between the SFC proxy and
   the SFC-unaware SF are dependent upon the specific behaviors and
   capabilities of that SFC-unaware SF, and thus are also out of scope
   for this architecture.

   Specifically, for traffic received from the SFF intended for the SF
   the proxy is representing, the SFC proxy:

   o  Removes the SFC encapsulation from SFC encapsulated packets.

   o  Identifies the required SF to be applied based on available
      information including that carried in the SFC encapsulation.

   o  Selects the appropriate outbound local attachment circuit through
      which the next SF for this SFP is reachable.  This is derived from
      the identification of the SF carried in the SFC encapsulation, and
      may include local techniques.  Examples of a local attachment
      circuit include, but are not limited to, VLAN, IP-in-IP, L2TPv3,
      GRE, VXLAN.

   o  Forwards the original payload via the selected local attachment
      circuit to the appropriate SF.

SB> I think you have missed the storage of the SFE and I am not
SB> sure how this gets back to the specific packet. This causes me
SB> wonder if it is the original payload or not since it may by
SB> now be SFC modified. It is surely the SFE payload that gets=20
SB> passed up, and to re-attach the correct SFE afterwards, might
SB> you not have to modify it?


 When traffic is returned from the SF:

   o  Applies the required SFC encapsulation.  The determination of the
      encapsulation details may be inferred by the local attachment
      circuit through which the packet and/or frame was received, or via
      packet classification, or other local policy.  In some cases,
      packet ordering or modification by the SF may necessitate
      additional classification in order to re-apply the correct SFC
      encapsulation.

SB> This function is surely split between the outbound and inbound
SB> proxy functions.

 Halpern & Pignataro      Expires March 24, 2015                [P=
age 15]
=0C
Internet-Draft              SFC Architecture              September 2014


   o  Delivers the packet with the SFC Encapsulation to the SFF, as
      would happen with packets returned from an SFC-aware SF.

   Alternatively, a service provider may decide to exclude legacy
   service functions from an SFC domain.

SB> This might have been better expressed earlier in the text my noting
SB> that the proxy was optional, making the afterthought above redundant=
.


 4.7.  Classification

   Traffic from the network that satisfies classification criteria is
   directed into an SFP and forwarded to the requisite service
   function(s).  Classification is handled by a service classification
   function; initial classification occurs at the ingress to the SFC
   domain.  The granularity of the initial classification is determined
   by the capabilities of the classifier and the requirements of the SFC
   policy.  For instance, classification might be relatively coarse: all
   packets from this port are subject to SFC policy X and directed into
   SFP A, or quite granular: all packets matching this 5-tuple are
   subject to SFC policy Y and directed into SFP B.

   As a consequence of the classification decision, the appropriate SFC
   encapsulation is imposed on the data, and a suitable SFP is selected
   or created.  Classification results in attaching the traffic to a
   specific SFP.

SB> How about:

SFC domain ingress traffic is first processed by a classifier which
either rejects the traffic or prepares it for processing by the required
SFs. The classifier applies policy to the packet to determine the required
SFC, and then to map that to the required SFP. The classifier applies
the corresponding SFE and if necessary the appropriate network layer
encapsulation and forwards the packet to the first SFF on the chain.
This seems to leave out and awful set of details. And why first either reje= cts or prepares?

 4.8.  Re-Classification and Branching

   The SFC architecture supports re-classification (or non-initial
   classification) as well. =20

SB> This is interesting, surely the packet only enters the
SB> SFC when it has been been classified (including the null classificat=
ion)
SB> and has the SFE applied?

   As packets traverse an SFP, re-
   classification may occur - typically performed by a classification
   function co-resident with a service function. =20
SB> Architecturally you may always want to include a reclassifier
SB> on exit (and may be entry) to every SF. It may be null, but it's
SB> probably better that it is there.

   Reclassification may
   result in the selection of a new SFP, an update of the associated
   metadata, or both.  This is referred to as "branching".

   For example, an initial classification results in the selection of
   SFP A: DPI_1 --> SLB_8.  However, when the DPI service function is
   executed, attack traffic is detected at the application layer.  DPI_1
   re-classifies the traffic as attack and alters the service path to
   SFP B, to include a firewall for policy enforcement: dropping the
   traffic: DPI_1 --> FW_4.  Subsequent to FW_4, surviving traffic would
   be returned to the original SFF.  In this simple example, the DPI
   service function re-classifies the traffic based on local application
   layer classification capabilities (that were not available during the
   initial classification step).

   When traffic arrives after being steered through an SFC-unaware SF,
   the SFC Proxy must perform re-classification of traffic to determine
   the SFP.  The SFC Proxy is concerned with re-attaching information

SB> This should have been part of the earlier proxy functional definitio=
n.
SB> Maybe if you moved this up earlier before proxy it would all be clea=
rer.


 Halpern & Pignataro      Expires March 24, 2015                [P=
age 16]
=0C
Internet-Draft              SFC Architecture              September 2014


   for SFC-unaware SFs, and a stateful SFC Proxy simplifies such
   classification to a flow lookup.

4.9.  Shared Metadata

SB> Isn't metadata always shared? If no one else sees it, there is
SB> no point in generating it.

It describes a key characteristic. Like saying =93differentiated strategy= =94 =97 isn=92t it always? This improves the text with appropriate qualifie= rs.
   Sharing metadata allows the network to provide network-d=
erived
   information to the SFs, SF-to-SF information exchange and the sharing
   of service-derived information to the network.  Some SFCs may not
   require metadata exchange.  SFC infrastructure enables the exchange
   of this shared data along the SFP.  The shared metadata serves
   several possible roles within the SFC architecture:

   o  Allows elements that typically operate as ships in the night to
      exchange information.

SB> That is a sort of tautology. If they share MD they are not true
SB> SITN. Surely this is about in band and outband state sharing.
I think you missed the =93typically=94.
   o  Encodes information about the network and/or data for post-
      service forwarding.

   o  Creates an identifier used for policy binding by SFs.

   Context information can be derived in several ways:

SB> This list does not scan properly from the intro fragment above.

   o  External sources

   o  Network node classification

   o  Service function classification



 5.  Additional Architectural Concepts

   There are a number of issues which solutions need to address, and
   which the architecture informs but does not determine.  This section
   lays out some of those concepts.

5.1.  The Role of Policy

   Much of the behavior of service chains is driven by operator and per-
   customer policy.  This architecture is structured to isolate the
   policy interactions from the data plane and control logic.

   Specifically, it is assumed that the service chaining control plane
   creates the service paths.  The service chaining data plane is used
   to deliver the classified packets along the service chains to the
   intended service functions.

   Policy, in contrast, interacts with the system in other places.
   Policies and policy engines may monitor service functions to decide
   if additional (or fewer) instances of services are needed. =20

SB> This seems to be conflating policy and resource management, and
SB> I am not sure this is wise. The resource manager should consult
SB> policy, but the problems are distinct.

   When



Halpern & Pignataro      Expires March 24, 2015                [Page 17=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   applicable, those decisions may in turn result in interactions that
   direct the control logic to change the SFP placement or packet
   classification rules.

   Similarly, operator service policy, often managed by operational or
   business support systems (OSS or BSS), will frequently determine what
   service functions are available.  Operator service policies also
   determine which sequences of functions are valid and are to be used
   or made available.

   The offering of service chains to customers, and the selection of
   which service chain a customer wishes to use, are driven by a
   combination of operator and customer policies using appropriate
   portals in conjunction with the OSS and BSS tools.  These selections
   then drive the service chaining control logic, which in turn
   establishes the appropriate packet classification rules.


SB> Didn't you just say the above. In any case it might be better in
SB> the form of an intro rather than a conclusion.

 5.2.  SFC Control Plane

   This is part of the overall architecture but outside the scope of
   this document.

SB> The specifics of the architecture of the CP may be out of scope
SB> but I cannot see how it can be out of scope of the main
SB> architecture, unless you want to reclassify this as the SFC packet
SB> plane architecture.
SB>
SB> As I read more of this text I am unclear why this in not promoted
SB> to the main body of the text.


    The SFC control plane is responsible for constructing SFPs,
   translating SFCs to forwarding paths and propagating path information
   to participating nodes to achieve requisite forwarding behavior to
   construct the service overlay.  For instance, an SFC construction may
   be static; selecting exactly which SFFs and which SFs from those SFFs
   are to be used, or it may be dynamic, allowing the network to perform
   some or all of the choices of SFF or SF to use to deliver the
   selected service chain within the constraints represented by the
   service path.

   In the SFC architecture, SFs are resources;=20

SB> SFs or SF instances? I don't think it becomes an accountable=20
SB> resource until it is instantiated.

   the control plane manages
   and communicates their capabilities, availability and location in
   fashions suitable for the transport and SFC operations in use.  The
   control plane is also responsible for the creation of the context
   (see below).  The control plane may be distributed (using new or
   existing control plane protocols), or be centralized, or a
   combination of the two.

   The SFC control plane provides the following functionality:

   1.  An SFC-enabled domain wide view of all available service function
       resources as well as the network locators through which they are
       reachable.

   2.  Uses SFC policy to construct service function chains, and
       associated service function paths.



Halpern & Pignataro      Expires March 24, 2015                [Page 18=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   3.  Selection of specific SFs for a requested SFC, either statically
       (using specific SFs) or dynamically (using service explicit SFs
       at the time of delivering traffic to them).

   4.  Provides requisite SFC data plane information to the SFC
       architecture components, most notably the SFF.

   5.  Allocation of metadata associated with a given SFP and
       propagation of the metadata to relevant SFs and/or SFC
       encapsulation-proxies or their respective policy planes.

SB> I am not sure what it means to allocate metadata. Do you mean
SB> MD storage, or MD packet space?

Neither =97 defining what is relevant MD for a given SFP.
 5.3.  Resource Control

   The SFC system may be responsible for managing all resources
   necessary for the SFC components to function.  This includes network
   constraints used to plan and choose network path(s) between service
   function forwarders, network communication paths between service
   function forwarders and their attached service functions,
   characteristics of the nodes themselves such as memory, number of
   virtual interfaces, routes, and instantiation, configuration, and
   deletion of SFs.

   The SFC system will also be required to reflect policy decisions
   about resource control, as expressed by other components in the
   system.

   While all of these aspects are part of the overall system, they are
   beyond the scope of this architecture.


SB> The relationship between the RC/RM and the CP seems unclear.

 5.4.  Infinite Loop Detection and Avoidance

   This SFC architecture is predicated on topological independence from
   the underlying forwarding topology.  Consequently, a service topology
   is created by Service Function Paths or by the local decisions of the
   Service Function Forwarders based on the constraints expressed in the
   SFP. =20

SB> The concept of service topologies and overlays would be useful much =
earlier in the text.

   Due to the overlay constraints, the packet-forwarding path may
   need to visit the same SFF multiple times, and in some less common
   cases may even need to visit the same SF more than once.  The Service
   Chaining solution needs to permit these limited and policy-compliant
   loops.  At the same time, the solutions must ensure that indefinite
   and unbounded loops cannot be formed, as such would consume unbounded
   resources without delivering any value.

   In other words, this architecture prevents infinite Service Function
   Loops, even when Service Functions may be invoked multiple times in
   the same SFP.

SB> You say it does, but I don't see how it does it. Do you anticipate
SB> it happening in the CP or the DP or both?
SB>=20
Both.

 Halpern & Pignataro      Expires March 24, 2015                [P=
age 19]
=0C
Internet-Draft              SFC Architecture              September 2014


5.5.  Load Balancing Considerations

   Supporting function elasticity and high-availability should not
   overly complicate SFC or lead to unnecessary scalability problems.

   In the simplest case, where there is only a single function in the
   SFP (the next hop is either the destination address of the flow or
   the appropriate next hop to that destination), one could argue that
   there may be no need for SFC.

SB> It is unusual to lead with the dejenerate case (i.e. no SFC)
Noted. It=92s going from simple to complex.
   In the cases where the classifier is separate from =
the single
   function or a function at the terminal address may need sub-prefix or
   per-subscriber metadata, a single SFP exists (the metadata changes
   but the SFP does not), regardless of the number of potential terminal
   addresses for the flow.  This is the case of the simple load
   balancer.  See Figure 4.

                            +---+    +---++--->web s=
erver
                  source+-->|sff|+-->|sf1|+--->web ser=
ver
                            +---+    +---++--->web s=
erver

                      Figure 4: Simple Load Balancing

   By extrapolation, in the case where intermediary functions within a
   chain had similar "elastic" behaviors, we do not need separate=
 chains
   to account for this behavior - as long as the traffic coalesces to a
   common next-hop after the point of elasticity.

   In Figure 5, we have a chain of five service functions between the
   traffic source and its destination.

                +---+ +---+ +---+   +---+ &=
#43;---+ +---+
                |sf2| |sf2| |sf3|   |sf3| |sf4| |sf4|
                +---+ +---+ +---+   +---+ &=
#43;---+ +---+
                  |     |     |       |     |     |
                  +-----+-----+       +-----+-----+
                        |                   |
                        +                   +
             +---+    +---+     +---+     +---&=
#43;    +---+
   source+-->|sff|+-->|sff|+--->|sff|+--->|sff|=
+-->|sff|+-->destination
             +---+    +---+     +---+     +---&=
#43;    +---+
               +                  +                  +
               |                  |                  |
             +---+              +---+              +---=
+
             |sf1|              |sf3|              |sf5|
             +---+              +---+              +---=
+

                         Figure 5: Load Balancing



Halpern & Pignataro      Expires March 24, 2015                [Page 20=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   This would be represented as one service function path:
   sf1->sf2->sf3->sf4->sf5.  The SFF is a logical element, whic=
h may be
   made up of one or multiple components.  In this architecture, the SFF
   may handle load distribution based on policy.

   It can also be seen in the above that the same service function may
   be reachable through multiple SFFs, as discussed earlier.  The
   selection of which SFF to use to reach SF3 may be made by the control
   logic in defining the SFP, or may be left to the SFFs themselves,
   depending upon policy, solution, and deployment constraints.  In the
   latter case, it needs to be assured that exactly one SFF takes
   responsibility to steer traffic through SF3.


SB> Shouldn't the architecture lead with the general case and note
SB> that any function can be replaced with the null function.

 5.6.  MTU and Fragmentation Considerations

   This architecture prescribes additional information being added to
   packets to identify service function paths and often to represent
   metadata.  It also envisions adding transport information to carry
   packets along service function paths, at least between service
   function forwarders.  This added information increases the size of
   the packet to be carried by service chaining.  Such additions could
   potentially increase the packet size beyond the MTU supported on some
   or all of the media used in the service chaining domain.

   Such packet size increases can thus cause operational MTU problems.
   Requiring fragmentation and reassembly in an SFF would be a major
   processing increase, and might be impossible with some transports.

SB> Sure but the SFE is teh network layer of the SFC plane and could
SB> do this.

   Expecting service functions to deal with packets fragmented by the
   SFC function might be onerous even when such fragmentation was
   possible.  Thus, at the very least, solutions need to pay attention
   to the size cost of their approach.  There may be alternative or
   additional means available, although any solution needs to consider
   the tradeoffs.

   These considerations apply to any generic architecture that increases
   the header size.  There are also more specific MTU considerations:
   Effects on Path MTU Discovery (PMTUD) as well as deployment
   considerations.  Deployments within a single administrative control
   or even a single Data Center complex can afford more flexibility in
   dealing with larger packets, and deploying existing mitigations that
   decrease the likelihood of fragmentation or discard.

5.7.  SFC OAM

   Operations, Administration, and Maintenance (OAM) tools are an
   integral part of the architecture.  These serve various purposes,
   including fault detection and isolation, and performance management.
   For example, there are many advantages of SFP liveness detection,



Halpern & Pignataro      Expires March 24, 2015                [Page 21=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   including status reporting, support for resiliency operations and
   policies, and an enhanced ability to balance load.

   Service Function Paths create a services topology, and OAM performs
   various functions within this service layer.  Furthermore, SFC OAM
   follows the same architectural principles of SFC in general.  For
   example, topological independence (including the ability to run OAM
   over various overlay technologies) and classification-based policy.

   We can subdivide the SFC OAM architecture in two parts:

   o  In-band: OAM packets follow the same path and share fate with user
      packets, within the service topology.  For this, they also follow
      the architectural principle of consistent policy identifiers, and
      use the same path IDs as the service chain data packets.  Load
      balancing and SFC encapsulation with packet forwarding are
      particularly important here.

   o  Out-of-band: reporting beyond the actual data plane.  An
      additional layer beyond the data-plane OAM allows for additional
      alerting and measurements.

   This architecture prescribes end-to-end SFP OAM functions, which
   implies SFF understanding of whether an in-band packet is an OAM or
   user packet.  However, service function validation is outside of the
   scope of this architecture, and application-level OAM is not what
   this architecture prescribes.

   Some of the detailed functions performed by SFC OAM include fault
   detection and isolation in a Service Function Path or a Service
   Function, verification that connectivity using SFPs is both effective
   and directing packets to the intended service functions, service path
   tracing, diagnostic and fault isolation, alarm reporting, performance
   measurement, locking and testing of service functions, validation
   with the control plane (see Section 5.2), and also allow for vendor-
   specific as well as experimental functions.  SFC should leverage, and
   if needed extend relevant existing OAM mechanisms.

5.8.  Resilience and Redundancy

   As a practical operational requirement, any service chaining solution
   needs to be able to respond effectively, and usually very quickly, to
   failure conditions.  These may be failures of connectivity in the
   network between SFFs, failures of SFFs, or failures of SFs.  Per-SF
   state, as for example stateful-firewall state, is the responsibility
   of the SF, and not addressed by this architecture.





Halpern & Pignataro      Expires March 24, 2015                [Page 22=
]
=0C
Internet-Draft              SFC Architecture              September 2014


   Multiple techniques are available to address this issue.  Solutions
   can describe both what they require and what they allow to address
   failure.  Solutions can make use of flexible specificity of service
   function paths, if the SFF can be given enough information in a
   timely fashion to do this.  Solutions can also make use of MAC or IP
   level redundancy mechanisms such as VRRP.  Also, particularly for SF
   failures, load balancers co-located with the SFF or as part of the
   service function delivery mechanism can provide such robustness.

   Similarly, operational requirements imply resilience in the face of
   load changes.  While mechanisms for managing (e.g., monitoring,
   instantiating, loading images, providing configuration to service
   function chaining control, deleting, etc.) virtual machines are out
   of scope for this architecture, solutions can and are aided by
   describing how they can make use of scaling mechanisms.


SB> Given that we are introducing a new network layer construct includin=
g
SB> something that is or is a very close cousin to a network layer, sure=
ly
SB> we are missing an opportunity by not including this on day one.


 6.  Security Considerations

   This document does not define a new protocol and therefore creates no
   new security issues.

   Security considerations apply to the realization of this
   architecture.  Such realization ought to provide means to protect the
   SFC-enabled domain and its borders against various forms of attacks,
   including DDoS attacks.  Further, SFC OAM Functions need to not
   negatively affect the security considerations of an SFC-enabled
   domain.  Additionally, all entities (software or hardware)
   interacting with the service chaining mechanisms need to provide
   means of security against malformed, poorly configured (deliberate or
   not) protocol constructs and loops.  These considerations are largely
   the same as those in any network, particularly an overlay network.


SB> I just don't buy this for a security analysis. The Architecture need=
s
SB> direct the compenent designers to look at security issues associated
SB> with the new components and functionality being introduced.
SB> For example the SFE will have special considerations, so will the=20
SB> the path changes that you talk about earlier. Then there is resource
SB> conflicts and their impact as a security problem. Then there is the=
=20
SB> issue of privacy. Really each component of the ach needs to be looke=
d
SB> at from a security PoV and guidance provided to the component design=
er.

Text?

Thanks,

Carlos.
- Stewart
 


--=20
For corporate legal information go to:

http://www.cisco.com/web/about/doing_bu=
siness/legal/cri/index.html

--_000_D8D13D2266C742499AEE2E681BE1739Bciscocom_--