From paulq@cisco.com Fri Oct 4 09:41:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F57F21F9CC0 for ; Fri, 4 Oct 2013 09:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XpULj-ATi34 for ; Fri, 4 Oct 2013 09:41:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id DF25D21F9CB1 for ; Fri, 4 Oct 2013 09:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1293; q=dns/txt; s=iport; t=1380904902; x=1382114502; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=WJaWnY24oIc84doLtNwlIukklUPP0g5w1PfqEKqN1xo=; b=VdgfWXQGi+h/btEypqYdl5sXzdWS0it+sMwI7qfIhkTOQ5iLJCnwup5h 1qd91P4t5fat19YLwCOTAKP/qVJ2e3BAqfawvVpekffF3fA43Fu5gF0gl NUXDSyrsFfknRyvLuEcsiTreXTWv0ZBLP3ucb+AB5Lo2h4VWuKl7VJNAu U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAAXvTlKtJV2Y/2dsb2JhbABZgwc4UsFGgRoWbQeCJQEBAQMBOj0SAgEaEBQQMhcECgIEGwESh2UGDLwQjyCDV4EEA5kwkFCDJIIq X-IronPort-AV: E=Sophos;i="4.90,1034,1371081600"; d="scan'208";a="268170210" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 04 Oct 2013 16:41:41 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r94Gffv8018179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 4 Oct 2013 16:41:41 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 4 Oct 2013 11:41:41 -0500 From: "Paul Quinn (paulq)" To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-00.txt Thread-Index: AQHOwR5TTuL4bis2qUSXTr27UV3hHg== Date: Fri, 4 Oct 2013 16:41:40 +0000 Message-ID: References: <20131004162519.12797.78819.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.90.93] Content-Type: text/plain; charset="us-ascii" Content-ID: <2898EC25383F0040A6B7383C735847FB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [nsc] Fwd: New Version Notification for draft-quinn-sfc-arch-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 16:41:47 -0000 Hello, This document will replace draft-quinn-nsc-arch-00 with the new sfc name. = The document also reflects comments from reviewers and has an updated autho= r section. Thanks Paul >=20 > A new version of I-D, draft-quinn-sfc-arch-00.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Filename: draft-quinn-sfc-arch > Revision: 00 > Title: Service Function Chaining (SFC) Architecture > Creation date: 2013-10-04 > Group: Individual Submission > Number of pages: 20 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -00.txt > Status: http://datatracker.ietf.org/doc/draft-quinn-sfc-arch > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-00 >=20 >=20 > Abstract: > This document describes an architecture for the creation of Service > Function Chains. It includes architectural concepts, principles, and > components used for the application of services in a network. This > document does not propose solutions or protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From mohamed.boucadair@orange.com Tue Oct 8 02:27:27 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA4211E80F6 for ; Tue, 8 Oct 2013 02:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.838 X-Spam-Level: X-Spam-Status: No, score=-0.838 tagged_above=-999 required=5 tests=[AWL=1.410, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOIi5XRbbxmO for ; Tue, 8 Oct 2013 02:27:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id C318C11E8183 for ; Tue, 8 Oct 2013 02:27:11 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id A66503B4050; Tue, 8 Oct 2013 11:27:09 +0200 (CEST) Received: from PUEXCH11.nanterre.francetelecom.fr (unknown [10.101.44.27]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 8D3944C024; Tue, 8 Oct 2013 11:27:09 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.8]) by PUEXCH11.nanterre.francetelecom.fr ([10.101.44.27]) with mapi; Tue, 8 Oct 2013 11:27:09 +0200 From: To: "Joel M. Halpern" , "nsc@ietf.org" Date: Tue, 8 Oct 2013 11:27:08 +0200 Thread-Topic: On subscriber-ID (was RE: [nsc] New NSC WG Charter - charter bullet #3) Thread-Index: Ac7ECI5Vm1K29pTSQKCueADXNQO93A== Message-ID: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.8.27.82422 Subject: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 09:27:27 -0000 Hi Joel, all, We updated the section that discuss subscriber-id consideration in the sfc = analysis draft. The text is available at: https://tools.ietf.org/html/draft= -boucadair-sfc-design-analysis-00#section-4.1.=20 Comments and additions to that text are welcome. Cheers, Med >-----Message d'origine----- >De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Jo= el >M. Halpern >Envoy=E9=A0: mercredi 25 septembre 2013 09:24 >=C0=A0: Linda Dunbar >Cc=A0: nsc@ietf.org; adrian@olddog.co.uk >Objet=A0: Re: [nsc] New NSC WG Charter - charter bullet #3 > >For me, the canonical example of metadata applies to the use case of a >service chain providing residential gateway functionality with network >resident NAT. >If the operator is choosing, due to IPv4 exhaustion, to resuse IP >addresses across subscribers, then some field is needed to identify the >subscriber in the service chain. >In a classic BNG, the physical port, VLAN, or incoming MAC address >provides this function. But those will all be lost in the service chain. > >I have also seen cases where DPI service engines are separate entities >in the chain from services which need the results of the DPI. That >seems a natural candidate for metadata. > >Yours, >Joel > >On 9/24/13 7:02 PM, Linda Dunbar wrote: >> Adrian, >> >> Very good analysis. Thank you. >> >> "Metadata" has been used extensively in the NSC context. But beyond the >"service chain ID", I can't find any other necessary information required >to be exchanged among the "Service Functions" in all the use cases >presented at the Berlin informal BoF and use cases drafts. Can anyone give >some examples of the information required to be exchanged among those >"Service Functions" given by the draft-quinn-nsc-arch-00? >> >> A non-exhaustive list of Service Functions includes: firewalls, >> WAN and application acceleration, Deep Packet Inspection (DPI), >> server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID >> injection, HTTP Header Enrichment functions, TCP optimizer, etc. >> >> >> Thanks, Linda >> >>> -----Original Message----- >>> >>> I think "metadata" is a particularly poor term to use here because it >>> actually >>> directly means "additional data attached to something specific". So, it >>> is >>> metadata when you put it in the encapsulation header on a packet, but >>> if it is >>> out of band, it is what it is. >>> >>> So, let's look at what you might be talking about for "metadata": >>> - The details of the service chain itself (e.g. the service path) >>> - Information that one service node wants to communicate with >>> another service node (e.g. about how to perform given some >>> state information) >>> >>> We should also look at what you mean by out-of-band. I think here you >>> mean >>> "using some information exchange protocol." >> >> [Linda] Since each Service-Chain ID represents a list of service >functions, it is possible to use "out-of-band" control channel to pass the >information on the sequence of Service Functions associated with the ID. >> >> >>> >>> The charter says: >>> >>> | The Service Function Chaining (SFC) working group will develop >>> | new approaches to service delivery and deployment, by >>> | providing a framework for service function chaining and the >>> | necessary protocols or protocol extensions to convey the >>> | service path and for communication between nodes that >>> | implement service functions >>> >>> and: >>> >>> | 4) Control Plane Mechanisms: A set of documents will be >>> | developed to describe requirements and protocols necessary >>> | to convey information to service function implementation >>> | points. Where possible, existing IETF protocols will be used >>> | and extended. >>> >>> This feels like out-of-band exchange of information is expected. >>> >>> Adrian >>> >>> >>> >>> >>> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jmh@joelhalpern.com Tue Oct 8 09:06:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EE321E81F8 for ; Tue, 8 Oct 2013 09:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8HArL-1FKla for ; Tue, 8 Oct 2013 09:06:25 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67D21E8200 for ; Tue, 8 Oct 2013 09:04:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 21CD6446CE8; Tue, 8 Oct 2013 09:04:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (207.47.24.2.static.nextweb.net [207.47.24.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id D7D41446CE7; Tue, 8 Oct 2013 09:04:06 -0700 (PDT) Message-ID: <52542CFB.1020301@joelhalpern.com> Date: Tue, 08 Oct 2013 12:04:11 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: mohamed.boucadair@orange.com References: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "nsc@ietf.org" Subject: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 16:06:30 -0000 I find that text extremely biased and centered on particular problems. Having said that, I agree that we should not have a mandatory field for subscriber ID in the header. I never suggested that we have such a mandatory field. Rather, I was pointing out that one of the uses of metadata (and there are many) is to carry subscriber ID. I would not want the architecture or protocol to mandate exactly what metadata is carried in the header, since different situations will need different metadata. Yours, Joel On 10/8/13 5:27 AM, mohamed.boucadair@orange.com wrote: > Hi Joel, all, > > We updated the section that discuss subscriber-id consideration in the sfc analysis draft. The text is available at: https://tools.ietf.org/html/draft-boucadair-sfc-design-analysis-00#section-4.1. > > Comments and additions to that text are welcome. > > Cheers, > Med > >> -----Message d'origine----- >> De : nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de Joel >> M. Halpern >> Envoyé : mercredi 25 septembre 2013 09:24 >> À : Linda Dunbar >> Cc : nsc@ietf.org; adrian@olddog.co.uk >> Objet : Re: [nsc] New NSC WG Charter - charter bullet #3 >> >> For me, the canonical example of metadata applies to the use case of a >> service chain providing residential gateway functionality with network >> resident NAT. >> If the operator is choosing, due to IPv4 exhaustion, to resuse IP >> addresses across subscribers, then some field is needed to identify the >> subscriber in the service chain. >> In a classic BNG, the physical port, VLAN, or incoming MAC address >> provides this function. But those will all be lost in the service chain. >> >> I have also seen cases where DPI service engines are separate entities >> in the chain from services which need the results of the DPI. That >> seems a natural candidate for metadata. >> >> Yours, >> Joel >> >> On 9/24/13 7:02 PM, Linda Dunbar wrote: >>> Adrian, >>> >>> Very good analysis. Thank you. >>> >>> "Metadata" has been used extensively in the NSC context. But beyond the >> "service chain ID", I can't find any other necessary information required >> to be exchanged among the "Service Functions" in all the use cases >> presented at the Berlin informal BoF and use cases drafts. Can anyone give >> some examples of the information required to be exchanged among those >> "Service Functions" given by the draft-quinn-nsc-arch-00? >>> >>> A non-exhaustive list of Service Functions includes: firewalls, >>> WAN and application acceleration, Deep Packet Inspection (DPI), >>> server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID >>> injection, HTTP Header Enrichment functions, TCP optimizer, etc. >>> >>> >>> Thanks, Linda >>> >>>> -----Original Message----- >>>> >>>> I think "metadata" is a particularly poor term to use here because it >>>> actually >>>> directly means "additional data attached to something specific". So, it >>>> is >>>> metadata when you put it in the encapsulation header on a packet, but >>>> if it is >>>> out of band, it is what it is. >>>> >>>> So, let's look at what you might be talking about for "metadata": >>>> - The details of the service chain itself (e.g. the service path) >>>> - Information that one service node wants to communicate with >>>> another service node (e.g. about how to perform given some >>>> state information) >>>> >>>> We should also look at what you mean by out-of-band. I think here you >>>> mean >>>> "using some information exchange protocol." >>> >>> [Linda] Since each Service-Chain ID represents a list of service >> functions, it is possible to use "out-of-band" control channel to pass the >> information on the sequence of Service Functions associated with the ID. >>> >>> >>>> >>>> The charter says: >>>> >>>> | The Service Function Chaining (SFC) working group will develop >>>> | new approaches to service delivery and deployment, by >>>> | providing a framework for service function chaining and the >>>> | necessary protocols or protocol extensions to convey the >>>> | service path and for communication between nodes that >>>> | implement service functions >>>> >>>> and: >>>> >>>> | 4) Control Plane Mechanisms: A set of documents will be >>>> | developed to describe requirements and protocols necessary >>>> | to convey information to service function implementation >>>> | points. Where possible, existing IETF protocols will be used >>>> | and extended. >>>> >>>> This feels like out-of-band exchange of information is expected. >>>> >>>> Adrian >>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> nsc mailing list >>> nsc@ietf.org >>> https://www.ietf.org/mailman/listinfo/nsc >>> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From Chuong.D.Pham@team.telstra.com Tue Oct 8 16:49:04 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F0E11E8112 for ; Tue, 8 Oct 2013 16:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRpBF7qyCw64 for ; Tue, 8 Oct 2013 16:48:59 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 1314611E810E for ; Tue, 8 Oct 2013 16:48:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,1059,1371045600"; d="scan'208";a="162130098" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 09 Oct 2013 10:48:50 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7222"; a="116551019" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcani.tcif.telstra.com.au with ESMTP; 09 Oct 2013 10:48:50 +1100 Received: from WSMSG3154V.srv.dir.telstra.com ([172.49.40.163]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Wed, 9 Oct 2013 10:48:50 +1100 From: "Pham, Chuong D" To: "mohamed.boucadair@orange.com" , "Joel M. Halpern" , "nsc@ietf.org" Date: Wed, 9 Oct 2013 10:48:49 +1100 Thread-Topic: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) Thread-Index: Ac7EWKuUSazsDpqNRyKTi9M6v8z0WQAIiAPQ Message-ID: <5602569641FB314FB4D9AD5659D41B9C2556BB762E@WSMSG3154V.srv.dir.telstra.com> References: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EF503F393@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-AU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bullet #3) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Oct 2013 23:49:04 -0000 I am happy with the Subscriber-ID being an optional field. For the purpose of future proofing the document, I do not think the text fr= agments below are correct. 1) "Note, current deployments may require an explicit subscriber-ID only during the authentication and authorization phases. These deployments do not require explicit subscriber-ID information to be conveyed when sending actual data traffic. Can you please provide some examples where these authentication and authori= zation take place with sub-id and sub-id is not required during "sending ac= tual data traffic"? In our case (a Mobile Operator), the sub-id is required= per IP packet, if the use case needs it. Without it, because IP address is= allocated dynamically to a user device, the nodes upstream cannot decide w= hich user an IP packet belong to.=20 My point is not making sub-id mandatory is good, but not necessarily becaus= e of the reason included in the text fragment above. The reason that not al= l use cases require sub-id is sufficient. =20 2) "A typical example where complications may arise is a deployment context ch= aracterized as follows: o Overlapping IP address pools are in use. o NAT function is not collocated with the GGSN or BNG." To me, those two points are separate issues altogether and not the main rea= son to make sub-id an optional field. If an Operator uses user's IP address as subscriber-id (as an optional fiel= d specified in this draft) then decided to put the traffic through a NAT, i= t is the responsibility of the Operator to provide a translation function t= o reflect the change of user's IP address i.e. an ALG function in the NAT. = However in our case (typical for Mobile Operator), MSISDN or IMSI is used a= s sub-id hence the user's IP address is not used to identify the user.=20 Regards, Chuong -----Original Message----- From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]=20 Sent: Tuesday, 8 October 2013 8:27 PM To: Joel M. Halpern; nsc@ietf.org Subject: [nsc] On subscriber-ID (was RE: New NSC WG Charter - charter bulle= t #3) Hi Joel, all, We updated the section that discuss subscriber-id consideration in the sfc = analysis draft. The text is available at: https://tools.ietf.org/html/draft= -boucadair-sfc-design-analysis-00#section-4.1.=20 Comments and additions to that text are welcome. Cheers, Med >-----Message d'origine----- >De=A0: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] De la part de=20 >Joel M. Halpern Envoy=E9=A0: mercredi 25 septembre 2013 09:24 =C0=A0: Lind= a=20 >Dunbar Cc=A0: nsc@ietf.org; adrian@olddog.co.uk Objet=A0: Re: [nsc] New NS= C=20 >WG Charter - charter bullet #3 > >For me, the canonical example of metadata applies to the use case of a=20 >service chain providing residential gateway functionality with network=20 >resident NAT. >If the operator is choosing, due to IPv4 exhaustion, to resuse IP=20 >addresses across subscribers, then some field is needed to identify the=20 >subscriber in the service chain. >In a classic BNG, the physical port, VLAN, or incoming MAC address=20 >provides this function. But those will all be lost in the service chain. > >I have also seen cases where DPI service engines are separate entities=20 >in the chain from services which need the results of the DPI. That=20 >seems a natural candidate for metadata. > >Yours, >Joel > >On 9/24/13 7:02 PM, Linda Dunbar wrote: >> Adrian, >> >> Very good analysis. Thank you. >> >> "Metadata" has been used extensively in the NSC context. But beyond=20 >> the >"service chain ID", I can't find any other necessary information=20 >required to be exchanged among the "Service Functions" in all the use=20 >cases presented at the Berlin informal BoF and use cases drafts. Can=20 >anyone give some examples of the information required to be exchanged=20 >among those "Service Functions" given by the draft-quinn-nsc-arch-00? >> >> A non-exhaustive list of Service Functions includes: firewalls, WAN=20 >> and application acceleration, Deep Packet Inspection (DPI), server=20 >> load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID injection,=20 >> HTTP Header Enrichment functions, TCP optimizer, etc. >> >> >> Thanks, Linda >> >>> -----Original Message----- >>> >>> I think "metadata" is a particularly poor term to use here because=20 >>> it actually directly means "additional data attached to something=20 >>> specific". So, it is metadata when you put it in the encapsulation=20 >>> header on a packet, but if it is out of band, it is what it is. >>> >>> So, let's look at what you might be talking about for "metadata": >>> - The details of the service chain itself (e.g. the service path) >>> - Information that one service node wants to communicate with >>> another service node (e.g. about how to perform given some >>> state information) >>> >>> We should also look at what you mean by out-of-band. I think here=20 >>> you mean "using some information exchange protocol." >> >> [Linda] Since each Service-Chain ID represents a list of service >functions, it is possible to use "out-of-band" control channel to pass=20 >the information on the sequence of Service Functions associated with the I= D. >> >> >>> >>> The charter says: >>> >>> | The Service Function Chaining (SFC) working group will develop new=20 >>> | approaches to service delivery and deployment, by providing a=20 >>> | framework for service function chaining and the necessary=20 >>> | protocols or protocol extensions to convey the service path and=20 >>> | for communication between nodes that implement service functions >>> >>> and: >>> >>> | 4) Control Plane Mechanisms: A set of documents will be developed=20 >>> | to describe requirements and protocols necessary to convey=20 >>> | information to service function implementation points. Where=20 >>> | possible, existing IETF protocols will be used and extended. >>> >>> This feels like out-of-band exchange of information is expected. >>> >>> Adrian >>> >>> >>> >>> >>> >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Oct 9 07:30:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08721F9C7A for ; Wed, 9 Oct 2013 07:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoSrbp+dYn1e for ; Wed, 9 Oct 2013 07:30:25 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C61CB21F9ADD for ; Wed, 9 Oct 2013 07:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9584; q=dns/txt; s=iport; t=1381328996; x=1382538596; h=from:to:subject:date:message-id:mime-version; bh=lCtzq6mKbIn7NMvNPTTn5/sgxf5RQDLu9X316sd3T5E=; b=OVa8YkwaMgrPD3rPgtr46nXPubGMV/hY0eZSb+mtqrBIsuldDye9F29/ iVjjKgC9S0MXuyN3Wsf1F/3yd4SuvT+TkuxRPqfRRZkUemvzayxpGxiYK tpiyxhL53eS1dwQiwT9T+fvPH11h8EyMknaCv77+lVBdgKMOh3m2dZai2 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8FAAFoVVKtJXHB/2dsb2JhbABagkNEOFKvD4liiEaBHRZtB4InAQSBCwEaEFYXEAQbh34Ml1ehSY8Ug1eBBAOZMpBSgySCKg X-IronPort-AV: E=Sophos;i="4.90,1064,1371081600"; d="scan'208,217";a="270076526" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 14:29:50 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r99ETosk006224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 9 Oct 2013 14:29:50 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 09:29:49 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: Preliminary SFC BoF agenda for IETF88 in Vancouver. Thread-Index: AQHOxPwCTtaobfXvXUmoBYc2VU4+uw== Date: Wed, 9 Oct 2013 14:29:48 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6DADAC@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F6DADACxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 14:30:33 -0000 --_000_68B171751455884590F8E38E96416F363F6DADACxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, The following is a preliminary agenda for review/comment. Please note that = we have 2 hours total for the SFC BoF and the times provided are subject to= change. The BoF itself will be split into two sections: 1) the core BoF, = where we will discuss the problem statement, use cases, architecture/framew= ork, and charter, as well as answer the more general question as to whether= a WG is to be formed, followed by: 2) discussion of related drafts and how= to organize the work going forward, assuming a WG gets formed. Please let = Thomas or I know if you would like a slot to present a particular draft. 0.00 Introduction (BoF-chairs) - [10 minutes] 00.10 Problem statement discussion (BoF-chairs + presenter) - [20 minutes] * Problem statement review (Navindra Yadav, Insieme Networks) - [10 min= utes] * http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement * Problem statement Q&A (open-mic) - [10 minutes] 00.30 SFC use case discussion (presenter + open-mic) - [20 minutes] * SFC use cases (Hongyu Li, Huawei) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cas= es * Use case Q&A (BoF-chairs) - [10 minutes] 00.50 SFC architecture & framework discussion - [20 minutes] * Architecture & framework review (Ron Parker, Affirmed Networks & Pau= l Quinn, Cisco) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch * Architecture & framework Q&A (open-mic) - [10 minutes] 01.10 Charter text discussion (BoF-chairs) - [25 minutes] * Charter text review (BoF-chairs) - [10 minutes] * http://datatracker.ietf.org/wg/sfc/charter/ * Charter Q&A (open-mic) - [15 minutes] For the remainder of the time, we will assume the previous discussion (i.e= ., the main BoF) went reasonably well and we are looking forward to what w= e would need to do if we were a chartered WG. 01.35 Evaluation of required & existing ID's (BoF-chairs + presenters) - [2= 0 minutes] 01.55 Closing (BoF-chairs) - [5 minutes] * Actions & Next Steps Thanks, Jim & Thomas. --_000_68B171751455884590F8E38E96416F363F6DADACxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <94A8957B78E93D4ABB1EA1DBF1FFC37B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

The following= is a preliminary agenda for review/comment. Please note that we have 2 hours total for the SFC BoF and the times provide= d are subject to change. The BoF itself will be split into two  sections: 1) the core BoF, where we will discuss t= he problem statement, use cases, architecture/framework, and charter, as we= ll as answer the more general question as to whether a WG is to be formed, = followed by: 2) discussion of related drafts and how to organize the work going forward, assuming a = WG gets formed. Please let Thomas or I know if you would like a slot to pre= sent a particular draft. 

0.00 Introduction (BoF= -chairs) - [10 minutes]
00.10<= span class=3D"b"> Problem statement discussion (BoF-chairs + presenter) - [20 minutes]
  • Problem statement review (Navindra Yadav, Insieme Networks) - [10 minutes]
  • Problem statement Q&A (open-mic) - [10 minutes]
00.30 SFC use case discussion (presenter + open-mic) - [20 minutes]
  • SFC use cases (Ho= ngyu Li, Huawei) - [10 minutes]
  • Use case Q&A = (BoF-chairs) - [10 minutes]
00.50 SFC architecture & framework discussion - [20 minutes]
  • Architecture  & framework review (Ron Parker, Affirmed Networks & Paul Quinn, C= isco) - [10 minutes]
  • Architecture & framework Q&A (open-mic) - [10 minutes]
01.10 Charter text discussion (BoF-chairs) - [25 minutes]
  • Charter text review (BoF-chairs) - [10 minutes]
  • Charter Q&A (= open-mic) - [15 minutes]
For the  remainder of the= time, we will assume the previous discussion (i.e., the  main BoF) we= nt reasonably well and we are looking forward to what we would need to do i= f we were a chartered WG.
 =
01.35<= span class=3D"b"> Evaluation of required & existing ID's (BoF-chairs + presenters) - [20 minutes]

01.55<= span class=3D"b"> Closing (BoF-cha= irs) - [5 minutes]
  • Actions & Next Steps
Thanks, Jim & Thomas.
--_000_68B171751455884590F8E38E96416F363F6DADACxmbrcdx01ciscoc_-- From liushucheng@huawei.com Thu Oct 10 23:14:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F275321E80DA for ; Thu, 10 Oct 2013 23:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZbYuh7b9GkO for ; Thu, 10 Oct 2013 23:14:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CABAC21E81A6 for ; Thu, 10 Oct 2013 23:14:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AYY90478; Fri, 11 Oct 2013 06:14:13 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 07:13:30 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Fri, 11 Oct 2013 07:14:07 +0100 Received: from szxeml559-mbx.china.huawei.com ([169.254.1.2]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Fri, 11 Oct 2013 14:13:59 +0800 From: "Liushucheng (Will)" To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOxYw1adpuHwAz9kCbO6dbFJuIcZntjaGA Date: Fri, 11 Oct 2013 06:13:59 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 06:14:23 -0000 Rm9sa3MsDQoNCldlJ3ZlIHVwbG9hZGVkIHRoZSB1cGRhdGVkIGFuZCByZW5hbWVkIHVzZSBjYXNl IGRyYWZ0LiBMb29raW5nIGZvcndhcmQgdG8geW91ciBjb21tZW50cy4NCg0KUmVnYXJkcywNClNo dWNoZW5nIExJVSAoV2lsbCkNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn XSANClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDEwLCAyMDEzIDM6NDIgUE0NClRvOiBMaXVzaHVj aGVuZyAoV2lsbCk7IEppZSBIdTsgSG9uZ3l1IExpIChKdWxpbyk7IEh1YW5neW9uZyAoT2xpdmVy KTsgTW9oYW1lZCBCb3VjYWRhaXI7IExpdXNodWNoZW5nIChXaWxsKTsgTmljb2xhaSBMZXltYW5u OyBaaGVuIENhbw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1s aXUtc2ZjLXVzZS1jYXNlcy0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt bGl1LXNmYy11c2UtY2FzZXMtMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFdpbGwoU2h1Y2hlbmcpIExpdSBhbmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5 Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxpdS1zZmMtdXNlLWNhc2VzDQpSZXZpc2lvbjoJIDAwDQpU aXRsZToJCSBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIFVzZSBDYXNlcw0KQ3JlYXRpb24gZGF0 ZToJIDIwMTMtMTAtMTANCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9m IHBhZ2VzOiAxNA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcy0wMC50eHQNClN0YXR1czogICAgICAgICAg aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saXUtc2ZjLXVzZS1jYXNlcw0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtc2Zj LXVzZS1jYXNlcy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIGRlbGl2ZXJ5IG9mIHZhbHVlLWFk ZGVkIHNlcnZpY2VzIHJlbGllcyBvbiB0aGUgaW52b2NhdGlvbiBvZg0KICAgYWR2YW5jZWQgU2Vy dmljZSBGdW5jdGlvbnMgaW4gYSBzZXF1ZW50aWFsIG9yZGVyLiAgVGhpcyBtZWNoYW5pc20gaXMN CiAgIGNhbGxlZCBTZXJ2aWNlIEZ1bmN0aW9uIENoYWluaW5nIChTRkMpLiAgVGhlIHNldCBvZiBp bnZvbHZlZCBTZXJ2aWNlDQogICBGdW5jdGlvbnMgYW5kIHRoZWlyIG9yZGVyIGRlcGVuZHMgb24g dGhlIHNlcnZpY2UgY29udGV4dC4NCg0KICAgVGhpcyBkb2N1bWVudCBwcmVzZW50cyBhIHNldCBv ZiB1c2UgY2FzZXMgb2YgU2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5pbmcgKFNGQykuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From Ron_Parker@affirmednetworks.com Fri Oct 11 05:55:27 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8AC11E8163 for ; Fri, 11 Oct 2013 05:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhXKeF2Yz7ft for ; Fri, 11 Oct 2013 05:55:21 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id 57F4511E8150 for ; Fri, 11 Oct 2013 05:55:16 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0123.003; Fri, 11 Oct 2013 05:55:10 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Thread-Index: AQHOxPwCTtaobfXvXUmoBYc2VU4+u5nvd5IA Date: Fri, 11 Oct 2013 12:55:09 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6DADAC@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6DADAC@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71049CMBX021W3CA2exch_" MIME-Version: 1.0 Subject: Re: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2013 12:55:27 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71049CMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Thanks for preparing the agenda. If time permits, I would request a slot = to present http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements= /. If agreed to, I might suggest to slot it after the use cases and befo= re the framework, as the requirements arise from the use cases and the fram= ework, hopefully, addresses the requirements. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, October 09, 2013 10:30 AM To: nsc@ietf.org Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Greetings, The following is a preliminary agenda for review/comment. Please note that = we have 2 hours total for the SFC BoF and the times provided are subject to= change. The BoF itself will be split into two sections: 1) the core BoF, = where we will discuss the problem statement, use cases, architecture/framew= ork, and charter, as well as answer the more general question as to whether= a WG is to be formed, followed by: 2) discussion of related drafts and how= to organize the work going forward, assuming a WG gets formed. Please let = Thomas or I know if you would like a slot to present a particular draft. 0.00 Introduction (BoF-chairs) - [10 minutes] 00.10 Problem statement discussion (BoF-chairs + presenter) - [20 minutes] * Problem statement review (Navindra Yadav, Insieme Networks) - [10 min= utes] * http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement * Problem statement Q&A (open-mic) - [10 minutes] 00.30 SFC use case discussion (presenter + open-mic) - [20 minutes] * SFC use cases (Hongyu Li, Huawei) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cas= es * Use case Q&A (BoF-chairs) - [10 minutes] 00.50 SFC architecture & framework discussion - [20 minutes] * Architecture & framework review (Ron Parker, Affirmed Networks & Pau= l Quinn, Cisco) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch * Architecture & framework Q&A (open-mic) - [10 minutes] 01.10 Charter text discussion (BoF-chairs) - [25 minutes] * Charter text review (BoF-chairs) - [10 minutes] * http://datatracker.ietf.org/wg/sfc/charter/ * Charter Q&A (open-mic) - [15 minutes] For the remainder of the time, we will assume the previous discussion (i.e= ., the main BoF) went reasonably well and we are looking forward to what w= e would need to do if we were a chartered WG. 01.35 Evaluation of required & existing ID's (BoF-chairs + presenters) - [2= 0 minutes] 01.55 Closing (BoF-chairs) - [5 minutes] * Actions & Next Steps Thanks, Jim & Thomas. --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71049CMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 <= /p>

Thanks for preparing the = agenda.   If time permits, I would request a slot to present http://datatracker.ietf.org/doc/draft-bo= ucadair-sfc-requirements/.    If agreed to, I might suggest to slot it after the use cases and before the framework, as the re= quirements arise from the use cases and the framework, hopefully, addresses= the requirements.

 

   Ron=

 

 <= /p>

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 09, 2013 10:30 AM
To: nsc@ietf.org
Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver.

 

Greetings,

 

The following is a prelimin= ary agenda for review/comment. Please note that we have 2 hours total = for the SFC BoF and the times provided are subject to change. The BoF itself will be split into two  sections: 1) the core BoF, whe= re we will discuss the problem statement, use cases, architecture/framework= , and charter, as well as answer the more general question as to whether a = WG is to be formed, followed by: 2) discussion of related drafts and how to organize the work going forward, assuming a&n= bsp;WG gets formed. Please let Thomas or I know if you would like a slot to= present a particular draft. 

 

0.00 Introduction (BoF-chairs) - [10 minutes]

00.10&= nbsp;Problem statement discussion (BoF-chairs + present= er) - [20 minutes]

  • Problem statement review (Navindra Yadav, Insieme Networks) - [10 minutes]<= /o:p>
  • Problem statement Q&A (open-mic) - [10 minutes]

00.30 SFC use case discussion (presenter + open-mic) - [= 20 minutes]

  • SFC use cases (Hongyu Li, Huawei) - [10 minutes]
  • Use case Q&A (BoF-chairs) - [10 minutes]

00.50 SFC architecture & framework discussion - [20 minu= tes]

  • Architecture  & framework review=  (Ron Parker, Affirmed Networks & P= aul Quinn, Cisco) - [10 minutes]
  • Architecture & framework Q&A (open-mic) - [10 minutes]=

01.10 Charter text discussion (BoF-chairs) - [25 minutes]

  • Charter text review (BoF-chairs) - [10 minutes]
  • Charter Q&A (open-mic) - [15 minutes]

For the  remainder of = the time, we will assume the previous discussion (i.e., the  main BoF)= went reasonably well and we are looking forward to what we would need to do if we were a chartered WG.

 

01.35&= nbsp;Evaluation of required & existing ID's (BoF-chairs= + presenters) - [20 minutes]

 

01.55&= nbsp;Closing (BoF-chairs) - [5 minutes]

  • Actions & Next Steps

Thanks, Jim & Thomas.

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71049CMBX021W3CA2exch_-- From diego@tid.es Mon Oct 14 15:09:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68C6121E8136 for ; Mon, 14 Oct 2013 15:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGXbO7txunuQ for ; Mon, 14 Oct 2013 15:09:35 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id DE77B21F93BF for ; Mon, 14 Oct 2013 15:09:32 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MUO00F7QIVVH8@tid.hi.inet> for nsc@ietf.org; Tue, 15 Oct 2013 00:09:31 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 03.16.28420.B9B6C525; Tue, 15 Oct 2013 00:09:31 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MUO00F7HIVVH8@tid.hi.inet> for nsc@ietf.org; Tue, 15 Oct 2013 00:09:31 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 00:09:30 +0200 Date: Mon, 14 Oct 2013 22:09:29 +0000 From: "Diego R. Lopez" In-reply-to: <94C682931C08B048B7A8645303FDC9F36EE6E834EC@PUEXCB1B.nanterre.francetelecom.fr> X-Originating-IP: [10.95.64.115] To: " " Message-id: <90016176-405D-4687-A232-FE5B92A46A82@tid.es> Content-id: <0A90983A20FA0849A7C1BB0AE5AA3290@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: inter-domain case (was RE: [nsc] Service chaining architecture question) Thread-index: Ac6MNppeZnTEQQ6wR1W9crOC8t9qJA8tJGMA X-AuditID: 0a5f4e69-b7fe58e000006f04-b9-525c6b9b7f99 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42Lhivcz1J2dHRNkcGKirMXxffvZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVceFYZMEXnYoPt58zNjA+0O5i5OSQEDCReHWnhQ3CFpO4cG89 kM3FISSwnVHi65kzjBDOd0aJGcu7WCGcmYwS/ctnM4O0sAioSqxeOZERxGYDsh81/2YHsYUF wiXOPL4PNpZTIE5i5ofjUCsUJP6ce8zSxcjBISKQKrFtnTVImFngLpPE8Q+6IDavgKXE3y1n WEFKmAXMJL7+VYEIC0r8mHyPBSKsLjFlSi5Ep7hEc+tNFghbUWLaogawYxgFZCXezZ/PCmKL CERIrPu+Hso2kpg2aT8jxDECEkv2nGeGsEUlXj7+B1YjJBArcefaDtYJjBKzEI6YheSIWQhH zEJyxCwkRyxgZF3FKFacVJSZnlGSm5iZk25gpJeRqZeZl1qyiRESbZk7GJfvVDnEKMDBqMTD +5M3JkiINbGsuDL3EKMEB7OSCG/u2+ggId6UxMqq1KL8+KLSnNTiQ4xMHJxSDYyCfaESi7Xt Odcc0174cFbhda+nl5aYvr4X8rZoctZ6i78vXt3N2Ljt5g3xz7/bXr9+UejeukrGy+mWkFmC Qm/67vyWnZeFP+lNmeO29oR/9zrGj1bO14vZowUWPjeaO7Nr/lL+L0lfv/JcVHl16JKQzqrp VW+PKshu31xmzPT7xw03y9WLPZdoK7EUZyQaajEXFScCAOOTVgCUAgAA References: <94C682931C08B048B7A8645303FDC9F36EE6E834EC@PUEXCB1B.nanterre.francetelecom.fr> Cc: "nsc@ietf.org" , "Carlos Pignataro \(cpignata\)" , "Jim Guichard \(jguichar\)" , "NAPIERALA, MARIA H" , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , "Joel M. Halpern" Subject: Re: [nsc] inter-domain case (was RE: Service chaining architecture question) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:09:40 -0000 SGksDQoNCkkga25vdyB0aGlzIHJlcGx5IGNvbWVzIHZlcnkgdmVyeSBsYXRlLiBJIGxlZnQgdGhp cyBtZXNzYWdlIChhbmQgZXZlcnl0aGluZyBhcm91bmQgU0ZDKSB0byBkZWFsIHdpdGggaXQgYWZ0 ZXIgbXkgaG9saWRheXMgaW4gQXVndXN0LCBhbmQgSSBhbSBhZnJhaWQgSSBmb3VuZCBhbiBlbm9y bW91cyBwaWxlIG9mIHVyZ2VudCBtYXR0ZXJzIHRvIGRlYWwgd2l0aC4gSSB0aG91Z2h0IHRoZSB3 aG9sZSBpbnRlci1kb21haW4gaXNzdWUgb3V0ZGF0ZWQsIGJ1dCB0aGUgcmVjZW50IG1lc3NhZ2Ug ZnJvbSBDaHJpc3RpYW4gaGFzIGJyb3VnaHQgaXQgYmFjayB0byBteSBtaW5kLiBBbmQgSSB0aGlu ayBJIGhhdmUgdG8gbWFrZSBteSBjYXNlIGZvciBpbnRlci1kb21haW4gY2hhaW5pbmcuIFNvbWUg cmVwbGllcyBpbmxpbmVkIGJlbG93Li4uDQoNCk9uIDI5IEp1bCAyMDEzLCBhdCAxMDozNSAsIDxt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPiB3cm90ZToNCg0KPiBIaSBEaWVnbywNCj4NCj4g VGhhbmsgeW91IGZvciB0aGUgYW5zd2VyLiBJIHN0aWxsIGRvbid0IHVuZGVyc3RhbmQgd2VsbCB0 aGUgaW50ZXItZG9tYWluIHVzZSBjYXNlIHlvdSBhcmUgcmVmZXJyaW5nIHRvIGFuZCB3aHkgdGhp cyBpcyBhIHJlcXVpcmVtZW50cy4gSW4gb3JkZXIgdG8gdW5kZXJzdGFuZCBiZXR0ZXIgdGhlIGNh c2UgYW5kIHRvIG1ha2Ugc3VyZSB0aGVyZSBpcyBubyB0ZXJtaW5vbG9neSBjb25mdXNpb24sIGJl bG93IHNvbWUgcXVlc3Rpb25zIGZvciB5b3U6DQo+DQo+ICogRG8geW91IGhhdmUgdHdvIGFkbWlu aXN0cmF0aXZlIGVudGl0aWVzIGludm9sdmVkIGluIHlvdXIgY2FzZT8NCg0KRFJMPiBZZXMuIFdp dGhvdXQgbGVhdmluZyBvdXIgY29ycG9yYXRlIGdyb3VwLCB2ZXJ5IG9mdGVuIHdoYXQgeW91IGhh dmUgYXJlIHNldmVyYWwgY29tcGFuaWVzICh3aXRoIGRpZmZlcmVudCBtYW5hZ2VtZW50IG9ibGln YXRpb25zIGFuZCBhZG1pbmlzdHJhdGl2ZWx5IGluZGVwZW5kZW50KSBjb29wZXJhdGluZyB0byBw cm92aWRlIGEgY2VydGFpbiBFMkUgc2VydmljZS4gVG9kYXkgdGhpcyBpcyBhY2hpZXZlZCBieSBk aXJlY3QgaHVtYW4gY29vcmRpbmF0aW9uIGFuZCBjb21wbGV0ZSBmdW5jdGlvbmFsIChhbmQgZXZl biBwaHlzaWNhbCkgc2VwYXJhdGlvbi4gSWYgeW91IGNhbiBkeW5hbWljYWxseSBjaGFpbiBzZXJ2 aWNlcyB0aGlzIHdvdWxkIHRyYW5zbGF0ZSBpbnRvIG11Y2ggYWdpbGUgYW5kIGVsYXN0aWMgcHJv dmlzaW9uIGFuZCBvcGVyYXRpb24uIEFuZCBJIGRvbid0IHNlZSB3aHkgdGhpcyB3b3VsZCBub3Qg aW52b2x2ZSBpbiB0aGUgbmVhciBmdXR1cmUgY29tcGxldGVseSBpbmRlcGVuZGVudCBjb21wYW5p ZXMgcHJvdmlkaW5nIGNvb3JkaW5hdGVkIHNlcnZpY2VzIGJ5IG1lYW5zIG9mIGNvbGxhYm9yYXRp b24gYWdyZWVtZW50cy4NCg0KPiAqIEFyZSBib3RoIGRvbWFpbnMgbWFuYWdlZCBieSBvbmUgc2lu Z2xlIGFkbWluaXN0cmF0aXZlIGVudGl0eT8NCg0KRFJMPiBBcyBJIHNhaWQsIGV2ZW4gaW4gdGhl IGNhc2VzIHRoYXQgSSBzZWUgaW4gb3VyIGdyb3VwJ3MgZW52aXJvbm1lbnQsIHRoYXQncyBub3Qg dGhlIGNhc2UuIFRvIGdpdmUgeW91IGFuIGV4YW1wbGUsIHdlIGhhdmUgc2VwYXJhdGUgY29tcGFu aWVzIGZvciB0aGUgYmFzaWMgbmV0d29yayBzZXJ2aWNlcyAoYW5kIHRoZXJlZm9yZSBuZXR3b3Jr IGZpcmV3YWxsaW5nKSBhbmQgY29udGVudCBkaXN0cmlidXRpb24gcGxhdGZvcm1zIChhbmQgdGhl cmVmb3JlIGNvbnRlbnQgY2FjaGluZyBhbmQgdGhlIGxpa2UpDQoNCj4gKiBXaG8gZGVjaWRlIG9u IHRoZSBpbnRlci1kb21haW4gZnVuY3Rpb24gY2hhaW5zPw0KDQpEUkw+IFRoYXQgd291bGQgYmUg cGFydCBvZiB0aGUgY29sbGFib3JhdGlvbiBhZ3JlZW1lbnQ6IHlvdSBjYW4gZ28gZnJvbSBhIHZl cnkgbG9vc2UgYXJyYW5nZW1lbnQgKGluIHdoaWNoIHlvdSBleHBvc2Ugb25seSB5b3VyIGluZ3Jl c3MgYW5kIGVncmVzcyBzZXJ2aWNlIHBvaW50cykgdG8gYSB0aWdodCBpbnRlZ3JhdGlvbiwgd2l0 aCBhIGNvb3JkaW5hdGVkIGVsZW1lbnQgdGFraW5nIGNhcmUgb2YgZXZlcnl0aGluZywgd2hlcmUg dGhlIGNvb3JkaW5hdGlvbiBjYW4gYmUgbWFkZSBieSBhIHRydXN0ZWQgdGhpcmQgcGFydHkgKGEg ZmVkZXJhdGlvbiBvcGVyYXRvciksIGJ5IG9uZSBvZiB0aGUgcGFydGllcyAoYSBzdWJvcmRpbmF0 ZWQgcmVsYXRpb25zaGlwKSBvciBieSBtZWFucyBvZiBwYXJ0aWN1bGFyIFNMQXMgKGEgU0ZhYVMs IHdlIGNvdWxkIHNheSkNCg0KPiAqIFdobyBpcyByZXNwb25zaWJsZSBmb3IgZW5zdXJpbmcgdGhl IG92ZXJhbGwgY29uc2lzdGVuY3k/DQoNCkRSTD4gQWdhaW4sIHRoYXQgd291bGQgYmUgcGFydCBv ZiB0aGUgY29sbGFib3JhdGlvbiBhZ3JlZW1lbnQsIGFuZCB5b3UnbGwgaGF2ZSBzaW1pbGFyIG9w dGlvbnMuDQoNCj4gKiBXaHkgdGhlIGNoYWluaW5nIHBvbGljaWVzIGFyZSB0byBiZSBleHBvc2Vk IHRvIGFuIGV4dGVybmFsIGRvbWFpbj8gV2h5IGVhY2ggZG9tYWluIG5lZWQgdG8gcmV2ZWFsIGl0 cyBpbnRyYSBwb2xpY2llcyB3aXRoIHJlZ2FyZHMgdG8gdGhlIHdheSBhIG5ldHdvcmsgaXMgZW5n aW5lZXJlZD8NCg0KRFJMPiBZb3UgZG9uJ3QgbmVlZCB0byBleHBvc2UgKmFsbCogeW91ciBwb2xp Y2llcyAoYXMgeW91IGRvbid0IGV4cG9zZSAqYWxsKiB5b3VyIHRvcG9sb2d5KSBidXQganVzdCB0 aGUgcmVsZXZhbnQgaW5mb3JtYXRpb24gZm9yIHRoZSBjb2xsYWJvcmF0aW9uIHRvIHRha2UgcGxh Y2UuIEFnYWluIGRpZmZlcmVudCBtb2RlbHMsIGZyb20gcHVyZSBQMlAgZXhjaGFuZ2UgdG8gYSBj ZW50cmFsaXplZCBjbGVhcmluZ2hvdXNlLCBjYW4gYmUgYXBwbGllZC4NCg0KPiAqIFdoeSBub3Qg ZWFjaCBvZiB0aGUgZG9tYWluIGVuZm9yY2VzIGl0cyBwb2xpY2llcyB3aXRob3V0IHJlcXVpcmlu ZyBhbnkgaW52b2x2ZW1lbnQgb2YgZnVuY3Rpb25zIGxvY2F0ZWQgaW4gYW5vdGhlciBleHRlcm5h bCBkb21haW4/DQoNCkRSTD4gQmVjYXVzZSBoYXZpbmcgc29tZSBrbm93bGVkZ2Ugb2Ygd2hhdCBh bmQgaG93IGNhbiBiZSBhcHBsaWVkIGJ5IHRoZSBvdGhlciBkb21haW4gY2FuIGhlbHAgYm90aCBk b21haW5zIGluIHByb3ZpZGluZyBhIGJldHRlciBzZXJ2aWNlIHRvIHRoZWlyIGVuZCB1c2Vycywg b3B0aW1pemUgdGhlaXIgaW5mcmFzdHJ1Y3R1cmUsIGFuZCBhZGRyZXNzIGFkZGl0aW9uYWwgYnVz aW5lc3MgbW9kZWxzLg0KDQo+ICogV2h5IGNoYWluaW5nIHdpbGwgbW9kaWZ5IHRoZSB3YXkgbmV0 d29ya3MgbWFuYWdlZCBieSB0d28gZGlzdGluY3QgYWRtaW5pc3RyYXRpdmUgZW50aXRpZXMgd2ls bCBiZSBpbnRlcmNvbm5lY3RlZD8NCg0KRFJMPkkgZG9uJ3QgdGhpbmsgdGhpcyB3b3VsZCBjaGFu Z2UgdGhlIHdheXMgdGhleSBpbnRlcmNvbm5lY3QsIGJ1dCB0aGUgd2F5IHRoZXkgYnVpbGQgc2Vy dmljZXMsIGFubm91bmNlIHRoZW0sIGFjY291bnQgZm9yIHRoZW0sIGFuZCBhcHBseSBjb250cm9s IG9uIHNlcnZpY2UgZnVuY3Rpb24gY2hhaW5pbmcuDQoNCkJlIGdvb2RlLA0KDQotLQ0KIkVzdGEg dmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoN ClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1t YWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2 ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1lbnNhamUgc2UgZGly aWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBjb25zdWx0YXIgbnVl c3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3JyZW8gZWxlY3Ryw7Nu aWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1lc3NhZ2UgaXMgaW50 ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkgc2VuZCBhbmQgcmVj ZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQgYXQ6DQpodHRwOi8v d3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From jguichar@cisco.com Mon Oct 14 15:31:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390B121E81B8 for ; Mon, 14 Oct 2013 15:31:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYcsHndGFMol for ; Mon, 14 Oct 2013 15:31:15 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8999021E8136 for ; Mon, 14 Oct 2013 15:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4856; q=dns/txt; s=iport; t=1381789858; x=1382999458; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sNG28FgVDfzkHBcF52c0iPnv4rpHNhbDlZmCHIFdxRE=; b=b2d40JS/aRm74yJgRAnXVbyqp65r0oh57IS1MazyuRfuUkq9CohAcI1g /koMcHrL5KFUBL+uL2m4ZWzYVoJjdD1yp6h9I2NO66UdUqVtgT0d34qxu Yc38qM4oLa+c8q4tAD72VKD7RJkXgl9kWs/Dwp2pGUDzDwLPZbpSNkyXN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAMVvXFKtJV2Z/2dsb2JhbABZgwc4UsIQgSgWdIIlAQEBBHIHEgEIEgYKC0sXDgEBBAENBQiHfgy9bI4IEIEGAjEHCoMVgQQDiQSLJIUMiSGHMoMkgXA5 X-IronPort-AV: E=Sophos;i="4.93,494,1378857600"; d="scan'208";a="272057856" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 14 Oct 2013 22:30:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9EMUvoq008229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Oct 2013 22:30:57 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 14 Oct 2013 17:30:57 -0500 From: "Jim Guichard (jguichar)" To: "Diego R. Lopez" , " " Thread-Topic: inter-domain case (was RE: [nsc] Service chaining architecture question) Thread-Index: Ac6MNppeZnTEQQ6wR1W9crOC8t9qJA8tJGMAABKQRwA= Date: Mon, 14 Oct 2013 22:30:56 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6EC397@xmb-rcd-x01.cisco.com> In-Reply-To: <90016176-405D-4687-A232-FE5B92A46A82@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <003E3F37DFEB0048A8B79CE55454FD18@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Carlos Pignataro \(cpignata\)" , "NAPIERALA, MARIA H" , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , "Joel M. Halpern" Subject: Re: [nsc] inter-domain case (was RE: Service chaining architecture question) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2013 22:31:20 -0000 Hi Diego, Is it fair to say, at least theoretically, that services might extend from the WAN edge into the DC, and in that case the WAN and DC *may* be separately managed, and therefore by definition the service becomes an inter-domain chain? Further, in order to setup such a chain a subset of information needs to be exchanged between the two; this need not be a full policy exchange but rather an aggregate of availability. On 10/14/13 6:09 PM, "Diego R. Lopez" wrote: >Hi, > >I know this reply comes very very late. I left this message (and >everything around SFC) to deal with it after my holidays in August, and I >am afraid I found an enormous pile of urgent matters to deal with. I >thought the whole inter-domain issue outdated, but the recent message >from Christian has brought it back to my mind. And I think I have to make >my case for inter-domain chaining. Some replies inlined below... > >On 29 Jul 2013, at 10:35 , wrote: > >> Hi Diego, >> >> Thank you for the answer. I still don't understand well the >>inter-domain use case you are referring to and why this is a >>requirements. In order to understand better the case and to make sure >>there is no terminology confusion, below some questions for you: >> >> * Do you have two administrative entities involved in your case? > >DRL> Yes. Without leaving our corporate group, very often what you have >are several companies (with different management obligations and >administratively independent) cooperating to provide a certain E2E >service. Today this is achieved by direct human coordination and complete >functional (and even physical) separation. If you can dynamically chain >services this would translate into much agile and elastic provision and >operation. And I don't see why this would not involve in the near future >completely independent companies providing coordinated services by means >of collaboration agreements. > >> * Are both domains managed by one single administrative entity? > >DRL> As I said, even in the cases that I see in our group's environment, >that's not the case. To give you an example, we have separate companies >for the basic network services (and therefore network firewalling) and >content distribution platforms (and therefore content caching and the >like) > >> * Who decide on the inter-domain function chains? > >DRL> That would be part of the collaboration agreement: you can go from a >very loose arrangement (in which you expose only your ingress and egress >service points) to a tight integration, with a coordinated element taking >care of everything, where the coordination can be made by a trusted third >party (a federation operator), by one of the parties (a subordinated >relationship) or by means of particular SLAs (a SFaaS, we could say) > >> * Who is responsible for ensuring the overall consistency? > >DRL> Again, that would be part of the collaboration agreement, and you'll >have similar options. > >> * Why the chaining policies are to be exposed to an external domain? >>Why each domain need to reveal its intra policies with regards to the >>way a network is engineered? > >DRL> You don't need to expose *all* your policies (as you don't expose >*all* your topology) but just the relevant information for the >collaboration to take place. Again different models, from pure P2P >exchange to a centralized clearinghouse, can be applied. > >> * Why not each of the domain enforces its policies without requiring >>any involvement of functions located in another external domain? > >DRL> Because having some knowledge of what and how can be applied by the >other domain can help both domains in providing a better service to their >end users, optimize their infrastructure, and address additional business >models. > >> * Why chaining will modify the way networks managed by two distinct >>administrative entities will be interconnected? > >DRL>I don't think this would change the ways they interconnect, but the >way they build services, announce them, account for them, and apply >control on service function chaining. > >Be goode, > >-- >"Esta vez no fallaremos, Doctor Infierno" > >Dr Diego R. Lopez >Telefonica I+D >http://people.tid.es/diego.lopez/ > >e-mail: diego@tid.es >Tel: +34 913 129 041 >Mobile: +34 682 051 091 >----------------------------------------- > > >________________________________ > >Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el = enlace >situado m=E1s abajo. >This message is intended exclusively for its addressee. We only send and >receive email on the basis of the terms set out at: >http://www.tid.es/ES/PAGINAS/disclaimer.aspx From jiangyuanlong@huawei.com Tue Oct 15 01:22:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3454921E81B2 for ; Tue, 15 Oct 2013 01:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVEHdLLlUyXk for ; Tue, 15 Oct 2013 01:22:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C41DB21E80CF for ; Tue, 15 Oct 2013 01:22:41 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AWU90610; Tue, 15 Oct 2013 08:22:40 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 09:21:34 +0100 Received: from SZXEMA402-HUB.china.huawei.com (10.82.72.34) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 15 Oct 2013 09:21:58 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.229]) by SZXEMA402-HUB.china.huawei.com ([10.82.72.34]) with mapi id 14.03.0146.000; Tue, 15 Oct 2013 16:21:45 +0800 From: Jiangyuanlong To: "Jim Guichard (jguichar)" , "nsc@ietf.org" Thread-Topic: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Thread-Index: AQHOxPwCTtaobfXvXUmoBYc2VU4+u5n1ZwEg Date: Tue, 15 Oct 2013 08:21:44 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6B365E@szxema506-mbs.china.huawei.com> References: <68B171751455884590F8E38E96416F363F6DADAC@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6DADAC@xmb-rcd-x01.cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6B365Eszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "Hongyu Li \(Julio\)" Subject: Re: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 08:22:48 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6B365Eszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim, Thank a lot for preparing the preliminary agenda. We've uploaded a new I-D = http://www.ietf.org/internet-drafts/draft-jiang-sfc-arch-00.txt, which repl= aced the original draft-jiang-service-chaining-arch-00. We would like to se= e it being discussed in "SFC architecture & framework discussion", could yo= u add it to the list in the agenda? Best regards, Yuanlong & Hongyu From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, October 09, 2013 10:30 PM To: nsc@ietf.org Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Greetings, The following is a preliminary agenda for review/comment. Please note that = we have 2 hours total for the SFC BoF and the times provided are subject to= change. The BoF itself will be split into two sections: 1) the core BoF, = where we will discuss the problem statement, use cases, architecture/framew= ork, and charter, as well as answer the more general question as to whether= a WG is to be formed, followed by: 2) discussion of related drafts and how= to organize the work going forward, assuming a WG gets formed. Please let = Thomas or I know if you would like a slot to present a particular draft. 0.00 Introduction (BoF-chairs) - [10 minutes] 00.10 Problem statement discussion (BoF-chairs + presenter) - [20 minutes] * Problem statement review (Navindra Yadav, Insieme Networks) - [10 min= utes] * http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement * Problem statement Q&A (open-mic) - [10 minutes] 00.30 SFC use case discussion (presenter + open-mic) - [20 minutes] * SFC use cases (Hongyu Li, Huawei) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cas= es * Use case Q&A (BoF-chairs) - [10 minutes] 00.50 SFC architecture & framework discussion - [20 minutes] * Architecture & framework review (Ron Parker, Affirmed Networks & Pau= l Quinn, Cisco) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch * Architecture & framework Q&A (open-mic) - [10 minutes] 01.10 Charter text discussion (BoF-chairs) - [25 minutes] * Charter text review (BoF-chairs) - [10 minutes] * http://datatracker.ietf.org/wg/sfc/charter/ * Charter Q&A (open-mic) - [15 minutes] For the remainder of the time, we will assume the previous discussion (i.e= ., the main BoF) went reasonably well and we are looking forward to what w= e would need to do if we were a chartered WG. 01.35 Evaluation of required & existing ID's (BoF-chairs + presenters) - [2= 0 minutes] 01.55 Closing (BoF-chairs) - [5 minutes] * Actions & Next Steps Thanks, Jim & Thomas. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6B365Eszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Jim,

 = ;

Thank a lo= t for preparing the preliminary agenda. We’ve uploaded a new I-D http://www.ietf.org/internet-drafts/dra= ft-jiang-sfc-arch-00.txt, which replaced the original draft-jiang-service-chaining-arch-00. We would= like to see it being discussed in “SFC architecture & framework = discussion”, could you add it to the list in the agenda?

 = ;

Best regar= ds,

Yuanlong & Hongyu



 = ;

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 09, 2013 10:30 PM
To: nsc@ietf.org
Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver.

 

Greetings,

 <= /o:p>

The followin= g is a preliminary agenda for review/comment. Please note that we have= 2 hours total for the SFC BoF and the times provided are subject to change. The BoF itself will be split into two  sections: 1) the co= re BoF, where we will discuss the problem statement, use cases, architectur= e/framework, and charter, as well as answer the more general question as to= whether a WG is to be formed, followed by: 2) discussion of related drafts and how to organize the work going for= ward, assuming a WG gets formed. Please let Thomas or I know if you wo= uld like a slot to present a particular draft. 

 <= /o:p>

0.00 Introduction (BoF-chairs) - [10 minutes]=

00.10 Problem statement discussion (BoF-chair= s + presenter) - [20 minutes]

  • Problem statement review (Navindra Yadav, Insieme = Networks) - [10 minutes]
  • Problem statement Q&A<= /span> (open-mic) - [10 minutes= ]

00.30 <= span class=3D"b">SFC use case discussion (presenter += ; open-mic) - [20 minutes]

  • SFC use cases (Hongyu Li, Huawei) - [10 minutes]
  • Use case Q&A (BoF-chairs) - [10 minutes]<= /o:p>

00.50 <= span class=3D"b">SFC architecture & framework discussion&= nbsp;- [20 minutes]

  • Architecture  & f= ramework review (Ron Par= ker, Affirmed Networks & Paul Quinn, Cisco) - [10 minutes]
  • Architecture & framewo= rk Q&A (open-mic) - = [10 minutes]

01.10 <= span class=3D"b">Charter text discussion (BoF-chairs) - = [25 minutes]

  • Charter text review <= /span>(BoF-chairs) - [10 minutes]
  • Charter Q&A (open-mic) - [15 minutes]

For the = ; remainder of the time, we will assume the previous discussion (i.e., the&= nbsp; main BoF) went reasonably well and we are looking forward to what we would need to do if we were a chartered WG.

 <= /o:p>

01.35 Evaluation of required & existing ID's&n= bsp;(BoF-chairs + presenters) - [20 minutes]

 <= /o:p>

01.55 Closing (BoF-chairs) - [5 minutes]=

  • Actions & Next Steps
    • =

Thanks, Jim = & Thomas.

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B5A6B365Eszxema506mbschi_-- From jguichar@cisco.com Tue Oct 15 08:33:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390CA21E81E3 for ; Tue, 15 Oct 2013 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpHMj5263w6F for ; Tue, 15 Oct 2013 08:33:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id F061C21E81DB for ; Tue, 15 Oct 2013 08:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49144; q=dns/txt; s=iport; t=1381851192; x=1383060792; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=KPWMopJBXpiG/t7V07GouQRnWrnIS1LEPJ+03b4lH2c=; b=QiVWhkyVwXuVJJfnirdcseAmHqfZGbhzHszG1N0A71F7xG8pHqMzLqAj Cf08IbaUSRrknlzCa0W/HKd3vA760RuvSy7Ci1+jBvv0pM9V+YbPXX6L+ asnkKIjVrg1A6fObe5pnDyFm0mwJkJwkjP60GTwkzPtIySeWUdNsvwKxv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAMdfXVKtJXG//2dsb2JhbABagkNEOFKve4lkiEuBIhZ0giUBAQEELV4BCBEBAgEBAQsWAQY5FAMGCAIEARIIh34MvTiPGQ0TFwGDH4EGA5kzkFODJIIp X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208,217";a="272154607" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2013 15:33:11 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9FFXA3b002241 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 15:33:10 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 10:33:10 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Thread-Index: AQHOxoEjE37ql62DMUCDM4jNGfPM15n1+3CA Date: Tue, 15 Oct 2013 15:33:09 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6EFB92@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F6EFB92xmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: Re: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:33:18 -0000 --_000_68B171751455884590F8E38E96416F363F6EFB92xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ron, Thomas and I discussed your request and have allocated a 10 minute slot dur= ing the second half of the BOF for you to present your draft. We both felt = that it was premature to include this discussion during the first half of t= he BOF as it would be a distraction from the core purpose of chartering the= WG. From: Ron Parker > Date: Friday, October 11, 2013 8:55 AM To: Jim Guichard >, "nsc@ietf= .org" > Subject: RE: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Jim, Thanks for preparing the agenda. If time permits, I would request a slot = to present http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements= /. If agreed to, I might suggest to slot it after the use cases and befo= re the framework, as the requirements arise from the use cases and the fram= ework, hopefully, addresses the requirements. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Wednesday, October 09, 2013 10:30 AM To: nsc@ietf.org Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver. Greetings, The following is a preliminary agenda for review/comment. Please note that = we have 2 hours total for the SFC BoF and the times provided are subject to= change. The BoF itself will be split into two sections: 1) the core BoF, = where we will discuss the problem statement, use cases, architecture/framew= ork, and charter, as well as answer the more general question as to whether= a WG is to be formed, followed by: 2) discussion of related drafts and how= to organize the work going forward, assuming a WG gets formed. Please let = Thomas or I know if you would like a slot to present a particular draft. 0.00 Introduction (BoF-chairs) - [10 minutes] 00.10 Problem statement discussion (BoF-chairs + presenter) - [20 minutes] * Problem statement review (Navindra Yadav, Insieme Networks) - [10 min= utes] * http://datatracker.ietf.org/doc/draft-quinn-nsc-problem-statement * Problem statement Q&A (open-mic) - [10 minutes] 00.30 SFC use case discussion (presenter + open-mic) - [20 minutes] * SFC use cases (Hongyu Li, Huawei) - [10 minutes] * http://datatracker.ietf.org/doc/draft-liu-service-chaining-use-cas= es * Use case Q&A (BoF-chairs) - [10 minutes] 00.50 SFC architecture & framework discussion - [20 minutes] * Architecture & framework review (Ron Parker, Affirmed Networks & Pau= l Quinn, Cisco) - [10 minutes] * http://datatracker.ietf.org/doc/draft-boucadair-sfc-framework * http://datatracker.ietf.org/doc/draft-quinn-sfc-arch * Architecture & framework Q&A (open-mic) - [10 minutes] 01.10 Charter text discussion (BoF-chairs) - [25 minutes] * Charter text review (BoF-chairs) - [10 minutes] * http://datatracker.ietf.org/wg/sfc/charter/ * Charter Q&A (open-mic) - [15 minutes] For the remainder of the time, we will assume the previous discussion (i.e= ., the main BoF) went reasonably well and we are looking forward to what w= e would need to do if we were a chartered WG. 01.35 Evaluation of required & existing ID's (BoF-chairs + presenters) - [2= 0 minutes] 01.55 Closing (BoF-chairs) - [5 minutes] * Actions & Next Steps Thanks, Jim & Thomas. --_000_68B171751455884590F8E38E96416F363F6EFB92xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Ron,

Thomas and I discussed your request and have allocated a 10 minute slo= t during the second half of the BOF for you to present your draft. We both = felt that it was premature to include this discussion during the first half= of the BOF as it would be a distraction from the core purpose of chartering the WG. 

From: Ron Parker <Ron_Parker@affirmednetworks.com>= ;
Date: Friday, October 11, 2013 8:55= AM
To: Jim Guichard <jguichar@cisco.com>, "nsc@ietf.org" <n= sc@ietf.org>
Subject: RE: [nsc] Preliminary SFC = BoF agenda for IETF88 in Vancouver.

Jim,

 

Thanks for preparing the agenda.&n= bsp;  If time permits, I would request a slot to present http://datatracker.ietf.org/doc/draft-boucadair-sfc-requ= irements/.    If agreed to, I might suggest to slot it after the use cases and before the framework, as the re= quirements arise from the use cases and the framework, hopefully, addresses= the requirements.

 

   Ron

 

 

 

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Wednesday, October 09, 2013 10:30 AM
To: nsc@ietf.org
Subject: [nsc] Preliminary SFC BoF agenda for IETF88 in Vancouver.

 

Greetings,

 

The following is a preliminary agenda for r= eview/comment. Please note that we have 2 hours total for the SFC BoF = and the times provided are subject to change. The BoF itself will be split into two  sections: 1) the core BoF, whe= re we will discuss the problem statement, use cases, architecture/framework= , and charter, as well as answer the more general question as to whether a = WG is to be formed, followed by: 2) discussion of related drafts and how to organize the work going forward, assuming a&n= bsp;WG gets formed. Please let Thomas or I know if you would like a slot to= present a particular draft. 

 

0.00 Introduction=  (BoF-chairs) - [10 minutes]

00.10 Problem sta= tement discussion (BoF-chairs + presenter) - [20 minute= s]

  • Problem statement review (Navindra Yadav,= Insieme Networks) - [10 minutes]
  • Problem statement Q&A (open-mic) - [1= 0 minutes]

00.30 SFC use cas= e discussion (presenter + open-mic) - [20 minutes]=

  • SFC use cases (Hongyu Li, Huawei) - [10 m= inutes]
  • Use case Q&A (BoF-chairs) - [10 minut= es]

00.50 SFC archite= cture & framework discussion - [20 minutes]<= /span>

  • Architecture  & framework review=  = ;(Ron Parker, Affirmed Networks & Paul Quinn, Cisco) - [10 minutes]
  • Architecture & framework Q&A (ope= n-mic) - [10 minutes]

01.10 Charter tex= t discussion (BoF-chairs) - [25 minutes]<= /p>

  • Charter text review (BoF-chairs) - [10 mi= nutes]
  • Charter Q&A (open-mic) - [15 minutes]=

For the  remainder of the time, we wil= l assume the previous discussion (i.e., the  main BoF) went reasonably= well and we are looking forward to what we would need to do if we were a chartered WG.

 

01.35 Evaluation = of required & existing ID's (BoF-chairs + presenter= s) - [20 minutes]

 

01.55 Closing=  (BoF-chairs) - [5 minutes]

  • Actio= ns & Next Steps

Thanks, Jim & Thomas.=

--_000_68B171751455884590F8E38E96416F363F6EFB92xmbrcdx01ciscoc_-- From sarikaya2012@gmail.com Tue Oct 15 08:44:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869F521E80D1 for ; Tue, 15 Oct 2013 08:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFaiTvO4u8sA for ; Tue, 15 Oct 2013 08:44:47 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5945521E80C6 for ; Tue, 15 Oct 2013 08:44:45 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ec20so851067lab.16 for ; Tue, 15 Oct 2013 08:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=H0ddMnr5hY9CYz4aw0i/uy/ZD6lIMCZDobn9QcdhBuI=; b=pQ0WA5O6yBHyrG3lLEICV9DTfXk1fhjHP8/cbMiRhXFNNeJhbxrc/PYVXo99BCuGWv l5ciZvN+iY0h31DYr6F1D00/gEBT9swEaUQk6JrL6sNy0eIlRhGpD3megEd4/6qaVe/q o8kdGd9rkdXKADLRo3+sfPVW3oQB6561t9V+qTUMUoRUohs2J8n9UUJWZUWKajeGQ2Nf W2e90TaTdW1dxsMIAh10Tuy/H64UlgJrvLYfV2fApxlCU68fdt6iZCTNPM/e7WI69Zvf k4Hc2kxHEgziOV83Zal53wT9mp3KwHwLyHJehYPEqLvGpWakzTTHWl8S5cpmEVLWoa+P TwsA== MIME-Version: 1.0 X-Received: by 10.112.235.3 with SMTP id ui3mr1937123lbc.44.1381851884304; Tue, 15 Oct 2013 08:44:44 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 15 Oct 2013 08:44:44 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Oct 2013 10:44:44 -0500 Message-ID: From: Behcet Sarikaya To: "Liushucheng (Will)" Content-Type: multipart/alternative; boundary=001a11c31720b23d0604e8c97623 Cc: "nsc@ietf.org" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 15:44:48 -0000 --001a11c31720b23d0604e8c97623 Content-Type: text/plain; charset=ISO-8859-1 Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) wrote: > Folks, > > We've uploaded the updated and renamed use case draft. Looking forward to > your comments. > > Regards, > Shucheng LIU (Will) > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 10, 2013 3:42 PM > To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); > Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao > Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt > > > A new version of I-D, draft-liu-sfc-use-cases-00.txt > has been successfully submitted by Will(Shucheng) Liu and posted to the > IETF repository. > > Filename: draft-liu-sfc-use-cases > Revision: 00 > Title: Service Function Chaining Use Cases > Creation date: 2013-10-10 > Group: Individual Submission > Number of pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt > Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases > Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 > > > Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > --001a11c31720b23d0604e8c97623 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Shucheng,

In the use c= ases draft, you say that

SFC are not per-subscriber.=A0 In other wo= rds, this document assumes
=A0=A0=A0=A0=A0 per-subscriber SFCs are not i= nstantiated in the network.
=A0=A0=A0=A0=A0 Deployments cases that would require per-subscriber SFCs ar= e out
=A0=A0=A0=A0=A0 of scope.

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

Regards,

Behcet
=

On Fri, Oct 11, 2013 at 1:13 AM, Liushuc= heng (Will) <liushucheng@huawei.com> wrote:
Folks,

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

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename: =A0 =A0 =A0 =A0draft-liu-sfc-use-cases
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Service Function Chaining Use Cases
Creation date: =A0 2013-10-10
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/inte= rnet-drafts/draft-liu-sfc-use-cases-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu-sfc-= use-cases-00


Abstract:
=A0 =A0The delivery of value-added services relies on the invocation of
=A0 =A0advanced Service Functions in a sequential order. =A0This mechanism = is
=A0 =A0called Service Function Chaining (SFC). =A0The set of involved Servi= ce
=A0 =A0Functions and their order depends on the service context.

=A0 =A0This document presents a set of use cases of Service Function
=A0 =A0Chaining (SFC).




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

The IETF Secretariat

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

--001a11c31720b23d0604e8c97623-- From jguichar@cisco.com Tue Oct 15 10:34:39 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3197621F9703 for ; Tue, 15 Oct 2013 10:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeWAS9NOwjWF for ; Tue, 15 Oct 2013 10:34:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id AD6A911E81A1 for ; Tue, 15 Oct 2013 10:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9594; q=dns/txt; s=iport; t=1381858470; x=1383068070; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=lPvQ6JDv7WQ+g9qn2PhaMipupSDl/z9ckkg7fGdOppY=; b=P9Ip4C2ADNuWOyC43IbiORtoxPg8iqjDa1LKGGZ3eSR3Mxtp+AyOuqJQ NCucPxtTPDmITgpPFMa6XqC8XsM/esSQEw/k1gBdAZZE7tHMHhjHQlAL6 2wES2Kax574so4UZb3k+NsJUrQAqdWfhB6P0gtQ5a7ONblt1K9z2ty6Hj g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAFAG17XVKtJXHA/2dsb2JhbABagkNEOFKve4lkiEuBIxZ0giUBAQEEAQEBawkCDAYBCBEDAQEBCx0oBgsUCAEIAgQBDQUIARKHWQMPDLNzDYlrjFyCPSANBAcGA4MWgQYDlCeBdIMYix2FNoMkgik X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208,217";a="272501509" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 15 Oct 2013 17:34:30 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9FHYTif020997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 17:34:29 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 12:34:29 -0500 From: "Jim Guichard (jguichar)" To: "sarikaya@ieee.org" , "Liushucheng (Will)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESg== Date: Tue, 15 Oct 2013 17:34:28 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.131.36.102] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F6F0E5Dxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:34:39 -0000 --_000_68B171751455884590F8E38E96416F363F6F0E5Dxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_68B171751455884590F8E38E96416F363F6F0E5Dxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng@huawei.com>= ;
Cc: "nsc@ietf.org" <nsc@ietf.= org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 --_000_68B171751455884590F8E38E96416F363F6F0E5Dxmbrcdx01ciscoc_-- From I.Smith@F5.com Tue Oct 15 10:52:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D311E819D for ; Tue, 15 Oct 2013 10:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2knDNQmJRSsc for ; Tue, 15 Oct 2013 10:51:59 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id D82AA1F0D55 for ; Tue, 15 Oct 2013 10:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381859518; x=1413395518; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=d+NWkHFJzREBaP+zMn2SbjKwSfPTLH9BIJjKPUuacH8=; b=HuNIbLGVhC30DsOeYCkKXOSnXmL87azTIYMD2aZzRgvPBc+xvFXluxD/ +9b0EjR0EDOixxCsm5ZOWbDmqUXKWH6b070adFeIOk2LHyVaN17NRnN0y Mpdm9XlZJh8H/9+7N41tCMukuqdfqpbvUM7DTTaPxwSd5ZCPGCfpXQ149 Q=; X-IronPort-AV: E=Sophos;i="4.93,500,1378857600"; d="scan'208,217";a="83573475" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 17:51:56 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 10:51:55 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" , "sarikaya@ieee.org" , "Liushucheng (Will)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiY Date: Tue, 15 Oct 2013 17:51:54 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A7020F0SEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 17:52:05 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A7020F0SEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guichard= (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A7020F0SEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
From: nsc-bounces@ietf.org [nsc-bounces@ie= tf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

--_000_419417C345CA5F48BF45F0A23955A0634A7020F0SEAEMBX02olympu_-- From jguichar@cisco.com Tue Oct 15 12:52:11 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA911E820B for ; Tue, 15 Oct 2013 12:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2OoB2I10cBQ for ; Tue, 15 Oct 2013 12:52:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 278A511E8156 for ; Tue, 15 Oct 2013 12:52:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14410; q=dns/txt; s=iport; t=1381866724; x=1383076324; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7BGTbCZlZEKtbXxffwXCoW/hOWI/MLnCtpHKggKlhAE=; b=DP8Q4qiSf4itVN1jj8O9NcyefBWwNfO10n48VdN02hN4MeaiBYo37gtV efAFf03HGr8iV94bQI2OerxsoXzmzjeySPfKx14GQHWGeF1zQEvpAZS9o EHqyDhTZltvZc9X2T6r12EkMr2150ZQRZAPfaI+4nz1ODkFg6kNqob2BR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FADecXVKtJXG8/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBawkCDAQCAQgOAwMBAQEoByEGCxQIAQgCBA4FCRKHWQMPDLQADYlrjFyBLIEXGg0EBgEGA4MWgQYDlCeBdIFpgS+LHYU2gyQ X-IronPort-AV: E=Sophos;i="4.93,501,1378857600"; d="scan'208,217";a="269489520" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 15 Oct 2013 19:52:03 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9FJq3d0022809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 19:52:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 14:52:03 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIw= Date: Tue, 15 Oct 2013 19:52:02 +0000 Message-ID: References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F998175F91C84F55AC317ECFDE6587AEciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 19:52:11 -0000 --_000_F998175F91C84F55AC317ECFDE6587AEciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_F998175F91C84F55AC317ECFDE6587AEciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry from per-s= ubscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim= Guichard (jguichar) [jguichar@cisco.= com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@ieee.org; Lius= hucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

--_000_F998175F91C84F55AC317ECFDE6587AEciscocom_-- From I.Smith@F5.com Tue Oct 15 13:30:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C69921F9D65 for ; Tue, 15 Oct 2013 13:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xCi4n-b4IYgh for ; Tue, 15 Oct 2013 13:30:18 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 521B121F9703 for ; Tue, 15 Oct 2013 13:30:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381869018; x=1413405018; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8EFldZMsIy2TfMv8k30DF5LZOa1I+cwqYfIL9AfNGdU=; b=Ygyw7fWcf0C5qDi7xjY3IvzK8jKyPNKSDAi5uYOhu7ZxYPG/3BljtleE 2SJWrK84Qnse9KE3t/9v3ADfGqQjBwTi6a/AqOBhFelAH7XIEPE22WhXT hBpxtONK3D36dONjBEZP5PEwGcS+fo3jfnxDZFVt3QG2veUzEuGc/8uGG o=; X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="83589910" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 20:30:13 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 13:30:13 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiYgACbHwD//5Pc1g== Date: Tue, 15 Oct 2013 20:30:12 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A70236ASEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:30:22 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A70236ASEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A70236ASEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
We do that already.

I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone).  T= he fixed is easy and not far removed from giving each student in a dorm their own vlan - something I've seen do= ne in the late 90s.  Mobile is a little more sophisticated, but still = achievable if you are automating your provisioning system and have an elast= ic VAS infrastructure.

In both cases you are just taking the IaaS model and reversing the flo= w of traffic.



From: Jim Guichard (jguichar) [jguichar@ci= sco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry from per-s= ubscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

--_000_419417C345CA5F48BF45F0A23955A0634A70236ASEAEMBX02olympu_-- From jguichar@cisco.com Tue Oct 15 13:33:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1880611E8210 for ; Tue, 15 Oct 2013 13:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id febkT8C+tlMA for ; Tue, 15 Oct 2013 13:33:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9E221F9D65 for ; Tue, 15 Oct 2013 13:33:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17654; q=dns/txt; s=iport; t=1381869218; x=1383078818; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=34NTXtTy9emcMZkskcFywxcEySJwqUtR5rGLP2rwPEA=; b=UlktcrfxQpj8iE8sDNbbvoYrLXHB/Wd1uE/2/7gEkAUcYw1g/sVN/gSo A4gq77/wDdHRAPZDNkHignXQ0g8PIBeEPXH1zcVrwRcJ3URtZC7SgtiDu IclbLnJrpM4O8bjBCqFZptfaWtETZZxO8Hvw3GlUK7g2PsGLMYyxxRLt5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAJylXVKtJV2a/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBawkCDAQCAQgOAwMBAQEoByEGCxQIAQgCBA4FCRKHWQMPDLQQDYlrjFyBLIEXGg0EBgEGA4MWgQYDjFOHVIF0gWmBL4YEhRmFNoMk X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="272511754" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2013 20:33:37 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FKXbpP005336 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 20:33:37 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 15:33:36 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAF57AP//rSHs Date: Tue, 15 Oct 2013 20:33:35 +0000 Message-ID: <3BE0905A-FF75-4271-98DD-38981D2FB71C@cisco.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, , <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3BE0905AFF75427198DD38981D2FB71Cciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:33:44 -0000 --_000_3BE0905AFF75427198DD38981D2FB71Cciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So you are saying each individual client sat on the end of some mobile devi= ce will get their own SFC? Sent from my iPhone On Oct 15, 2013, at 4:30 PM, "Ian Smith" > wrote: We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_3BE0905AFF75427198DD38981D2FB71Cciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So you are saying each individual client sat on the end of some mobile= device will get their own SFC? 

Sent from my iPhone

On Oct 15, 2013, at 4:30 PM, "Ian Smith" <I.Smith@F5.com> wrote:

We do that already.

I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone).  T= he fixed is easy and not far removed from giving each student in a dorm their own vlan - something I've seen do= ne in the late 90s.  Mobile is a little more sophisticated, but still = achievable if you are automating your provisioning system and have an elast= ic VAS infrastructure.

In both cases you are just taking the IaaS model and reversing the flo= w of traffic.



From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry from per-s= ubscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

--_000_3BE0905AFF75427198DD38981D2FB71Cciscocom_-- From Ron_Parker@affirmednetworks.com Tue Oct 15 13:37:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5614011E81EA for ; Tue, 15 Oct 2013 13:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9DezRrphbs9 for ; Tue, 15 Oct 2013 13:37:24 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED111E8218 for ; Tue, 15 Oct 2013 13:37:19 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 13:37:14 -0700 From: Ron Parker To: Ian Smith , "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczVyp1jgKYkE0WXE6hidxpy5pn2gDYAgAAhkQCAAAqqAP//i33A Date: Tue, 15 Oct 2013 20:37:14 +0000 Message-ID: References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71287AMBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:37:29 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71287AMBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian, >From my perspective, the vision for the SFC classifier is to not only be su= bscriber aware, but also flow aware. This alleviates the bypass traffic p= roblem that occurs when 100% of traffic at some granularity (network, APN, = subscriber) is sent through a sequence of service nodes, as is done in toda= y's topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasse= s non-TCP). Thus, the number of distinct chain sequences is somewhat orth= ogonal to the number of subscribers and is driven by subscriber-aware/flow-= aware policy. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian S= mith Sent: Tuesday, October 15, 2013 4:30 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71287AMBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ian,

 <= /p>

From my perspective, the = vision for the SFC classifier is to not only be subscriber aware, but also = flow aware.   This alleviates the bypass traffic problem that occurs when 100% of traffic at some granularity (network, APN, subscr= iber) is sent through a sequence of service nodes, as is done in today̵= 7;s topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasse= s non-TCP).   Thus, the number of distinct chain sequences is somewhat orthogonal to the number of subscribers and is= driven by subscriber-aware/flow-aware policy.

 <= /p>

   Ron

 <= /p>

 <= /p>

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:30 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

We do that already.

 

I'm talking about giving eac= h /64 their own path from the IP anchor through the VAS LAN to the PE route= r tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just t= aking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) [jgu= ichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fore= gone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 =

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 =

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet=

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A71287AMBX021W3CA2exch_-- From jguichar@cisco.com Tue Oct 15 13:45:22 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F221621F8FDC for ; Tue, 15 Oct 2013 13:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.336 X-Spam-Level: X-Spam-Status: No, score=-10.336 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJiDHi6lG7oN for ; Tue, 15 Oct 2013 13:45:16 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F022421F8E40 for ; Tue, 15 Oct 2013 13:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26613; q=dns/txt; s=iport; t=1381869906; x=1383079506; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vEmqXF3umiGDmoEgFfPoFrfxO5Q46SGF7fZFVK70kBU=; b=ah3Bz8Gt1u9abs4VN07AAaiL5YK0UyN4Sjw/mDeCMQ+Sm6VVencVtcYm kHnU7WOCR9jfkDcp4n43wK6hMSO6ZHzCu6MSux4ZO0w4avbUcBTjZJlBe iJefXWYaOwy3Lxx1iiq4hpN2RoaqGKNaM1P2R1hXFeIZAG1GHpK7xau+n s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAO6nXVKtJV2d/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBKkEJAgwEAgEIEQMBAQEhBwchBgsUCAEIAgQOBQkSh1kDDwy0Dw2Ja4xcgSyBFQIHEw0EBgEGA4MWgQYDjFOHVIF0gWmBL4YEhRmFNoMk X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="272515931" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 15 Oct 2013 20:45:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9FKj4cV020614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 20:45:04 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 15:45:04 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAF57AIAAAfcA//+uXaw= Date: Tue, 15 Oct 2013 20:45:03 +0000 Message-ID: References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D48B206528B94BB984346162EA179518ciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:45:22 -0000 --_000_D48B206528B94BB984346162EA179518ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ron, The granularity of what you describe as "subscriber" is important here; one= could classify traffic as belonging to subscriber "android" or as belongin= g to "Jim who happens to be using an Android". The former is a lot less "su= bscribers" than the latter. In my world I tend to think of the former as th= e classification granularity. I certainly would not anticipate building an = SFC just for the sole use of "Jim" (I'm really not that important ;) ). Sent from my iPhone On Oct 15, 2013, at 4:37 PM, "Ron Parker" > wrote: Ian, >From my perspective, the vision for the SFC classifier is to not only be su= bscriber aware, but also flow aware. This alleviates the bypass traffic p= roblem that occurs when 100% of traffic at some granularity (network, APN, = subscriber) is sent through a sequence of service nodes, as is done in toda= y=92s topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypas= ses non-TCP). Thus, the number of distinct chain sequences is somewhat or= thogonal to the number of subscribers and is driven by subscriber-aware/flo= w-aware policy. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ian Smith Sent: Tuesday, October 15, 2013 4:30 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_D48B206528B94BB984346162EA179518ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ron,

The granularity of what you describe as "subscriber" is impo= rtant here; one could classify traffic as belonging to subscriber "and= roid" or as belonging to "Jim who happens to be using an Android&= quot;. The former is a lot less "subscribers" than the latter. In my world I tend to think of the former as the classification granularit= y. I certainly would not anticipate building an SFC just for the sole use o= f "Jim" (I'm really not that important ;) ).

Sent from my iPhone

On Oct 15, 2013, at 4:37 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wro= te:

Ian,

 <= /p>

From my perspective, the = vision for the SFC classifier is to not only be subscriber aware, but also = flow aware.   This alleviates the bypass traffic problem that occurs when 100% of traffic at some granularity (network, APN, subscr= iber) is sent through a sequence of service nodes, as is done in today=92s = topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasses no= n-TCP).   Thus, the number of distinct chain sequences is somewhat orthogonal to the number of subscribers and is= driven by subscriber-aware/flow-aware policy.

 <= /p>

   Ron

 <= /p>

 <= /p>

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:30 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

We do that already.

 

I'm talking about giving eac= h /64 their own path from the IP anchor through the VAS LAN to the PE route= r tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just t= aking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fore= gone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 =

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 =

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet=

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 =

--_000_D48B206528B94BB984346162EA179518ciscocom_-- From sarikaya2012@gmail.com Tue Oct 15 13:45:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDF21F894E for ; Tue, 15 Oct 2013 13:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.491, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+iUhn+nnv-9 for ; Tue, 15 Oct 2013 13:45:27 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) by ietfa.amsl.com (Postfix) with ESMTP id D025621F8201 for ; Tue, 15 Oct 2013 13:45:16 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id w7so7189459lbi.22 for ; Tue, 15 Oct 2013 13:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Y8Y0iGayYZDFXk47Mnfcv5jovJnM8PGV+GE3+RFTZwg=; b=rA4bJBr26nhDxRblmXkKqbhAfpXHqi8GgsqG7nCSCskiHLZmkFzJBBYqW7oNVU8lDi DiExLxpWj0rEJmFoxkLEoiKV7wTYYzJsYh5nHTH6EJxn/Vbw8np1OgW5pFvbPAwExNgU 2FiREI6ZwNW4tdjOoUg2M4rh38y4phlkImUTUGlK9RFRflKpQrWRiSfWUcNlcfs24+zn fX6SWb/xMe1iDDPtf8R+zq6x8rC23tg43iYEFsvjZzDmjTR1SxdEGWZqimBQ3bhlkZkd +XRR+BZBRbMQ1F3Nmh0e6gUcL4TQ3JmpCxzXDJEQNLM+w/2Q7iRGGg7mar3eStmkJMys fY4w== MIME-Version: 1.0 X-Received: by 10.152.9.36 with SMTP id w4mr3842923laa.34.1381869912358; Tue, 15 Oct 2013 13:45:12 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 15 Oct 2013 13:45:12 -0700 (PDT) In-Reply-To: References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> Date: Tue, 15 Oct 2013 15:45:12 -0500 Message-ID: From: Behcet Sarikaya To: "Jim Guichard (jguichar)" Content-Type: multipart/alternative; boundary=089e0158b7e840826704e8cda9d4 Cc: "nsc@ietf.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:45:29 -0000 --089e0158b7e840826704e8cda9d4 Content-Type: text/plain; charset=ISO-8859-1 I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) wrote: > Hi Ian, > If by subscriber you mean per-tenant or per-subscriber-group then I will > agree that SFC's will be built for these but that's a far cry from > per-subscriber which implies to me an individual broadband or mobile client. > > Sent from my iPhone > > On Oct 15, 2013, at 1:51 PM, "Ian Smith" wrote: > > I don't think that is a foregone conclusion. > > When you combine what is being done in IaaS environments for muti-tenant > dynamic datacenters with what you can do with policy defined networking and > IPv6, for an access provider to provision per-subscriber VAS LANs and > default gateways takes away a lot of the big problems caused by aggregation > that you're trying to solve with service chains. More to the point, you > don't need to disaggregate anything when you know that all the traffic > belongs to a single customer, and that the default gateway of each node is > the next hop in the service chain. Solving the problem for 1 > subscriber@1Gbps is trivial; what makes what we're talking about in this > list hard is that you are trying to solve it for 10 million subscribers > @100Gbps but in truth the only technology-based reason you do that is > because of administrative challenges that the cloud world is solving (and > may have solved before anything is produced in a WG) and that are squarely > in the domain of things already proven to be better done by computers than > people. > > I tend to argue that per-subscriber provisioning of the access path > triggered by identity-based authentication is the obvious and natural > evolution of the technology being fielded today. > > > ------------------------------ > *From:* nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim > Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 1:34 PM > *To:* sarikaya@ieee.org; Liushucheng (Will) > *Cc:* nsc@ietf.org > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > It seems very unlikely that one would opt for a solution whereby a > separate SFC is required per-subscriber; clearly millions of SFC's is not > desirable no matter how you cut it. IMHO, the support of services that > require per-subscriber policy are more likely to be realized using > something like the solution described in draft-quinn-sfc-nsh. > > From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM > To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > Hi Shucheng, > > In the use cases draft, you say that > > SFC are not per-subscriber. In other words, this document assumes > per-subscriber SFCs are not instantiated in the network. > Deployments cases that would require per-subscriber SFCs are out > of scope. > > However you have at least three parental control use cases. How would it > be possible to have parental control not being per-subscriber? > > Regards, > > Behcet > > > On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) < > liushucheng@huawei.com> wrote: > >> Folks, >> >> We've uploaded the updated and renamed use case draft. Looking forward to >> your comments. >> >> Regards, >> Shucheng LIU (Will) >> >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Thursday, October 10, 2013 3:42 PM >> To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); >> Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao >> Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt >> >> >> A new version of I-D, draft-liu-sfc-use-cases-00.txt >> has been successfully submitted by Will(Shucheng) Liu and posted to the >> IETF repository. >> >> Filename: draft-liu-sfc-use-cases >> Revision: 00 >> Title: Service Function Chaining Use Cases >> Creation date: 2013-10-10 >> Group: Individual Submission >> Number of pages: 14 >> URL: >> http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt >> Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases >> Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 >> >> >> Abstract: >> The delivery of value-added services relies on the invocation of >> advanced Service Functions in a sequential order. This mechanism is >> called Service Function Chaining (SFC). The set of involved Service >> Functions and their order depends on the service context. >> >> This document presents a set of use cases of Service Function >> Chaining (SFC). >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> > > --089e0158b7e840826704e8cda9d4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0I was talking about something like parental c= ontrol.
Do you qualify such an SFC as each mobile client getting i= ts own SFC?

I think it is more like per-subscriber-group. It c= ould be per subscriber as well but I can not think of an example at this mo= ment.



On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) <jguichar@= cisco.com> wrote:
Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry fr= om per-subscriber which implies to me an individual broadband or mobile cli= ent.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't = think that is a foregone conclusion.=A0

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with se= rvice chains.=A0 More to the point, you don't need to disaggregate anyt= hing when you know that all the traffic belongs to a single customer, and t= hat the default gateway of each node is the next hop in the service chain.=A0 Solving the problem for 1 subscriber@1Gb= ps is trivial; what makes what we're talking about in this list hard is= that you are trying to solve it for 10 million subscribers @100Gbps but in= truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

=A0
Fro= m: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not = desirable no matter how you cut it. IMHO, the support of services that requ= ire per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh.=A0

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.=A0 In other words, this document assumes
=A0=A0=A0=A0=A0 per-subscriber SFCs are not instantiated in the network. =A0=A0=A0=A0=A0 Deployments cases that would require per-subscriber SFCs ar= e out
=A0=A0=A0=A0=A0 of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

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

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename: =A0 =A0 =A0 =A0draft-liu-sfc-use-cases
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Service Function Chaining Use Cases
Creation date: =A0 2013-10-10
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu-sfc-= use-cases-00


Abstract:
=A0 =A0The delivery of value-added services relies on the invocation of
=A0 =A0advanced Service Functions in a sequential order. =A0This mechanism = is
=A0 =A0called Service Function Chaining (SFC). =A0The set of involved Servi= ce
=A0 =A0Functions and their order depends on the service context.

=A0 =A0This document presents a set of use cases of Service Function
=A0 =A0Chaining (SFC).




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

The IETF Secretariat

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


--089e0158b7e840826704e8cda9d4-- From I.Smith@F5.com Tue Oct 15 13:46:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CE421F8E40 for ; Tue, 15 Oct 2013 13:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4rxUPPPMq0K for ; Tue, 15 Oct 2013 13:46:53 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id EFC3A21F894E for ; Tue, 15 Oct 2013 13:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381870013; x=1413406013; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YUnTvY7D2V2g7i505n5qYP4d7bS3N9pkp/iGG1+bqrw=; b=eT+4UG/crwVxZf3AtPMj3uKeKQ155wvKVTZEeNo1KRlPcd/8AiKCzy92 Cli33gXN3OMwaTo5q3vJdKM9fuflVY8bjYWVXqz4/7Q9fEHzsPgRlmFXY xHKc8mJZOL+yL8oIgqXVol9VBWM2chcvgZPq+27KRoG3u/oVjt7/42em7 s=; X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="83591595" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 20:46:52 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 13:46:51 -0700 From: Ian Smith To: Ron Parker , "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiYgACbHwD//5Pc1oAAeMUA//+MFyA= Date: Tue, 15 Oct 2013 20:46:51 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A702401@SEAEMBX02.olympus.F5Net.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A702401SEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:46:57 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A702401SEAEMBX02olympu_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sure, but you are still having to classify all the traffic for all the subs= cribers. And you have to deal with mid-flow changes to that classification= . I'm not saying that it can't be done, I'm just remarking that "no one wi= ll ever need more than 640K" problems shouldn't be dismissed too quickly. ________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Tuesday, October 15, 2013 4:37 PM To: Ian Smith; Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: RE: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Ian, >From my perspective, the vision for the SFC classifier is to not only be su= bscriber aware, but also flow aware. This alleviates the bypass traffic p= roblem that occurs when 100% of traffic at some granularity (network, APN, = subscriber) is sent through a sequence of service nodes, as is done in toda= y=92s topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypas= ses non-TCP). Thus, the number of distinct chain sequences is somewhat or= thogonal to the number of subscribers and is driven by subscriber-aware/flo= w-aware policy. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian S= mith Sent: Tuesday, October 15, 2013 4:30 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A702401SEAEMBX02olympu_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Sure, but you are still having to classify all the traffic for all t= he subscribers.  And you have to deal with mid-flow changes to that cl= assification.  I'm not saying that it can't be done, I'm just remarking that "no one will ever need more than 640= K" problems shouldn't be dismissed too quickly. 

From: Ron Parker [Ron_Parker@affirmednetw= orks.com]
Sent: Tuesday, October 15, 2013 4:37 PM
To: Ian Smith; Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: RE: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Ian,

 

From my perspective, th= e vision for the SFC classifier is to not only be subscriber aware, but als= o flow aware.   This alleviates the bypass traffic problem that occurs when 100% of traffic at some granularity (network, APN, subscr= iber) is sent through a sequence of service nodes, as is done in today=92s = topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasses no= n-TCP).   Thus, the number of distinct chain sequences is somewhat orthogonal to the number of subscribers and is= driven by subscriber-aware/flow-aware policy.

 

   Ron=

 

 

 

From: nsc-= bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:30 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

We do that already.=

 

I'm talking about giving e= ach /64 their own path from the IP anchor through the VAS LAN to the PE rou= ter tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just= taking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) = [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@= ieee.org; Liushucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fo= regone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com> Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at least three parental control use cases. How woul= d it be possible to have parental control not being per-subscriber?<= /p>

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

--_000_419417C345CA5F48BF45F0A23955A0634A702401SEAEMBX02olympu_-- From I.Smith@F5.com Tue Oct 15 13:47:51 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE09721F8FF5 for ; Tue, 15 Oct 2013 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UN-Rp9FiD0Zk for ; Tue, 15 Oct 2013 13:47:36 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4A21F8517 for ; Tue, 15 Oct 2013 13:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381870057; x=1413406057; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2HlDjBLtF2ARGpa0eDrUpvXJNXErbd9Ti/dTU+Iq/II=; b=w8mrDfHZ16+hvpH3/cDIkTvTINjtP6ipLAYQ8LGX2Ci/xHtPhQmBiBgI v3ohu0sbtcRJg43u3cuokEQZEPrLwiKJQ5Qbbal02Hcggu322RGfPz/al nIxqG99MH9DoljSAW4/nqHvbatCnwABwsui0Xe+c/wShqGcNk04ng7j0z o=; X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="83591668" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 20:47:36 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 13:47:35 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiYgACbHwD//5Pc1oAAd8CA//+OZJ4= Date: Tue, 15 Oct 2013 20:47:35 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70241C@SEAEMBX02.olympus.F5Net.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, , <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, <3BE0905A-FF75-4271-98DD-38981D2FB71C@cisco.com> In-Reply-To: <3BE0905A-FF75-4271-98DD-38981D2FB71C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A70241CSEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:47:51 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A70241CSEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable yeah. I'm saying we shouldn't assume that isn't going to happen. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 4:33 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt So you are saying each individual client sat on the end of some mobile devi= ce will get their own SFC? Sent from my iPhone On Oct 15, 2013, at 4:30 PM, "Ian Smith" > wrote: We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A70241CSEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
yeah.  I'm saying we shouldn't assume that isn't going to happe= n.

From: Jim Guichard (jguichar) [jguichar@c= isco.com]
Sent: Tuesday, October 15, 2013 4:33 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

So you are saying each individual client sat on the end of some mobile= device will get their own SFC? 

Sent from my iPhone

On Oct 15, 2013, at 4:30 PM, "Ian Smith" <I.Smith@F5.com> wrote:

We do that already.

I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone).  T= he fixed is easy and not far removed from giving each student in a dorm their own vlan - something I've seen do= ne in the late 90s.  Mobile is a little more sophisticated, but still = achievable if you are automating your provisioning system and have an elast= ic VAS infrastructure.

In both cases you are just taking the IaaS model and reversing the flo= w of traffic.



From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@= ieee.org; Liushucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry from per-s= ubscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

--_000_419417C345CA5F48BF45F0A23955A0634A70241CSEAEMBX02olympu_-- From jguichar@cisco.com Tue Oct 15 13:48:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B9121F8E40 for ; Tue, 15 Oct 2013 13:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.322 X-Spam-Level: X-Spam-Status: No, score=-10.322 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sKIVDMP7yMi for ; Tue, 15 Oct 2013 13:47:58 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4DE21F9948 for ; Tue, 15 Oct 2013 13:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16161; q=dns/txt; s=iport; t=1381870073; x=1383079673; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=//PO+xnhmBhwj6rhMOwROA7jnvFPm62G/oaeBKsg0HM=; b=WDzRYtz71DTHLkGzksoAuOK+5tncafdBJFZY5zE9F4T3FMypsct8tIHk Kvws9l6ZZtj3oK1VKgjTqZGOjRv7MilM29syUAa8zzZlMUyxnL+Ggv0Ve b16c53HamMsAElpSHLn2WBno4T65mep8hpjQmjPUfJSoe1LRyUmOUWpbi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FACGpXVKtJV2c/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBawkCDAQCAQgRAwEBASgHIQYLFAgBCAIEDgUJEodZAw8MtA0NiWuMXIEsgRcaDQQGAQYDgxaBBgOUJ4F0gWmBL4sdhTaDJA X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="269512434" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 15 Oct 2013 20:47:52 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9FKlq9Q018608 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 20:47:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 15:47:52 -0500 From: "Jim Guichard (jguichar)" To: "" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAGKsAP//rOyM Date: Tue, 15 Oct 2013 20:47:52 +0000 Message-ID: <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_791251A6CA0A424C83DB7EF34BD2D738ciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:48:03 -0000 --_000_791251A6CA0A424C83DB7EF34BD2D738ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_791251A6CA0A424C83DB7EF34BD2D738ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No, to me this is most certainly a per-subscriber-group.

Sent from my iPhone

On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

 I was talking about something like parental control.
Do you qualify such an SFC as each mobile client getting its own SFC?

I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment.



On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (j= guichar) <jguichar@cisco.com> wrote:
Hi Ian,
If by subscriber you mean per-tenant or per-subscriber-group then I wi= ll agree that SFC's will be built for these but that's a far cry from per-s= ubscriber which implies to me an individual broadband or mobile client.

Sent from my iPhone

On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't thin= k that is a foregone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 
Fro= m: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solution whereby a sep= arate SFC is required per-subscriber; clearly millions of SFC's is not desi= rable no matter how you cut it. IMHO, the support of services that require = per-subscriber policy are more likely to be realized using something like the solution described in draft-quinn-= sfc-nsh. 

From: Behcet Sarikaya <sarikaya2012@gmail.com= >
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org> Date: Tuesday, October 15, 2013 11:= 44 AM
To: "Liushucheng (Will)" = <liushucheng= @huawei.com>
Cc: "nsc@ietf.org" <nsc@ietf.org>
Subject: Re: [nsc] FW: New Version = Notification for draft-liu-sfc-use-cases-00.txt

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet


On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Wi= ll) <liushucheng= @huawei.com> wrote:
Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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


--_000_791251A6CA0A424C83DB7EF34BD2D738ciscocom_-- From Ron_Parker@affirmednetworks.com Tue Oct 15 13:49:10 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA69C21F8E40 for ; Tue, 15 Oct 2013 13:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v7QPCLI7qx04 for ; Tue, 15 Oct 2013 13:49:06 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id C06F721F9123 for ; Tue, 15 Oct 2013 13:49:05 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 13:48:58 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczVyp1jgKYkE0WXE6hidxpy5pn2gDYAgAAhkQCAAAqqAP//i33AgAB4qYD//4uboA== Date: Tue, 15 Oct 2013 20:48:56 +0000 Message-ID: References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712914MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:49:10 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712914MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My intention was to convey subscriber as "Jim who happens to be using an An= droid." Ron From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, October 15, 2013 4:45 PM To: Ron Parker Cc: Ian Smith; nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Ron, The granularity of what you describe as "subscriber" is important here; one= could classify traffic as belonging to subscriber "android" or as belongin= g to "Jim who happens to be using an Android". The former is a lot less "su= bscribers" than the latter. In my world I tend to think of the former as th= e classification granularity. I certainly would not anticipate building an = SFC just for the sole use of "Jim" (I'm really not that important ;) ). Sent from my iPhone On Oct 15, 2013, at 4:37 PM, "Ron Parker" > wrote: Ian, >From my perspective, the vision for the SFC classifier is to not only be su= bscriber aware, but also flow aware. This alleviates the bypass traffic p= roblem that occurs when 100% of traffic at some granularity (network, APN, = subscriber) is sent through a sequence of service nodes, as is done in toda= y's topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasse= s non-TCP). Thus, the number of distinct chain sequences is somewhat orth= ogonal to the number of subscribers and is driven by subscriber-aware/flow-= aware policy. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ian Smith Sent: Tuesday, October 15, 2013 4:30 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712914MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My intention was to conve= y subscriber as “Jim who happens to be using an Android.”<= /o:p>

 <= /p>

   Ron

 <= /p>

 <= /p>

From: Jim Gu= ichard (jguichar) [mailto:jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 4:45 PM
To: Ron Parker
Cc: Ian Smith; nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Ron,

 

The granularity of what you describe as "subscr= iber" is important here; one could classify traffic as belonging to su= bscriber "android" or as belonging to "Jim who happens to be= using an Android". The former is a lot less "subscribers" than the latter. In my world I tend to think of the former as the classifi= cation granularity. I certainly would not anticipate building an SFC just f= or the sole use of "Jim" (I'm really not that important ;) ).

Sent from my iPhone


On Oct 15, 2013, at 4:37 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wro= te:

Ian,

 <= /p>

From my perspective, the = vision for the SFC classifier is to not only be subscriber aware, but also = flow aware.   This alleviates the bypass traffic problem that occurs when 100% of traffic at some granularity (network, APN, subscr= iber) is sent through a sequence of service nodes, as is done in today̵= 7;s topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasse= s non-TCP).   Thus, the number of distinct chain sequences is somewhat orthogonal to the number of subscribers and is= driven by subscriber-aware/flow-aware policy.

 <= /p>

   Ron

 <= /p>

 <= /p>

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:30 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

We do that already.

 

I'm talking about giving eac= h /64 their own path from the IP anchor through the VAS LAN to the PE route= r tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just t= aking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fore= gone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 =

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 =

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at least three parental control use cases. How woul= d it be possible to have parental control not being per-subscriber?<= o:p>

Regards,

Behcet=

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712914MBX021W3CA2exch_-- From Ron_Parker@affirmednetworks.com Tue Oct 15 13:51:25 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A57A421F9BAD for ; Tue, 15 Oct 2013 13:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2XUHg+nm+Pf for ; Tue, 15 Oct 2013 13:51:21 -0700 (PDT) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) by ietfa.amsl.com (Postfix) with ESMTP id 7344B21F9A15 for ; Tue, 15 Oct 2013 13:51:16 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 13:51:16 -0700 From: Ron Parker To: Ian Smith , "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczVyp1jgKYkE0WXE6hidxpy5pn2gDYAgAAhkQCAAAqqAIAAAPKAgAAD6YD//4tTMA== Date: Tue, 15 Oct 2013 20:51:15 +0000 Message-ID: References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, , <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, <3BE0905A-FF75-4271-98DD-38981D2FB71C@cisco.com> <419417C345CA5F48BF45F0A23955A0634A70241C@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70241C@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712926MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:51:25 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712926MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I can't argue with that. If chain-id appears on the wire as an (unsigned= ) integer, I'd suggest that it should be 32-bits, at least. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian S= mith Sent: Tuesday, October 15, 2013 4:48 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt yeah. I'm saying we shouldn't assume that isn't going to happen. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 4:33 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt So you are saying each individual client sat on the end of some mobile devi= ce will get their own SFC? Sent from my iPhone On Oct 15, 2013, at 4:30 PM, "Ian Smith" > wrote: We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712926MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I can’t argue with = that.    If chain-id appears on the wire as an (unsigned) in= teger, I’d suggest that it should be 32-bits, at least.

 <= /p>

   Ron

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:48 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

yeah.  I'm saying we sh= ouldn't assume that isn't going to happen.

 

From: Jim Guichard (jguichar) [jgu= ichar@cisco.com]
Sent: Tuesday, October 15, 2013 4:33 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

So you are saying each i= ndividual client sat on the end of some mobile device will get their own SF= C? 

Sent from my iPhone


On Oct 15, 2013, at 4:30 PM, "Ian Smith" <I.Smith@F5.com> wrote:

We do that already.

 

I'm talking about giving eac= h /64 their own path from the IP anchor through the VAS LAN to the PE route= r tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just t= aking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) [jguichar@cisco.com= ]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@= ieee.org; Liushucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fore= gone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 =

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 =

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

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

Regards,

Behcet=

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 =

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712926MBX021W3CA2exch_-- From jguichar@cisco.com Tue Oct 15 13:51:30 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27A9121F9BC1 for ; Tue, 15 Oct 2013 13:51:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.388 X-Spam-Level: X-Spam-Status: No, score=-10.388 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYADR5vEWpbr for ; Tue, 15 Oct 2013 13:51:25 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C594C21F9A43 for ; Tue, 15 Oct 2013 13:51:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29829; q=dns/txt; s=iport; t=1381870284; x=1383079884; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=z6eeY385gUWxP48wQGajhkKjYwvyshw52kKKDfJT1NE=; b=RlE5K6mgAkxAhUu3ylPY69qOeNWWHz+x2fvAAoXCUX+9vKayg8swowGV gkd821CMgGcrVW41wR4dQ1O089b8MUJPaXEbUKeKIz0bRs9pNyo7PahsB WONgqZ1ssWNPkxA0KIEpGb5hZMX1KmY+3DZu7bz8JuPygC28Ja+ghtf7D M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAJqpXVKtJV2a/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBKkEJAgwEAgEIEQMBAQEhBwchBgsUCAEIAgQOBQkSh1kDDwy0DQ2Ja4xcgSyBFQIHEw0EBgEGA4MWgQYDjFOHVIF0gWmBL4YEhRmFNoMk X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="272536814" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 15 Oct 2013 20:51:23 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9FKpN61024365 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 20:51:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 15:51:23 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAF57AIAAAfcA//+uXayAAFToAP//rN3s Date: Tue, 15 Oct 2013 20:51:23 +0000 Message-ID: <71E05E76-FA0C-452B-97C0-BE48B50B8A2E@cisco.com> References: , <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com>, <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70236A@SEAEMBX02.olympus.F5Net.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_71E05E76FA0C452B97C0BE48B50B8A2Eciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "sarikaya@ieee.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:51:30 -0000 --_000_71E05E76FA0C452B97C0BE48B50B8A2Eciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Conveying that classification is different than spinning up individual serv= ice functions into a chain that only my traffic can be forwarded into. Sent from my iPhone On Oct 15, 2013, at 4:49 PM, "Ron Parker" > wrote: My intention was to convey subscriber as =93Jim who happens to be using an = Android.=94 Ron From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] Sent: Tuesday, October 15, 2013 4:45 PM To: Ron Parker Cc: Ian Smith; nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Ron, The granularity of what you describe as "subscriber" is important here; one= could classify traffic as belonging to subscriber "android" or as belongin= g to "Jim who happens to be using an Android". The former is a lot less "su= bscribers" than the latter. In my world I tend to think of the former as th= e classification granularity. I certainly would not anticipate building an = SFC just for the sole use of "Jim" (I'm really not that important ;) ). Sent from my iPhone On Oct 15, 2013, at 4:37 PM, "Ron Parker" > wrote: Ian, >From my perspective, the vision for the SFC classifier is to not only be su= bscriber aware, but also flow aware. This alleviates the bypass traffic p= roblem that occurs when 100% of traffic at some granularity (network, APN, = subscriber) is sent through a sequence of service nodes, as is done in toda= y=92s topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypas= ses non-TCP). Thus, the number of distinct chain sequences is somewhat or= thogonal to the number of subscribers and is driven by subscriber-aware/flo= w-aware policy. Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Ian Smith Sent: Tuesday, October 15, 2013 4:30 PM To: Jim Guichard (jguichar) Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt We do that already. I'm talking about giving each /64 their own path from the IP anchor through= the VAS LAN to the PE router tailored to their individual profile (which t= hey probably have some control over through an app on their phone). The fi= xed is easy and not far removed from giving each student in a dorm their ow= n vlan - something I've seen done in the late 90s. Mobile is a little more= sophisticated, but still achievable if you are automating your provisionin= g system and have an elastic VAS infrastructure. In both cases you are just taking the IaaS model and reversing the flow of = traffic. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 3:52 PM To: Ian Smith Cc: sarikaya@ieee.org; Liushucheng (Will); nsc@ie= tf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_71E05E76FA0C452B97C0BE48B50B8A2Eciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Conveying that classification is different than spinning up individual= service functions into a chain that only my traffic can be forwarded into.=  

Sent from my iPhone

On Oct 15, 2013, at 4:49 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wro= te:

My intention was to conve= y subscriber as =93Jim who happens to be using an Android.=94

 <= /p>

   Ron

 <= /p>

 <= /p>

From: Jim Gu= ichard (jguichar) [mailto:jguichar@ci= sco.com]
Sent: Tuesday, October 15, 2013 4:45 PM
To: Ron Parker
Cc: Ian Smith; nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Ron,

 

The granularity of what you describe as "subscr= iber" is important here; one could classify traffic as belonging to su= bscriber "android" or as belonging to "Jim who happens to be= using an Android". The former is a lot less "subscribers" than the latter. In my world I tend to think of the former as the classifi= cation granularity. I certainly would not anticipate building an SFC just f= or the sole use of "Jim" (I'm really not that important ;) ).

Sent from my iPhone


On Oct 15, 2013, at 4:37 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wro= te:

Ian,

 <= /p>

From my perspective, the = vision for the SFC classifier is to not only be subscriber aware, but also = flow aware.   This alleviates the bypass traffic problem that occurs when 100% of traffic at some granularity (network, APN, subscr= iber) is sent through a sequence of service nodes, as is done in today=92s = topology-based mobile Gi-LAN architectures (i.e., TCP optimizer bypasses no= n-TCP).   Thus, the number of distinct chain sequences is somewhat orthogonal to the number of subscribers and is= driven by subscriber-aware/flow-aware policy.

 <= /p>

   Ron

 <= /p>

 <= /p>

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Ian Smith
Sent: Tuesday, October 15, 2013 4:30 PM
To: Jim Guichard (jguichar)
Cc: nsc@ietf.org; sarikaya@ieee.org; Liushucheng (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

We do that already.

 

I'm talking about giving eac= h /64 their own path from the IP anchor through the VAS LAN to the PE route= r tailored to their individual profile (which they probably have some control over through an app on their phone).  The fixed is = easy and not far removed from giving each student in a dorm their own vlan = - something I've seen done in the late 90s.  Mobile is a little more s= ophisticated, but still achievable if you are automating your provisioning system and have an elastic VAS infrastruc= ture.

 

In both cases you are just t= aking the IaaS model and reversing the flow of traffic.

 

 

 

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 3:52 PM
To: Ian Smith
Cc: sarikaya@ieee.org; Lius= hucheng (Will); nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Hi Ian,

If by subscriber you mea= n per-tenant or per-subscriber-group then I will agree that SFC's will be b= uilt for these but that's a far cry from per-subscriber which implies to me= an individual broadband or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a fore= gone conclusion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely t= hat one would opt for a solution whereby a separate SFC is required per-sub= scriber; clearly millions of SFC's is not desirable no matter how you cut i= t. IMHO, the support of services that require per-subscriber policy are more likely to be realized using somethi= ng like the solution described in draft-quinn-sfc-nsh. 

 =

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 =

Hi Shucheng,

In the use cases draft, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at least three parental control use cases. How woul= d it be possible to have parental control not being per-subscriber?<= o:p>

Regards,

Behcet=

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 =

--_000_71E05E76FA0C452B97C0BE48B50B8A2Eciscocom_-- From Ron_Parker@affirmednetworks.com Tue Oct 15 13:52:53 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0AB21F9BC1 for ; Tue, 15 Oct 2013 13:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+En3gJPEJwS for ; Tue, 15 Oct 2013 13:52:48 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id A418821F9B86 for ; Tue, 15 Oct 2013 13:52:48 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0123.003; Tue, 15 Oct 2013 13:52:47 -0700 From: Ron Parker To: "Jim Guichard (jguichar)" , "" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyefa7wC2gzsb6kCeq8L77Iqab5n2PNuA Date: Tue, 15 Oct 2013 20:52:46 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> In-Reply-To: <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712946MBX021W3CA2exch_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 20:52:53 -0000 --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712946MBX021W3CA2exch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712946MBX021W3CA2exch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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

 <= /p>

   Ron

 <= /p>

From: nsc-bo= unces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, October 15, 2013 4:48 PM
To: <sarikaya@ieee.org>
Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone


On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclus= ion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

 

--_000_CDF2F015F4429F458815ED2A6C2B6B0B1A712946MBX021W3CA2exch_-- From jguichar@cisco.com Tue Oct 15 14:02:54 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1926021F9D1C for ; Tue, 15 Oct 2013 14:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efbZSOxYDa5a for ; Tue, 15 Oct 2013 14:02:49 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0355F21F9D7A for ; Tue, 15 Oct 2013 14:02:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22071; q=dns/txt; s=iport; t=1381870969; x=1383080569; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=RwtiSQQiehlVs6clxqEjPUriSyDMfGTa+y10hCcDBWU=; b=Bpzxo3WZYlpjFnpsIE+Oa1TDlaHn2sSH8J5pK+ZinKHtKvq89GLj6CbQ nazPKzwJ+BWWFUff7duKD0J/P2i8T2/GNH7/0P/YEBP+X5NPNwXsfLTCw c2fxA6Nbkm4y60vPDxXJkKOMpTfZKOXNM14fg6iQS4199JZi5OGZ5ZHfR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAN+sXVKtJXHB/2dsb2JhbABRCYJDRDiwTYlkiEuBJRZ0giUBAQEEAQEBKkEJAgwEAgEIEQMBAQEoByEGCxQIAQgCBA4FCRKHWQMPDLN9DYlrjFyBLIEVAgcTDQQGAQYDgxaBBgOUJ4F0gWmBL4sdhTaDJA X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="269517624" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 15 Oct 2013 21:02:48 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9FL2mZk002190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 21:02:48 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 16:02:47 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAGKsAP//rOyMgABVMQD//676DA== Date: Tue, 15 Oct 2013 21:02:47 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D72D4692797D421D910145B22D194E9Dciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "" , "Liushucheng \(Will\)" , Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:02:54 -0000 --_000_D72D4692797D421D910145B22D194E9Dciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_D72D4692797D421D910145B22D194E9Dciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Sure but we should deal in reality driven by use cases and I have yet = to see anyone suggest they will build an individual service chain for every= client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetworks.com> wro= te:

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

 <= /p>

   Ron

 <= /p>

From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim Guichard (jguichar)
Sent: Tuesday, October 15, 2013 4:48 PM
To: <sarikaya@ieee.org&g= t;
Cc: nsc@ietf.org; Liushucheng (W= ill); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone


On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclus= ion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

 

--_000_D72D4692797D421D910145B22D194E9Dciscocom_-- From I.Smith@F5.com Tue Oct 15 14:11:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D97121F9F20 for ; Tue, 15 Oct 2013 14:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zmiPesGcOT9 for ; Tue, 15 Oct 2013 14:11:24 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7E21F9F3D for ; Tue, 15 Oct 2013 14:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381871484; x=1413407484; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vwJoz4ToN+OAlJBKplbaO7e4MJnjy2ClnXD4oe2jo6M=; b=EPWvmoWg7GWi8l8Emkb6qsiKZN8dbAR5jra/sYq6BOaZ4k0uBlBq/c4X hT6moS2M9+Dq7FJD5Cs1wKiSIl9Ycp6OQKqt42Btqv7ORKT7cHXqMaKeQ CP64deYgSYsWj9vZaGRcQUrJYD95mp6qn0ACsnWVshMcs0/nQSFAIzKRx o=; X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="83594079" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 21:11:22 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 14:11:22 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" , Ron Parker Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiYgACbHwCAAA7bAIAAAL4AgAABXwCAAALMgP//iuyc Date: Tue, 15 Oct 2013 21:11:21 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A7024E4SEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "" , "Liushucheng \(Will\)" Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:11:28 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A7024E4SEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: ; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A7024E4SEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
what do you need to make this reality driven? 
From: Jim Guichard (jguichar) [jguichar= @cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarikaya@ieee.org>; nsc@ietf.org; Liushucheng (Will); Ian= Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cases and I have yet = to see anyone suggest they will build an individual service chain for every= client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typic= al usage of policy.   And, the degenerate case is that the world = is comprised of subscriber groups that have exactly 1 subscriber. &nbs= p; Probably not practical, but why prevent it?

 

   Ron=

 

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclu= sion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

 

--_000_419417C345CA5F48BF45F0A23955A0634A7024E4SEAEMBX02olympu_-- From jguichar@cisco.com Tue Oct 15 14:14:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC0421F9FAE for ; Tue, 15 Oct 2013 14:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.315 X-Spam-Level: X-Spam-Status: No, score=-10.315 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GytGnI2KzMKc for ; Tue, 15 Oct 2013 14:14:24 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA321F9FA3 for ; Tue, 15 Oct 2013 14:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23087; q=dns/txt; s=iport; t=1381871663; x=1383081263; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dx5hgCaZqAgFtYpIB6FALFZp0LQidQpAnFdUhwuLMAw=; b=c8VdPY12lcw9H7q59CvCW1tOu9gnRqpuiNBw8/56CRlx7W7bgDK69+TG cqnCGuAMeraZ/h5PIZfXApYO2fYBVvha8QvdbAMCzuf63VcrCwPUmt5qc 1dSjnhG4chX0R2RpqIR4UpOYSGOUCGZ0rhVVlwhrXYQZnTbCRts442WaW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au8FAHOvXVKtJXG9/2dsb2JhbABRCYJDRDiwTYlkiEuBJhZ0giUBAQEEAQEBawkCDAQCAQgOAwMBAQEoByEGCxQIAQgCBA4FCRKHWQMPDLQBDYlrjFyBLIEXGg0EBgEGA4MWgQYDlCeBdIFpgS+LHYU2gyQ X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="272325191" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2013 21:14:23 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9FLEMUZ030809 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Oct 2013 21:14:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 15 Oct 2013 16:14:22 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOyczMYlaZYduwC0uCge6agZJESpn2Xq8A///NwIyAAGKsAP//rOyMgABVMQD//676DAAKxvKA//+tBew= Date: Tue, 15 Oct 2013 21:14:21 +0000 Message-ID: <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com>, , , <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7B83A934C36C4538A2746146E03C4A5Eciscocom_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "" , "Liushucheng \(Will\)" , Ron Parker Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:14:29 -0000 --_000_7B83A934C36C4538A2746146E03C4A5Eciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Use cases from real operators would be a start. Sent from my iPhone On Oct 15, 2013, at 5:11 PM, "Ian Smith" > wrote: what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: >; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_7B83A934C36C4538A2746146E03C4A5Eciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Use cases from real operators would be a start.

Sent from my iPhone

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

what do you need to make this reality driven? 
From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarikaya@ieee.org&g= t;; nsc@ietf.org; Liushucheng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cases and I have yet = to see anyone suggest they will build an individual service chain for every= client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typic= al usage of policy.   And, the degenerate case is that the world = is comprised of subscriber groups that have exactly 1 subscriber. &nbs= p; Probably not practical, but why prevent it?

 

   Ron=

 

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclu= sion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

 

--_000_7B83A934C36C4538A2746146E03C4A5Eciscocom_-- From I.Smith@F5.com Tue Oct 15 14:15:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9973921F9F4F for ; Tue, 15 Oct 2013 14:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.283 X-Spam-Level: X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYlXBjulfpOk for ; Tue, 15 Oct 2013 14:15:22 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id B375C21F9D94 for ; Tue, 15 Oct 2013 14:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1381871718; x=1413407718; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bU6qvzp4lc0fKxeMM3+lRANhZ3uCqdD/ZQtbv13KvBk=; b=uQaHGj2ThkmSbQcCu5Ay8dcwK19Ip3WbgGDluXxVsblRrjDPuiuZoLz8 AyD+CZK2Ps+gCnI9sdMEZvCEd+YL5PuPcK5/YCdDPGbSbWnXdjVE77b3l +nxt2FYmqax9JzZN6PfTb1a5uUKWoeaJ/Wbk/XjQUllaV3U31PgRPXOow A=; X-IronPort-AV: E=Sophos;i="4.93,502,1378857600"; d="scan'208,217";a="83594429" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 15 Oct 2013 21:14:57 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Tue, 15 Oct 2013 14:14:57 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt Thread-Index: AQHOycziRnUMCqM8tku411pgr5Pcvpn2BqiYgACbHwCAAA7bAIAAAL4AgAABXwCAAALMgP//iuycgAB4UID//4q8lA== Date: Tue, 15 Oct 2013 21:14:56 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> , <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com>, , , <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com>, <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> In-Reply-To: <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: multipart/alternative; boundary="_000_419417C345CA5F48BF45F0A23955A0634A702507SEAEMBX02olympu_" MIME-Version: 1.0 Cc: "nsc@ietf.org" , "" , "Liushucheng \(Will\)" , Ron Parker Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 21:15:37 -0000 --_000_419417C345CA5F48BF45F0A23955A0634A702507SEAEMBX02olympu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'll see what I can do. ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:14 PM To: Ian Smith Cc: Ron Parker; ; nsc@ietf.org; Liushucheng (Will) Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Use cases from real operators would be a start. Sent from my iPhone On Oct 15, 2013, at 5:11 PM, "Ian Smith" > wrote: what do you need to make this reality driven? ________________________________ From: Jim Guichard (jguichar) [jguichar@cisco.com] Sent: Tuesday, October 15, 2013 5:02 PM To: Ron Parker Cc: >; nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Sure but we should deal in reality driven by use cases and I have yet to se= e anyone suggest they will build an individual service chain for every clie= nt. In fact the complete opposite seems true. Sent from my iPhone On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: Agree that is the typical usage of policy. And, the degenerate case is th= at the world is comprised of subscriber groups that have exactly 1 subscrib= er. Probably not practical, but why prevent it? Ron From: nsc-bounces@ietf.org [mailto:nsc-bounces= @ietf.org] On Behalf Of Jim Guichard (jguichar) Sent: Tuesday, October 15, 2013 4:48 PM To: > Cc: nsc@ietf.org; Liushucheng (Will); Ian Smith Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt No, to me this is most certainly a per-subscriber-group. Sent from my iPhone On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: I was talking about something like parental control. Do you qualify such an SFC as each mobile client getting its own SFC? I think it is more like per-subscriber-group. It could be per subscriber as= well but I can not think of an example at this moment. On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) > wrote: Hi Ian, If by subscriber you mean per-tenant or per-subscriber-group then I will ag= ree that SFC's will be built for these but that's a far cry from per-subscr= iber which implies to me an individual broadband or mobile client. Sent from my iPhone On Oct 15, 2013, at 1:51 PM, "Ian Smith" > wrote: I don't think that is a foregone conclusion. When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that = you're trying to solve with service chains. More to the point, you don't n= eed to disaggregate anything when you know that all the traffic belongs to = a single customer, and that the default gateway of each node is the next ho= p in the service chain. Solving the problem for 1 subscriber@1Gbps is triv= ial; what makes what we're talking about in this list hard is that you are = trying to solve it for 10 million subscribers @100Gbps but in truth the onl= y technology-based reason you do that is because of administrative challeng= es that the cloud world is solving (and may have solved before anything is = produced in a WG) and that are squarely in the domain of things already pro= ven to be better done by computers than people. I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today. ________________________________ From: nsc-bounces@ietf.org [nsc-bounces@ietf.o= rg] on behalf of Jim Guichard (jguichar) [jgui= char@cisco.com] Sent: Tuesday, October 15, 2013 1:34 PM To: sarikaya@ieee.org; Liushucheng (Will) Cc: nsc@ietf.org Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt It seems very unlikely that one would opt for a solution whereby a separate= SFC is required per-subscriber; clearly millions of SFC's is not desirable= no matter how you cut it. IMHO, the support of services that require per-s= ubscriber policy are more likely to be realized using something like the so= lution described in draft-quinn-sfc-nsh. From: Behcet Sarikaya > Reply-To: "sarikaya@ieee.org" > Date: Tuesday, October 15, 2013 11:44 AM To: "Liushucheng (Will)" > Cc: "nsc@ietf.org" > Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases= -00.txt Hi Shucheng, In the use cases draft, you say that SFC are not per-subscriber. In other words, this document assumes per-subscriber SFCs are not instantiated in the network. Deployments cases that would require per-subscriber SFCs are out of scope. However you have at least three parental control use cases. How would it be= possible to have parental control not being per-subscriber? Regards, Behcet On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) > wrote: Folks, We've uploaded the updated and renamed use case draft. Looking forward to y= our comments. Regards, Shucheng LIU (Will) -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Thursday, October 10, 2013 3:42 PM To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt A new version of I-D, draft-liu-sfc-use-cases-00.txt has been successfully submitted by Will(Shucheng) Liu and posted to the IETF repository. Filename: draft-liu-sfc-use-cases Revision: 00 Title: Service Function Chaining Use Cases Creation date: 2013-10-10 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-liu-sfc-use-case= s-00.txt Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 Abstract: The delivery of value-added services relies on the invocation of advanced Service Functions in a sequential order. This mechanism is called Service Function Chaining (SFC). The set of involved Service Functions and their order depends on the service context. This document presents a set of use cases of Service Function Chaining (SFC). Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc --_000_419417C345CA5F48BF45F0A23955A0634A702507SEAEMBX02olympu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'll see what I can do.

From: Jim Guichard (jguichar) [jguichar= @cisco.com]
Sent: Tuesday, October 15, 2013 5:14 PM
To: Ian Smith
Cc: Ron Parker; <sarikaya@ieee.org>; nsc@ietf.org; Liushucheng= (Will)
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Use cases from real operators would be a start.

Sent from my iPhone

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

what do you need to make this reality driven? 
From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarik= aya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cases and I have yet = to see anyone suggest they will build an individual service chain for every= client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typic= al usage of policy.   And, the degenerate case is that the world = is comprised of subscriber groups that have exactly 1 subscriber. &nbs= p; Probably not practical, but why prevent it?

 

   Ron=

 

 

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone

 I was talking about something like parental co= ntrol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

 

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that's a = far cry from per-subscriber which implies to me an individual broadband or = mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone conclu= sion. 

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with servic= e chains.  More to the point, you don't need to disaggregate anything = when you know that all the traffic belongs to a single customer, and that t= he default gateway of each node is the next hop in the service chain.  Solving the problem for 1 subscriber@= 1Gbps is trivial; what makes what we're talking about in this list hard is = that you are trying to solve it for 10 million subscribers @100Gbps but in = truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

 

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of serv= ices that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh. 

 

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

 

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.  In other words, this document assumes
      per-subscriber SFCs are not instantiated in = the network.
      Deployments cases that would require per-sub= scriber SFCs are out
      of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

 

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

Folks,

We've uploaded the updated and renamed use case draft. Looking forward to y= our comments.

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename:        draft-liu-sfc-use-cases
Revision:        00
Title:           Service Function Chaining Use Cas= es
Creation date:   2013-10-10
Group:           Individual Submission
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status:          http://datatracker.iet= f.org/doc/draft-liu-sfc-use-cases
Htmlized:        http://tools.ietf.org/html/dr= aft-liu-sfc-use-cases-00


Abstract:
   The delivery of value-added services relies on the invocation = of
   advanced Service Functions in a sequential order.  This m= echanism is
   called Service Function Chaining (SFC).  The set of invol= ved Service
   Functions and their order depends on the service context.

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




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

The IETF Secretariat

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

 

 

--_000_419417C345CA5F48BF45F0A23955A0634A702507SEAEMBX02olympu_-- From sarikaya2012@gmail.com Tue Oct 15 15:11:08 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383FF21F8447 for ; Tue, 15 Oct 2013 15:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.875 X-Spam-Level: X-Spam-Status: No, score=-1.875 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQyCT-UjMLCZ for ; Tue, 15 Oct 2013 15:11:07 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2EC21F9B10 for ; Tue, 15 Oct 2013 15:11:04 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id hp15so3279050lab.24 for ; Tue, 15 Oct 2013 15:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5BIzw93bCav4LhgupAv9tpNwygAdupY2k7m8NowFrvw=; b=pumVdp0uJHePitoKdDkpNAuIEOew4bJlzYQyHzuXp9HUe6IxkyiOMnJYQ2lWn3nstm jCoto+8iqjLs6zmA7HRRNFvkEq5SrpYz+NzuAXQC6qvVY1qJsLiLcB3knf7gpJHxigUA cvcNWZq7p5NnxBhQG2GoteJOyvf07NI6fexv/wwltp3aW9dOje6H08C7VjiydU44QfaK NlfOkOTLQnzP+RKdlRQn/ZKccoQKqJw8t6zEKpnUcgjObEMAwb/Z8TqIN2cuDmfFapoX nBzYEa40+EakTwN3sukgj/BN+6lYcwSyopKZBp1YvftNfgemw21Cfb1tQoz/dIVxCASz uwTQ== MIME-Version: 1.0 X-Received: by 10.112.77.134 with SMTP id s6mr104943lbw.38.1381875063949; Tue, 15 Oct 2013 15:11:03 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Tue, 15 Oct 2013 15:11:03 -0700 (PDT) In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> References: <68B171751455884590F8E38E96416F363F6F0E5D@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A7020F0@SEAEMBX02.olympus.F5Net.com> <791251A6-CA0A-424C-83DB-7EF34BD2D738@cisco.com> <419417C345CA5F48BF45F0A23955A0634A7024E4@SEAEMBX02.olympus.F5Net.com> <7B83A934-C36C-4538-A274-6146E03C4A5E@cisco.com> <419417C345CA5F48BF45F0A23955A0634A702507@SEAEMBX02.olympus.F5Net.com> Date: Tue, 15 Oct 2013 17:11:03 -0500 Message-ID: From: Behcet Sarikaya To: Ian Smith Content-Type: multipart/alternative; boundary=001a11c3dfba4f8f6c04e8cedc29 Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" , "Liushucheng \(Will\)" , Ron Parker Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-use-cases-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:11:08 -0000 --001a11c3dfba4f8f6c04e8cedc29 Content-Type: text/plain; charset=ISO-8859-1 Folks, I checked and found out that in the requirements draft per-subscriber service issue is pretty clearly stated. My suggestion is to remove the paragraph that starts with SFC are not per-subscriber. It is confusing. Regards, Behcet On Tue, Oct 15, 2013 at 4:14 PM, Ian Smith wrote: > I'll see what I can do. > > ------------------------------ > *From:* Jim Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 5:14 PM > *To:* Ian Smith > *Cc:* Ron Parker; ; nsc@ietf.org; Liushucheng (Will) > > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > Use cases from real operators would be a start. > > Sent from my iPhone > > On Oct 15, 2013, at 5:11 PM, "Ian Smith" wrote: > > what do you need to make this reality driven? > ------------------------------ > *From:* Jim Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 5:02 PM > *To:* Ron Parker > *Cc:* ; nsc@ietf.org; Liushucheng (Will); Ian Smith > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > Sure but we should deal in reality driven by use cases and I have yet > to see anyone suggest they will build an individual service chain for every > client. In fact the complete opposite seems true. > > Sent from my iPhone > > On Oct 15, 2013, at 4:52 PM, "Ron Parker" > wrote: > > Agree that is the typical usage of policy. And, the degenerate case > is that the world is comprised of subscriber groups that have exactly 1 > subscriber. Probably not practical, but why prevent it? > > > > Ron > > > > *From:* nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] > *On Behalf Of *Jim Guichard (jguichar) > *Sent:* Tuesday, October 15, 2013 4:48 PM > *To:* > *Cc:* nsc@ietf.org; Liushucheng (Will); Ian Smith > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > No, to me this is most certainly a per-subscriber-group. > > Sent from my iPhone > > > On Oct 15, 2013, at 4:45 PM, "Behcet Sarikaya" > wrote: > > I was talking about something like parental control. > > Do you qualify such an SFC as each mobile client getting its own SFC? > > I think it is more like per-subscriber-group. It could be per subscriber > as well but I can not think of an example at this moment. > > > > On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguichar) < > jguichar@cisco.com> wrote: > > Hi Ian, > > If by subscriber you mean per-tenant or per-subscriber-group then I will > agree that SFC's will be built for these but that's a far cry from > per-subscriber which implies to me an individual broadband or mobile client. > > Sent from my iPhone > > > On Oct 15, 2013, at 1:51 PM, "Ian Smith" wrote: > > I don't think that is a foregone conclusion. > > When you combine what is being done in IaaS environments for muti-tenant > dynamic datacenters with what you can do with policy defined networking and > IPv6, for an access provider to provision per-subscriber VAS LANs and > default gateways takes away a lot of the big problems caused by aggregation > that you're trying to solve with service chains. More to the point, you > don't need to disaggregate anything when you know that all the traffic > belongs to a single customer, and that the default gateway of each node is > the next hop in the service chain. Solving the problem for 1 > subscriber@1Gbps is trivial; what makes what we're talking about in this > list hard is that you are trying to solve it for 10 million subscribers > @100Gbps but in truth the only technology-based reason you do that is > because of administrative challenges that the cloud world is solving (and > may have solved before anything is produced in a WG) and that are squarely > in the domain of things already proven to be better done by computers than > people. > > I tend to argue that per-subscriber provisioning of the access path > triggered by identity-based authentication is the obvious and natural > evolution of the technology being fielded today. > > > ------------------------------ > > *From:* nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Jim > Guichard (jguichar) [jguichar@cisco.com] > *Sent:* Tuesday, October 15, 2013 1:34 PM > *To:* sarikaya@ieee.org; Liushucheng (Will) > *Cc:* nsc@ietf.org > *Subject:* Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > It seems very unlikely that one would opt for a solution whereby a > separate SFC is required per-subscriber; clearly millions of SFC's is not > desirable no matter how you cut it. IMHO, the support of services that > require per-subscriber policy are more likely to be realized using > something like the solution described in draft-quinn-sfc-nsh. > > > > *From: *Behcet Sarikaya > *Reply-To: *"sarikaya@ieee.org" > *Date: *Tuesday, October 15, 2013 11:44 AM > *To: *"Liushucheng (Will)" > *Cc: *"nsc@ietf.org" > *Subject: *Re: [nsc] FW: New Version Notification for > draft-liu-sfc-use-cases-00.txt > > > > Hi Shucheng, > > In the use cases draft, you say that > > SFC are not per-subscriber. In other words, this document assumes > per-subscriber SFCs are not instantiated in the network. > Deployments cases that would require per-subscriber SFCs are out > of scope. > > However you have at least three parental control use cases. How would it > be possible to have parental control not being per-subscriber? > > Regards, > > Behcet > > > > On Fri, Oct 11, 2013 at 1:13 AM, Liushucheng (Will) < > liushucheng@huawei.com> wrote: > > Folks, > > We've uploaded the updated and renamed use case draft. Looking forward to > your comments. > > Regards, > Shucheng LIU (Will) > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Thursday, October 10, 2013 3:42 PM > To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); > Mohamed Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao > Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt > > > A new version of I-D, draft-liu-sfc-use-cases-00.txt > has been successfully submitted by Will(Shucheng) Liu and posted to the > IETF repository. > > Filename: draft-liu-sfc-use-cases > Revision: 00 > Title: Service Function Chaining Use Cases > Creation date: 2013-10-10 > Group: Individual Submission > Number of pages: 14 > URL: > http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt > Status: http://datatracker.ietf.org/doc/draft-liu-sfc-use-cases > Htmlized: http://tools.ietf.org/html/draft-liu-sfc-use-cases-00 > > > Abstract: > The delivery of value-added services relies on the invocation of > advanced Service Functions in a sequential order. This mechanism is > called Service Function Chaining (SFC). The set of involved Service > Functions and their order depends on the service context. > > This document presents a set of use cases of Service Function > Chaining (SFC). > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > > > > > > --001a11c3dfba4f8f6c04e8cedc29 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Folks, I checked and found out that in the = requirements draft per-subscriber service issue is pretty clearly stated.
My suggestion is to remove the paragraph that starts with SFC a= re not per-subscriber. It is confusing.

Regards,

Behcet
=

On Tue, Oct 15, 2013 at 4:14 PM, Ian Smi= th <I.Smith@f5.com> wrote:
I'll see= what I can do.

From: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 5:14 PM
To: Ian Smith
Cc: Ron Parker; <sarikaya@ieee.org>; nsc@ietf.org; Liushucheng (Will)

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

Use cases from real operators would be a start.

Sent from my iPhone

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

what do you = need to make this reality driven?=A0
Fro= m: Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 5:02 PM
To: Ron Parker
Cc: <sarik= aya@ieee.org>; nsc@ietf.org; Liushuc= heng (Will); Ian Smith
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

Sure but we should deal in reality driven by use cases and I have yet = to see anyone suggest they will build an individual service chain for every= client. In fact the complete opposite seems true.

Sent from my iPhone

On Oct 15, 2013, at 4:52 PM, "Ron Parker" <Ron_Parker@affirmednetwor= ks.com> wrote:

Agree that is the typical= usage of policy.=A0=A0 And, the degenerate case is that the world is compr= ised of subscriber groups that have exactly 1 subscriber.=A0=A0 Probably not practical, but why prevent it?

=A0

=A0=A0 Ron

=A0

=A0

No, to me this is most certainly a per-subscriber-gr= oup.

Sent from my iPhone

=A0I was talking about something like parental contr= ol.

Do you qualify such a= n SFC as each mobile client getting its own SFC?

I think it is more li= ke per-subscriber-group. It could be per subscriber as well but I can not t= hink of an example at this moment.

=A0

On Tue, Oct 15, 2013 at 2:52 PM, Jim Guichard (jguic= har) <jguichar@c= isco.com> wrote:

Hi Ian,

If by subscriber you mean per-tenant or per-subscrib= er-group then I will agree that SFC's will be built for these but that&= #39;s a far cry from per-subscriber which implies to me an individual broad= band or mobile client.

Sent from my iPhone


On Oct 15, 2013, at 1:51 PM, "Ian Smith" <I.Smith@F5.com> wrote:

I don't think that is a foregone con= clusion.=A0

When you combine what is being done in IaaS environments for muti-tenant dy= namic datacenters with what you can do with policy defined networking and I= Pv6, for an access provider to provision per-subscriber VAS LANs and defaul= t gateways takes away a lot of the big problems caused by aggregation that you're trying to solve with se= rvice chains.=A0 More to the point, you don't need to disaggregate anyt= hing when you know that all the traffic belongs to a single customer, and t= hat the default gateway of each node is the next hop in the service chain.=A0 Solving the problem for 1 subscriber@1Gb= ps is trivial; what makes what we're talking about in this list hard is= that you are trying to solve it for 10 million subscribers @100Gbps but in= truth the only technology-based reason you do that is because of administrative challenges that the cloud world i= s solving (and may have solved before anything is produced in a WG) and tha= t are squarely in the domain of things already proven to be better done by = computers than people.

I tend to argue that per-subscriber provisioning of the access path trigger= ed by identity-based authentication is the obvious and natural evolution of= the technology being fielded today.

=A0

From: nsc-bounces@ietf.= org [nsc-boun= ces@ietf.org] on behalf of Jim Guichard (jguichar) [jguichar@cisco.com]
Sent: Tuesday, October 15, 2013 1:34 PM
To: sarikaya@= ieee.org; Liushucheng (Will)
Cc: nsc@ietf.org
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

It seems very unlikely that one would opt for a solu= tion whereby a separate SFC is required per-subscriber; clearly millions of= SFC's is not desirable no matter how you cut it. IMHO, the support of = services that require per-subscriber policy are more likely to be realized using something like the solution described= in draft-quinn-sfc-nsh.=A0

=A0

From: Behcet Sarikaya <sarikaya2012@gmail.com>
Reply-To: "sarikaya@ieee.org" <sarikaya@ieee.org>
Date: Tuesday, October 15, 2013 11:44 AM
To: "Liushucheng (Will)" <liushucheng@huawei.com>
Cc: "nsc@ietf= .org" <nsc@ie= tf.org>
Subject: Re: [nsc] FW: New Version Notification for draft-liu-sfc-us= e-cases-00.txt

=A0

Hi Shucheng,

In the use cases draf= t, you say that

SFC are not per-subscriber.=A0 In other words, this document assumes
=A0=A0=A0=A0=A0 per-subscriber SFCs are not instantiated in the network. =A0=A0=A0=A0=A0 Deployments cases that would require per-subscriber SFCs ar= e out
=A0=A0=A0=A0=A0 of scope.

However you have at l= east three parental control use cases. How would it be possible to have par= ental control not being per-subscriber?

Regards,

Behcet

=A0

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

Folks,

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

Regards,
Shucheng LIU (Will)


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Thursday, October 10, 2013 3:42 PM
To: Liushucheng (Will); Jie Hu; Hongyu Li (Julio); Huangyong (Oliver); Moha= med Boucadair; Liushucheng (Will); Nicolai Leymann; Zhen Cao
Subject: New Version Notification for draft-liu-sfc-use-cases-00.txt


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

Filename: =A0 =A0 =A0 =A0draft-liu-sfc-use-cases
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Service Function Chaining Use Cases
Creation date: =A0 2013-10-10
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 14
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-liu-sfc-use-cases-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -liu-sfc-use-cases
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-liu-sfc-= use-cases-00


Abstract:
=A0 =A0The delivery of value-added services relies on the invocation of
=A0 =A0advanced Service Functions in a sequential order. =A0This mechanism = is
=A0 =A0called Service Function Chaining (SFC). =A0The set of involved Servi= ce
=A0 =A0Functions and their order depends on the service context.

=A0 =A0This document presents a set of use cases of Service Function
=A0 =A0Chaining (SFC).




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

The IETF Secretariat

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

=A0

=A0


--001a11c3dfba4f8f6c04e8cedc29-- From diego@tid.es Tue Oct 15 17:08:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF7211E8232 for ; Tue, 15 Oct 2013 17:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7k4MNEYxDCcK for ; Tue, 15 Oct 2013 17:08:44 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id AE38D11E822E for ; Tue, 15 Oct 2013 17:08:41 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MUQ00MWDJ2GUS@tid.hi.inet> for nsc@ietf.org; Wed, 16 Oct 2013 02:08:40 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3A.4C.28420.809DD525; Wed, 16 Oct 2013 02:08:40 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MUQ00MW4J2FUS@tid.hi.inet> for nsc@ietf.org; Wed, 16 Oct 2013 02:08:40 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS7-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Wed, 16 Oct 2013 02:08:39 +0200 Date: Wed, 16 Oct 2013 00:08:37 +0000 From: "Diego R. Lopez" In-reply-to: <68B171751455884590F8E38E96416F363F6EC397@xmb-rcd-x01.cisco.com> X-Originating-IP: [10.95.64.115] To: "Jim Guichard (jguichar)" Message-id: <8C64B37E-2CB6-4564-A8A0-C3EFE8602656@tid.es> Content-id: <9429E56301AC7842BAA2418C8ACBC43F@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: inter-domain case (was RE: [nsc] Service chaining architecture question) Thread-index: Ac6MNppeZnTEQQ6wR1W9crOC8t9qJA8tJGMAABKQRwAAL2rJAA== X-AuditID: 0a5f4e69-b7fe58e000006f04-e4-525dd9080cc6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhivcz1OW4GRtk0Duf1+L4vv1sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKmPNtJXtBl0HFzSfX2RoYn6l1MXJwSAiYSKx6pNHFyAlkiklc uLeerYuRi0NIYDujxO9D2xkhnO+MEnfe/WCGcGYySsw6NpMNpIVFQFWi8UYDE4jNBmQ/av7N DmILC4RLnHl8H6yGU8BXYuasiawQKxQk/px7zAJiiwgYSXRfeg8WZxaYyCyx7GAOiM0rYCmx 8kgzM0TcTOLwnOlsEHFBiR+T77FAxHUker9/g6oRl2huvQkV15Z48u4C2ExGAVmJd/Pns0Ls ipBY9309lO0k8fHFVmaIewQkluw5D2WLSrx8/A+sRkjAR+L7x8mME4BeRXLGLCRnzEJyxiwk Z8xCcsYCRtZVjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxghcZe5g3H5TpVDjAIcjEo8vOej YoOEWBPLiitzDzFKcDArifDynwYK8aYkVlalFuXHF5XmpBYfYmTi4JRqYMyR+DnB+5dcY8yL +lu3tBI3XA37vmup3lW5F4pq73RLDjXMdDnwJP5Ik8mh/+5LJxx6bTTvStbDFy7fbqRrTN39 avOByGmCx3XPiMWYlXxY9Pf4x0MTDzfs+eGq53Tc4JfnDpsPstzVnmGWzd13f6vlpv7Rl22p CF/b1ugn85D5hd3fUovQBHElluKMREMt5qLiRABx7+W2mQIAAA== References: <68B171751455884590F8E38E96416F363F6EC397@xmb-rcd-x01.cisco.com> Cc: "nsc@ietf.org" , "Carlos Pignataro \(cpignata\)" , "NAPIERALA, MARIA H" , Linda Dunbar , "Paul Quinn \(paulq\)" , Ron Parker , "Joel M. Halpern" , " " Subject: Re: [nsc] inter-domain case (was RE: Service chaining architecture question) X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 00:08:48 -0000 Hi Jim, This situation you describe is precisely what I had in mind when mentioning= what can (or I'd say "will") happen even within a single provider. And, ye= s, the need for exchanging of information between domains was what made me = think about getting back to this, looking at a few slides from Christian on= the edge nodes removing any SFC headers. Be goode, On 15 Oct 2013, at 00:30 , Jim Guichard (jguichar) wrote: > Hi Diego, > > Is it fair to say, at least theoretically, that services might extend fro= m > the WAN edge into the DC, and in that case the WAN and DC *may* be > separately managed, and therefore by definition the service becomes an > inter-domain chain? Further, in order to setup such a chain a subset of > information needs to be exchanged between the two; this need not be a ful= l > policy exchange but rather an aggregate of availability. > > On 10/14/13 6:09 PM, "Diego R. Lopez" wrote: > >> Hi, >> >> I know this reply comes very very late. I left this message (and >> everything around SFC) to deal with it after my holidays in August, and = I >> am afraid I found an enormous pile of urgent matters to deal with. I >> thought the whole inter-domain issue outdated, but the recent message >> from Christian has brought it back to my mind. And I think I have to mak= e >> my case for inter-domain chaining. Some replies inlined below... >> >> On 29 Jul 2013, at 10:35 , wrote: >> >>> Hi Diego, >>> >>> Thank you for the answer. I still don't understand well the >>> inter-domain use case you are referring to and why this is a >>> requirements. In order to understand better the case and to make sure >>> there is no terminology confusion, below some questions for you: >>> >>> * Do you have two administrative entities involved in your case? >> >> DRL> Yes. Without leaving our corporate group, very often what you have >> are several companies (with different management obligations and >> administratively independent) cooperating to provide a certain E2E >> service. Today this is achieved by direct human coordination and complet= e >> functional (and even physical) separation. If you can dynamically chain >> services this would translate into much agile and elastic provision and >> operation. And I don't see why this would not involve in the near future >> completely independent companies providing coordinated services by means >> of collaboration agreements. >> >>> * Are both domains managed by one single administrative entity? >> >> DRL> As I said, even in the cases that I see in our group's environment, >> that's not the case. To give you an example, we have separate companies >> for the basic network services (and therefore network firewalling) and >> content distribution platforms (and therefore content caching and the >> like) >> >>> * Who decide on the inter-domain function chains? >> >> DRL> That would be part of the collaboration agreement: you can go from = a >> very loose arrangement (in which you expose only your ingress and egress >> service points) to a tight integration, with a coordinated element takin= g >> care of everything, where the coordination can be made by a trusted thir= d >> party (a federation operator), by one of the parties (a subordinated >> relationship) or by means of particular SLAs (a SFaaS, we could say) >> >>> * Who is responsible for ensuring the overall consistency? >> >> DRL> Again, that would be part of the collaboration agreement, and you'l= l >> have similar options. >> >>> * Why the chaining policies are to be exposed to an external domain? >>> Why each domain need to reveal its intra policies with regards to the >>> way a network is engineered? >> >> DRL> You don't need to expose *all* your policies (as you don't expose >> *all* your topology) but just the relevant information for the >> collaboration to take place. Again different models, from pure P2P >> exchange to a centralized clearinghouse, can be applied. >> >>> * Why not each of the domain enforces its policies without requiring >>> any involvement of functions located in another external domain? >> >> DRL> Because having some knowledge of what and how can be applied by the >> other domain can help both domains in providing a better service to thei= r >> end users, optimize their infrastructure, and address additional busines= s >> models. >> >>> * Why chaining will modify the way networks managed by two distinct >>> administrative entities will be interconnected? >> >> DRL>I don't think this would change the ways they interconnect, but the >> way they build services, announce them, account for them, and apply >> control on service function chaining. >> >> Be goode, >> >> -- >> "Esta vez no fallaremos, Doctor Infierno" >> >> Dr Diego R. Lopez >> Telefonica I+D >> http://people.tid.es/diego.lopez/ >> >> e-mail: diego@tid.es >> Tel: +34 913 129 041 >> Mobile: +34 682 051 091 >> ----------------------------------------- >> >> >> ________________________________ >> >> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar >> nuestra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en e= l enlace >> situado m=E1s abajo. >> This message is intended exclusively for its addressee. We only send and >> receive email on the basis of the terms set out at: >> http://www.tid.es/ES/PAGINAS/disclaimer.aspx > -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From andre.beliveau@ericsson.com Wed Oct 16 07:32:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EAD11E82A5 for ; Wed, 16 Oct 2013 07:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xblFSO9XjnRg for ; Wed, 16 Oct 2013 07:32:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 78D0111E8260 for ; Wed, 16 Oct 2013 07:31:58 -0700 (PDT) X-AuditID: c618062d-b7fda8e0000024c6-87-525ea35dc6fb Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.1E.09414.D53AE525; Wed, 16 Oct 2013 16:31:58 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Wed, 16 Oct 2013 10:31:57 -0400 From: Andre Beliveau To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-beliveau-sfc-architecture-00.txt Thread-Index: AQHOynsLQt1THPk3hk6TN43kaz7+aJn3Yh1A Date: Wed, 16 Oct 2013 14:31:56 +0000 Message-ID: <3049626EAC5C3E43866CD2692A7E19AC1C276B53@eusaamb103.ericsson.se> References: <20131016142137.32193.69942.idtracker@ietfa.amsl.com> In-Reply-To: <20131016142137.32193.69942.idtracker@ietfa.amsl.com> Accept-Language: fr-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUyuXRPgm7c4rggg+l7OSyO79vP5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujI8nz7IWtAhXvL7SwdbAeESoi5GDQ0LAROL/L/cuRk4gU0zi wr31bF2MXBxCAkcZJY4t+cEC4SxnlNh67SMrSBWbgJHE+yuTGEGaRQQUJXa+SQEJCwv4SDzd f4kFIhws8XdmAIRpJNFyoBykgkVAVaLzSjcziM0r4CvRP387WLWQgKPEpSehIGFOASeJy4vm soPYjAKyEhsmfmMBsZkFxCVuPZnPBHGlgMSSPeeZIWxRiZeP/7FC2MoSS57sBxvJLKApsX6X PkSrosSU7ofsEFsFJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEjyypGjtLi1LLcdCODTYzAYD8m waa7g3HPS8tDjNIcLErivF/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYJzMmHtW6f6y /e8MeB2Xrnr7Q3P2sXtL+T3Dupk8q55+Uj+tt3x3y4Jf2/6KJKUeD+Sf+yC2dbPo1s7Q4x1Z 1lVmP987TZrpVjTxbVPt80K188v69gdPmfdLL2/FgqcZsT9Mn6dP/l16pEpSS6DZ9UNh04tz yYeNmqQvB8ha5z/cdGSx57NbhjJKLMUZiYZazEXFiQBzCJN8RAIAAA== Subject: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:32:05 -0000 SGksIA0KDQpJ4oCZdmUganVzdCB1cGxvYWRlZCBhIGZpcnN0IHZlcnNpb24gb2YgbXkgdmlldyBv ZiBhbiBhcmNoaXRlY3R1cmUgZm9yIFNlcnZpY2UgQ2hhaW5pbmcgYXQgdGhlIGxpbmsgYmVsb3cu IA0KVGhlcmUgYXJlIHNpbWlsYXJpdGllcyB3aXRoIFBhdWwncyBhcmNoaXRlY3R1cmUgZHJhZnQu ICBJIGhhdmUgYWxyZWFkeSB0YWxrZWQgd2l0aCBQYXVsIGFuZCB3ZSB3aWxsIGJlIHdvcmtpbmcg dG8gY29udmVyZ2UgdG93YXJkIGEgc2luZ2xlIGRyYWZ0Lg0KDQpMb29raW5nIGZvcndhcmQgdG8g eW91ciBjb21tZW50cy4NCg0KL0FuZHJlIEJlbGl2ZWF1DQogDQoNCi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogT2N0b2Jlci0xNi0xMyAxMDoyMiBBTQ0KVG86IGFu ZHJlLmJlbGl2ZWF1QDsgQW5kcmUgQmVsaXZlYXUNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtYmVsaXZlYXUtc2ZjLWFyY2hpdGVjdHVyZS0wMC50eHQNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtYmVsaXZlYXUtc2ZjLWFyY2hpdGVjdHVyZS0wMC50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQW5kcmUgQmVsaXZlYXUgYW5k IHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWJlbGl2 ZWF1LXNmYy1hcmNoaXRlY3R1cmUNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFNlcnZpY2UgRnVu Y3Rpb24gQ2hhaW5pbmcgQXJjaGl0ZWN0dXJlDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xNg0K R3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDEwDQpVUkw6 ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWJl bGl2ZWF1LXNmYy1hcmNoaXRlY3R1cmUtMDAudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYmVsaXZlYXUtc2ZjLWFyY2hpdGVjdHVyZQ0K SHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWxpdmVh dS1zZmMtYXJjaGl0ZWN0dXJlLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcyBhbiBhcmNoaXRlY3R1cmUgZm9yIFNlcnZpY2UgRnVuY3Rpb24NCiAgIENoYWluaW5n LiAgSXQgYWRkcmVzc2VzIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YgU2VydmljZSBGdW5jdGlvbg0K ICAgQ2hhaW5pbmcgc3VjaCBhZG1pbmlzdHJhdGlvbiBvZiBTZXJ2aWNlIEZ1bmN0aW9uIENoYWlu cywgbmV0d29yayBhbmQNCiAgIGZvcndhcmRpbmcgcHJpbmNpcGxlcy4gIEl0IGFsc28gY292ZXJz IGFyY2hpdGVjdHVyYWwgcHJpbmNpcGxlcyB0bw0KICAgc3VwcG9ydCBzY2FsZS1pbiBhbmQgc2Nh bGUtb3V0IG9mIFNlcnZpY2UgRnVuY3Rpb25zLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFu ZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3Jl dGFyaWF0DQoNCg== From Snigs_Mukhopadhyay@DELL.com Wed Oct 16 07:58:39 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F83311E81D3 for ; Wed, 16 Oct 2013 07:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABcEvAkMRskJ for ; Wed, 16 Oct 2013 07:58:34 -0700 (PDT) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) by ietfa.amsl.com (Postfix) with ESMTP id 308A811E8255 for ; Wed, 16 Oct 2013 07:58:33 -0700 (PDT) X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="4.93,508,1378875600"; d="scan'208";a="335817660" From: To: , Date: Wed, 16 Oct 2013 09:58:23 -0500 Thread-Topic: New Version Notification for draft-beliveau-sfc-architecture-00.txt Thread-Index: AQHOynsLQt1THPk3hk6TN43kaz7+aJn3Yh1AgAAIWAA= Message-ID: <1A7A190903EBC04B8EF1B91674C7EB753A3C26CB07@AUSX7MCPC105.AMER.DELL.COM> References: <20131016142137.32193.69942.idtracker@ietfa.amsl.com> <3049626EAC5C3E43866CD2692A7E19AC1C276B53@eusaamb103.ericsson.se> In-Reply-To: <3049626EAC5C3E43866CD2692A7E19AC1C276B53@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 14:58:39 -0000 SGkNCg0KSXMgdGhlcmUgYSBkb2N1bWVudCB0aGUgZGVzY3JpYmVzIHRoZSByZXF1aXJlbWVudHMg b2YgdGhlIHNlcnZpY2UgZnVuY3Rpb25zID8gU29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyB0aGF0 IHRoZSANCg0KCXNlcnZpY2UgZnVuY3Rpb25zIHdpbGwgbmVlZCB0byBhY2NlcHQgcGFja2V0cyB3 aXRoIGFkZGl0aW9uYWwgdGFnIGluZm9ybWF0aW9uID8gDQoJc2VydmljZSBmdW5jdGlvbnMgd2ls bCBtb2RpZnkgdGhlIHNlcnZpY2UgY2hhaW4gaW5mb3JtYXRpb24gPyBvciBub3QgPw0KCXNlcnZp Y2UgZnVuY3Rpb25zIHdpbGwgbmVlZCB0byBzdXBwb3J0IGxvZ2ljYWwgaW5ncmVzcyBhbmQgZWdy ZXNzIGludGVyZmFjZXMgcGVyIGNoYWluID8NCg0KUmVnYXJkcw0KU25pZ2RoZW5kdQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpuc2MtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHJlIEJlbGl2ZWF1DQpTZW50 OiBXZWRuZXNkYXksIE9jdG9iZXIgMTYsIDIwMTMgNzozMiBBTQ0KVG86IG5zY0BpZXRmLm9yZw0K U3ViamVjdDogW25zY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iZWxpdmVh dS1zZmMtYXJjaGl0ZWN0dXJlLTAwLnR4dA0KDQpIaSwgDQoNCknigJl2ZSBqdXN0IHVwbG9hZGVk IGEgZmlyc3QgdmVyc2lvbiBvZiBteSB2aWV3IG9mIGFuIGFyY2hpdGVjdHVyZSBmb3IgU2Vydmlj ZSBDaGFpbmluZyBhdCB0aGUgbGluayBiZWxvdy4gDQpUaGVyZSBhcmUgc2ltaWxhcml0aWVzIHdp dGggUGF1bCdzIGFyY2hpdGVjdHVyZSBkcmFmdC4gIEkgaGF2ZSBhbHJlYWR5IHRhbGtlZCB3aXRo IFBhdWwgYW5kIHdlIHdpbGwgYmUgd29ya2luZyB0byBjb252ZXJnZSB0b3dhcmQgYSBzaW5nbGUg ZHJhZnQuDQoNCkxvb2tpbmcgZm9yd2FyZCB0byB5b3VyIGNvbW1lbnRzLg0KDQovQW5kcmUgQmVs aXZlYXUNCiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBP Y3RvYmVyLTE2LTEzIDEwOjIyIEFNDQpUbzogYW5kcmUuYmVsaXZlYXVAOyBBbmRyZSBCZWxpdmVh dQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iZWxpdmVhdS1z ZmMtYXJjaGl0ZWN0dXJlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1i ZWxpdmVhdS1zZmMtYXJjaGl0ZWN0dXJlLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1 Ym1pdHRlZCBieSBBbmRyZSBCZWxpdmVhdSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtYmVsaXZlYXUtc2ZjLWFyY2hpdGVjdHVyZQ0KUmV2aXNp b246CSAwMA0KVGl0bGU6CQkgU2VydmljZSBGdW5jdGlvbiBDaGFpbmluZyBBcmNoaXRlY3R1cmUN CkNyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE2DQpHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NCk51bWJlciBvZiBwYWdlczogMTANClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmVsaXZlYXUtc2ZjLWFyY2hpdGVjdHVyZS0wMC50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1iZWxpdmVhdS1zZmMtYXJjaGl0ZWN0dXJlDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJlbGl2ZWF1LXNmYy1hcmNoaXRlY3R1cmUtMDANCg0KDQpB YnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuIGFyY2hpdGVjdHVyZSBmb3Ig U2VydmljZSBGdW5jdGlvbg0KICAgQ2hhaW5pbmcuICBJdCBhZGRyZXNzZXMgb3BlcmF0aW9uYWwg YXNwZWN0cyBvZiBTZXJ2aWNlIEZ1bmN0aW9uDQogICBDaGFpbmluZyBzdWNoIGFkbWluaXN0cmF0 aW9uIG9mIFNlcnZpY2UgRnVuY3Rpb24gQ2hhaW5zLCBuZXR3b3JrIGFuZA0KICAgZm9yd2FyZGlu ZyBwcmluY2lwbGVzLiAgSXQgYWxzbyBjb3ZlcnMgYXJjaGl0ZWN0dXJhbCBwcmluY2lwbGVzIHRv DQogICBzdXBwb3J0IHNjYWxlLWluIGFuZCBzY2FsZS1vdXQgb2YgU2VydmljZSBGdW5jdGlvbnMu DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0BpZXRm Lm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From repenno@cisco.com Wed Oct 16 08:02:12 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5007111E82AB for ; Wed, 16 Oct 2013 08:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CpRGqvrQglx for ; Wed, 16 Oct 2013 08:01:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id DF03211E81DB for ; Wed, 16 Oct 2013 08:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2940; q=dns/txt; s=iport; t=1381935712; x=1383145312; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Mswoe7/4Danc7XggXzKbW6f56qZ0fG/9pEY3YdFTosw=; b=QumaCjIr/lZasyUbdepMv39mE1bA36pHxLpdYC7WtWTwnqgHG2t04F8a FvF9kHSoQOYftw1qhWb6zYT8ye9n5SzS1mMEWJ1qx42NRJZDihcooqbGS /E4y6jjmiQys2RLHkuHTpZl/RvhkkDfip9TWBVHjc5FfH5c+1+jPjJ2zF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFACKpXlKtJV2d/2dsb2JhbABagwc4UsIPgR0WdIIlAQEBBAEBAWsJDgYBCBEBAwEBCx0uCxQDBggCBAESCAGHfQy/Go8gBgkpAgSDGYEGA4kEkC+QU4Mkgik X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="272808014" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 16 Oct 2013 15:01:51 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9GF1pxo010328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 15:01:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:01:51 -0500 From: "Reinaldo Penno (repenno)" To: "Snigs_Mukhopadhyay@DELL.com" , "andre.beliveau@ericsson.com" , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt Thread-Index: AQHOyoCkcq/0PUcsJEKLpe8j9XvSxg== Date: Wed, 16 Oct 2013 15:01:50 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7360F1@xmb-rcd-x04.cisco.com> In-Reply-To: <1A7A190903EBC04B8EF1B91674C7EB753A3C26CB07@AUSX7MCPC105.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.68.203] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8AC844DB2C251147BDEDDDF1A26B51B8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:02:12 -0000 Probably something along the lines of: http://tools.ietf.org/html/draft-boucadair-sfc-framework-00 On 10/16/13 7:58 AM, "Snigs_Mukhopadhyay@DELL.com" wrote: >Hi > >Is there a document the describes the requirements of the service >functions ? Something along the lines that the > > service functions will need to accept packets with additional tag >information ?=20 > service functions will modify the service chain information ? or not ? > service functions will need to support logical ingress and egress >interfaces per chain ? > >Regards >Snigdhendu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Andre Beliveau >Sent: Wednesday, October 16, 2013 7:32 AM >To: nsc@ietf.org >Subject: [nsc] New Version Notification for >draft-beliveau-sfc-architecture-00.txt > >Hi,=20 > >I=B9ve just uploaded a first version of my view of an architecture for >Service Chaining at the link below. >There are similarities with Paul's architecture draft. I have already >talked with Paul and we will be working to converge toward a single draft. > >Looking forward to your comments. > >/Andre Beliveau >=20 > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: October-16-13 10:22 AM >To: andre.beliveau@; Andre Beliveau >Subject: New Version Notification for >draft-beliveau-sfc-architecture-00.txt > > >A new version of I-D, draft-beliveau-sfc-architecture-00.txt >has been successfully submitted by Andre Beliveau and posted to the IETF >repository. > >Filename: draft-beliveau-sfc-architecture >Revision: 00 >Title: Service Function Chaining Architecture >Creation date: 2013-10-16 >Group: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-beliveau-sfc-architecture-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-beliveau-sfc-architecture >Htmlized: =20 >http://tools.ietf.org/html/draft-beliveau-sfc-architecture-00 > > >Abstract: > This document describes an architecture for Service Function > Chaining. It addresses operational aspects of Service Function > Chaining such administration of Service Function Chains, network and > forwarding principles. It also covers architectural principles to > support scale-in and scale-out of Service Functions. > > > =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 > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Oct 16 08:03:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B60B11E81DA for ; Wed, 16 Oct 2013 08:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.467 X-Spam-Level: X-Spam-Status: No, score=-10.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPI-kDAliMTl for ; Wed, 16 Oct 2013 08:03:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C6EA611E8255 for ; Wed, 16 Oct 2013 08:03:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3137; q=dns/txt; s=iport; t=1381935797; x=1383145397; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=kRXkhDXDpVF8oofTX7Zi+sGqKz4Jt1Ad2wjVAC7faRQ=; b=X/WrSfCMwfsbp8Jtt9R2oAMyV38/Lu9m0byhx4gTJpTQLe6KPT6dqi5i 9Q+9+qBcET0NUDLdoMUwDMQUlhV0T7nGgE43E6Ekp25NBqK+cpFdn2On3 a8qqGVYMsdKktWBPEGZbwAOZj+mbKE08j7mTEPEtHCGzr+MOSeIFfiQT6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAHKqXlKtJV2Z/2dsb2JhbABagwc4UsIPgR0WdIIlAQEBBAEBASRHCQ4GAQgRAQMBAQsdLgsUAwYIAgQBEggBh30MvyCPIAYFLQIEgxmBBgOJBJAvkFODJIIp X-IronPort-AV: E=Sophos;i="4.93,508,1378857600"; d="scan'208";a="272774095" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 16 Oct 2013 15:02:53 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9GF2rPr000998 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 16 Oct 2013 15:02:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 16 Oct 2013 10:02:52 -0500 From: "Jim Guichard (jguichar)" To: "Snigs_Mukhopadhyay@DELL.com" , "andre.beliveau@ericsson.com" , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt Thread-Index: AQHOyoDJ3EslpkJ8bUWcSmP+gmNjvw== Date: Wed, 16 Oct 2013 15:02:52 +0000 Message-ID: <68B171751455884590F8E38E96416F363F6F4AC0@xmb-rcd-x01.cisco.com> In-Reply-To: <1A7A190903EBC04B8EF1B91674C7EB753A3C26CB07@AUSX7MCPC105.AMER.DELL.COM> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7574E8D138A73B4692D34887B6284B82@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] New Version Notification for draft-beliveau-sfc-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:03:24 -0000 Yes -> http://datatracker.ietf.org/doc/draft-boucadair-sfc-requirements. However, this is still a work-in-progress document and further requirements will no doubt be added or existing ones revised. I would encourage you to review the document and contact the authors with specific comments.=20 On 10/16/13 10:58 AM, "Snigs_Mukhopadhyay@DELL.com" wrote: >Hi > >Is there a document the describes the requirements of the service >functions ? Something along the lines that the > > service functions will need to accept packets with additional tag >information ?=20 > service functions will modify the service chain information ? or not ? > service functions will need to support logical ingress and egress >interfaces per chain ? > >Regards >Snigdhendu > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >Andre Beliveau >Sent: Wednesday, October 16, 2013 7:32 AM >To: nsc@ietf.org >Subject: [nsc] New Version Notification for >draft-beliveau-sfc-architecture-00.txt > >Hi,=20 > >I=B9ve just uploaded a first version of my view of an architecture for >Service Chaining at the link below. >There are similarities with Paul's architecture draft. I have already >talked with Paul and we will be working to converge toward a single draft. > >Looking forward to your comments. > >/Andre Beliveau >=20 > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: October-16-13 10:22 AM >To: andre.beliveau@; Andre Beliveau >Subject: New Version Notification for >draft-beliveau-sfc-architecture-00.txt > > >A new version of I-D, draft-beliveau-sfc-architecture-00.txt >has been successfully submitted by Andre Beliveau and posted to the IETF >repository. > >Filename: draft-beliveau-sfc-architecture >Revision: 00 >Title: Service Function Chaining Architecture >Creation date: 2013-10-16 >Group: Individual Submission >Number of pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-beliveau-sfc-architecture-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-beliveau-sfc-architecture >Htmlized: =20 >http://tools.ietf.org/html/draft-beliveau-sfc-architecture-00 > > >Abstract: > This document describes an architecture for Service Function > Chaining. It addresses operational aspects of Service Function > Chaining such administration of Service Function Chains, network and > forwarding principles. It also covers architectural principles to > support scale-in and scale-out of Service Functions. > > > =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 > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From zehn.cao@gmail.com Mon Oct 21 08:54:49 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB1821F9A10 for ; Mon, 21 Oct 2013 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLu1WsZUYkAH for ; Mon, 21 Oct 2013 08:54:49 -0700 (PDT) Received: from mail-qe0-x235.google.com (mail-qe0-x235.google.com [IPv6:2607:f8b0:400d:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id B4A5411E8413 for ; Mon, 21 Oct 2013 08:54:28 -0700 (PDT) Received: by mail-qe0-f53.google.com with SMTP id cy11so3890209qeb.26 for ; Mon, 21 Oct 2013 08:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=YgaG+e0zJmSalnALdn1FyFz0uYmqOr7Rgug3sEICuFU=; b=W3C6baw9IpM5yMYPFpDFhYfrDPxEKHFHAjVLvJPFCti4TC9AWesTSFcsIgEORkxbbe TYOFxJYmFyjhE5TtZXlbULrlKdT5iSRZqSoBgk1cvcZBBDvfAgFWygBKIStvdvp1/stJ oSvTVP89aUzSoPexPGprJpApKYecbVMn2cpFsI3Mr4UDIDw4ZjLq8pSbWd9z+EXV2EFw 6A97JuDAx+PQgaBD3aQLDq7Pe1mtGnsRRgrFkkRSnUVFswXXST+TUbE9RohKcE2BE2Hh k0QH2r3+t+Zfp3vKswT0U1EYwUxwKbNQ75KWlefpVARcNu9J6RnkBff/seM7LjT/LGyc qiWA== MIME-Version: 1.0 X-Received: by 10.49.96.42 with SMTP id dp10mr3024587qeb.94.1382370858609; Mon, 21 Oct 2013 08:54:18 -0700 (PDT) Received: by 10.96.185.68 with HTTP; Mon, 21 Oct 2013 08:54:18 -0700 (PDT) In-Reply-To: <20131021105431.29409.44036.idtracker@ietfa.amsl.com> References: <20131021105431.29409.44036.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 17:54:18 +0200 Message-ID: From: "Cao,Zhen" To: "nsc@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [nsc] Fwd: New Version Notification for draft-cao-nsc-rtg-update-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:54:50 -0000 Hello, all Comments welcome for this simple draft. Best regards, cz ---------- Forwarded message ---------- From: Date: Mon, Oct 21, 2013 at 12:54 PM Subject: New Version Notification for draft-cao-nsc-rtg-update-00.txt To: Zehn Cao A new version of I-D, draft-cao-nsc-rtg-update-00.txt has been successfully submitted by Zhen Cao and posted to the IETF repository. Filename: draft-cao-nsc-rtg-update Revision: 00 Title: Routing Update Mechanism for Network Service Chaining Creation date: 2013-10-21 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-cao-nsc-rtg-update-00.txt Status: http://datatracker.ietf.org/doc/draft-cao-nsc-rtg-update Htmlized: http://tools.ietf.org/html/draft-cao-nsc-rtg-update-00 Abstract: This document proposes a mechanism of routing the packets through a series of (virtual) service functions. The mechanism uses the existing IPv6 Mobility Header for routing advertisements, updates and acknowledgements. Comparison with existing service chaining mechanisms is to be analyzed. 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 linda.dunbar@huawei.com Mon Oct 21 14:15:57 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803C11E8626 for ; Mon, 21 Oct 2013 14:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe1f-J37i3qZ for ; Mon, 21 Oct 2013 14:15:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 91AA011E8278 for ; Mon, 21 Oct 2013 14:15:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZH68743; Mon, 21 Oct 2013 21:15:37 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 22:14:37 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 21 Oct 2013 22:15:35 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0146.000; Mon, 21 Oct 2013 14:15:29 -0700 From: Linda Dunbar To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoA Date: Mon, 21 Oct 2013 21:15:29 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.7] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Donald Eastlake , Ning So , Ian Smith , Sumandra Majee Subject: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 21:15:57 -0000 VGhlcmUgaGF2ZSBiZWVuIG1hbnkgZHJhZnRzIHN1Ym1pdHRlZCBmb3IgU0ZDIChTZXJ2aWNlIEZ1 bmN0aW9uIENoYWluaW5nKSBCT0YgYWxyZWFkeS4gSG93ZXZlciwgd2UgZmVsdCB0aGF0IGFyY2hp dGVjdHVyZSBhbmQgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyBleGlzdGluZyBMYXll ciA0LTcgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIFNlcnZpY2UgRW5j YXBzdWxhdGlvbiBoZWFkZXIgaGF2ZW7igJl0IGJlZW4gYWRkcmVzc2VkIGJ5IGFueSBkcmFmdHMg KHdoaWNoIGlzIGNhbGxlZCDigJxQcm94eSBOb2Rlc+KAnSBieSBkcmFmdC1xdWlubi1uc2gtMDEp LiAgIA0KDQpXZSBwdXQgdG9nZXRoZXIgYSBkcmFmdCB0byBhbmFseXplIHRoZSBpc3N1ZXMgYXNz b2NpYXRlZCB3aXRoIGNoYWluaW5nIGV4aXN0aW5nDQogICBMYXllciA0LTcgc2VydmljZSBmdW5j dGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIHNlcnZpY2UNCiAgIGVuY2Fwc3VsYXRpb24gbGF5 ZXJzLiBUaGlzIGRyYWZ0IGFsc28gZXhhbWluZXMgdGhlIG5ldHdvcmsNCiAgIGFyY2hpdGVjdHVy ZSBmb3IgY2hhaW5pbmcgZXhpc3RpbmcgTDQtTDcgc2VydmljZSBmdW5jdGlvbnMuIFRoZQ0KICAg aW50ZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBkZXNjcmliZSBnYXBzIHRoYXQgaGF2ZSBub3QgYmVl bg0KICAgYWRkcmVzc2VkIGJ5IG90aGVyIFNGQyBkcmFmdHMuIA0KDQpZb3VyIGNvbW1lbnRzIGFy ZSBncmVhdGx5IGFwcHJlY2lhdGVkLiANCg0KDQpGaWxlbmFtZToJIGRyYWZ0LWR1bmJhci1zZmMt bGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZQ0KUmV2aXNpb246CSAwMA0KVGl0bGU6CQkg QXJjaGl0ZWN0dXJlIGZvciBDaGFpbmluZyBMZWdhY3kgTGF5ZXIgNC03IFNlcnZpY2UgRnVuY3Rp b25zDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xNg0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNo YWluLWFyY2hpdGVjdHVyZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNo aXRlY3R1cmUNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwDQoNCg0KTGlu ZGEsIE5pbmcsIElhbiwgU3VtYW5kcmEsIGFuZCBEb25hbGQNCg0K From Ron_Parker@affirmednetworks.com Mon Oct 21 15:02:09 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101BE11E858C for ; Mon, 21 Oct 2013 15:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5VC7AaKG5Kf9 for ; Mon, 21 Oct 2013 15:02:04 -0700 (PDT) Received: from hub021-ca-8.exch021.serverdata.net (hub021-ca-8.exch021.serverdata.net [64.78.56.73]) by ietfa.amsl.com (Postfix) with ESMTP id 261A111E875B for ; Mon, 21 Oct 2013 15:01:59 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-8.exch021.domain.local ([10.254.4.112]) with mapi id 14.03.0123.003; Mon, 21 Oct 2013 15:01:58 -0700 From: Ron Parker To: Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoAgAAKa5A= Date: Mon, 21 Oct 2013 22:01:57 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Donald Eastlake , Ian Smith , Ning So , Sumandra Majee Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:02:09 -0000 SGksIExpbmRhLg0KDQpUaGlzIGNvbnRyaWJ1dGlvbiBpcyB2ZXJ5IHVzZWZ1bCBpbiBhZGRpbmcg Y2xhcml0eSBhcyB0byBob3cgU0ZDIGNhbiBiZSByZWFsaXplZCB3aXRoIGxlZ2FjeSBzZXJ2aWNl IGZ1bmN0aW9ucy4gICBJIGRvIGhhdmUgYSBmZXcgY29tbWVudHMgYW5kIG9uZSBvdmVyYWxsIHRo ZW1lIHJlZ2FyZGluZyAic3RlZXJpbmciLCB3aGljaCBJIGNvbnNpZGVyIHRoZSBsZWdhY3kgYXBw cm9hY2ggdGhhdCB3ZSBhcmUgdHJ5aW5nIHRvIGltcHJvdmUgaW4gU0ZDLg0KDQpSZXNwZWN0ZnVs bHksDQoNCiAgICBSb24NCg0KDQpJbiBzZWN0aW9uIDMuMywgZmlndXJlIDIgKENoYWluZ2luZyBl eGlzdGluZyBMYXllciA0LTcgc2VydmljZSBub2RlcykgLS0gYWx0aG91Z2ggaXQgbWF5IGJlIHNs aWdodGx5IG9mZiB0b3BpYyBmb3IgeW91ciBkcmFmdCwgaXQgb2NjdXJzIHRvIG1lIHRoYXQgdGhl IHByb3h5IG5vZGVzIHdvdWxkIGJlIGlkZWFsIGxvY2F0aW9ucyB0byBsb2FkIGJhbGFuY2UgdG93 YXJkcyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgdHlwZSBvZiBzZXJ2aWNlIG5vZGUg KGkuZS4sIGNvbWJpbmluZyBwcm94eS1ub2RlIGFuZCBsb2FkLWJhbGFuY2luZykuDQoNCkluIHNl Y3Rpb24gNC4xIChMNC1MNyBub2RlcyBjb25uZWN0aW9uIHRvIFNlcnZpY2UgQ2hhaW4gUHJveHkg Tm9kZXMpLCB0aGUgZmlyc3QgaW5kZW50ZWQgYnVsbGV0IHN0YXRlcyB0aGF0IHRoZSBzZXJ2aWNl IGZ1bmN0aW9uIGNhbiBiZSBlbWJlZGRlZCBpbiBhIHNlcnZpY2UgY2hhaW4gcHJveHkuICAgRnJv bSBhIHNvZnR3YXJlIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlIHRoYXQgbWFrZXMgcGVyZmVj dCBzZW5zZS4gICBCdXQgZnJvbSBhIG5ldHdvcmsgdG9wb2xvZ3kgcGVyc3BlY3RpdmUsIHRoZSBw cm94eSB3b3VsZCBub3QgYmUgZXhwbGljaXRseSBvYnNlcnZhYmxlIC0tIHRoZSBzZXJ2aWNlIGZ1 bmN0aW9uIHdvdWxkIGxvb2sgbGlrZSBpdCBoYWQgbmF0aXZlIFNGQyBjYXBhYmlsaXRpZXMgd2l0 aCByZXNwZWN0IHRvIG90aGVyIFNGQyBzZXJ2aWNlIG5vZGVzIGFuZC9vciBjbGFzc2lmaWVycy4N Cg0KQWxzbyBpbiBzZWN0aW9uIDQuMSwgdGhlcmUgaXMgZGlzY3Vzc2lvbiBvZiBwYXJ0aWN1bGFy IG5ldHdvcmsgdG9wb2xvZ2llcy4gICBJdCBoYXMgYmVlbiBwcm9wb3NlZCBpbiBvdGhlciBkcmFm dHMgdGhhdCB0aGUgU0ZDIGFwcHJvYWNoIGJlIHRvcG9sb2d5IHVuYXdhcmUuDQoNClNlY3Rpb24g NC4yICh0cmFmZmljIHN0ZWVyaW5nKS4gICBDb25zaXN0ZW50IHdpdGggbXkgY29tbWVudCBhYm92 ZSwgbXkgZmVlbGluZyBpcyB0aGF0IG9uZSBvZiB0aGUgYmlnZ2VzdCBhZHZhbnRhZ2VzIG9mIFNG QyBpcyB0byBiZWNvbWUgdG9wb2xvZ3kgYW5kIHRyYW5zcG9ydCB1bmF3YXJlIHNvIHRoYXQgYSBu ZXcgbWVjaGFuaXNtIG5lZWQgbm90IGJlIGludmVudGVkIGZvciBldmVyeSBjb21iaW5hdGlvbiBv ZiBuZXR3b3JrIHRvcG9sb2d5IChpLmUuLCAxIGhvcCBhd2F5LCAyIGhvcHMgYXdheSwgbW9yZSkg YW5kIHRyYW5zcG9ydCB0ZWNobm9sb2d5IChpLmUuLCBNQUMgYnJpZGdpbmcsIElQIGZvcndhcmRp bmcsIE1QTFMgTEVSL0xTUiwgQUNMLWJhc2VkIGZpbHRlcmVkIGZvcndhcmRpbmcsIGV0Yy4pLg0K DQpTZWN0aW9uIDUuMSAobXVsdGlwbGUgaW5zdGFuY2VzKS4gICBDb25zaXN0ZW50IHdpdGggY29t bWVudHMgYWJvdmUsIHdpdGggY29ycmVjdCBzZXBhcmF0aW9uIG9mIHRoZSBsb2dpY2FsIGFuZCBw aHlzaWNhbCwgc3RlZXJpbmcgdGFibGVzIHdvdWxkIG5vdCBuZWVkIHRvIGJlIHVwZGF0ZWQgZWFj aCB0aW1lIGFuIE5GViBldmVudCBvY2N1cnJlZCAoaS5lLiwgaW5zdGFjZSB1cCwgZG93biwgbW92 ZWQsIGV4cGFuZGVkLCBjb250cmFjdGVkLCBldGMuKS4NCg0KU2VjdGlvbiA1LjIgKGNoYWxsZW5n ZXMgb2YgTGF5ZXIgNC03IHRyYWZmaWMgc3RlZXJpbmcpLiAgIFNpbWlsYXIgY29tbWVudHMgdG8g YWJvdmUuICAgSWYgd2UgY2hvb3NlIGEgdG9wb2xvZ3kgYW5kIHRyYW5zcG9ydCBpbmRlcGVuZGVu dCBtZWNoYW5pc20gdG8gZm9sbG93IGEgc2VydmljZSBjaGFpbiwgdGhlIGNvbXBsZXhpdHkgaXMg cmVkdWNlZCBhbmQgdGhlIHJlbGlhYmlsaXR5IGlzIGltcHJvdmVkLiAgICBTb21ldGhpbmcgYWtp biB0byB0aGUgc3RlZXJpbmcgdGhhdCB5b3UgbWVudGlvbiBpcyBjb25zdHJhaW5lZCB0byB0aGUg Y2xhc3NpZmljYXRpb24gbm9kZShzKSwgZ3JlYXRseSBzaW1wbGlmeWluZyB0aGUgc2VydmljZSBu b2Rlcy4NCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IG5zYy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBM aW5kYSBEdW5iYXINClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMSwgMjAxMyA1OjE1IFBNDQpUbzog bnNjQGlldGYub3JnDQpDYzogRG9uYWxkIEVhc3RsYWtlOyBOaW5nIFNvOyBJYW4gU21pdGg7IFN1 bWFuZHJhIE1hamVlDQpTdWJqZWN0OiBbbnNjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQN Cg0KVGhlcmUgaGF2ZSBiZWVuIG1hbnkgZHJhZnRzIHN1Ym1pdHRlZCBmb3IgU0ZDIChTZXJ2aWNl IEZ1bmN0aW9uIENoYWluaW5nKSBCT0YgYWxyZWFkeS4gSG93ZXZlciwgd2UgZmVsdCB0aGF0IGFy Y2hpdGVjdHVyZSBhbmQgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyBleGlzdGluZyBM YXllciA0LTcgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIFNlcnZpY2Ug RW5jYXBzdWxhdGlvbiBoZWFkZXIgaGF2ZW7igJl0IGJlZW4gYWRkcmVzc2VkIGJ5IGFueSBkcmFm dHMgKHdoaWNoIGlzIGNhbGxlZCDigJxQcm94eSBOb2Rlc+KAnSBieSBkcmFmdC1xdWlubi1uc2gt MDEpLiAgIA0KDQpXZSBwdXQgdG9nZXRoZXIgYSBkcmFmdCB0byBhbmFseXplIHRoZSBpc3N1ZXMg YXNzb2NpYXRlZCB3aXRoIGNoYWluaW5nIGV4aXN0aW5nDQogICBMYXllciA0LTcgc2VydmljZSBm dW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIHNlcnZpY2UNCiAgIGVuY2Fwc3VsYXRpb24g bGF5ZXJzLiBUaGlzIGRyYWZ0IGFsc28gZXhhbWluZXMgdGhlIG5ldHdvcmsNCiAgIGFyY2hpdGVj dHVyZSBmb3IgY2hhaW5pbmcgZXhpc3RpbmcgTDQtTDcgc2VydmljZSBmdW5jdGlvbnMuIFRoZQ0K ICAgaW50ZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBkZXNjcmliZSBnYXBzIHRoYXQgaGF2ZSBub3Qg YmVlbg0KICAgYWRkcmVzc2VkIGJ5IG90aGVyIFNGQyBkcmFmdHMuIA0KDQpZb3VyIGNvbW1lbnRz IGFyZSBncmVhdGx5IGFwcHJlY2lhdGVkLiANCg0KDQpGaWxlbmFtZToJIGRyYWZ0LWR1bmJhci1z ZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZQ0KUmV2aXNpb246CSAwMA0KVGl0bGU6 CQkgQXJjaGl0ZWN0dXJlIGZvciBDaGFpbmluZyBMZWdhY3kgTGF5ZXIgNC03IFNlcnZpY2UgRnVu Y3Rpb25zDQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0xMC0xNg0KR3JvdXA6CQkgSW5kaXZpZHVhbCBT dWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDE2DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3 LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1h cmNoaXRlY3R1cmUNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwDQoNCg0K TGluZGEsIE5pbmcsIElhbiwgU3VtYW5kcmEsIGFuZCBEb25hbGQNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5zYyBtYWlsaW5nIGxpc3QNCm5zY0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uc2MNCg== From paulq@cisco.com Mon Oct 21 15:51:15 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6747011E8746 for ; Mon, 21 Oct 2013 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf9ucXT4yF-o for ; Mon, 21 Oct 2013 15:51:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C6B5C21F9A5F for ; Mon, 21 Oct 2013 15:50:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1288; q=dns/txt; s=iport; t=1382395818; x=1383605418; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=gPgmtcn2QCkiLyW/ISynuwNfL7kAptA2jczdRB8i9pY=; b=idKHitbpzOt5guFLnMMHt98jGfWgvUtFgUTeGT79V9cgSy+vX8HlRGg3 Zds7KWDamB6Q7WRKIuCyKFEbLj452XE/eUtBRGOJ9f9GvQTr+69xiWIo5 mPh8KI23q1BSc27DAlvETxGOpljSSuyinvrH+/Jrs9D8xO1nNYfAb1iDU w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcGAHmuZVKtJV2c/2dsb2JhbABZgwc4Tga+PIEwFm0HgiUBAQEDATo9EgIBGhAUEDIXBAoCBBsBEodlBggFukSPKoNXgQoDmTiQWIMkgio X-IronPort-AV: E=Sophos;i="4.93,543,1378857600"; d="scan'208";a="274850876" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 21 Oct 2013 22:50:16 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9LMoGn2005449 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 21 Oct 2013 22:50:16 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 21 Oct 2013 17:50:15 -0500 From: "Paul Quinn (paulq)" To: "nsc@ietf.org" Thread-Topic: New Version Notification for draft-quinn-sfc-arch-02.txt Thread-Index: AQHOzq/oyGgTbbdC4EO9BHpt/aPHbw== Date: Mon, 21 Oct 2013 22:50:15 +0000 Message-ID: References: <20131021213813.32521.9081.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.80.207] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [nsc] Fwd: New Version Notification for draft-quinn-sfc-arch-02.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 22:51:15 -0000 Hello, This new version reflects comments from several reviewers and adds new co-a= uthors. Thanks Paul >=20 > A new version of I-D, draft-quinn-sfc-arch-02.txt > has been successfully submitted by Paul Quinn and posted to the > IETF repository. >=20 > Filename: draft-quinn-sfc-arch > Revision: 02 > Title: Service Function Chaining (SFC) Architecture > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-quinn-sfc-arch= -02.txt > Status: http://datatracker.ietf.org/doc/draft-quinn-sfc-arch > Htmlized: http://tools.ietf.org/html/draft-quinn-sfc-arch-02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-quinn-sfc-arch-= 02 >=20 > Abstract: > This document describes an architecture for the creation of Service > Function Chains. It includes architectural concepts, principles, and > components used for the application of services in a network. This > document does not propose solutions or protocols. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From linda.dunbar@huawei.com Tue Oct 22 13:33:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6FE21E8085 for ; Tue, 22 Oct 2013 13:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm05XR+bX49i for ; Tue, 22 Oct 2013 13:33:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 46E3B11E821F for ; Tue, 22 Oct 2013 13:33:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZI67724; Tue, 22 Oct 2013 20:33:28 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 21:30:23 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 22 Oct 2013 21:31:23 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.209]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0146.000; Tue, 22 Oct 2013 13:31:19 -0700 From: Linda Dunbar To: Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkw+nbGpDp0qEuPFGDEvZ4F75oBK27A Date: Tue, 22 Oct 2013 20:31:19 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.132.222] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Donald Eastlake , Ian Smith , Ning So , Sumandra Majee Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 20:33:38 -0000 Um9uLCANCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRzLiBT ZWUgbXkgcmVzcG9uc2UgaW5zZXJ0ZWQgYmVsb3c6DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gDQo+IA0KPiBJbiBzZWN0aW9uIDMuMywgZmlndXJlIDIgKENoYWluZ2luZyBleGlz dGluZyBMYXllciA0LTcgc2VydmljZSBub2RlcykgLQ0KPiAtIGFsdGhvdWdoIGl0IG1heSBiZSBz bGlnaHRseSBvZmYgdG9waWMgZm9yIHlvdXIgZHJhZnQsIGl0IG9jY3VycyB0byBtZQ0KPiB0aGF0 IHRoZSBwcm94eSBub2RlcyB3b3VsZCBiZSBpZGVhbCBsb2NhdGlvbnMgdG8gbG9hZCBiYWxhbmNl IHRvd2FyZHMNCj4gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBzYW1lIHR5cGUgb2Ygc2Vydmlj ZSBub2RlIChpLmUuLCBjb21iaW5pbmcNCj4gcHJveHktbm9kZSBhbmQgbG9hZC1iYWxhbmNpbmcp Lg0KDQpbTGluZGFdIGFyZSB5b3Ugc2F5aW5nIHRoYXQgbXVsdGlwbGUgaW5zdGFuY2VzIGFyZSBj by1sb2NhdGVkPyBXaGF0IGlmIG11bHRpcGxlIGluc3RhbmNlcyBmb3Igb25lIG5ldHdvcmsgZnVu Y3Rpb24gYXJlIGxvY2F0ZWQgaW4gZGlmZmVyZW50IHBsYWNlcz8gDQpEbyB5b3UgdGhpbmsgdGhl ICJwcm94eSBub2RlIiBzaG91bGQgYmFsYW5jZSB0aGVtLCBvciBzaG91bGQgdGhlIGNvbnRyb2xs ZXIgYmFsYW5jZSB0aGVtIGFuZCBzaW1wbHkgaW5mb3JtIHRoZSAicHJveHkgbm9kZSI/ICBvciBj b21iaW5hdGlvbiBvZiBib3RoPw0KDQoNCj4gDQo+IEluIHNlY3Rpb24gNC4xIChMNC1MNyBub2Rl cyBjb25uZWN0aW9uIHRvIFNlcnZpY2UgQ2hhaW4gUHJveHkgTm9kZXMpLA0KPiB0aGUgZmlyc3Qg aW5kZW50ZWQgYnVsbGV0IHN0YXRlcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBiZQ0K PiBlbWJlZGRlZCBpbiBhIHNlcnZpY2UgY2hhaW4gcHJveHkuICAgRnJvbSBhIHNvZnR3YXJlIGlt cGxlbWVudGF0aW9uDQo+IHBlcnNwZWN0aXZlIHRoYXQgbWFrZXMgcGVyZmVjdCBzZW5zZS4gICBC dXQgZnJvbSBhIG5ldHdvcmsgdG9wb2xvZ3kNCj4gcGVyc3BlY3RpdmUsIHRoZSBwcm94eSB3b3Vs ZCBub3QgYmUgZXhwbGljaXRseSBvYnNlcnZhYmxlIC0tIHRoZQ0KPiBzZXJ2aWNlIGZ1bmN0aW9u IHdvdWxkIGxvb2sgbGlrZSBpdCBoYWQgbmF0aXZlIFNGQyBjYXBhYmlsaXRpZXMgd2l0aA0KPiBy ZXNwZWN0IHRvIG90aGVyIFNGQyBzZXJ2aWNlIG5vZGVzIGFuZC9vciBjbGFzc2lmaWVycy4NCg0K W0xpbmRhXSBJIHdpbGwgY2hhbmdlIHRoZSB0ZXh0IHRvIHJlZmxlY3QgdGhpcyBwb2ludC4gT24g dGhlIG90aGVyIGhhbmQsIG1hbnkgb2YgdG9kYXkncyBzZXJ2aWNlIGZ1bmN0aW9ucyBhcmUgaW5k ZXBlbmRlbnQuIFRoZXkgZG9uJ3QgY2FyZSB3aG8gaXMgYWhlYWQgb2YgdGhlbSBhbmQgd2hvIGlz IGFmdGVyLiBIb3cgd291bGQgeW91IGRlc2NyaWJlIHRoaXMgc2NlbmFyaW8/IA0KDQogDQo+IA0K PiBBbHNvIGluIHNlY3Rpb24gNC4xLCB0aGVyZSBpcyBkaXNjdXNzaW9uIG9mIHBhcnRpY3VsYXIg bmV0d29yaw0KPiB0b3BvbG9naWVzLiAgIEl0IGhhcyBiZWVuIHByb3Bvc2VkIGluIG90aGVyIGRy YWZ0cyB0aGF0IHRoZSBTRkMNCj4gYXBwcm9hY2ggYmUgdG9wb2xvZ3kgdW5hd2FyZS4NCj4gDQpb TGluZGFdICBJbiB0aGlzIGNvbnRleHQsIHRoZSBQcm94eSBub2RlcyBhcmUgdG9wb2xvZ3kgdW5h d2FyZS4gQnV0IHByb3h5IG5vZGVzIGtub3cgdGhlaXIgY29ubmVjdGlvbiB0byB0aGUgZGlyZWN0 bHkgY29ubmVjdGVkIHNlcnZpY2UgZnVuY3Rpb25zLiBJcyBpdCBPSz8gIA0KDQpNYXliZSB3ZSBj YW4gY2hhdCBmYWNlIHRvIGZhY2UgaW4gVmFuY291dmVyIGZvciB0aGUgZm9sbG93aW5nIHBvaW50 cy4gDQoNCkxpbmRhDQo+IFNlY3Rpb24gNC4yICh0cmFmZmljIHN0ZWVyaW5nKS4gICBDb25zaXN0 ZW50IHdpdGggbXkgY29tbWVudCBhYm92ZSwgbXkNCj4gZmVlbGluZyBpcyB0aGF0IG9uZSBvZiB0 aGUgYmlnZ2VzdCBhZHZhbnRhZ2VzIG9mIFNGQyBpcyB0byBiZWNvbWUNCj4gdG9wb2xvZ3kgYW5k IHRyYW5zcG9ydCB1bmF3YXJlIHNvIHRoYXQgYSBuZXcgbWVjaGFuaXNtIG5lZWQgbm90IGJlDQo+ IGludmVudGVkIGZvciBldmVyeSBjb21iaW5hdGlvbiBvZiBuZXR3b3JrIHRvcG9sb2d5IChpLmUu LCAxIGhvcCBhd2F5LCAyDQo+IGhvcHMgYXdheSwgbW9yZSkgYW5kIHRyYW5zcG9ydCB0ZWNobm9s b2d5IChpLmUuLCBNQUMgYnJpZGdpbmcsIElQDQo+IGZvcndhcmRpbmcsIE1QTFMgTEVSL0xTUiwg QUNMLWJhc2VkIGZpbHRlcmVkIGZvcndhcmRpbmcsIGV0Yy4pLg0KPiANCj4gU2VjdGlvbiA1LjEg KG11bHRpcGxlIGluc3RhbmNlcykuICAgQ29uc2lzdGVudCB3aXRoIGNvbW1lbnRzIGFib3ZlLA0K PiB3aXRoIGNvcnJlY3Qgc2VwYXJhdGlvbiBvZiB0aGUgbG9naWNhbCBhbmQgcGh5c2ljYWwsIHN0 ZWVyaW5nIHRhYmxlcw0KPiB3b3VsZCBub3QgbmVlZCB0byBiZSB1cGRhdGVkIGVhY2ggdGltZSBh biBORlYgZXZlbnQgb2NjdXJyZWQgKGkuZS4sDQo+IGluc3RhY2UgdXAsIGRvd24sIG1vdmVkLCBl eHBhbmRlZCwgY29udHJhY3RlZCwgZXRjLikuDQo+IA0KPiBTZWN0aW9uIDUuMiAoY2hhbGxlbmdl cyBvZiBMYXllciA0LTcgdHJhZmZpYyBzdGVlcmluZykuICAgU2ltaWxhcg0KPiBjb21tZW50cyB0 byBhYm92ZS4gICBJZiB3ZSBjaG9vc2UgYSB0b3BvbG9neSBhbmQgdHJhbnNwb3J0IGluZGVwZW5k ZW50DQo+IG1lY2hhbmlzbSB0byBmb2xsb3cgYSBzZXJ2aWNlIGNoYWluLCB0aGUgY29tcGxleGl0 eSBpcyByZWR1Y2VkIGFuZCB0aGUNCj4gcmVsaWFiaWxpdHkgaXMgaW1wcm92ZWQuICAgIFNvbWV0 aGluZyBha2luIHRvIHRoZSBzdGVlcmluZyB0aGF0IHlvdQ0KPiBtZW50aW9uIGlzIGNvbnN0cmFp bmVkIHRvIHRoZSBjbGFzc2lmaWNhdGlvbiBub2RlKHMpLCBncmVhdGx5DQo+IHNpbXBsaWZ5aW5n IHRoZSBzZXJ2aWNlIG5vZGVzLg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2MtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IExpbmRhIER1bmJhcg0KPiBTZW50OiBNb25kYXks IE9jdG9iZXIgMjEsIDIwMTMgNToxNSBQTQ0KPiBUbzogbnNjQGlldGYub3JnDQo+IENjOiBEb25h bGQgRWFzdGxha2U7IE5pbmcgU287IElhbiBTbWl0aDsgU3VtYW5kcmEgTWFqZWUNCj4gU3ViamVj dDogW25zY10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLWxl Z2FjeS1sNC0NCj4gbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwLnR4dA0KPiANCj4gVGhlcmUgaGF2 ZSBiZWVuIG1hbnkgZHJhZnRzIHN1Ym1pdHRlZCBmb3IgU0ZDIChTZXJ2aWNlIEZ1bmN0aW9uDQo+ IENoYWluaW5nKSBCT0YgYWxyZWFkeS4gSG93ZXZlciwgd2UgZmVsdCB0aGF0IGFyY2hpdGVjdHVy ZSBhbmQgaXNzdWVzDQo+IGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyBleGlzdGluZyBMYXllciA0 LTcgc2VydmljZSBmdW5jdGlvbnMgdGhhdCBhcmUNCj4gbm90IGF3YXJlIG9mIFNlcnZpY2UgRW5j YXBzdWxhdGlvbiBoZWFkZXIgaGF2ZW7igJl0IGJlZW4gYWRkcmVzc2VkIGJ5IGFueQ0KPiBkcmFm dHMgKHdoaWNoIGlzIGNhbGxlZCDigJxQcm94eSBOb2Rlc+KAnSBieSBkcmFmdC1xdWlubi1uc2gt MDEpLg0KPiANCj4gV2UgcHV0IHRvZ2V0aGVyIGEgZHJhZnQgdG8gYW5hbHl6ZSB0aGUgaXNzdWVz IGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZw0KPiBleGlzdGluZw0KPiAgICBMYXllciA0LTcgc2Vy dmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIHNlcnZpY2UNCj4gICAgZW5jYXBz dWxhdGlvbiBsYXllcnMuIFRoaXMgZHJhZnQgYWxzbyBleGFtaW5lcyB0aGUgbmV0d29yaw0KPiAg ICBhcmNoaXRlY3R1cmUgZm9yIGNoYWluaW5nIGV4aXN0aW5nIEw0LUw3IHNlcnZpY2UgZnVuY3Rp b25zLiBUaGUNCj4gICAgaW50ZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBkZXNjcmliZSBnYXBzIHRo YXQgaGF2ZSBub3QgYmVlbg0KPiAgICBhZGRyZXNzZWQgYnkgb3RoZXIgU0ZDIGRyYWZ0cy4NCj4g DQo+IFlvdXIgY29tbWVudHMgYXJlIGdyZWF0bHkgYXBwcmVjaWF0ZWQuDQo+IA0KPiANCj4gRmls ZW5hbWU6CSBkcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUN Cj4gUmV2aXNpb246CSAwMA0KPiBUaXRsZToJCSBBcmNoaXRlY3R1cmUgZm9yIENoYWluaW5nIExl Z2FjeSBMYXllciA0LTcgU2VydmljZQ0KPiBGdW5jdGlvbnMNCj4gQ3JlYXRpb24gZGF0ZToJIDIw MTMtMTAtMTYNCj4gR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJlciBvZiBw YWdlczogMTYNCj4gVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1kdW5iYXItc2ZjLQ0KPiBsZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0 dXJlLTAwLnR4dA0KPiBTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZHVuYmFyLXNmYy0NCj4gbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVy ZQ0KPiBIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWR1 bmJhci1zZmMtbGVnYWN5LWw0LQ0KPiBsNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDANCj4gDQo+IA0K PiBMaW5kYSwgTmluZywgSWFuLCBTdW1hbmRyYSwgYW5kIERvbmFsZA0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbnNjIG1haWxpbmcgbGlz dA0KPiBuc2NAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uc2MNCg== From Ron_Parker@affirmednetworks.com Tue Oct 22 14:49:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED4D11E8276 for ; Tue, 22 Oct 2013 14:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JRkNr0B67JH for ; Tue, 22 Oct 2013 14:49:14 -0700 (PDT) Received: from hub021-ca-3.exch021.serverdata.net (hub021-ca-3.exch021.serverdata.net [64.78.22.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9384C21F9A3B for ; Tue, 22 Oct 2013 14:49:06 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-3.exch021.domain.local ([10.254.4.36]) with mapi id 14.03.0158.001; Tue, 22 Oct 2013 14:48:39 -0700 From: Ron Parker To: Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoAgAAKa5CAAfJagP//ndDQ Date: Tue, 22 Oct 2013 21:48:38 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Donald Eastlake , Ian Smith , Ning So , Sumandra Majee Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:49:39 -0000 SGksIExpbmRhLg0KDQpSZXNwb25zZXMgaW5saW5lLg0KDQoJUm9uDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IExpbmRhIER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJhckBo dWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjIsIDIwMTMgNDozMSBQTQ0KVG86 IFJvbiBQYXJrZXI7IG5zY0BpZXRmLm9yZw0KQ2M6IERvbmFsZCBFYXN0bGFrZTsgTmluZyBTbzsg SWFuIFNtaXRoOyBTdW1hbmRyYSBNYWplZQ0KU3ViamVjdDogUkU6IFtuc2NdIE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJj aGl0ZWN0dXJlLTAwLnR4dA0KDQpSb24sIA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUg dmFsdWFibGUgY29tbWVudHMuIFNlZSBteSByZXNwb25zZSBpbnNlcnRlZCBiZWxvdzoNCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gDQo+IEluIHNlY3Rpb24gMy4zLCBmaWd1 cmUgMiAoQ2hhaW5naW5nIGV4aXN0aW5nIExheWVyIDQtNyBzZXJ2aWNlIG5vZGVzKSANCj4gLQ0K PiAtIGFsdGhvdWdoIGl0IG1heSBiZSBzbGlnaHRseSBvZmYgdG9waWMgZm9yIHlvdXIgZHJhZnQs IGl0IG9jY3VycyB0byANCj4gbWUgdGhhdCB0aGUgcHJveHkgbm9kZXMgd291bGQgYmUgaWRlYWwg bG9jYXRpb25zIHRvIGxvYWQgYmFsYW5jZSANCj4gdG93YXJkcyBtdWx0aXBsZSBpbnN0YW5jZXMg b2YgdGhlIHNhbWUgdHlwZSBvZiBzZXJ2aWNlIG5vZGUgKGkuZS4sIA0KPiBjb21iaW5pbmcgcHJv eHktbm9kZSBhbmQgbG9hZC1iYWxhbmNpbmcpLg0KDQpbTGluZGFdIGFyZSB5b3Ugc2F5aW5nIHRo YXQgbXVsdGlwbGUgaW5zdGFuY2VzIGFyZSBjby1sb2NhdGVkPyBXaGF0IGlmIG11bHRpcGxlIGlu c3RhbmNlcyBmb3Igb25lIG5ldHdvcmsgZnVuY3Rpb24gYXJlIGxvY2F0ZWQgaW4gZGlmZmVyZW50 IHBsYWNlcz8gDQpEbyB5b3UgdGhpbmsgdGhlICJwcm94eSBub2RlIiBzaG91bGQgYmFsYW5jZSB0 aGVtLCBvciBzaG91bGQgdGhlIGNvbnRyb2xsZXIgYmFsYW5jZSB0aGVtIGFuZCBzaW1wbHkgaW5m b3JtIHRoZSAicHJveHkgbm9kZSI/ICBvciBjb21iaW5hdGlvbiBvZiBib3RoPw0KDQoNCltSb25d IE15IHRoaW5raW5nLCBzbyBmYXIsIGlzIHRoYXQgYSBsb2FkLWJhbGFuY2VyIGlzLCBpdHNlbGYg YSBuZXR3b3JrIHNlcnZpY2UgZnVuY3Rpb24gd2hpY2ggdW5kZXJzdGFuZHMgdGhhdCBpdCBtYW5n ZXMgc29tZSBzZXQgb2YgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgc3VidGVuZGVkIG5ldHdvcmsg c2VydmljZSBmdW5jdGlvbiBpbnN0YW5jZXMuICAgIEJ1dCwgZnJvbSBhIGxvZ2ljYWwgcGVyc3Bl Y3RpdmUsIEkgdGhpbmsgdGhhdCBJIGhhdmUgYXJndWVkIG15c2VsZiBvdXQgb2YgY28tbWluZ2xp bmcgdGhlIHByb3h5IGNvbmNlcHQgYW5kIHRoZSBsb2FkIGJhbGFuY2luZyBjb25jZXB0LiAgIFRo ZXkgY2FuIGJlIG1peGVkIGFuZCBtYXRjaGVkIGFzIG5lY2Vzc2FyeSwgYW5kIGNvLWxvY2F0ZWQg YXMgZGVzaXJlZC4gICBGb3IgZXhhbXBsZSwgYSBjaGFpbiBtYXkgaW5kaWNhdGUgdGhhdCBhIGxv YWQtYmFsYW5jZXIgbXVzdCBiZSB2aXNpdGVkLiAgIFRoZSBsb2FkIGJhbGFuY2VyIGJhbGFuY2Vz IHRvIG11bHRpcGxlIGluc3RhbmNlcyBvZiBwcm94eS1mcm9udGVkIG5vbi1TRkMtYXdhcmUgc2Vy dmljZSBmdW5jdGlvbnMuICAgIEJ1dCwgYWxsIG9mIHRoaXMgaXMgb2ZmLXRvcGljLCBzbyBJIGFw b2xvZ2l6ZSBmb3IgaW50cm9kdWNpbmcgaXQgaGVyZS4NCg0KPiANCj4gSW4gc2VjdGlvbiA0LjEg KEw0LUw3IG5vZGVzIGNvbm5lY3Rpb24gdG8gU2VydmljZSBDaGFpbiBQcm94eSBOb2RlcyksIA0K PiB0aGUgZmlyc3QgaW5kZW50ZWQgYnVsbGV0IHN0YXRlcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0 aW9uIGNhbiBiZQ0KPiBlbWJlZGRlZCBpbiBhIHNlcnZpY2UgY2hhaW4gcHJveHkuICAgRnJvbSBh IHNvZnR3YXJlIGltcGxlbWVudGF0aW9uDQo+IHBlcnNwZWN0aXZlIHRoYXQgbWFrZXMgcGVyZmVj dCBzZW5zZS4gICBCdXQgZnJvbSBhIG5ldHdvcmsgdG9wb2xvZ3kNCj4gcGVyc3BlY3RpdmUsIHRo ZSBwcm94eSB3b3VsZCBub3QgYmUgZXhwbGljaXRseSBvYnNlcnZhYmxlIC0tIHRoZSANCj4gc2Vy dmljZSBmdW5jdGlvbiB3b3VsZCBsb29rIGxpa2UgaXQgaGFkIG5hdGl2ZSBTRkMgY2FwYWJpbGl0 aWVzIHdpdGggDQo+IHJlc3BlY3QgdG8gb3RoZXIgU0ZDIHNlcnZpY2Ugbm9kZXMgYW5kL29yIGNs YXNzaWZpZXJzLg0KDQpbTGluZGFdIEkgd2lsbCBjaGFuZ2UgdGhlIHRleHQgdG8gcmVmbGVjdCB0 aGlzIHBvaW50LiBPbiB0aGUgb3RoZXIgaGFuZCwgbWFueSBvZiB0b2RheSdzIHNlcnZpY2UgZnVu Y3Rpb25zIGFyZSBpbmRlcGVuZGVudC4gVGhleSBkb24ndCBjYXJlIHdobyBpcyBhaGVhZCBvZiB0 aGVtIGFuZCB3aG8gaXMgYWZ0ZXIuIEhvdyB3b3VsZCB5b3UgZGVzY3JpYmUgdGhpcyBzY2VuYXJp bz8NCg0KDQpbUm9uXSBJIHRoaW5rIHdlIGFyZSBzYXlpbmcgdGhhdCB0byBiZSBTRkMtYXdhcmUg aXMgdG8ga25vdywgZXhwbGljaXRseSwgd2hpY2ggc2VydmljZSBmdW5jdGlvbiBpcyBuZXh0LiAg IEEgc2VydmljZSBmdW5jdGlvbiB3aGljaCBkb2Vzbid0IHVuZGVyc3RhbmQgdGhhdCBjb25jZXB0 IGlzIGZyb250LWVuZGVkIGJ5IGFuIFNGQy1wcm94eS4NCg0KIA0KPiANCj4gQWxzbyBpbiBzZWN0 aW9uIDQuMSwgdGhlcmUgaXMgZGlzY3Vzc2lvbiBvZiBwYXJ0aWN1bGFyIG5ldHdvcmsNCj4gdG9w b2xvZ2llcy4gICBJdCBoYXMgYmVlbiBwcm9wb3NlZCBpbiBvdGhlciBkcmFmdHMgdGhhdCB0aGUg U0ZDDQo+IGFwcHJvYWNoIGJlIHRvcG9sb2d5IHVuYXdhcmUuDQo+IA0KW0xpbmRhXSAgSW4gdGhp cyBjb250ZXh0LCB0aGUgUHJveHkgbm9kZXMgYXJlIHRvcG9sb2d5IHVuYXdhcmUuIEJ1dCBwcm94 eSBub2RlcyBrbm93IHRoZWlyIGNvbm5lY3Rpb24gdG8gdGhlIGRpcmVjdGx5IGNvbm5lY3RlZCBz ZXJ2aWNlIGZ1bmN0aW9ucy4gSXMgaXQgT0s/ICANCg0KW1Jvbl0gSSB0aGluayB0aGlzIGdvZXMg dG8gd2hlcmUgdGhlIGludGVsbGlnZW5jZSBpcyBmb3IgdGhlIGZvcndhcmRpbmcuDQoNCk1heWJl IHdlIGNhbiBjaGF0IGZhY2UgdG8gZmFjZSBpbiBWYW5jb3V2ZXIgZm9yIHRoZSBmb2xsb3dpbmcg cG9pbnRzLg0KDQpbUm9uXSBJdCB3b3VsZCBiZSBteSBwbGVhc3VyZSA6KS4gICBQbGVhc2UgY29u dGFjdCBtZSBwcml2YXRlbHkuDQogDQoNCkxpbmRhDQo+IFNlY3Rpb24gNC4yICh0cmFmZmljIHN0 ZWVyaW5nKS4gICBDb25zaXN0ZW50IHdpdGggbXkgY29tbWVudCBhYm92ZSwgbXkNCj4gZmVlbGlu ZyBpcyB0aGF0IG9uZSBvZiB0aGUgYmlnZ2VzdCBhZHZhbnRhZ2VzIG9mIFNGQyBpcyB0byBiZWNv bWUgDQo+IHRvcG9sb2d5IGFuZCB0cmFuc3BvcnQgdW5hd2FyZSBzbyB0aGF0IGEgbmV3IG1lY2hh bmlzbSBuZWVkIG5vdCBiZSANCj4gaW52ZW50ZWQgZm9yIGV2ZXJ5IGNvbWJpbmF0aW9uIG9mIG5l dHdvcmsgdG9wb2xvZ3kgKGkuZS4sIDEgaG9wIGF3YXksIA0KPiAyIGhvcHMgYXdheSwgbW9yZSkg YW5kIHRyYW5zcG9ydCB0ZWNobm9sb2d5IChpLmUuLCBNQUMgYnJpZGdpbmcsIElQIA0KPiBmb3J3 YXJkaW5nLCBNUExTIExFUi9MU1IsIEFDTC1iYXNlZCBmaWx0ZXJlZCBmb3J3YXJkaW5nLCBldGMu KS4NCj4gDQo+IFNlY3Rpb24gNS4xIChtdWx0aXBsZSBpbnN0YW5jZXMpLiAgIENvbnNpc3RlbnQg d2l0aCBjb21tZW50cyBhYm92ZSwNCj4gd2l0aCBjb3JyZWN0IHNlcGFyYXRpb24gb2YgdGhlIGxv Z2ljYWwgYW5kIHBoeXNpY2FsLCBzdGVlcmluZyB0YWJsZXMgDQo+IHdvdWxkIG5vdCBuZWVkIHRv IGJlIHVwZGF0ZWQgZWFjaCB0aW1lIGFuIE5GViBldmVudCBvY2N1cnJlZCAoaS5lLiwgDQo+IGlu c3RhY2UgdXAsIGRvd24sIG1vdmVkLCBleHBhbmRlZCwgY29udHJhY3RlZCwgZXRjLikuDQo+IA0K PiBTZWN0aW9uIDUuMiAoY2hhbGxlbmdlcyBvZiBMYXllciA0LTcgdHJhZmZpYyBzdGVlcmluZyku ICAgU2ltaWxhcg0KPiBjb21tZW50cyB0byBhYm92ZS4gICBJZiB3ZSBjaG9vc2UgYSB0b3BvbG9n eSBhbmQgdHJhbnNwb3J0IGluZGVwZW5kZW50DQo+IG1lY2hhbmlzbSB0byBmb2xsb3cgYSBzZXJ2 aWNlIGNoYWluLCB0aGUgY29tcGxleGl0eSBpcyByZWR1Y2VkIGFuZCB0aGUNCj4gcmVsaWFiaWxp dHkgaXMgaW1wcm92ZWQuICAgIFNvbWV0aGluZyBha2luIHRvIHRoZSBzdGVlcmluZyB0aGF0IHlv dQ0KPiBtZW50aW9uIGlzIGNvbnN0cmFpbmVkIHRvIHRoZSBjbGFzc2lmaWNhdGlvbiBub2RlKHMp LCBncmVhdGx5IA0KPiBzaW1wbGlmeWluZyB0aGUgc2VydmljZSBub2Rlcy4NCj4gDQo+IA0KPiAN Cj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG5zYy1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiANCj4gTGlu ZGEgRHVuYmFyDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAyMSwgMjAxMyA1OjE1IFBNDQo+IFRv OiBuc2NAaWV0Zi5vcmcNCj4gQ2M6IERvbmFsZCBFYXN0bGFrZTsgTmluZyBTbzsgSWFuIFNtaXRo OyBTdW1hbmRyYSBNYWplZQ0KPiBTdWJqZWN0OiBbbnNjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIA0KPiBkcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC0gbDctY2hhaW4tYXJjaGl0ZWN0 dXJlLTAwLnR4dA0KPiANCj4gVGhlcmUgaGF2ZSBiZWVuIG1hbnkgZHJhZnRzIHN1Ym1pdHRlZCBm b3IgU0ZDIChTZXJ2aWNlIEZ1bmN0aW9uDQo+IENoYWluaW5nKSBCT0YgYWxyZWFkeS4gSG93ZXZl ciwgd2UgZmVsdCB0aGF0IGFyY2hpdGVjdHVyZSBhbmQgaXNzdWVzIA0KPiBhc3NvY2lhdGVkIHdp dGggY2hhaW5pbmcgZXhpc3RpbmcgTGF5ZXIgNC03IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgYXJl IA0KPiBub3QgYXdhcmUgb2YgU2VydmljZSBFbmNhcHN1bGF0aW9uIGhlYWRlciBoYXZlbuKAmXQg YmVlbiBhZGRyZXNzZWQgYnkgDQo+IGFueSBkcmFmdHMgKHdoaWNoIGlzIGNhbGxlZCDigJxQcm94 eSBOb2Rlc+KAnSBieSBkcmFmdC1xdWlubi1uc2gtMDEpLg0KPiANCj4gV2UgcHV0IHRvZ2V0aGVy IGEgZHJhZnQgdG8gYW5hbHl6ZSB0aGUgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCBjaGFpbmluZyAN Cj4gZXhpc3RpbmcNCj4gICAgTGF5ZXIgNC03IHNlcnZpY2UgZnVuY3Rpb25zIHRoYXQgYXJlIG5v dCBhd2FyZSBvZiBzZXJ2aWNlDQo+ICAgIGVuY2Fwc3VsYXRpb24gbGF5ZXJzLiBUaGlzIGRyYWZ0 IGFsc28gZXhhbWluZXMgdGhlIG5ldHdvcmsNCj4gICAgYXJjaGl0ZWN0dXJlIGZvciBjaGFpbmlu ZyBleGlzdGluZyBMNC1MNyBzZXJ2aWNlIGZ1bmN0aW9ucy4gVGhlDQo+ICAgIGludGVudCBpcyB0 byBpZGVudGlmeSBhbmQgZGVzY3JpYmUgZ2FwcyB0aGF0IGhhdmUgbm90IGJlZW4NCj4gICAgYWRk cmVzc2VkIGJ5IG90aGVyIFNGQyBkcmFmdHMuDQo+IA0KPiBZb3VyIGNvbW1lbnRzIGFyZSBncmVh dGx5IGFwcHJlY2lhdGVkLg0KPiANCj4gDQo+IEZpbGVuYW1lOgkgZHJhZnQtZHVuYmFyLXNmYy1s ZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlDQo+IFJldmlzaW9uOgkgMDANCj4gVGl0bGU6 CQkgQXJjaGl0ZWN0dXJlIGZvciBDaGFpbmluZyBMZWdhY3kgTGF5ZXIgNC03IFNlcnZpY2UNCj4g RnVuY3Rpb25zDQo+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE2DQo+IEdyb3VwOgkJIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPiBOdW1iZXIgb2YgcGFnZXM6IDE2DQo+IFVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLXNmYy0N Cj4gbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQNCj4gU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWR1bmJhci1zZmMtDQo+ IGxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUNCj4gSHRtbGl6ZWQ6ICAgICAgICBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC0NCj4gbDct Y2hhaW4tYXJjaGl0ZWN0dXJlLTAwDQo+IA0KPiANCj4gTGluZGEsIE5pbmcsIElhbiwgU3VtYW5k cmEsIGFuZCBEb25hbGQNCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG5zYyBtYWlsaW5nIGxpc3QNCj4gbnNjQGlldGYub3JnDQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQo= From diego@tid.es Wed Oct 23 07:49:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5CBC11E83E5 for ; Wed, 23 Oct 2013 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7nDSzstehYc for ; Wed, 23 Oct 2013 07:48:57 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id A912911E83B0 for ; Wed, 23 Oct 2013 07:48:48 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MV4003J6MHBHM@tid.hi.inet> for nsc@ietf.org; Wed, 23 Oct 2013 16:48:47 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id F2.5C.03197.FC1E7625; Wed, 23 Oct 2013 16:48:47 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MV4003IYMHBHM@tid.hi.inet> for nsc@ietf.org; Wed, 23 Oct 2013 16:48:47 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.03.0123.003; Wed, 23 Oct 2013 16:48:47 +0200 Date: Wed, 23 Oct 2013 14:48:46 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Ron Parker Message-id: <4780BEE6-9A1B-4EF4-BE0E-405BEEC8E9A6@tid.es> Content-id: MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-index: AQHOzqk2NVXbhmi+TUCylPosmksTNZoCPxiA X-AuditID: 0a5f4068-b7f3e8e000000c7d-50-5267e1cf666c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42Lhinfg0j3/MD3I4NFOA4vj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8+H+WwFH/Urtqx7zNzA+Fiti5GTQ0LAROLptWOMELaYxIV7 69m6GLk4hAQOMkrseXyKBcL5xijx/cZjRghnI6PEupc9bCAtLAKqEv2HTzOD2GxA9qPm3+xd jBwcwgKZEr8fs4KEOQViJU6/2MsMsUFB4s+5xywgtoiAgcTrz6fAapgFbjBKLJzmDmLzClhK LN7xHCpuJnFtzn1GiLigxI/J91gg4noSH//cZoSwxSWaW29CxbUlnry7ANbLKCAr8W7+fFaI XVkSzV87GSFsI4mm1gfsEPcISCzZcx7qNlGJl4//sUL8uIJRYvvXucwTGCVmIbljFpI7ZiG5 YxaSO2YhuWMBI+sqRrHipKLM9IyS3MTMnHQDQ72MTL3MvNSSTYyQyMvYwbh8p8ohRgEORiUe 3pfdaUFCrIllxZW5hxglOJiVRHh33E0PEuJNSaysSi3Kjy8qzUktPsTIxMEp1cDIm3ie08Th sPqcjjsn7QtaOGS1b3pMO+gcxxp1m70xavOXaolnU8+8ftZ7aOoqq2n/Nh7d49dTP41v30E7 +QvWgvqvfy5KuDx1d/iXR35bpQ9sajim1LD36aZdm+IYskqOBuz9apwz/dffhpAfyW8euvqV fux9s+RmJlfoo9ps1yU7bBI2yGXnKrEUZyQaajEXFScCAGTyNcOaAgAA References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> Cc: "nsc@ietf.org" , Sumandra Majee , Ian Smith , Linda Dunbar , Ning So , Donald Eastlake Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 14:49:02 -0000 Hi, I fully agree with Ron in finding this draft extremely valuable in how to a= chieve SFC without supporting the SFC procedures-to-be, and therefore a key= aspect for supporting migration and satisfying one of the key requirements= that were made at the beginning of the NSC/SFC discussion (by Maria Napier= ala, if I remember well) Furthermore, I find the node classification into p= roxy-based and packet-based extremely interesting and worth more deep explo= ration, including the reflection on nodes able to change the values under w= hich classification was originally performed. What I find strange is the usage of the "L4-L7" label to qualify the kind o= f services being considered, as my understanding is that principles are gen= erally applicable, unless you understand that almost anything is a L4-L7 se= rvice (like the mention of things like NAT seems to imply) Why not talk abo= ut legacy chain mechanisms in plain? Be goode, On 22 Oct 2013, at 00:01 , Ron Parker wrote: > Hi, Linda. > > This contribution is very useful in adding clarity as to how SFC can be r= ealized with legacy service functions. I do have a few comments and one o= verall theme regarding "steering", which I consider the legacy approach tha= t we are trying to improve in SFC. > > Respectfully, > > Ron > > > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) -- = although it may be slightly off topic for your draft, it occurs to me that = the proxy nodes would be ideal locations to load balance towards multiple i= nstances of the same type of service node (i.e., combining proxy-node and l= oad-balancing). > > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), the= first indented bullet states that the service function can be embedded in = a service chain proxy. From a software implementation perspective that ma= kes perfect sense. But from a network topology perspective, the proxy wou= ld not be explicitly observable -- the service function would look like it = had native SFC capabilities with respect to other SFC service nodes and/or = classifiers. > > Also in section 4.1, there is discussion of particular network topologies= . It has been proposed in other drafts that the SFC approach be topology = unaware. > > Section 4.2 (traffic steering). Consistent with my comment above, my fe= eling is that one of the biggest advantages of SFC is to become topology an= d transport unaware so that a new mechanism need not be invented for every = combination of network topology (i.e., 1 hop away, 2 hops away, more) and t= ransport technology (i.e., MAC bridging, IP forwarding, MPLS LER/LSR, ACL-b= ased filtered forwarding, etc.). > > Section 5.1 (multiple instances). Consistent with comments above, with = correct separation of the logical and physical, steering tables would not n= eed to be updated each time an NFV event occurred (i.e., instace up, down, = moved, expanded, contracted, etc.). > > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar comment= s to above. If we choose a topology and transport independent mechanism t= o follow a service chain, the complexity is reduced and the reliability is = improved. Something akin to the steering that you mention is constrained= to the classification node(s), greatly simplifying the service nodes. > > > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Lin= da Dunbar > Sent: Monday, October 21, 2013 5:15 PM > To: nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7= -chain-architecture-00.txt > > There have been many drafts submitted for SFC (Service Function Chaining)= BOF already. However, we felt that architecture and issues associated with= chaining existing Layer 4-7 service functions that are not aware of Servic= e Encapsulation header haven=92t been addressed by any drafts (which is cal= led =93Proxy Nodes=94 by draft-quinn-nsh-01). > > We put together a draft to analyze the issues associated with chaining ex= isting > Layer 4-7 service functions that are not aware of service > encapsulation layers. This draft also examines the network > architecture for chaining existing L4-L7 service functions. The > intent is to identify and describe gaps that have not been > addressed by other SFC drafts. > > Your comments are greatly appreciated. > > > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > Revision: 00 > Title: Architecture for Chaining Legacy Layer 4-7 Service= Functions > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-leg= acy-l4-l7-chain-architecture-00.txt > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-= l4-l7-chain-architecture > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-l7= -chain-architecture-00 > > > Linda, Ning, Ian, Sumandra, and Donald > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From sarikaya2012@gmail.com Wed Oct 23 09:29:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767D811E81B5 for ; Wed, 23 Oct 2013 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o62tIEzXzHvH for ; Wed, 23 Oct 2013 09:29:18 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA6B11E83CB for ; Wed, 23 Oct 2013 09:29:12 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id p9so1114164lbv.27 for ; Wed, 23 Oct 2013 09:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kH8CjgY10UbJgxlVz1nqnCJIsKoN94P3vhoqEB81oOM=; b=zy3jf+0PQ4re574Eir9ymFkhNrcXXk3N7GxnKW0qS5hQE6gVzVU9oWuHHoYmjCa2DA WTFBugI4wx/jU/ZB+ZAc09NnohFO5GDACfiOjAzJxzZHxUrZttH8YgtfRwBKbLFaFdCO 5pvy60dccfn+UJW8xr7mr+4+1WLXfdyhJdCZdttzE67ax9mMwjofagoPeRsfrSeGP/Nt VufaVnZ837hdnfQoi7Ku7uGEsvfq8s8/AEqYbno/u+OyGoZGWqVbNjLPQePFy/H6IT19 NH7uU6rsls9MMTuEbOuWQXxG+DSyHvzmTvXrF5uBhlrnbRgQBQyrdp3E0hIczixxG3jI 3uUQ== MIME-Version: 1.0 X-Received: by 10.152.8.51 with SMTP id o19mr1873555laa.42.1382545751329; Wed, 23 Oct 2013 09:29:11 -0700 (PDT) Received: by 10.114.98.227 with HTTP; Wed, 23 Oct 2013 09:29:11 -0700 (PDT) In-Reply-To: <01FE63842C181246BBE4CF183BD159B448F290C4@nkgeml504-mbx.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B448F290C4@nkgeml504-mbx.china.huawei.com> Date: Wed, 23 Oct 2013 11:29:11 -0500 Message-ID: From: Behcet Sarikaya To: "nsc@ietf.org" Content-Type: multipart/alternative; boundary=001a11c352aa64d16204e96b04c8 Cc: Xueli Subject: [nsc] Fwd: FW: New Version Notification for draft-xue-aps-service-chaining-usecase-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 16:29:19 -0000 --001a11c352aa64d16204e96b04c8 Content-Type: text/plain; charset=ISO-8859-1 Hi all**** ** ** There is a new draft which is the use case about address sharing issues in service function chaining.**** The use cases are on the parental control service and offloading service.*** * Your comments and opinions are appreciated.**** ** ** Regards**** Li **** ** ** On Mon, Oct 21, 2013 at 11:07 AM, wrote:**** A new version of I-D, draft-xue-aps-service-chaining-usecase-00.txt has been successfully submitted by Li Xue and posted to the IETF repository. Filename: draft-xue-aps-service-chaining-usecase Revision: 00 Title: Address Sharing Problem Use Cases in Service Chaining Scenario Creation date: 2013-10-21 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-xue-aps-service-chaining-usecase-00.txt Status: http://datatracker.ietf.org/doc/draft-xue-aps-service-chaining-usecase Htmlized: http://tools.ietf.org/html/draft-xue-aps-service-chaining-usecase-00 Abstract: The purpose of this document is to present two use cases on problems arising from address sharing in service function chaining. The use cases are on the parental control service and offloading service. 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**** ** ** --001a11c352aa64d16204e96b04c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi all<= /u>

=A0=

There is a= new draft which is the use case about address sharing issues in service fu= nction chaining.

The use ca= ses are on the parental control service and offloading service.

Your= comments and opinions are appreciated.

=A0=

Regards=

Li


<= div>

= =A0

On Mon, Oct 21, 2013 at 11:07 A= M, <intern= et-drafts@ietf.org> wrote:

=
A new version of I-D, draft-xue-aps-service-chaining-usecase-00.txt
has been successfully submitted by Li Xue and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-xue-aps-service-chaining-usecase
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Address Sharing Problem Use Cases in Service Cha= ining Scenario
Creation date: =A0 2013-10-21
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-xue-aps-service-chaining-usecase-= 00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.iet= f.org/doc/draft-xue-aps-service-chaining-usecase
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html= /draft-xue-aps-service-chaining-usecase-00


Abstract:
=A0 =A0The purpose of this document is to present two use cases on problems=
=A0 =A0arising from address sharing in service function chaining. =A0The us= e
=A0 =A0cases are on the parental control service and offloading service.



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

The IETF Secretariat

=A0


--001a11c352aa64d16204e96b04c8-- From S.Majee@F5.com Wed Oct 23 11:02:31 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BB821E808C for ; Wed, 23 Oct 2013 11:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTU-aipPnVJR for ; Wed, 23 Oct 2013 11:02:27 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 390CC21E8097 for ; Wed, 23 Oct 2013 11:02:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,555,1378857600"; d="scan'208";a="85029125" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 23 Oct 2013 18:02:25 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 11:02:24 -0700 From: Sumandra Majee To: "Diego R. Lopez" , Ron Parker Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOz/7+lVdG4iUe7UOTLa38nJa9LpoCkD4g Date: Wed, 23 Oct 2013 18:02:23 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098848CF508@SEAEMBX01.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4780BEE6-9A1B-4EF4-BE0E-405BEEC8E9A6@tid.es> In-Reply-To: <4780BEE6-9A1B-4EF4-BE0E-405BEEC8E9A6@tid.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" , Donald Eastlake , Ning So , Ian Smith , Linda Dunbar Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:02:31 -0000 >>What I find strange is the usage of the "L4-L7" label to qualify the kind= of services being considered, as my understanding is that principles are g= enerally applicable, unless you understand that almost anything is a L4-L7 = service (like the mention of things like NAT seems to imply) Why not talk a= bout legacy chain mechanisms in plain? [SM] You are correct this approach is broadly applicable, however the l7 se= rvices e.g. content optimizers, protocol converters etc. are often inserted= dynamically based on deeper classification (http request hdr, response si= de etc.). =20 -----Original Message----- From: Diego R. Lopez [mailto:diego@tid.es]=20 Sent: Wednesday, October 23, 2013 7:49 AM To: Ron Parker Cc: Linda Dunbar; nsc@ietf.org; Donald Eastlake; Ian Smith; Ning So; Sumand= ra Majee Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Hi, I fully agree with Ron in finding this draft extremely valuable in how to a= chieve SFC without supporting the SFC procedures-to-be, and therefore a key= aspect for supporting migration and satisfying one of the key requirements= that were made at the beginning of the NSC/SFC discussion (by Maria Napier= ala, if I remember well) Furthermore, I find the node classification into p= roxy-based and packet-based extremely interesting and worth more deep explo= ration, including the reflection on nodes able to change the values under w= hich classification was originally performed. What I find strange is the usage of the "L4-L7" label to qualify the kind o= f services being considered, as my understanding is that principles are gen= erally applicable, unless you understand that almost anything is a L4-L7 se= rvice (like the mention of things like NAT seems to imply) Why not talk abo= ut legacy chain mechanisms in plain? Be goode, On 22 Oct 2013, at 00:01 , Ron Parker wrote: > Hi, Linda. > > This contribution is very useful in adding clarity as to how SFC can be r= ealized with legacy service functions. I do have a few comments and one o= verall theme regarding "steering", which I consider the legacy approach tha= t we are trying to improve in SFC. > > Respectfully, > > Ron > > > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) -- = although it may be slightly off topic for your draft, it occurs to me that = the proxy nodes would be ideal locations to load balance towards multiple i= nstances of the same type of service node (i.e., combining proxy-node and l= oad-balancing). > > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), the= first indented bullet states that the service function can be embedded in = a service chain proxy. From a software implementation perspective that ma= kes perfect sense. But from a network topology perspective, the proxy wou= ld not be explicitly observable -- the service function would look like it = had native SFC capabilities with respect to other SFC service nodes and/or = classifiers. > > Also in section 4.1, there is discussion of particular network topologies= . It has been proposed in other drafts that the SFC approach be topology = unaware. > > Section 4.2 (traffic steering). Consistent with my comment above, my fe= eling is that one of the biggest advantages of SFC is to become topology an= d transport unaware so that a new mechanism need not be invented for every = combination of network topology (i.e., 1 hop away, 2 hops away, more) and t= ransport technology (i.e., MAC bridging, IP forwarding, MPLS LER/LSR, ACL-b= ased filtered forwarding, etc.). > > Section 5.1 (multiple instances). Consistent with comments above, with = correct separation of the logical and physical, steering tables would not n= eed to be updated each time an NFV event occurred (i.e., instace up, down, = moved, expanded, contracted, etc.). > > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar comment= s to above. If we choose a topology and transport independent mechanism t= o follow a service chain, the complexity is reduced and the reliability is = improved. Something akin to the steering that you mention is constrained= to the classification node(s), greatly simplifying the service nodes. > > > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Lin= da Dunbar > Sent: Monday, October 21, 2013 5:15 PM > To: nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7= -chain-architecture-00.txt > > There have been many drafts submitted for SFC (Service Function Chaining)= BOF already. However, we felt that architecture and issues associated with= chaining existing Layer 4-7 service functions that are not aware of Servic= e Encapsulation header haven't been addressed by any drafts (which is calle= d "Proxy Nodes" by draft-quinn-nsh-01). > > We put together a draft to analyze the issues associated with chaining ex= isting > Layer 4-7 service functions that are not aware of service > encapsulation layers. This draft also examines the network > architecture for chaining existing L4-L7 service functions. The > intent is to identify and describe gaps that have not been > addressed by other SFC drafts. > > Your comments are greatly appreciated. > > > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > Revision: 00 > Title: Architecture for Chaining Legacy Layer 4-7 Service= Functions > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-leg= acy-l4-l7-chain-architecture-00.txt > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-legacy-= l4-l7-chain-architecture > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-l7= -chain-architecture-00 > > > Linda, Ning, Ian, Sumandra, and Donald > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From diego@tid.es Wed Oct 23 11:20:23 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9D11E8198 for ; Wed, 23 Oct 2013 11:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngv4w0Hw0K5w for ; Wed, 23 Oct 2013 11:20:08 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A56111E83E8 for ; Wed, 23 Oct 2013 11:20:07 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MV40045UW9I5A@tid.hi.inet> for nsc@ietf.org; Wed, 23 Oct 2013 20:20:06 +0200 (MEST) Received: from dequeue_removeroute (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id F3.70.03197.65318625; Wed, 23 Oct 2013 20:20:06 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MV40045LW9H5A@tid.hi.inet> for nsc@ietf.org; Wed, 23 Oct 2013 20:20:06 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Wed, 23 Oct 2013 20:20:05 +0200 Date: Wed, 23 Oct 2013 18:20:04 +0000 From: "Diego R. Lopez" In-reply-to: <0BF7E0211CA62B42AE3FD4020E416098848CF508@SEAEMBX01.olympus.F5Net.com> X-Originating-IP: [10.95.64.115] To: Sumandra Majee Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, es-ES Thread-topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-index: AQHO0BoO5vryRUubD0yHc7huuKBJppoCdzSA X-AuditID: 0a5f4068-b7f3e8e000000c7d-60-52681356e953 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42Lhinfg0g0TzggymL5Y0OL4vv1sDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK2P39KHvBHZ6KXddKGhjXcnUxcnBICJhILJpe0cXICWSKSVy4 t56ti5GLQ0jgIKPEqr/nWSGcb4wSO989Z4dwZjJKnPi8mQWkhUVAVaL93ilWEJsNyH7U/Jsd ZKqwQKbEmW5xkDCnQKjEtCVr2SA2KEj8OfcYrFVEQFniV9sJZpCZzALPGSUWrd/HCJLgFbCU mHTmHDuIzSxgJvH3w1QmiLigxI/J91gg4joSvd+/MUPY4hLNrTeh4toST95dALuHUUBW4t38 +awQy7Ik+rZuYYawjSQu/l8OdZCAxJI955khbFGJl4//QX28kElixvUZbBMYJWYhuWMWkjtm IbljFpI7ZiG5YwEj6ypGseKkosz0jJLcxMycdANDvYxMvcy81JJNjJC4y9jBuHynyiFGAQ5G JR5ejQ/pQUKsiWXFlbmHGCU4mJVEeJ/8AQrxpiRWVqUW5ccXleakFh9iZOLglGpg3FMuYXp+ VrVX8j/HM1+1ggxdFdV+r5kXysZyM3m9gOUtYRuJha22xdVMKROiN+v59ImJq8af3PDMWfVo y8dLlS93/M/htti2d5agf6vim0LmVWfO81iG6L/4XlVRw6Rl9arItSzRPlRnv5B88fHDM3R0 1tixn+D3eTXzwXJZZ82E7JYjDTuUWIozEg21mIuKEwFDcbHTmQIAAA== References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4780BEE6-9A1B-4EF4-BE0E-405BEEC8E9A6@tid.es> <0BF7E0211CA62B42AE3FD4020E416098848CF508@SEAEMBX01.olympus.F5Net.com> Cc: "nsc@ietf.org" , Ron Parker , Ian Smith , Linda Dunbar , Ning So , Donald Eastlake Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 18:20:23 -0000 On 23 Oct 2013, at 20:02 , Sumandra Majee wrote: >>> What I find strange is the usage of the "L4-L7" label to qualify the ki= nd of services being considered, as my understanding is that principles are= generally applicable, unless you understand that almost anything is a L4-L= 7 service (like the mention of things like NAT seems to imply) Why not talk= about legacy chain mechanisms in plain? > > [SM] You are correct this approach is broadly applicable, however the l7 = services e.g. content optimizers, protocol converters etc. are often insert= ed dynamically based on deeper classification (http request hdr, response = side etc.). > I can agree with this, but let me insist in this fact not justifying that t= hose general principles are only discussed in the document for those L4-L7 = services. I see there a difference in the classification mechanisms (also a= pplicable for SFC-tagged environments) but not in the purpose of the servic= es... Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D http://people.tid.es/diego.lopez/ e-mail: diego@tid.es Tel: +34 913 129 041 Mobile: +34 682 051 091 ----------------------------------------- ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx From S.Majee@F5.com Wed Oct 23 13:44:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB29011E8215 for ; Wed, 23 Oct 2013 13:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmIIEmOszrTU for ; Wed, 23 Oct 2013 13:44:43 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 941E011E821A for ; Wed, 23 Oct 2013 13:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=S.Majee@f5.com; q=dns/txt; s=seattle; t=1382561050; x=1414097050; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hxp3pGNzB2cnVkvejskXMr5jozCWjm1CjGwFqHc867w=; b=ypEzsgXdlyHoCUWmjSxEORneV6dZXpdGyopLdmipPmbERKTRHhifJKJI vFgqcAjsgffjCX+8jNlbN+htJLAAzaxEW9dmPOehdi53CcBImmYnFkJO0 xtnMhU9m28Q/MVkjJGoQUHXL+RpRgkBiazUpBdaskzLq3dKdNdKkua3dr g=; X-IronPort-AV: E=Sophos;i="4.93,556,1378857600"; d="scan'208";a="84265300" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 23 Oct 2013 20:43:58 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 13:43:57 -0700 From: Sumandra Majee To: Ron Parker , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrLfNNaagQZEeSXSekqoV235oBo1qAgAAVmgCAAPm68A== Date: Wed, 23 Oct 2013 20:43:57 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.236] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Donald Eastlake , Ian Smith , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 20:44:48 -0000 PkkgZG8gaGF2ZSBhIGZldyBjb21tZW50cyBhbmQgb25lIG92ZXJhbGwgdGhlbWUgcmVnYXJkaW5n ICJzdGVlcmluZyIsIHdoaWNoIEkgY29uc2lkZXIgdGhlIGxlZ2FjeSBhcHByb2FjaCB0aGF0IHdl IGFyZSB0cnlpbmcgdG8gaW1wcm92ZSBpbiBTRkMuDQoNCltTTV0gTm90IHN1cmUgSSBnZXQgdGhl IGRpc3RpbmN0aW9uIGJldHdlZW4gImNoYWluaW5nIiBhbmQgInN0ZWVyaW5nIi4gIFRoZSBMNyBz ZXJ2aWNlcyBhcmUgb2Z0ZW4gaW5zZXJ0ZWQgZHluYW1pY2FsbHkgdG8gdGhlIHNlcnZpY2UgY2hh aW4gYmFzZWQgb24gMSkgbGF0ZXIgY2xhc3NpZmljYXRpb24gMikgYmFzZWQgb24gbmV0d29yayBj b25kaXRpb24gbGlrZSAic3RlZXJpbmciIHRvIHZpZGVvIG9wdGltaXplciB3aGVuIGF2YWlsYWJs ZSBiYW5kd2lkdGggZmFsbHMgYmVsb3cgY2VydGFpbiB0aHJlc2hvbGQuIA0KDQo+IA0KPiBBbHNv IGluIHNlY3Rpb24gNC4xLCB0aGVyZSBpcyBkaXNjdXNzaW9uIG9mIHBhcnRpY3VsYXIgbmV0d29y aw0KPiB0b3BvbG9naWVzLiAgIEl0IGhhcyBiZWVuIHByb3Bvc2VkIGluIG90aGVyIGRyYWZ0cyB0 aGF0IHRoZSBTRkMNCj4gYXBwcm9hY2ggYmUgdG9wb2xvZ3kgdW5hd2FyZS4NCj4gDQpbTGluZGFd ICBJbiB0aGlzIGNvbnRleHQsIHRoZSBQcm94eSBub2RlcyBhcmUgdG9wb2xvZ3kgdW5hd2FyZS4g QnV0IHByb3h5IG5vZGVzIGtub3cgdGhlaXIgY29ubmVjdGlvbiB0byB0aGUgZGlyZWN0bHkgY29u bmVjdGVkIHNlcnZpY2UgZnVuY3Rpb25zLiBJcyBpdCBPSz8gIA0KW1Jvbl0gSSB0aGluayB0aGlz IGdvZXMgdG8gd2hlcmUgdGhlIGludGVsbGlnZW5jZSBpcyBmb3IgdGhlIGZvcndhcmRpbmcuDQoN CltTTV0gQWdyZWVkIHRoYXQgdGhlIGZvcndhcmRpbmcgcG9pbnQgbmVlZCB0byBiZSBhd2FyZSBv ZiB0aGUgdG9wb2xvZ3kgYnV0IHByb3h5LW5vZGUgaXRzZWxmIGRvZXNuJ3QgbmVlZCB0by4gDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSb24gUGFya2VyIFttYWlsdG86Um9u X1BhcmtlckBhZmZpcm1lZG5ldHdvcmtzLmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDIy LCAyMDEzIDI6NDkgUE0NClRvOiBMaW5kYSBEdW5iYXI7IG5zY0BpZXRmLm9yZw0KQ2M6IERvbmFs ZCBFYXN0bGFrZTsgTmluZyBTbzsgSWFuIFNtaXRoOyBTdW1hbmRyYSBNYWplZQ0KU3ViamVjdDog UkU6IFtuc2NdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZHVuYmFyLXNmYy1s ZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwLnR4dA0KDQpIaSwgTGluZGEuDQoNClJl c3BvbnNlcyBpbmxpbmUuDQoNCglSb24NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogTGluZGEgRHVuYmFyIFttYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQpTZW50 OiBUdWVzZGF5LCBPY3RvYmVyIDIyLCAyMDEzIDQ6MzEgUE0NClRvOiBSb24gUGFya2VyOyBuc2NA aWV0Zi5vcmcNCkNjOiBEb25hbGQgRWFzdGxha2U7IE5pbmcgU287IElhbiBTbWl0aDsgU3VtYW5k cmEgTWFqZWUNClN1YmplY3Q6IFJFOiBbbnNjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y IGRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQN Cg0KUm9uLCANCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHZhbHVhYmxlIGNvbW1lbnRz LiBTZWUgbXkgcmVzcG9uc2UgaW5zZXJ0ZWQgYmVsb3c6DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gDQo+IA0KPiBJbiBzZWN0aW9uIDMuMywgZmlndXJlIDIgKENoYWluZ2luZyBl eGlzdGluZyBMYXllciA0LTcgc2VydmljZSBub2RlcykNCj4gLQ0KPiAtIGFsdGhvdWdoIGl0IG1h eSBiZSBzbGlnaHRseSBvZmYgdG9waWMgZm9yIHlvdXIgZHJhZnQsIGl0IG9jY3VycyB0byANCj4g bWUgdGhhdCB0aGUgcHJveHkgbm9kZXMgd291bGQgYmUgaWRlYWwgbG9jYXRpb25zIHRvIGxvYWQg YmFsYW5jZSANCj4gdG93YXJkcyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNhbWUgdHlwZSBv ZiBzZXJ2aWNlIG5vZGUgKGkuZS4sIA0KPiBjb21iaW5pbmcgcHJveHktbm9kZSBhbmQgbG9hZC1i YWxhbmNpbmcpLg0KDQpbTGluZGFdIGFyZSB5b3Ugc2F5aW5nIHRoYXQgbXVsdGlwbGUgaW5zdGFu Y2VzIGFyZSBjby1sb2NhdGVkPyBXaGF0IGlmIG11bHRpcGxlIGluc3RhbmNlcyBmb3Igb25lIG5l dHdvcmsgZnVuY3Rpb24gYXJlIGxvY2F0ZWQgaW4gZGlmZmVyZW50IHBsYWNlcz8gDQpEbyB5b3Ug dGhpbmsgdGhlICJwcm94eSBub2RlIiBzaG91bGQgYmFsYW5jZSB0aGVtLCBvciBzaG91bGQgdGhl IGNvbnRyb2xsZXIgYmFsYW5jZSB0aGVtIGFuZCBzaW1wbHkgaW5mb3JtIHRoZSAicHJveHkgbm9k ZSI/ICBvciBjb21iaW5hdGlvbiBvZiBib3RoPw0KDQoNCltSb25dIE15IHRoaW5raW5nLCBzbyBm YXIsIGlzIHRoYXQgYSBsb2FkLWJhbGFuY2VyIGlzLCBpdHNlbGYgYSBuZXR3b3JrIHNlcnZpY2Ug ZnVuY3Rpb24gd2hpY2ggdW5kZXJzdGFuZHMgdGhhdCBpdCBtYW5nZXMgc29tZSBzZXQgb2YgZnVu Y3Rpb25hbGx5IGVxdWl2YWxlbnQgc3VidGVuZGVkIG5ldHdvcmsgc2VydmljZSBmdW5jdGlvbiBp bnN0YW5jZXMuICAgIEJ1dCwgZnJvbSBhIGxvZ2ljYWwgcGVyc3BlY3RpdmUsIEkgdGhpbmsgdGhh dCBJIGhhdmUgYXJndWVkIG15c2VsZiBvdXQgb2YgY28tbWluZ2xpbmcgdGhlIHByb3h5IGNvbmNl cHQgYW5kIHRoZSBsb2FkIGJhbGFuY2luZyBjb25jZXB0LiAgIFRoZXkgY2FuIGJlIG1peGVkIGFu ZCBtYXRjaGVkIGFzIG5lY2Vzc2FyeSwgYW5kIGNvLWxvY2F0ZWQgYXMgZGVzaXJlZC4gICBGb3Ig ZXhhbXBsZSwgYSBjaGFpbiBtYXkgaW5kaWNhdGUgdGhhdCBhIGxvYWQtYmFsYW5jZXIgbXVzdCBi ZSB2aXNpdGVkLiAgIFRoZSBsb2FkIGJhbGFuY2VyIGJhbGFuY2VzIHRvIG11bHRpcGxlIGluc3Rh bmNlcyBvZiBwcm94eS1mcm9udGVkIG5vbi1TRkMtYXdhcmUgc2VydmljZSBmdW5jdGlvbnMuICAg IEJ1dCwgYWxsIG9mIHRoaXMgaXMgb2ZmLXRvcGljLCBzbyBJIGFwb2xvZ2l6ZSBmb3IgaW50cm9k dWNpbmcgaXQgaGVyZS4NCg0KPiANCj4gSW4gc2VjdGlvbiA0LjEgKEw0LUw3IG5vZGVzIGNvbm5l Y3Rpb24gdG8gU2VydmljZSBDaGFpbiBQcm94eSBOb2RlcyksIA0KPiB0aGUgZmlyc3QgaW5kZW50 ZWQgYnVsbGV0IHN0YXRlcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9uIGNhbiBiZQ0KPiBlbWJl ZGRlZCBpbiBhIHNlcnZpY2UgY2hhaW4gcHJveHkuICAgRnJvbSBhIHNvZnR3YXJlIGltcGxlbWVu dGF0aW9uDQo+IHBlcnNwZWN0aXZlIHRoYXQgbWFrZXMgcGVyZmVjdCBzZW5zZS4gICBCdXQgZnJv bSBhIG5ldHdvcmsgdG9wb2xvZ3kNCj4gcGVyc3BlY3RpdmUsIHRoZSBwcm94eSB3b3VsZCBub3Qg YmUgZXhwbGljaXRseSBvYnNlcnZhYmxlIC0tIHRoZSANCj4gc2VydmljZSBmdW5jdGlvbiB3b3Vs ZCBsb29rIGxpa2UgaXQgaGFkIG5hdGl2ZSBTRkMgY2FwYWJpbGl0aWVzIHdpdGggDQo+IHJlc3Bl Y3QgdG8gb3RoZXIgU0ZDIHNlcnZpY2Ugbm9kZXMgYW5kL29yIGNsYXNzaWZpZXJzLg0KDQpbTGlu ZGFdIEkgd2lsbCBjaGFuZ2UgdGhlIHRleHQgdG8gcmVmbGVjdCB0aGlzIHBvaW50LiBPbiB0aGUg b3RoZXIgaGFuZCwgbWFueSBvZiB0b2RheSdzIHNlcnZpY2UgZnVuY3Rpb25zIGFyZSBpbmRlcGVu ZGVudC4gVGhleSBkb24ndCBjYXJlIHdobyBpcyBhaGVhZCBvZiB0aGVtIGFuZCB3aG8gaXMgYWZ0 ZXIuIEhvdyB3b3VsZCB5b3UgZGVzY3JpYmUgdGhpcyBzY2VuYXJpbz8NCg0KDQpbUm9uXSBJIHRo aW5rIHdlIGFyZSBzYXlpbmcgdGhhdCB0byBiZSBTRkMtYXdhcmUgaXMgdG8ga25vdywgZXhwbGlj aXRseSwgd2hpY2ggc2VydmljZSBmdW5jdGlvbiBpcyBuZXh0LiAgIEEgc2VydmljZSBmdW5jdGlv biB3aGljaCBkb2Vzbid0IHVuZGVyc3RhbmQgdGhhdCBjb25jZXB0IGlzIGZyb250LWVuZGVkIGJ5 IGFuIFNGQy1wcm94eS4NCg0KIA0KPiANCj4gQWxzbyBpbiBzZWN0aW9uIDQuMSwgdGhlcmUgaXMg ZGlzY3Vzc2lvbiBvZiBwYXJ0aWN1bGFyIG5ldHdvcmsNCj4gdG9wb2xvZ2llcy4gICBJdCBoYXMg YmVlbiBwcm9wb3NlZCBpbiBvdGhlciBkcmFmdHMgdGhhdCB0aGUgU0ZDDQo+IGFwcHJvYWNoIGJl IHRvcG9sb2d5IHVuYXdhcmUuDQo+IA0KW0xpbmRhXSAgSW4gdGhpcyBjb250ZXh0LCB0aGUgUHJv eHkgbm9kZXMgYXJlIHRvcG9sb2d5IHVuYXdhcmUuIEJ1dCBwcm94eSBub2RlcyBrbm93IHRoZWly IGNvbm5lY3Rpb24gdG8gdGhlIGRpcmVjdGx5IGNvbm5lY3RlZCBzZXJ2aWNlIGZ1bmN0aW9ucy4g SXMgaXQgT0s/ICANCg0KW1Jvbl0gSSB0aGluayB0aGlzIGdvZXMgdG8gd2hlcmUgdGhlIGludGVs bGlnZW5jZSBpcyBmb3IgdGhlIGZvcndhcmRpbmcuDQoNCk1heWJlIHdlIGNhbiBjaGF0IGZhY2Ug dG8gZmFjZSBpbiBWYW5jb3V2ZXIgZm9yIHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KDQpbUm9uXSBJ dCB3b3VsZCBiZSBteSBwbGVhc3VyZSA6KS4gICBQbGVhc2UgY29udGFjdCBtZSBwcml2YXRlbHku DQogDQoNCkxpbmRhDQo+IFNlY3Rpb24gNC4yICh0cmFmZmljIHN0ZWVyaW5nKS4gICBDb25zaXN0 ZW50IHdpdGggbXkgY29tbWVudCBhYm92ZSwgbXkNCj4gZmVlbGluZyBpcyB0aGF0IG9uZSBvZiB0 aGUgYmlnZ2VzdCBhZHZhbnRhZ2VzIG9mIFNGQyBpcyB0byBiZWNvbWUgDQo+IHRvcG9sb2d5IGFu ZCB0cmFuc3BvcnQgdW5hd2FyZSBzbyB0aGF0IGEgbmV3IG1lY2hhbmlzbSBuZWVkIG5vdCBiZSAN Cj4gaW52ZW50ZWQgZm9yIGV2ZXJ5IGNvbWJpbmF0aW9uIG9mIG5ldHdvcmsgdG9wb2xvZ3kgKGku ZS4sIDEgaG9wIGF3YXksDQo+IDIgaG9wcyBhd2F5LCBtb3JlKSBhbmQgdHJhbnNwb3J0IHRlY2hu b2xvZ3kgKGkuZS4sIE1BQyBicmlkZ2luZywgSVAgDQo+IGZvcndhcmRpbmcsIE1QTFMgTEVSL0xT UiwgQUNMLWJhc2VkIGZpbHRlcmVkIGZvcndhcmRpbmcsIGV0Yy4pLg0KPiANCj4gU2VjdGlvbiA1 LjEgKG11bHRpcGxlIGluc3RhbmNlcykuICAgQ29uc2lzdGVudCB3aXRoIGNvbW1lbnRzIGFib3Zl LA0KPiB3aXRoIGNvcnJlY3Qgc2VwYXJhdGlvbiBvZiB0aGUgbG9naWNhbCBhbmQgcGh5c2ljYWws IHN0ZWVyaW5nIHRhYmxlcyANCj4gd291bGQgbm90IG5lZWQgdG8gYmUgdXBkYXRlZCBlYWNoIHRp bWUgYW4gTkZWIGV2ZW50IG9jY3VycmVkIChpLmUuLCANCj4gaW5zdGFjZSB1cCwgZG93biwgbW92 ZWQsIGV4cGFuZGVkLCBjb250cmFjdGVkLCBldGMuKS4NCj4gDQo+IFNlY3Rpb24gNS4yIChjaGFs bGVuZ2VzIG9mIExheWVyIDQtNyB0cmFmZmljIHN0ZWVyaW5nKS4gICBTaW1pbGFyDQo+IGNvbW1l bnRzIHRvIGFib3ZlLiAgIElmIHdlIGNob29zZSBhIHRvcG9sb2d5IGFuZCB0cmFuc3BvcnQgaW5k ZXBlbmRlbnQNCj4gbWVjaGFuaXNtIHRvIGZvbGxvdyBhIHNlcnZpY2UgY2hhaW4sIHRoZSBjb21w bGV4aXR5IGlzIHJlZHVjZWQgYW5kIHRoZQ0KPiByZWxpYWJpbGl0eSBpcyBpbXByb3ZlZC4gICAg U29tZXRoaW5nIGFraW4gdG8gdGhlIHN0ZWVyaW5nIHRoYXQgeW91DQo+IG1lbnRpb24gaXMgY29u c3RyYWluZWQgdG8gdGhlIGNsYXNzaWZpY2F0aW9uIG5vZGUocyksIGdyZWF0bHkgDQo+IHNpbXBs aWZ5aW5nIHRoZSBzZXJ2aWNlIG5vZGVzLg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbnNjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpuc2Mt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIA0KPiBMaW5kYSBEdW5iYXINCj4gU2VudDog TW9uZGF5LCBPY3RvYmVyIDIxLCAyMDEzIDU6MTUgUE0NCj4gVG86IG5zY0BpZXRmLm9yZw0KPiBD YzogRG9uYWxkIEVhc3RsYWtlOyBOaW5nIFNvOyBJYW4gU21pdGg7IFN1bWFuZHJhIE1hamVlDQo+ IFN1YmplY3Q6IFtuc2NdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQtZHVu YmFyLXNmYy1sZWdhY3ktbDQtIGw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQNCj4gDQo+IFRo ZXJlIGhhdmUgYmVlbiBtYW55IGRyYWZ0cyBzdWJtaXR0ZWQgZm9yIFNGQyAoU2VydmljZSBGdW5j dGlvbg0KPiBDaGFpbmluZykgQk9GIGFscmVhZHkuIEhvd2V2ZXIsIHdlIGZlbHQgdGhhdCBhcmNo aXRlY3R1cmUgYW5kIGlzc3VlcyANCj4gYXNzb2NpYXRlZCB3aXRoIGNoYWluaW5nIGV4aXN0aW5n IExheWVyIDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSANCj4gbm90IGF3YXJlIG9mIFNl cnZpY2UgRW5jYXBzdWxhdGlvbiBoZWFkZXIgaGF2ZW7igJl0IGJlZW4gYWRkcmVzc2VkIGJ5IA0K PiBhbnkgZHJhZnRzICh3aGljaCBpcyBjYWxsZWQg4oCcUHJveHkgTm9kZXPigJ0gYnkgZHJhZnQt cXVpbm4tbnNoLTAxKS4NCj4gDQo+IFdlIHB1dCB0b2dldGhlciBhIGRyYWZ0IHRvIGFuYWx5emUg dGhlIGlzc3VlcyBhc3NvY2lhdGVkIHdpdGggY2hhaW5pbmcgDQo+IGV4aXN0aW5nDQo+ICAgIExh eWVyIDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0IGFyZSBub3QgYXdhcmUgb2Ygc2VydmljZQ0K PiAgICBlbmNhcHN1bGF0aW9uIGxheWVycy4gVGhpcyBkcmFmdCBhbHNvIGV4YW1pbmVzIHRoZSBu ZXR3b3JrDQo+ICAgIGFyY2hpdGVjdHVyZSBmb3IgY2hhaW5pbmcgZXhpc3RpbmcgTDQtTDcgc2Vy dmljZSBmdW5jdGlvbnMuIFRoZQ0KPiAgICBpbnRlbnQgaXMgdG8gaWRlbnRpZnkgYW5kIGRlc2Ny aWJlIGdhcHMgdGhhdCBoYXZlIG5vdCBiZWVuDQo+ICAgIGFkZHJlc3NlZCBieSBvdGhlciBTRkMg ZHJhZnRzLg0KPiANCj4gWW91ciBjb21tZW50cyBhcmUgZ3JlYXRseSBhcHByZWNpYXRlZC4NCj4g DQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LWw3LWNoYWluLWFy Y2hpdGVjdHVyZQ0KPiBSZXZpc2lvbjoJIDAwDQo+IFRpdGxlOgkJIEFyY2hpdGVjdHVyZSBmb3Ig Q2hhaW5pbmcgTGVnYWN5IExheWVyIDQtNyBTZXJ2aWNlDQo+IEZ1bmN0aW9ucw0KPiBDcmVhdGlv biBkYXRlOgkgMjAxMy0xMC0xNg0KPiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4g TnVtYmVyIG9mIHBhZ2VzOiAxNg0KPiBVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWR1bmJhci1zZmMtDQo+IGxlZ2FjeS1sNC1sNy1jaGFp bi1hcmNoaXRlY3R1cmUtMDAudHh0DQo+IFN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLQ0KPiBsZWdhY3ktbDQtbDctY2hhaW4t YXJjaGl0ZWN0dXJlDQo+IEh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtZHVuYmFyLXNmYy1sZWdhY3ktbDQtDQo+IGw3LWNoYWluLWFyY2hpdGVjdHVyZS0w MA0KPiANCj4gDQo+IExpbmRhLCBOaW5nLCBJYW4sIFN1bWFuZHJhLCBhbmQgRG9uYWxkDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuc2Mg bWFpbGluZyBsaXN0DQo+IG5zY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25zYw0K From jguichar@cisco.com Wed Oct 23 15:25:44 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74DE11E8266 for ; Wed, 23 Oct 2013 15:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWbZ2Y0nHvp5 for ; Wed, 23 Oct 2013 15:25:39 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 699FC11E8250 for ; Wed, 23 Oct 2013 15:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8862; q=dns/txt; s=iport; t=1382567139; x=1383776739; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=8waFG0D0d6B5Utl5VzTWwmCUvyD3KoKfC9Cn6db1mdk=; b=fLAPcDvSHIG2LwhDRx1JAX83WarrhdtygXOrorjros2fEHAgcclai33p EaNAwqbpGJhCZzNc3KX2KGInhztxasnIZgRSly78o3yKfYj6Q1XjCWlB/ SWIgZQxZab5bpmfIu8zz8ff5s/qkItz6oeAB+0gG3r3bmj3q0jGJlV4GE I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAI5MaFKtJXG9/2dsb2JhbABPCoMHOFS+VoErFnSCJQEBAQQBAQELVwkJAgwGAQgOAwEDAQELHS4LFAMGCAIEAQ0FCAGHfQ27RY4LgRIGKwcGgxmBCwOJB4sjhQ6QWIFmgT6CKg X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208";a="275870866" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 23 Oct 2013 22:25:38 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9NMPc5B029641 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 22:25:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 17:25:38 -0500 From: "Jim Guichard (jguichar)" To: Sumandra Majee , Ron Parker , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7M4bo+2KAbgEmsGb3qc1DuTw== Date: Wed, 23 Oct 2013 22:25:37 +0000 Message-ID: <68B171751455884590F8E38E96416F363F708124@xmb-rcd-x01.cisco.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So , Ian Smith Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:25:44 -0000 How can a proxy-node not know the topology? Maybe I am missing the point of this discussion but a proxy node (as defined in the reference made in draft-dunbar-sfc-legacy-l4-l7-chain) is a front-end to one or more service functions that are unable to process any type of service encapsulation. Therefore the proxy processes said encapsulation on their behalf. In order for a proxy to forward traffic to the next service function in the chain it *has* to know the topology. Further, a previous comment said "it has been proposed in other drafts that the SFC approach be topology unaware"; which proposal indicates this? I would agree that the SFC approach should be *transport independent* but topology awareness is necessary somewhere as otherwise one could not forward packets from/to the right places. On 10/23/13 4:43 PM, "Sumandra Majee" wrote: >>I do have a few comments and one overall theme regarding "steering", >>which I consider the legacy approach that we are trying to improve in >>SFC. > >[SM] Not sure I get the distinction between "chaining" and "steering". >The L7 services are often inserted dynamically to the service chain based >on 1) later classification 2) based on network condition like "steering" >to video optimizer when available bandwidth falls below certain >threshold.=20 > >>=20 >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >>=20 >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? =20 >[Ron] I think this goes to where the intelligence is for the forwarding. > >[SM] Agreed that the forwarding point need to be aware of the topology >but proxy-node itself doesn't need to. > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Tuesday, October 22, 2013 2:49 PM >To: Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Linda. > >Responses inline. > > Ron > > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Tuesday, October 22, 2013 4:31 PM >To: Ron Parker; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Ron,=20 > >Thank you very much for the valuable comments. See my response inserted >below: > >> -----Original Message----- >>=20 >>=20 >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). > >[Linda] are you saying that multiple instances are co-located? What if >multiple instances for one network function are located in different >places?=20 >Do you think the "proxy node" should balance them, or should the >controller balance them and simply inform the "proxy node"? or >combination of both? > > >[Ron] My thinking, so far, is that a load-balancer is, itself a network >service function which understands that it manges some set of >functionally equivalent subtended network service function instances. >But, from a logical perspective, I think that I have argued myself out of >co-mingling the proxy concept and the load balancing concept. They can >be mixed and matched as necessary, and co-located as desired. For >example, a chain may indicate that a load-balancer must be visited. The >load balancer balances to multiple instances of proxy-fronted >non-SFC-aware service functions. But, all of this is off-topic, so I >apologize for introducing it here. > >>=20 >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), >> the first indented bullet states that the service function can be >> embedded in a service chain proxy. From a software implementation >> perspective that makes perfect sense. But from a network topology >> perspective, the proxy would not be explicitly observable -- the >> service function would look like it had native SFC capabilities with >> respect to other SFC service nodes and/or classifiers. > >[Linda] I will change the text to reflect this point. On the other hand, >many of today's service functions are independent. They don't care who is >ahead of them and who is after. How would you describe this scenario? > > >[Ron] I think we are saying that to be SFC-aware is to know, explicitly, >which service function is next. A service function which doesn't >understand that concept is front-ended by an SFC-proxy. > >=20 >>=20 >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >>=20 >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? =20 > >[Ron] I think this goes to where the intelligence is for the forwarding. > >Maybe we can chat face to face in Vancouver for the following points. > >[Ron] It would be my pleasure :). Please contact me privately. >=20 > >Linda >> Section 4.2 (traffic steering). Consistent with my comment above, my >> feeling is that one of the biggest advantages of SFC is to become >> topology and transport unaware so that a new mechanism need not be >> invented for every combination of network topology (i.e., 1 hop away, >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). >>=20 >> Section 5.1 (multiple instances). Consistent with comments above, >> with correct separation of the logical and physical, steering tables >> would not need to be updated each time an NFV event occurred (i.e., >> instace up, down, moved, expanded, contracted, etc.). >>=20 >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar >> comments to above. If we choose a topology and transport independent >> mechanism to follow a service chain, the complexity is reduced and the >> reliability is improved. Something akin to the steering that you >> mention is constrained to the classification node(s), greatly >> simplifying the service nodes. >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Monday, October 21, 2013 5:15 PM >> To: nsc@ietf.org >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >> Subject: [nsc] New Version Notification for >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt >>=20 >> There have been many drafts submitted for SFC (Service Function >> Chaining) BOF already. However, we felt that architecture and issues >> associated with chaining existing Layer 4-7 service functions that are >> not aware of Service Encapsulation header haven=B9t been addressed by >> any drafts (which is called =B3Proxy Nodes=B2 by draft-quinn-nsh-01). >>=20 >> We put together a draft to analyze the issues associated with chaining >> existing >> Layer 4-7 service functions that are not aware of service >> encapsulation layers. This draft also examines the network >> architecture for chaining existing L4-L7 service functions. The >> intent is to identify and describe gaps that have not been >> addressed by other SFC drafts. >>=20 >> Your comments are greatly appreciated. >>=20 >>=20 >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture >> Revision: 00 >> Title: Architecture for Chaining Legacy Layer 4-7 Service >> Functions >> Creation date: 2013-10-16 >> Group: Individual Submission >> Number of pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture-00.txt >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- >> l7-chain-architecture-00 >>=20 >>=20 >> Linda, Ning, Ian, Sumandra, and Donald >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Wed Oct 23 15:40:11 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE7111E82AE for ; Wed, 23 Oct 2013 15:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYqmBwip1fLz for ; Wed, 23 Oct 2013 15:40:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 544FA11E83E4 for ; Wed, 23 Oct 2013 15:38:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXD07153; Wed, 23 Oct 2013 22:38:16 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 23:38:13 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 23 Oct 2013 23:38:16 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 15:38:09 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7SNf/CZ5QE9EyYtVfHaKGq/ZoC3t/Q Date: Wed, 23 Oct 2013 22:38:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BE7C78@dfweml509-mbb.china.huawei.com> References: <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <68B171751455884590F8E38E96416F363F708124@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F708124@xmb-rcd-x01.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.132.111] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Donald Eastlake , Ning So , Ian Smith Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:40:12 -0000 Jim,=20 There are tunnels (e.g. VxLAN, NVGRE, or others) interconnecting the "proxy= nodes" and "service nodes". Therefore, the "proxy nodes" know their connec= tion to other "Proxy nodes" or/and "service nodes", but "proxy nodes" don't= know the network topology underneath the "tunnels".=20 The "proxy nodes" are very much like "service nodes" in that sense. "Servic= e nodes" know their interconnection to other "service nodes", but "service = nodes" don't know the network topology underneath the "tunnels" that interc= onnect the "service nodes". =20 Linda > -----Original Message----- > From: Jim Guichard (jguichar) [mailto:jguichar@cisco.com] > Sent: Wednesday, October 23, 2013 5:26 PM > To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org > Cc: Donald Eastlake; Ian Smith; Ning So > Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc- > legacy-l4-l7-chain-architecture-00.txt >=20 > How can a proxy-node not know the topology? Maybe I am missing the > point > of this discussion but a proxy node (as defined in the reference made > in > draft-dunbar-sfc-legacy-l4-l7-chain) is a front-end to one or more > service > functions that are unable to process any type of service encapsulation. > Therefore the proxy processes said encapsulation on their behalf. In > order > for a proxy to forward traffic to the next service function in the > chain > it *has* to know the topology. >=20 > Further, a previous comment said "it has been proposed in other drafts > that the SFC approach be topology unaware"; which proposal indicates > this? > I would agree that the SFC approach should be *transport independent* > but > topology awareness is necessary somewhere as otherwise one could not > forward packets from/to the right places. >=20 > On 10/23/13 4:43 PM, "Sumandra Majee" wrote: >=20 > >>I do have a few comments and one overall theme regarding "steering", > >>which I consider the legacy approach that we are trying to improve in > >>SFC. > > > >[SM] Not sure I get the distinction between "chaining" and "steering". > >The L7 services are often inserted dynamically to the service chain > based > >on 1) later classification 2) based on network condition like > "steering" > >to video optimizer when available bandwidth falls below certain > >threshold. > > > >> > >> Also in section 4.1, there is discussion of particular network > >> topologies. It has been proposed in other drafts that the SFC > >> approach be topology unaware. > >> > >[Linda] In this context, the Proxy nodes are topology unaware. But > proxy > >nodes know their connection to the directly connected service > functions. > >Is it OK? > >[Ron] I think this goes to where the intelligence is for the > forwarding. > > > >[SM] Agreed that the forwarding point need to be aware of the topology > >but proxy-node itself doesn't need to. > > > >-----Original Message----- > >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > >Sent: Tuesday, October 22, 2013 2:49 PM > >To: Linda Dunbar; nsc@ietf.org > >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > >Subject: RE: [nsc] New Version Notification for > >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > > > >Hi, Linda. > > > >Responses inline. > > > > Ron > > > > > >-----Original Message----- > >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > >Sent: Tuesday, October 22, 2013 4:31 PM > >To: Ron Parker; nsc@ietf.org > >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > >Subject: RE: [nsc] New Version Notification for > >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > > > >Ron, > > > >Thank you very much for the valuable comments. See my response > inserted > >below: > > > >> -----Original Message----- > >> > >> > >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) > >> - > >> - although it may be slightly off topic for your draft, it occurs to > >> me that the proxy nodes would be ideal locations to load balance > >> towards multiple instances of the same type of service node (i.e., > >> combining proxy-node and load-balancing). > > > >[Linda] are you saying that multiple instances are co-located? What if > >multiple instances for one network function are located in different > >places? > >Do you think the "proxy node" should balance them, or should the > >controller balance them and simply inform the "proxy node"? or > >combination of both? > > > > > >[Ron] My thinking, so far, is that a load-balancer is, itself a > network > >service function which understands that it manges some set of > >functionally equivalent subtended network service function instances. > >But, from a logical perspective, I think that I have argued myself out > of > >co-mingling the proxy concept and the load balancing concept. They > can > >be mixed and matched as necessary, and co-located as desired. For > >example, a chain may indicate that a load-balancer must be visited. > The > >load balancer balances to multiple instances of proxy-fronted > >non-SFC-aware service functions. But, all of this is off-topic, so > I > >apologize for introducing it here. > > > >> > >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), > >> the first indented bullet states that the service function can be > >> embedded in a service chain proxy. From a software implementation > >> perspective that makes perfect sense. But from a network topology > >> perspective, the proxy would not be explicitly observable -- the > >> service function would look like it had native SFC capabilities with > >> respect to other SFC service nodes and/or classifiers. > > > >[Linda] I will change the text to reflect this point. On the other > hand, > >many of today's service functions are independent. They don't care who > is > >ahead of them and who is after. How would you describe this scenario? > > > > > >[Ron] I think we are saying that to be SFC-aware is to know, > explicitly, > >which service function is next. A service function which doesn't > >understand that concept is front-ended by an SFC-proxy. > > > > > >> > >> Also in section 4.1, there is discussion of particular network > >> topologies. It has been proposed in other drafts that the SFC > >> approach be topology unaware. > >> > >[Linda] In this context, the Proxy nodes are topology unaware. But > proxy > >nodes know their connection to the directly connected service > functions. > >Is it OK? > > > >[Ron] I think this goes to where the intelligence is for the > forwarding. > > > >Maybe we can chat face to face in Vancouver for the following points. > > > >[Ron] It would be my pleasure :). Please contact me privately. > > > > > >Linda > >> Section 4.2 (traffic steering). Consistent with my comment above, > my > >> feeling is that one of the biggest advantages of SFC is to become > >> topology and transport unaware so that a new mechanism need not be > >> invented for every combination of network topology (i.e., 1 hop away, > >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP > >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). > >> > >> Section 5.1 (multiple instances). Consistent with comments above, > >> with correct separation of the logical and physical, steering tables > >> would not need to be updated each time an NFV event occurred (i.e., > >> instace up, down, moved, expanded, contracted, etc.). > >> > >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar > >> comments to above. If we choose a topology and transport > independent > >> mechanism to follow a service chain, the complexity is reduced and > the > >> reliability is improved. Something akin to the steering that you > >> mention is constrained to the classification node(s), greatly > >> simplifying the service nodes. > >> > >> > >> > >> > >> -----Original Message----- > >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf > Of > >> Linda Dunbar > >> Sent: Monday, October 21, 2013 5:15 PM > >> To: nsc@ietf.org > >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > >> Subject: [nsc] New Version Notification for > >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt > >> > >> There have been many drafts submitted for SFC (Service Function > >> Chaining) BOF already. However, we felt that architecture and issues > >> associated with chaining existing Layer 4-7 service functions that > are > >> not aware of Service Encapsulation header haven=B9t been addressed by > >> any drafts (which is called =B3Proxy Nodes=B2 by draft-quinn-nsh-01). > >> > >> We put together a draft to analyze the issues associated with > chaining > >> existing > >> Layer 4-7 service functions that are not aware of service > >> encapsulation layers. This draft also examines the network > >> architecture for chaining existing L4-L7 service functions. The > >> intent is to identify and describe gaps that have not been > >> addressed by other SFC drafts. > >> > >> Your comments are greatly appreciated. > >> > >> > >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > >> Revision: 00 > >> Title: Architecture for Chaining Legacy Layer 4-7 Service > >> Functions > >> Creation date: 2013-10-16 > >> Group: Individual Submission > >> Number of pages: 16 > >> URL: http://www.ietf.org/internet-drafts/draft-dunbar- > sfc- > >> legacy-l4-l7-chain-architecture-00.txt > >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- > >> legacy-l4-l7-chain-architecture > >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy- > l4- > >> l7-chain-architecture-00 > >> > >> > >> Linda, Ning, Ian, Sumandra, and Donald > >> > >> _______________________________________________ > >> nsc mailing list > >> nsc@ietf.org > >> https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Oct 23 15:57:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB3B11E826F for ; Wed, 23 Oct 2013 15:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.624 X-Spam-Level: X-Spam-Status: No, score=-9.624 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl8I4z2GCMwy for ; Wed, 23 Oct 2013 15:57:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B517E11E827A for ; Wed, 23 Oct 2013 15:57:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14804; q=dns/txt; s=iport; t=1382569041; x=1383778641; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=g0JQOuv0dhh00Mz7jYpVq5nywj+7bYoodPFuSwhen3c=; b=UMozy8aJ0pql0cCHZeZlVVFt0awhXBZ4YZb0hk6tQ2Pa3qFa8dBtkkgy pEGaHWDlFgBqwbMFUi8IlGuHTqnFhU+dA9BRF/DtM6wpiWeIva98re7Uk XmTgpx1LYom76FwX42yy7g2JjEsviqB3aq7Y1v41w9CPK9WsK4PEXjXZo U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAM5TaFKtJV2d/2dsb2JhbABPCoMHOFSDKrstGIESFnSCJQEBAQQBAQELJjEJCQIMBgEIEQEDAQEBBAYdBQQlCxQDBggCBAENBQgBh30NjQGbVQaSWoEjjGiBEAIGKwcEAoJeO4ELA5QqhQ6QWIFmgT6CKg X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208";a="275832828" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2013 22:57:18 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9NMvHIi023250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 22:57:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 17:57:17 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7M4bo+2KAbgEmsGb3qc1DuT5oDNGyA///CSIA= Date: Wed, 23 Oct 2013 22:57:17 +0000 Message-ID: <68B171751455884590F8E38E96416F363F708277@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE7C78@dfweml509-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Donald Eastlake , Ning So , Ian Smith Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 22:57:29 -0000 TGluZGEsDQpUaGF0IG1heSBvciBtYXkgbm90IGJlIGEgdmFsaWQgYXNzdW1wdGlvbi4gV2hpbGUg aXQgaXMgdHJ1ZSB0aGF0IHNvbWUNCnByb3hpZXMgbWF5IHJlbHkgdXBvbiBhbiB1cHN0cmVhbSBu b2RlIHRvIHBlcmZvcm0gcGFja2V0IGZvcndhcmRpbmcgaW50bw0KdGhlIHVuZGVybGF5IG9uIHRo ZWlyIGJlaGFsZiAodGhpbmsgVE9SKSwgaXQgaXMgYWxzbyB0cnVlIHRoYXQgdGhlIHByb3h5DQpt YXkgc2ltcGx5IGhhdmUgdGhhdCBjYXBhYmlsaXR5IGl0c2VsZiAodGhpbmsgcm91dGVyKS4NCg0K T24gMTAvMjMvMTMgNjozOCBQTSwgIkxpbmRhIER1bmJhciIgPGxpbmRhLmR1bmJhckBodWF3ZWku Y29tPiB3cm90ZToNCg0KPkppbSwgDQo+DQo+VGhlcmUgYXJlIHR1bm5lbHMgKGUuZy4gVnhMQU4s IE5WR1JFLCBvciBvdGhlcnMpIGludGVyY29ubmVjdGluZyB0aGUNCj4icHJveHkgbm9kZXMiIGFu ZCAic2VydmljZSBub2RlcyIuIFRoZXJlZm9yZSwgdGhlICJwcm94eSBub2RlcyIga25vdw0KPnRo ZWlyIGNvbm5lY3Rpb24gdG8gb3RoZXIgIlByb3h5IG5vZGVzIiBvci9hbmQgInNlcnZpY2Ugbm9k ZXMiLCBidXQNCj4icHJveHkgbm9kZXMiIGRvbid0IGtub3cgdGhlIG5ldHdvcmsgdG9wb2xvZ3kg dW5kZXJuZWF0aCB0aGUgInR1bm5lbHMiLg0KPg0KPlRoZSAicHJveHkgbm9kZXMiIGFyZSB2ZXJ5 IG11Y2ggbGlrZSAic2VydmljZSBub2RlcyIgaW4gdGhhdCBzZW5zZS4NCj4iU2VydmljZSBub2Rl cyIga25vdyB0aGVpciBpbnRlcmNvbm5lY3Rpb24gdG8gb3RoZXIgInNlcnZpY2Ugbm9kZXMiLCBi dXQNCj4ic2VydmljZSBub2RlcyIgZG9uJ3Qga25vdyB0aGUgbmV0d29yayB0b3BvbG9neSB1bmRl cm5lYXRoIHRoZSAidHVubmVscyINCj50aGF0IGludGVyY29ubmVjdCB0aGUgInNlcnZpY2Ugbm9k ZXMiLg0KPg0KPkxpbmRhDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJv bTogSmltIEd1aWNoYXJkIChqZ3VpY2hhcikgW21haWx0bzpqZ3VpY2hhckBjaXNjby5jb21dDQo+ PiBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMjMsIDIwMTMgNToyNiBQTQ0KPj4gVG86IFN1bWFu ZHJhIE1hamVlOyBSb24gUGFya2VyOyBMaW5kYSBEdW5iYXI7IG5zY0BpZXRmLm9yZw0KPj4gQ2M6 IERvbmFsZCBFYXN0bGFrZTsgSWFuIFNtaXRoOyBOaW5nIFNvDQo+PiBTdWJqZWN0OiBSZTogW25z Y10gTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1kdW5iYXItc2ZjLQ0KPj4gbGVn YWN5LWw0LWw3LWNoYWluLWFyY2hpdGVjdHVyZS0wMC50eHQNCj4+IA0KPj4gSG93IGNhbiBhIHBy b3h5LW5vZGUgbm90IGtub3cgdGhlIHRvcG9sb2d5PyBNYXliZSBJIGFtIG1pc3NpbmcgdGhlDQo+ PiBwb2ludA0KPj4gb2YgdGhpcyBkaXNjdXNzaW9uIGJ1dCBhIHByb3h5IG5vZGUgKGFzIGRlZmlu ZWQgaW4gdGhlIHJlZmVyZW5jZSBtYWRlDQo+PiBpbg0KPj4gZHJhZnQtZHVuYmFyLXNmYy1sZWdh Y3ktbDQtbDctY2hhaW4pIGlzIGEgZnJvbnQtZW5kIHRvIG9uZSBvciBtb3JlDQo+PiBzZXJ2aWNl DQo+PiBmdW5jdGlvbnMgdGhhdCBhcmUgdW5hYmxlIHRvIHByb2Nlc3MgYW55IHR5cGUgb2Ygc2Vy dmljZSBlbmNhcHN1bGF0aW9uLg0KPj4gVGhlcmVmb3JlIHRoZSBwcm94eSBwcm9jZXNzZXMgc2Fp ZCBlbmNhcHN1bGF0aW9uIG9uIHRoZWlyIGJlaGFsZi4gSW4NCj4+IG9yZGVyDQo+PiBmb3IgYSBw cm94eSB0byBmb3J3YXJkIHRyYWZmaWMgdG8gdGhlIG5leHQgc2VydmljZSBmdW5jdGlvbiBpbiB0 aGUNCj4+IGNoYWluDQo+PiBpdCAqaGFzKiB0byBrbm93IHRoZSB0b3BvbG9neS4NCj4+IA0KPj4g RnVydGhlciwgYSBwcmV2aW91cyBjb21tZW50IHNhaWQgIml0IGhhcyBiZWVuIHByb3Bvc2VkIGlu IG90aGVyIGRyYWZ0cw0KPj4gdGhhdCB0aGUgU0ZDIGFwcHJvYWNoIGJlIHRvcG9sb2d5IHVuYXdh cmUiOyB3aGljaCBwcm9wb3NhbCBpbmRpY2F0ZXMNCj4+IHRoaXM/DQo+PiBJIHdvdWxkIGFncmVl IHRoYXQgdGhlIFNGQyBhcHByb2FjaCBzaG91bGQgYmUgKnRyYW5zcG9ydCBpbmRlcGVuZGVudCoN Cj4+IGJ1dA0KPj4gdG9wb2xvZ3kgYXdhcmVuZXNzIGlzIG5lY2Vzc2FyeSBzb21ld2hlcmUgYXMg b3RoZXJ3aXNlIG9uZSBjb3VsZCBub3QNCj4+IGZvcndhcmQgcGFja2V0cyBmcm9tL3RvIHRoZSBy aWdodCBwbGFjZXMuDQo+PiANCj4+IE9uIDEwLzIzLzEzIDQ6NDMgUE0sICJTdW1hbmRyYSBNYWpl ZSIgPFMuTWFqZWVARjUuY29tPiB3cm90ZToNCj4+IA0KPj4gPj5JIGRvIGhhdmUgYSBmZXcgY29t bWVudHMgYW5kIG9uZSBvdmVyYWxsIHRoZW1lIHJlZ2FyZGluZyAic3RlZXJpbmciLA0KPj4gPj53 aGljaCBJIGNvbnNpZGVyIHRoZSBsZWdhY3kgYXBwcm9hY2ggdGhhdCB3ZSBhcmUgdHJ5aW5nIHRv IGltcHJvdmUgaW4NCj4+ID4+U0ZDLg0KPj4gPg0KPj4gPltTTV0gTm90IHN1cmUgSSBnZXQgdGhl IGRpc3RpbmN0aW9uIGJldHdlZW4gImNoYWluaW5nIiBhbmQgInN0ZWVyaW5nIi4NCj4+ID5UaGUg TDcgc2VydmljZXMgYXJlIG9mdGVuIGluc2VydGVkIGR5bmFtaWNhbGx5IHRvIHRoZSBzZXJ2aWNl IGNoYWluDQo+PiBiYXNlZA0KPj4gPm9uIDEpIGxhdGVyIGNsYXNzaWZpY2F0aW9uIDIpIGJhc2Vk IG9uIG5ldHdvcmsgY29uZGl0aW9uIGxpa2UNCj4+ICJzdGVlcmluZyINCj4+ID50byB2aWRlbyBv cHRpbWl6ZXIgd2hlbiBhdmFpbGFibGUgYmFuZHdpZHRoIGZhbGxzIGJlbG93IGNlcnRhaW4NCj4+ ID50aHJlc2hvbGQuDQo+PiA+DQo+PiA+Pg0KPj4gPj4gQWxzbyBpbiBzZWN0aW9uIDQuMSwgdGhl cmUgaXMgZGlzY3Vzc2lvbiBvZiBwYXJ0aWN1bGFyIG5ldHdvcmsNCj4+ID4+IHRvcG9sb2dpZXMu ICAgSXQgaGFzIGJlZW4gcHJvcG9zZWQgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdGhlIFNGQw0KPj4g Pj4gYXBwcm9hY2ggYmUgdG9wb2xvZ3kgdW5hd2FyZS4NCj4+ID4+DQo+PiA+W0xpbmRhXSAgSW4g dGhpcyBjb250ZXh0LCB0aGUgUHJveHkgbm9kZXMgYXJlIHRvcG9sb2d5IHVuYXdhcmUuIEJ1dA0K Pj4gcHJveHkNCj4+ID5ub2RlcyBrbm93IHRoZWlyIGNvbm5lY3Rpb24gdG8gdGhlIGRpcmVjdGx5 IGNvbm5lY3RlZCBzZXJ2aWNlDQo+PiBmdW5jdGlvbnMuDQo+PiA+SXMgaXQgT0s/DQo+PiA+W1Jv bl0gSSB0aGluayB0aGlzIGdvZXMgdG8gd2hlcmUgdGhlIGludGVsbGlnZW5jZSBpcyBmb3IgdGhl DQo+PiBmb3J3YXJkaW5nLg0KPj4gPg0KPj4gPltTTV0gQWdyZWVkIHRoYXQgdGhlIGZvcndhcmRp bmcgcG9pbnQgbmVlZCB0byBiZSBhd2FyZSBvZiB0aGUgdG9wb2xvZ3kNCj4+ID5idXQgcHJveHkt bm9kZSBpdHNlbGYgZG9lc24ndCBuZWVkIHRvLg0KPj4gPg0KPj4gPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+PiA+RnJvbTogUm9uIFBhcmtlciBbbWFpbHRvOlJvbl9QYXJrZXJAYWZmaXJt ZWRuZXR3b3Jrcy5jb21dDQo+PiA+U2VudDogVHVlc2RheSwgT2N0b2JlciAyMiwgMjAxMyAyOjQ5 IFBNDQo+PiA+VG86IExpbmRhIER1bmJhcjsgbnNjQGlldGYub3JnDQo+PiA+Q2M6IERvbmFsZCBF YXN0bGFrZTsgTmluZyBTbzsgSWFuIFNtaXRoOyBTdW1hbmRyYSBNYWplZQ0KPj4gPlN1YmplY3Q6 IFJFOiBbbnNjXSBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+PiA+ZHJhZnQtZHVuYmFy LXNmYy1sZWdhY3ktbDQtbDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwLnR4dA0KPj4gPg0KPj4gPkhp LCBMaW5kYS4NCj4+ID4NCj4+ID5SZXNwb25zZXMgaW5saW5lLg0KPj4gPg0KPj4gPglSb24NCj4+ ID4NCj4+ID4NCj4+ID4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gPkZyb206IExpbmRh IER1bmJhciBbbWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KPj4gPlNlbnQ6IFR1ZXNk YXksIE9jdG9iZXIgMjIsIDIwMTMgNDozMSBQTQ0KPj4gPlRvOiBSb24gUGFya2VyOyBuc2NAaWV0 Zi5vcmcNCj4+ID5DYzogRG9uYWxkIEVhc3RsYWtlOyBOaW5nIFNvOyBJYW4gU21pdGg7IFN1bWFu ZHJhIE1hamVlDQo+PiA+U3ViamVjdDogUkU6IFtuc2NdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3INCj4+ID5kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1 cmUtMDAudHh0DQo+PiA+DQo+PiA+Um9uLA0KPj4gPg0KPj4gPlRoYW5rIHlvdSB2ZXJ5IG11Y2gg Zm9yIHRoZSB2YWx1YWJsZSBjb21tZW50cy4gU2VlIG15IHJlc3BvbnNlDQo+PiBpbnNlcnRlZA0K Pj4gPmJlbG93Og0KPj4gPg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+ DQo+PiA+Pg0KPj4gPj4gSW4gc2VjdGlvbiAzLjMsIGZpZ3VyZSAyIChDaGFpbmdpbmcgZXhpc3Rp bmcgTGF5ZXIgNC03IHNlcnZpY2Ugbm9kZXMpDQo+PiA+PiAtDQo+PiA+PiAtIGFsdGhvdWdoIGl0 IG1heSBiZSBzbGlnaHRseSBvZmYgdG9waWMgZm9yIHlvdXIgZHJhZnQsIGl0IG9jY3VycyB0bw0K Pj4gPj4gbWUgdGhhdCB0aGUgcHJveHkgbm9kZXMgd291bGQgYmUgaWRlYWwgbG9jYXRpb25zIHRv IGxvYWQgYmFsYW5jZQ0KPj4gPj4gdG93YXJkcyBtdWx0aXBsZSBpbnN0YW5jZXMgb2YgdGhlIHNh bWUgdHlwZSBvZiBzZXJ2aWNlIG5vZGUgKGkuZS4sDQo+PiA+PiBjb21iaW5pbmcgcHJveHktbm9k ZSBhbmQgbG9hZC1iYWxhbmNpbmcpLg0KPj4gPg0KPj4gPltMaW5kYV0gYXJlIHlvdSBzYXlpbmcg dGhhdCBtdWx0aXBsZSBpbnN0YW5jZXMgYXJlIGNvLWxvY2F0ZWQ/IFdoYXQgaWYNCj4+ID5tdWx0 aXBsZSBpbnN0YW5jZXMgZm9yIG9uZSBuZXR3b3JrIGZ1bmN0aW9uIGFyZSBsb2NhdGVkIGluIGRp ZmZlcmVudA0KPj4gPnBsYWNlcz8NCj4+ID5EbyB5b3UgdGhpbmsgdGhlICJwcm94eSBub2RlIiBz aG91bGQgYmFsYW5jZSB0aGVtLCBvciBzaG91bGQgdGhlDQo+PiA+Y29udHJvbGxlciBiYWxhbmNl IHRoZW0gYW5kIHNpbXBseSBpbmZvcm0gdGhlICJwcm94eSBub2RlIj8gIG9yDQo+PiA+Y29tYmlu YXRpb24gb2YgYm90aD8NCj4+ID4NCj4+ID4NCj4+ID5bUm9uXSBNeSB0aGlua2luZywgc28gZmFy LCBpcyB0aGF0IGEgbG9hZC1iYWxhbmNlciBpcywgaXRzZWxmIGENCj4+IG5ldHdvcmsNCj4+ID5z ZXJ2aWNlIGZ1bmN0aW9uIHdoaWNoIHVuZGVyc3RhbmRzIHRoYXQgaXQgbWFuZ2VzIHNvbWUgc2V0 IG9mDQo+PiA+ZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgc3VidGVuZGVkIG5ldHdvcmsgc2Vydmlj ZSBmdW5jdGlvbiBpbnN0YW5jZXMuDQo+PiA+QnV0LCBmcm9tIGEgbG9naWNhbCBwZXJzcGVjdGl2 ZSwgSSB0aGluayB0aGF0IEkgaGF2ZSBhcmd1ZWQgbXlzZWxmIG91dA0KPj4gb2YNCj4+ID5jby1t aW5nbGluZyB0aGUgcHJveHkgY29uY2VwdCBhbmQgdGhlIGxvYWQgYmFsYW5jaW5nIGNvbmNlcHQu ICAgVGhleQ0KPj4gY2FuDQo+PiA+YmUgbWl4ZWQgYW5kIG1hdGNoZWQgYXMgbmVjZXNzYXJ5LCBh bmQgY28tbG9jYXRlZCBhcyBkZXNpcmVkLiAgIEZvcg0KPj4gPmV4YW1wbGUsIGEgY2hhaW4gbWF5 IGluZGljYXRlIHRoYXQgYSBsb2FkLWJhbGFuY2VyIG11c3QgYmUgdmlzaXRlZC4NCj4+IFRoZQ0K Pj4gPmxvYWQgYmFsYW5jZXIgYmFsYW5jZXMgdG8gbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHByb3h5 LWZyb250ZWQNCj4+ID5ub24tU0ZDLWF3YXJlIHNlcnZpY2UgZnVuY3Rpb25zLiAgICBCdXQsIGFs bCBvZiB0aGlzIGlzIG9mZi10b3BpYywgc28NCj4+IEkNCj4+ID5hcG9sb2dpemUgZm9yIGludHJv ZHVjaW5nIGl0IGhlcmUuDQo+PiA+DQo+PiA+Pg0KPj4gPj4gSW4gc2VjdGlvbiA0LjEgKEw0LUw3 IG5vZGVzIGNvbm5lY3Rpb24gdG8gU2VydmljZSBDaGFpbiBQcm94eSBOb2RlcyksDQo+PiA+PiB0 aGUgZmlyc3QgaW5kZW50ZWQgYnVsbGV0IHN0YXRlcyB0aGF0IHRoZSBzZXJ2aWNlIGZ1bmN0aW9u IGNhbiBiZQ0KPj4gPj4gZW1iZWRkZWQgaW4gYSBzZXJ2aWNlIGNoYWluIHByb3h5LiAgIEZyb20g YSBzb2Z0d2FyZSBpbXBsZW1lbnRhdGlvbg0KPj4gPj4gcGVyc3BlY3RpdmUgdGhhdCBtYWtlcyBw ZXJmZWN0IHNlbnNlLiAgIEJ1dCBmcm9tIGEgbmV0d29yayB0b3BvbG9neQ0KPj4gPj4gcGVyc3Bl Y3RpdmUsIHRoZSBwcm94eSB3b3VsZCBub3QgYmUgZXhwbGljaXRseSBvYnNlcnZhYmxlIC0tIHRo ZQ0KPj4gPj4gc2VydmljZSBmdW5jdGlvbiB3b3VsZCBsb29rIGxpa2UgaXQgaGFkIG5hdGl2ZSBT RkMgY2FwYWJpbGl0aWVzIHdpdGgNCj4+ID4+IHJlc3BlY3QgdG8gb3RoZXIgU0ZDIHNlcnZpY2Ug bm9kZXMgYW5kL29yIGNsYXNzaWZpZXJzLg0KPj4gPg0KPj4gPltMaW5kYV0gSSB3aWxsIGNoYW5n ZSB0aGUgdGV4dCB0byByZWZsZWN0IHRoaXMgcG9pbnQuIE9uIHRoZSBvdGhlcg0KPj4gaGFuZCwN Cj4+ID5tYW55IG9mIHRvZGF5J3Mgc2VydmljZSBmdW5jdGlvbnMgYXJlIGluZGVwZW5kZW50LiBU aGV5IGRvbid0IGNhcmUgd2hvDQo+PiBpcw0KPj4gPmFoZWFkIG9mIHRoZW0gYW5kIHdobyBpcyBh ZnRlci4gSG93IHdvdWxkIHlvdSBkZXNjcmliZSB0aGlzIHNjZW5hcmlvPw0KPj4gPg0KPj4gPg0K Pj4gPltSb25dIEkgdGhpbmsgd2UgYXJlIHNheWluZyB0aGF0IHRvIGJlIFNGQy1hd2FyZSBpcyB0 byBrbm93LA0KPj4gZXhwbGljaXRseSwNCj4+ID53aGljaCBzZXJ2aWNlIGZ1bmN0aW9uIGlzIG5l eHQuICAgQSBzZXJ2aWNlIGZ1bmN0aW9uIHdoaWNoIGRvZXNuJ3QNCj4+ID51bmRlcnN0YW5kIHRo YXQgY29uY2VwdCBpcyBmcm9udC1lbmRlZCBieSBhbiBTRkMtcHJveHkuDQo+PiA+DQo+PiA+DQo+ PiA+Pg0KPj4gPj4gQWxzbyBpbiBzZWN0aW9uIDQuMSwgdGhlcmUgaXMgZGlzY3Vzc2lvbiBvZiBw YXJ0aWN1bGFyIG5ldHdvcmsNCj4+ID4+IHRvcG9sb2dpZXMuICAgSXQgaGFzIGJlZW4gcHJvcG9z ZWQgaW4gb3RoZXIgZHJhZnRzIHRoYXQgdGhlIFNGQw0KPj4gPj4gYXBwcm9hY2ggYmUgdG9wb2xv Z3kgdW5hd2FyZS4NCj4+ID4+DQo+PiA+W0xpbmRhXSAgSW4gdGhpcyBjb250ZXh0LCB0aGUgUHJv eHkgbm9kZXMgYXJlIHRvcG9sb2d5IHVuYXdhcmUuIEJ1dA0KPj4gcHJveHkNCj4+ID5ub2RlcyBr bm93IHRoZWlyIGNvbm5lY3Rpb24gdG8gdGhlIGRpcmVjdGx5IGNvbm5lY3RlZCBzZXJ2aWNlDQo+ PiBmdW5jdGlvbnMuDQo+PiA+SXMgaXQgT0s/DQo+PiA+DQo+PiA+W1Jvbl0gSSB0aGluayB0aGlz IGdvZXMgdG8gd2hlcmUgdGhlIGludGVsbGlnZW5jZSBpcyBmb3IgdGhlDQo+PiBmb3J3YXJkaW5n Lg0KPj4gPg0KPj4gPk1heWJlIHdlIGNhbiBjaGF0IGZhY2UgdG8gZmFjZSBpbiBWYW5jb3V2ZXIg Zm9yIHRoZSBmb2xsb3dpbmcgcG9pbnRzLg0KPj4gPg0KPj4gPltSb25dIEl0IHdvdWxkIGJlIG15 IHBsZWFzdXJlIDopLiAgIFBsZWFzZSBjb250YWN0IG1lIHByaXZhdGVseS4NCj4+ID4NCj4+ID4N Cj4+ID5MaW5kYQ0KPj4gPj4gU2VjdGlvbiA0LjIgKHRyYWZmaWMgc3RlZXJpbmcpLiAgIENvbnNp c3RlbnQgd2l0aCBteSBjb21tZW50IGFib3ZlLA0KPj4gbXkNCj4+ID4+IGZlZWxpbmcgaXMgdGhh dCBvbmUgb2YgdGhlIGJpZ2dlc3QgYWR2YW50YWdlcyBvZiBTRkMgaXMgdG8gYmVjb21lDQo+PiA+ PiB0b3BvbG9neSBhbmQgdHJhbnNwb3J0IHVuYXdhcmUgc28gdGhhdCBhIG5ldyBtZWNoYW5pc20g bmVlZCBub3QgYmUNCj4+ID4+IGludmVudGVkIGZvciBldmVyeSBjb21iaW5hdGlvbiBvZiBuZXR3 b3JrIHRvcG9sb2d5IChpLmUuLCAxIGhvcCBhd2F5LA0KPj4gPj4gMiBob3BzIGF3YXksIG1vcmUp IGFuZCB0cmFuc3BvcnQgdGVjaG5vbG9neSAoaS5lLiwgTUFDIGJyaWRnaW5nLCBJUA0KPj4gPj4g Zm9yd2FyZGluZywgTVBMUyBMRVIvTFNSLCBBQ0wtYmFzZWQgZmlsdGVyZWQgZm9yd2FyZGluZywg ZXRjLikuDQo+PiA+Pg0KPj4gPj4gU2VjdGlvbiA1LjEgKG11bHRpcGxlIGluc3RhbmNlcykuICAg Q29uc2lzdGVudCB3aXRoIGNvbW1lbnRzIGFib3ZlLA0KPj4gPj4gd2l0aCBjb3JyZWN0IHNlcGFy YXRpb24gb2YgdGhlIGxvZ2ljYWwgYW5kIHBoeXNpY2FsLCBzdGVlcmluZyB0YWJsZXMNCj4+ID4+ IHdvdWxkIG5vdCBuZWVkIHRvIGJlIHVwZGF0ZWQgZWFjaCB0aW1lIGFuIE5GViBldmVudCBvY2N1 cnJlZCAoaS5lLiwNCj4+ID4+IGluc3RhY2UgdXAsIGRvd24sIG1vdmVkLCBleHBhbmRlZCwgY29u dHJhY3RlZCwgZXRjLikuDQo+PiA+Pg0KPj4gPj4gU2VjdGlvbiA1LjIgKGNoYWxsZW5nZXMgb2Yg TGF5ZXIgNC03IHRyYWZmaWMgc3RlZXJpbmcpLiAgIFNpbWlsYXINCj4+ID4+IGNvbW1lbnRzIHRv IGFib3ZlLiAgIElmIHdlIGNob29zZSBhIHRvcG9sb2d5IGFuZCB0cmFuc3BvcnQNCj4+IGluZGVw ZW5kZW50DQo+PiA+PiBtZWNoYW5pc20gdG8gZm9sbG93IGEgc2VydmljZSBjaGFpbiwgdGhlIGNv bXBsZXhpdHkgaXMgcmVkdWNlZCBhbmQNCj4+IHRoZQ0KPj4gPj4gcmVsaWFiaWxpdHkgaXMgaW1w cm92ZWQuICAgIFNvbWV0aGluZyBha2luIHRvIHRoZSBzdGVlcmluZyB0aGF0IHlvdQ0KPj4gPj4g bWVudGlvbiBpcyBjb25zdHJhaW5lZCB0byB0aGUgY2xhc3NpZmljYXRpb24gbm9kZShzKSwgZ3Jl YXRseQ0KPj4gPj4gc2ltcGxpZnlpbmcgdGhlIHNlcnZpY2Ugbm9kZXMuDQo+PiA+Pg0KPj4gPj4N Cj4+ID4+DQo+PiA+Pg0KPj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+ID4+IEZy b206IG5zYy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bnNjLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZg0KPj4gT2YNCj4+ID4+IExpbmRhIER1bmJhcg0KPj4gPj4gU2VudDogTW9uZGF5LCBP Y3RvYmVyIDIxLCAyMDEzIDU6MTUgUE0NCj4+ID4+IFRvOiBuc2NAaWV0Zi5vcmcNCj4+ID4+IENj OiBEb25hbGQgRWFzdGxha2U7IE5pbmcgU287IElhbiBTbWl0aDsgU3VtYW5kcmEgTWFqZWUNCj4+ ID4+IFN1YmplY3Q6IFtuc2NdIE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+ID4+IGRy YWZ0LWR1bmJhci1zZmMtbGVnYWN5LWw0LSBsNy1jaGFpbi1hcmNoaXRlY3R1cmUtMDAudHh0DQo+ PiA+Pg0KPj4gPj4gVGhlcmUgaGF2ZSBiZWVuIG1hbnkgZHJhZnRzIHN1Ym1pdHRlZCBmb3IgU0ZD IChTZXJ2aWNlIEZ1bmN0aW9uDQo+PiA+PiBDaGFpbmluZykgQk9GIGFscmVhZHkuIEhvd2V2ZXIs IHdlIGZlbHQgdGhhdCBhcmNoaXRlY3R1cmUgYW5kIGlzc3Vlcw0KPj4gPj4gYXNzb2NpYXRlZCB3 aXRoIGNoYWluaW5nIGV4aXN0aW5nIExheWVyIDQtNyBzZXJ2aWNlIGZ1bmN0aW9ucyB0aGF0DQo+ PiBhcmUNCj4+ID4+IG5vdCBhd2FyZSBvZiBTZXJ2aWNlIEVuY2Fwc3VsYXRpb24gaGVhZGVyIGhh dmVuqfZ0IGJlZW4gYWRkcmVzc2VkIGJ5DQo+PiA+PiBhbnkgZHJhZnRzICh3aGljaCBpcyBjYWxs ZWQgqfhQcm94eSBOb2Rlc6n3IGJ5IGRyYWZ0LXF1aW5uLW5zaC0wMSkuDQo+PiA+Pg0KPj4gPj4g V2UgcHV0IHRvZ2V0aGVyIGEgZHJhZnQgdG8gYW5hbHl6ZSB0aGUgaXNzdWVzIGFzc29jaWF0ZWQg d2l0aA0KPj4gY2hhaW5pbmcNCj4+ID4+IGV4aXN0aW5nDQo+PiA+PiAgICBMYXllciA0LTcgc2Vy dmljZSBmdW5jdGlvbnMgdGhhdCBhcmUgbm90IGF3YXJlIG9mIHNlcnZpY2UNCj4+ID4+ICAgIGVu Y2Fwc3VsYXRpb24gbGF5ZXJzLiBUaGlzIGRyYWZ0IGFsc28gZXhhbWluZXMgdGhlIG5ldHdvcmsN Cj4+ID4+ICAgIGFyY2hpdGVjdHVyZSBmb3IgY2hhaW5pbmcgZXhpc3RpbmcgTDQtTDcgc2Vydmlj ZSBmdW5jdGlvbnMuIFRoZQ0KPj4gPj4gICAgaW50ZW50IGlzIHRvIGlkZW50aWZ5IGFuZCBkZXNj cmliZSBnYXBzIHRoYXQgaGF2ZSBub3QgYmVlbg0KPj4gPj4gICAgYWRkcmVzc2VkIGJ5IG90aGVy IFNGQyBkcmFmdHMuDQo+PiA+Pg0KPj4gPj4gWW91ciBjb21tZW50cyBhcmUgZ3JlYXRseSBhcHBy ZWNpYXRlZC4NCj4+ID4+DQo+PiA+Pg0KPj4gPj4gRmlsZW5hbWU6CSBkcmFmdC1kdW5iYXItc2Zj LWxlZ2FjeS1sNC1sNy1jaGFpbi1hcmNoaXRlY3R1cmUNCj4+ID4+IFJldmlzaW9uOgkgMDANCj4+ ID4+IFRpdGxlOgkJIEFyY2hpdGVjdHVyZSBmb3IgQ2hhaW5pbmcgTGVnYWN5IExheWVyIDQtNyBT ZXJ2aWNlDQo+PiA+PiBGdW5jdGlvbnMNCj4+ID4+IENyZWF0aW9uIGRhdGU6CSAyMDEzLTEwLTE2 DQo+PiA+PiBHcm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4+ID4+IE51bWJlciBvZiBw YWdlczogMTYNCj4+ID4+IFVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtZHVuYmFyLQ0KPj4gc2ZjLQ0KPj4gPj4gbGVnYWN5LWw0LWw3LWNo YWluLWFyY2hpdGVjdHVyZS0wMC50eHQNCj4+ID4+IFN0YXR1czogICAgICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kdW5iYXItc2ZjLQ0KPj4gPj4gbGVnYWN5LWw0 LWw3LWNoYWluLWFyY2hpdGVjdHVyZQ0KPj4gPj4gSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1kdW5iYXItc2ZjLWxlZ2FjeS0NCj4+IGw0LQ0KPj4gPj4g bDctY2hhaW4tYXJjaGl0ZWN0dXJlLTAwDQo+PiA+Pg0KPj4gPj4NCj4+ID4+IExpbmRhLCBOaW5n LCBJYW4sIFN1bWFuZHJhLCBhbmQgRG9uYWxkDQo+PiA+Pg0KPj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+IG5zYyBtYWlsaW5nIGxpc3QN Cj4+ID4+IG5zY0BpZXRmLm9yZw0KPj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uc2MNCj4+ID5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4gPm5zYyBtYWlsaW5nIGxpc3QNCj4+ID5uc2NAaWV0Zi5vcmcNCj4+ID5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25zYw0KPg0KDQo= From linda.dunbar@huawei.com Wed Oct 23 16:06:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33CE11E828A for ; Wed, 23 Oct 2013 16:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.48 X-Spam-Level: X-Spam-Status: No, score=-6.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMgFKdDyUsKl for ; Wed, 23 Oct 2013 16:06:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A298211E8224 for ; Wed, 23 Oct 2013 16:06:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZK09480; Wed, 23 Oct 2013 23:06:08 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 00:06:05 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 24 Oct 2013 00:06:08 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Wed, 23 Oct 2013 16:06:01 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7SNf/CZ5QE9EyYtVfHaKGq/ZoC3t/QgAB8bYD//4uYIA== Date: Wed, 23 Oct 2013 23:06:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BE7CA2@dfweml509-mbb.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BE7C78@dfweml509-mbb.china.huawei.com> <68B171751455884590F8E38E96416F363F708277@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F708277@xmb-rcd-x01.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.132.111] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Donald Eastlake , Ning So , Ian Smith Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:06:18 -0000 Jim > -----Original Message----- >=20 > Linda, > That may or may not be a valid assumption. While it is true that some > proxies may rely upon an upstream node to perform packet forwarding > into > the underlay on their behalf (think TOR), it is also true that the > proxy > may simply have that capability itself (think router). [Linda] Then there are (at least) two components on this "router": proxy fo= r service functions and the routing for the underlay networks.=20 The "proxy component" don't know the underlay network. It is like having se= rvice functions embedded in a router.=20 The service functions don't know the underlay network.=20 Linda From jguichar@cisco.com Wed Oct 23 16:14:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC60411E8224 for ; Wed, 23 Oct 2013 16:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.504 X-Spam-Level: X-Spam-Status: No, score=-10.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYYFi3OlvRf5 for ; Wed, 23 Oct 2013 16:13:58 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3CEFC11E8283 for ; Wed, 23 Oct 2013 16:13:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1080; q=dns/txt; s=iport; t=1382570035; x=1383779635; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=MvPrNh226zODEr/hLAstA989QVbR7Y0RvkpWjZOdiJM=; b=Q2Ovnb9KiurwcrW6Yi4XI08lcEBR/iPXHjWFcc2Z7/sXvKxCM6DPMrns R8pwS5csDRU/z9w9Ne4EmqO4GWN/FgPlGn9m8ypZzbeLjZalIQfL4LRlm 8OkmYmAw/AS+o+eix5ArGWphTDYJAFvPi9NvQBUe+AJ+Szu1zrGg2PdN3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA1XaFKtJV2Y/2dsb2JhbABZgwc4VL5XgSsWdIIlAQEBBAEBATc0CQIMBgEIEhAUNwsXDgIEAQ0FCId+Dbs1BI8dMQeDH4ELA6oQgWaBPoIq X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208";a="275889934" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 23 Oct 2013 23:13:55 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9NNDsJU019084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 23:13:54 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 18:13:54 -0500 From: "Jim Guichard (jguichar)" To: Linda Dunbar , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7M4bo+2KAbgEmsGb3qc1DuT5oDNGyA///CSICAAEWBgP//vyQA Date: Wed, 23 Oct 2013 23:13:54 +0000 Message-ID: <68B171751455884590F8E38E96416F363F7082D0@xmb-rcd-x01.cisco.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE7CA2@dfweml509-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ian Smith , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:14:05 -0000 That's an implementation detail and not a requirement of the architecture; it is unnecessary in my opinion to assume that the proxy component is independent of the forwarding component. On 10/23/13 7:06 PM, "Linda Dunbar" wrote: >Jim > >> -----Original Message----- >>=20 >> Linda, >> That may or may not be a valid assumption. While it is true that some >> proxies may rely upon an upstream node to perform packet forwarding >> into >> the underlay on their behalf (think TOR), it is also true that the >> proxy >> may simply have that capability itself (think router). > >[Linda] Then there are (at least) two components on this "router": proxy >for service functions and the routing for the underlay networks. > >The "proxy component" don't know the underlay network. It is like having >service functions embedded in a router. >The service functions don't know the underlay network. > >Linda > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From Snigs_Mukhopadhyay@DELL.com Wed Oct 23 16:46:15 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404211E8294 for ; Wed, 23 Oct 2013 16:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nflhVH+0fNtL for ; Wed, 23 Oct 2013 16:46:10 -0700 (PDT) Received: from ausxippc101.us.dell.com (ausxippc101.us.dell.com [143.166.85.207]) by ietfa.amsl.com (Postfix) with ESMTP id EB6B011E829B for ; Wed, 23 Oct 2013 16:46:06 -0700 (PDT) X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="4.93,557,1378875600"; d="scan'208";a="301221065" From: To: , , , , Date: Wed, 23 Oct 2013 18:45:58 -0500 Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7M4bo+2KAbgEmsGb3qc1DuT5oDNGyA///CSICAAEWBgP//vyQA///3d2A= Message-ID: <1A7A190903EBC04B8EF1B91674C7EB753A3C3AECB5@AUSX7MCPC105.AMER.DELL.COM> References: <4A95BA014132FF49AE685FAB4B9F17F645BE7CA2@dfweml509-mbb.china.huawei.com> <68B171751455884590F8E38E96416F363F7082D0@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F7082D0@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: d3e3e3@gmail.com, Ning.So@tatacommunications.com, I.Smith@F5.com Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:46:15 -0000 ... it appears that the proxy has these 4 functional components a) A Gateway function at the ingress and egress of a chain to transfer pack= ets to and from the network layer b) An access function to the service while maintaining the service context c) A topology function to identify the location of the next service in the= service chain d) A forwarding function to the next proxy node in the service chain=20 right ? Snigs -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Wednesday, October 23, 2013 4:14 PM To: Linda Dunbar; Sumandra Majee; Ron Parker; nsc@ietf.org Cc: Donald Eastlake; Ian Smith; Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt That's an implementation detail and not a requirement of the architecture; = it is unnecessary in my opinion to assume that the proxy component is indep= endent of the forwarding component. On 10/23/13 7:06 PM, "Linda Dunbar" wrote: >Jim > >> -----Original Message----- >>=20 >> Linda, >> That may or may not be a valid assumption. While it is true that some=20 >> proxies may rely upon an upstream node to perform packet forwarding=20 >> into the underlay on their behalf (think TOR), it is also true that=20 >> the proxy may simply have that capability itself (think router). > >[Linda] Then there are (at least) two components on this "router":=20 >proxy for service functions and the routing for the underlay networks. > >The "proxy component" don't know the underlay network. It is like=20 >having service functions embedded in a router. >The service functions don't know the underlay network. > >Linda > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Wed Oct 23 16:56:50 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7741F11E8294 for ; Wed, 23 Oct 2013 16:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.52 X-Spam-Level: X-Spam-Status: No, score=-10.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEd64BSaAUsj for ; Wed, 23 Oct 2013 16:56:44 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3A11E823F for ; Wed, 23 Oct 2013 16:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1709; q=dns/txt; s=iport; t=1382572604; x=1383782204; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KerBzf1JIhJLXzJz5eSli67Qwgtul5cgZSpzldXn66o=; b=MyLTamr2fz++MWXGBqCKV3pvnue7ujvc9r0mqYkdiRzfiROgU/TeifVO QPeRcfSTYvoGubNUdB2aomJMIkU0Pqv//6+LATEJgr3/D5/1rPnFe1N81 7vNFAik0QoL80RYr75kqIn1i02LuOeHOtL43KWx5gaQcRGAZvMccRkhCc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAOVhaFKtJV2Z/2dsb2JhbABZgweBDL5XgSsWdIIlAQEBBA4sKxICDAYBCBIQFEIXDgIEAQ0Nh367RY8dMQeDH4ELA6oQgWaBPoIq X-IronPort-AV: E=Sophos;i="4.93,557,1378857600"; d="scan'208";a="275847343" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2013 23:56:35 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9NNuQHA027009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 23 Oct 2013 23:56:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Wed, 23 Oct 2013 18:56:25 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0Et7HFzjP4VrH0eYepxd+SGTkQ== Date: Wed, 23 Oct 2013 23:56:25 +0000 Message-ID: <68B171751455884590F8E38E96416F363F7083C8@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <48DA0DDDE6759647A6B5174658022903@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So , Ian Smith , Sumandra Majee Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 23:56:50 -0000 > >> -----Original Message----- >>=20 >>=20 >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). > >[Linda] are you saying that multiple instances are co-located? What if >multiple instances for one network function are located in different >places?=20 >Do you think the "proxy node" should balance them, or should the >controller balance them and simply inform the "proxy node"? or >combination of both? > > >[Ron] My thinking, so far, is that a load-balancer is, itself a network >service function which understands that it manges some set of >functionally equivalent subtended network service function instances. >But, from a logical perspective, I think that I have argued myself out of >co-mingling the proxy concept and the load balancing concept. They can >be mixed and matched as necessary, and co-located as desired. For >example, a chain may indicate that a load-balancer must be visited. The >load balancer balances to multiple instances of proxy-fronted >non-SFC-aware service functions. But, all of this is off-topic, so I >apologize for introducing it here. Jim> Ron, your point is not off-topic. A proxy node *could* load balance across multiple instances of the next service function in the chain, and this could be a local decision at the proxy node, or a decision taken by the controller and pushed down to the proxy node, either directly or indirectly.=20 >> From kgray@juniper.net Thu Oct 24 07:03:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103B411E83F0 for ; Thu, 24 Oct 2013 07:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggBh0gr8mVA6 for ; Thu, 24 Oct 2013 07:03:08 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5DC11E83F6 for ; Thu, 24 Oct 2013 07:03:07 -0700 (PDT) Received: from mail119-co9-R.bigfish.com (10.236.132.236) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Thu, 24 Oct 2013 14:03:06 +0000 Received: from mail119-co9 (localhost [127.0.0.1]) by mail119-co9-R.bigfish.com (Postfix) with ESMTP id A8A6BBC0128; Thu, 24 Oct 2013 14:03:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail119-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(189002)(199002)(51704005)(13464003)(24454002)(31966008)(63696002)(74662001)(65816001)(80022001)(76796001)(56776001)(74876001)(74502001)(47446002)(85306002)(77982001)(59766001)(81542001)(79102001)(46102001)(53806001)(54356001)(83072001)(56816003)(51856001)(36756003)(74366001)(77096001)(81342001)(81686001)(4396001)(47736001)(49866001)(50986001)(47976001)(81816001)(76176001)(74706001)(76786001)(69226001)(19580405001)(83322001)(76482001)(83506001)(54316002)(19580395003)(80976001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB083; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail119-co9 (localhost.localdomain [127.0.0.1]) by mail119-co9 (MessageSwitch) id 1382623344571064_19348; Thu, 24 Oct 2013 14:02:24 +0000 (UTC) Received: from CO9EHSMHS018.bigfish.com (unknown [10.236.132.234]) by mail119-co9.bigfish.com (Postfix) with ESMTP id F402A68004E; Thu, 24 Oct 2013 14:02:01 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS018.bigfish.com (10.236.130.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 24 Oct 2013 14:02:00 +0000 Received: from BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 24 Oct 2013 14:01:56 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB083.namprd05.prod.outlook.com (10.255.232.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 24 Oct 2013 14:01:54 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.214]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.182]) with mapi id 15.00.0785.001; Thu, 24 Oct 2013 14:01:54 +0000 From: Ken Gray To: Linda Dunbar , "Jim Guichard (jguichar)" , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7oO1CtzMSPGkGBNkgIDpBWgpoC4JqAgAAFWYCAAAJwgIAAtzwA Date: Thu, 24 Oct 2013 14:01:53 +0000 Message-ID: In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645BE7CA2@dfweml509-mbb.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 000947967F Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Donald Eastlake , Ian Smith , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:03:13 -0000 I just don't think you can assume an overlay all the time. On 10/23/13 7:06 PM, "Linda Dunbar" wrote: >Jim > >> -----Original Message----- >>=20 >> Linda, >> That may or may not be a valid assumption. While it is true that some >> proxies may rely upon an upstream node to perform packet forwarding >> into >> the underlay on their behalf (think TOR), it is also true that the >> proxy >> may simply have that capability itself (think router). > >[Linda] Then there are (at least) two components on this "router": proxy >for service functions and the routing for the underlay networks. > >The "proxy component" don't know the underlay network. It is like having >service functions embedded in a router. >The service functions don't know the underlay network. > >Linda > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From tnadeau@lucidvision.com Thu Oct 24 07:29:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395FF11E830E for ; Thu, 24 Oct 2013 07:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+Qo88Z8PuK2 for ; Thu, 24 Oct 2013 07:29:16 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F26E911E81C3 for ; Thu, 24 Oct 2013 07:29:15 -0700 (PDT) Received: from [192.168.1.113] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id D940725BB42F; Thu, 24 Oct 2013 10:29:14 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F5A4670C-926B-4D96-8ACB-D4E9E587E99B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Thomas Nadeau In-Reply-To: Date: Thu, 24 Oct 2013 10:29:13 -0400 Message-Id: <428987F6-F498-402B-BB63-C112547C8C87@lucidvision.com> References: To: gray ken X-Mailer: Apple Mail (2.1816) Cc: "nsc@ietf.org" , Sumandra Majee , Ian Smith , Guichard Jim , Ning So , Linda Dunbar , Ron Parker , Donald Eastlake Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:29:29 -0000 --Apple-Mail=_F5A4670C-926B-4D96-8ACB-D4E9E587E99B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree. You definitely can construct situations where no = overlays are desired or needed. Insisting on them as a requirement for = NSC to work in these cases adds unnecessary complication. --Tom > I just don't think you can assume an overlay all the time. >=20 > On 10/23/13 7:06 PM, "Linda Dunbar" wrote: >=20 >> Jim >>=20 >>> -----Original Message----- >>>=20 >>> Linda, >>> That may or may not be a valid assumption. While it is true that = some >>> proxies may rely upon an upstream node to perform packet forwarding >>> into >>> the underlay on their behalf (think TOR), it is also true that the >>> proxy >>> may simply have that capability itself (think router). >>=20 >> [Linda] Then there are (at least) two components on this "router": = proxy >> for service functions and the routing for the underlay networks. >>=20 >> The "proxy component" don't know the underlay network. It is like = having >> service functions embedded in a router. >> The service functions don't know the underlay network. >>=20 >> Linda >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >>=20 >>=20 >=20 >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc >=20 --Apple-Mail=_F5A4670C-926B-4D96-8ACB-D4E9E587E99B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJSaS65AAoJEPcO+I7eiUJZtw8QALNI0PuI+F81rGN1JhPkATH/ iobTZQRE9nJvxFT3pDxoZ5ztwTiKb4CYIxUVIPhHNCo+jJQfb5Q7CH/qr60IVPjm gYAWtMsxflO0IK+D+yzwHKVpB0o4WlW4CJvaMPV6zw5Djj6QKFc+hPc/eO6aM6n3 S9fmSo/ZKHVQz3qSGOqQLVz8ZVPHDcyIoD6b4zDI32w+g8mLuDJzqDw7sSK/Q1m6 SBkzVxrglWGbF1bSSluF+d+2ikhkH8MM+Hum2K6ug6JCJ3O1UveQEMANgxSSTtQh hwGSBJ2Xl3hMzMKvhjNQR8viUln6z9zUABXr3aICQzm6LtMPQXNHm7z/gDK+Z/n0 KzcsBI3jhvMnBBHIlXVRMcHSMc1NvvEIgpSjJkVChAQcqnt5P59egVMIgVw0qEFL UxoU/XpSubOzii3qTU/O7c1L80TDPYO8uLt/OiltZiQC0RgTUc9wcPqzodr0gUr0 bYKwFyNrahDFUIGOVX5vuHZmeRKUAlncyxaFEKYjjJ/wrrprycpzMEJ2+WmwmEuQ EWSzwg4DygxOB7U8EBb+vA4nROQDxU9zQnCGD31+Cdwce8c7TaZs9fCSm4L8HMKd Cg9EjZRSaHEGf0x7bhyVNI0TIhPFTG8kkd73I05+P+S0qvgf4Yfq4o13LkIMMide qGNOTJTTL+Z0aGvA2Cwr =OG8m -----END PGP SIGNATURE----- --Apple-Mail=_F5A4670C-926B-4D96-8ACB-D4E9E587E99B-- From I.Smith@F5.com Thu Oct 24 08:50:20 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C3611E8365 for ; Thu, 24 Oct 2013 08:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW4c9qZKQbfj for ; Thu, 24 Oct 2013 08:50:14 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2F21F9E6D for ; Thu, 24 Oct 2013 08:46:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382629602; x=1414165602; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Bgr3LaA5vvi0ahQBMe82qKyY6fjS7M5FK2nly2BmNRg=; b=vshn12mhOpWKddJEA2+JbFIbkLIxfdJwD49VQfheySkq6XJOHXF9jgQw J+ubADRhTIrnL4Y7AvZkXddFpR2/qwps/offjuMzV7ktBnhS3De7X74X4 0E2wjqr4J20USMQD6EMW/TdsihMHz+asS/kp7xA7phzv2ZnCR27bqGUoA 4=; X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="84341395" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 15:46:35 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 08:46:34 -0700 From: Ian Smith To: Sumandra Majee , Ron Parker , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrw1GG5M74Ck+l8hfL728XsJoBo1qAgAAVmgCAAYBCgIAAvrU/ Date: Thu, 24 Oct 2013 15:46:34 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> In-Reply-To: <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:50:22 -0000 X-List-Received-Date: Thu, 24 Oct 2013 15:50:22 -0000 In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop. =0A= =0A= There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain).=0A= =0A= this is a steering rule:=0A= =0A= match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] =0A= (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.) =0A= =0A= this is a chaining rule:=0A= =0A= match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic from the source prefix, send to the default gateway)=0A= =0A= or=0A= =0A= match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132]=0A= (for traffic with policy 1000, send to the default gateway)=0A= =0A= =0A= =0A= ________________________________________=0A= From: Sumandra Majee=0A= Sent: Wednesday, October 23, 2013 4:43 PM=0A= To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC.=0A= =0A= [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold.=0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to.=0A= =0A= -----Original Message-----=0A= From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= Sent: Tuesday, October 22, 2013 2:49 PM=0A= To: Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hi, Linda.=0A= =0A= Responses inline.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= Sent: Tuesday, October 22, 2013 4:31 PM=0A= To: Ron Parker; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ron,=0A= =0A= Thank you very much for the valuable comments. See my response inserted bel= ow:=0A= =0A= > -----Original Message-----=0A= >=0A= >=0A= > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= > -=0A= > - although it may be slightly off topic for your draft, it occurs to=0A= > me that the proxy nodes would be ideal locations to load balance=0A= > towards multiple instances of the same type of service node (i.e.,=0A= > combining proxy-node and load-balancing).=0A= =0A= [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places?=0A= Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both?= =0A= =0A= =0A= [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here.=0A= =0A= >=0A= > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= > the first indented bullet states that the service function can be=0A= > embedded in a service chain proxy. From a software implementation=0A= > perspective that makes perfect sense. But from a network topology=0A= > perspective, the proxy would not be explicitly observable -- the=0A= > service function would look like it had native SFC capabilities with=0A= > respect to other SFC service nodes and/or classifiers.=0A= =0A= [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario?=0A= =0A= =0A= [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy.=0A= =0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= =0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= Maybe we can chat face to face in Vancouver for the following points.=0A= =0A= [Ron] It would be my pleasure :). Please contact me privately.=0A= =0A= =0A= Linda=0A= > Section 4.2 (traffic steering). Consistent with my comment above, my=0A= > feeling is that one of the biggest advantages of SFC is to become=0A= > topology and transport unaware so that a new mechanism need not be=0A= > invented for every combination of network topology (i.e., 1 hop away,=0A= > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >=0A= > Section 5.1 (multiple instances). Consistent with comments above,=0A= > with correct separation of the logical and physical, steering tables=0A= > would not need to be updated each time an NFV event occurred (i.e.,=0A= > instace up, down, moved, expanded, contracted, etc.).=0A= >=0A= > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= > comments to above. If we choose a topology and transport independent=0A= > mechanism to follow a service chain, the complexity is reduced and the=0A= > reliability is improved. Something akin to the steering that you=0A= > mention is constrained to the classification node(s), greatly=0A= > simplifying the service nodes.=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Linda Dunbar=0A= > Sent: Monday, October 21, 2013 5:15 PM=0A= > To: nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: [nsc] New Version Notification for=0A= > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >=0A= > There have been many drafts submitted for SFC (Service Function=0A= > Chaining) BOF already. However, we felt that architecture and issues=0A= > associated with chaining existing Layer 4-7 service functions that are=0A= > not aware of Service Encapsulation header haven=92t been addressed by=0A= > any drafts (which is called =93Proxy Nodes=94 by draft-quinn-nsh-01).=0A= >=0A= > We put together a draft to analyze the issues associated with chaining=0A= > existing=0A= > Layer 4-7 service functions that are not aware of service=0A= > encapsulation layers. This draft also examines the network=0A= > architecture for chaining existing L4-L7 service functions. The=0A= > intent is to identify and describe gaps that have not been=0A= > addressed by other SFC drafts.=0A= >=0A= > Your comments are greatly appreciated.=0A= >=0A= >=0A= > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= > Revision: 00=0A= > Title: Architecture for Chaining Legacy Layer 4-7 Service= =0A= > Functions=0A= > Creation date: 2013-10-16=0A= > Group: Individual Submission=0A= > Number of pages: 16=0A= > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture-00.txt=0A= > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture=0A= > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= > l7-chain-architecture-00=0A= >=0A= >=0A= > Linda, Ning, Ian, Sumandra, and Donald=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From Ron_Parker@affirmednetworks.com Thu Oct 24 09:07:35 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4913C21E8092 for ; Thu, 24 Oct 2013 09:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBcqdil89MX5 for ; Thu, 24 Oct 2013 09:07:12 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3914911E83A0 for ; Thu, 24 Oct 2013 09:02:06 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:01:56 -0700 From: Ron Parker To: Ian Smith , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoAgAAKa5CAAfJagP//ndDQgAH4DICAAT8+AP//jMiQ Date: Thu, 24 Oct 2013 16:01:56 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:07:35 -0000 Hi, Ian. I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity. Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier. Ron -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com]=20 Sent: Thursday, October 24, 2013 11:47 AM To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop. =20 There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain). this is a steering rule: match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.)=20 this is a chaining rule: match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic from the source prefix, send to the default gateway) or match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132] (for traffic with policy 1000, send to the default gateway) ________________________________________ From: Sumandra Majee Sent: Wednesday, October 23, 2013 4:43 PM To: Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC. [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, October 22, 2013 2:49 PM To: Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Hi, Linda. Responses inline. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Tuesday, October 22, 2013 4:31 PM To: Ron Parker; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Ron, Thank you very much for the valuable comments. See my response inserted bel= ow: > -----Original Message----- > > > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) > - > - although it may be slightly off topic for your draft, it occurs to=20 > me that the proxy nodes would be ideal locations to load balance=20 > towards multiple instances of the same type of service node (i.e.,=20 > combining proxy-node and load-balancing). [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places? Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both? [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here. > > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=20 > the first indented bullet states that the service function can be > embedded in a service chain proxy. From a software implementation > perspective that makes perfect sense. But from a network topology > perspective, the proxy would not be explicitly observable -- the=20 > service function would look like it had native SFC capabilities with=20 > respect to other SFC service nodes and/or classifiers. [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario? [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. Maybe we can chat face to face in Vancouver for the following points. [Ron] It would be my pleasure :). Please contact me privately. Linda > Section 4.2 (traffic steering). Consistent with my comment above, my > feeling is that one of the biggest advantages of SFC is to become=20 > topology and transport unaware so that a new mechanism need not be=20 > invented for every combination of network topology (i.e., 1 hop away, > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=20 > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). > > Section 5.1 (multiple instances). Consistent with comments above, > with correct separation of the logical and physical, steering tables=20 > would not need to be updated each time an NFV event occurred (i.e.,=20 > instace up, down, moved, expanded, contracted, etc.). > > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar > comments to above. If we choose a topology and transport independent > mechanism to follow a service chain, the complexity is reduced and the > reliability is improved. Something akin to the steering that you > mention is constrained to the classification node(s), greatly=20 > simplifying the service nodes. > > > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Linda Dunbar > Sent: Monday, October 21, 2013 5:15 PM > To: nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: [nsc] New Version Notification for > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt > > There have been many drafts submitted for SFC (Service Function > Chaining) BOF already. However, we felt that architecture and issues=20 > associated with chaining existing Layer 4-7 service functions that are=20 > not aware of Service Encapsulation header haven't been addressed by=20 > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). > > We put together a draft to analyze the issues associated with chaining=20 > existing > Layer 4-7 service functions that are not aware of service > encapsulation layers. This draft also examines the network > architecture for chaining existing L4-L7 service functions. The > intent is to identify and describe gaps that have not been > addressed by other SFC drafts. > > Your comments are greatly appreciated. > > > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > Revision: 00 > Title: Architecture for Chaining Legacy Layer 4-7 Service > Functions > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture-00.txt > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- > l7-chain-architecture-00 > > > Linda, Ning, Ian, Sumandra, and Donald > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Thu Oct 24 09:18:42 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BF211E81B2 for ; Thu, 24 Oct 2013 09:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.306 X-Spam-Level: X-Spam-Status: No, score=-10.306 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ced1kPTQtGdU for ; Thu, 24 Oct 2013 09:18:38 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id E9EF311E8367 for ; Thu, 24 Oct 2013 09:16:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="85134130" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 24 Oct 2013 16:16:31 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:16:30 -0700 From: Ian Smith To: Ron Parker , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrw1GG5M74Ck+l8hfL728XsJoBo1qAgAAVmgCAAYBCgIAAvrU/gACE1QD//41DAw== Date: Thu, 24 Oct 2013 16:16:30 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:18:42 -0000 Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function.=0A= =0A= Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point.=0A= =0A= Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place.=0A= =0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:01 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity.=0A= =0A= Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 11:47 AM=0A= To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop.=0A= =0A= There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain).=0A= =0A= this is a steering rule:=0A= =0A= match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.)=0A= =0A= this is a chaining rule:=0A= =0A= match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic from the source prefix, send to the default gateway)=0A= =0A= or=0A= =0A= match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132]=0A= (for traffic with policy 1000, send to the default gateway)=0A= =0A= =0A= =0A= ________________________________________=0A= From: Sumandra Majee=0A= Sent: Wednesday, October 23, 2013 4:43 PM=0A= To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC.=0A= =0A= [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold.=0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to.=0A= =0A= -----Original Message-----=0A= From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= Sent: Tuesday, October 22, 2013 2:49 PM=0A= To: Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hi, Linda.=0A= =0A= Responses inline.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= Sent: Tuesday, October 22, 2013 4:31 PM=0A= To: Ron Parker; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ron,=0A= =0A= Thank you very much for the valuable comments. See my response inserted bel= ow:=0A= =0A= > -----Original Message-----=0A= >=0A= >=0A= > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= > -=0A= > - although it may be slightly off topic for your draft, it occurs to=0A= > me that the proxy nodes would be ideal locations to load balance=0A= > towards multiple instances of the same type of service node (i.e.,=0A= > combining proxy-node and load-balancing).=0A= =0A= [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places?=0A= Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both?= =0A= =0A= =0A= [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here.=0A= =0A= >=0A= > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= > the first indented bullet states that the service function can be=0A= > embedded in a service chain proxy. From a software implementation=0A= > perspective that makes perfect sense. But from a network topology=0A= > perspective, the proxy would not be explicitly observable -- the=0A= > service function would look like it had native SFC capabilities with=0A= > respect to other SFC service nodes and/or classifiers.=0A= =0A= [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario?=0A= =0A= =0A= [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy.=0A= =0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= =0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= Maybe we can chat face to face in Vancouver for the following points.=0A= =0A= [Ron] It would be my pleasure :). Please contact me privately.=0A= =0A= =0A= Linda=0A= > Section 4.2 (traffic steering). Consistent with my comment above, my=0A= > feeling is that one of the biggest advantages of SFC is to become=0A= > topology and transport unaware so that a new mechanism need not be=0A= > invented for every combination of network topology (i.e., 1 hop away,=0A= > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >=0A= > Section 5.1 (multiple instances). Consistent with comments above,=0A= > with correct separation of the logical and physical, steering tables=0A= > would not need to be updated each time an NFV event occurred (i.e.,=0A= > instace up, down, moved, expanded, contracted, etc.).=0A= >=0A= > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= > comments to above. If we choose a topology and transport independent=0A= > mechanism to follow a service chain, the complexity is reduced and the=0A= > reliability is improved. Something akin to the steering that you=0A= > mention is constrained to the classification node(s), greatly=0A= > simplifying the service nodes.=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Linda Dunbar=0A= > Sent: Monday, October 21, 2013 5:15 PM=0A= > To: nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: [nsc] New Version Notification for=0A= > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >=0A= > There have been many drafts submitted for SFC (Service Function=0A= > Chaining) BOF already. However, we felt that architecture and issues=0A= > associated with chaining existing Layer 4-7 service functions that are=0A= > not aware of Service Encapsulation header haven't been addressed by=0A= > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >=0A= > We put together a draft to analyze the issues associated with chaining=0A= > existing=0A= > Layer 4-7 service functions that are not aware of service=0A= > encapsulation layers. This draft also examines the network=0A= > architecture for chaining existing L4-L7 service functions. The=0A= > intent is to identify and describe gaps that have not been=0A= > addressed by other SFC drafts.=0A= >=0A= > Your comments are greatly appreciated.=0A= >=0A= >=0A= > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= > Revision: 00=0A= > Title: Architecture for Chaining Legacy Layer 4-7 Service= =0A= > Functions=0A= > Creation date: 2013-10-16=0A= > Group: Individual Submission=0A= > Number of pages: 16=0A= > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture-00.txt=0A= > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture=0A= > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= > l7-chain-architecture-00=0A= >=0A= >=0A= > Linda, Ning, Ian, Sumandra, and Donald=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From Ron_Parker@affirmednetworks.com Thu Oct 24 09:31:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E4911E829B for ; Thu, 24 Oct 2013 09:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LsglgC5JjCi for ; Thu, 24 Oct 2013 09:31:24 -0700 (PDT) Received: from hub021-ca-4.exch021.serverdata.net (hub021-ca-4.exch021.serverdata.net [64.78.22.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89D11E8342 for ; Thu, 24 Oct 2013 09:31:24 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-4.exch021.domain.local ([10.254.4.39]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:31:24 -0700 From: Ron Parker To: Ian Smith , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoAgAAKa5CAAfJagP//ndDQgAH4DICAAT8+AP//jMiQgAB7lQD//4yx4A== Date: Thu, 24 Oct 2013 16:31:23 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:31:29 -0000 Hi, Ian. Please see inline below. Ron -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com]=20 Sent: Thursday, October 24, 2013 12:17 PM To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function. Ron> Sure, the "start the chain" enforcement function is free to engage the= services of a remote policy evaluation engine. Nothing in the architectu= re precludes that. Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point. Ron> Are you saying that DPI platforms should become "start the chain" enfo= rcement functions? Nothing in the architecture precludes that. Can you = elaborate on the "marking" concept, please? In an SFC environment, would = that become the addition of the SFC service header encapsulation? Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place. Ron> This capability would not be restricted to flows carrying "content" as= commonly defined (i.e., HTTP objects, FTP files, etc.). One example coul= d be a service function that is performing some sort of quota accounting --= after reaching some quota threshold, a different set of services is chosen= (perhaps a subset of what is selected at original policy classification). ________________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Thursday, October 24, 2013 12:01 PM To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt Hi, Ian. I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity. Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier. Ron -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: Thursday, October 24, 2013 11:47 AM To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop. There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain). this is a steering rule: match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.) this is a chaining rule: match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic from the source prefix, send to the default gateway) or match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132] (for traffic with policy 1000, send to the default gateway) ________________________________________ From: Sumandra Majee Sent: Wednesday, October 23, 2013 4:43 PM To: Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC. [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, October 22, 2013 2:49 PM To: Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Hi, Linda. Responses inline. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Tuesday, October 22, 2013 4:31 PM To: Ron Parker; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Ron, Thank you very much for the valuable comments. See my response inserted bel= ow: > -----Original Message----- > > > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) > - > - although it may be slightly off topic for your draft, it occurs to=20 > me that the proxy nodes would be ideal locations to load balance=20 > towards multiple instances of the same type of service node (i.e.,=20 > combining proxy-node and load-balancing). [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places? Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both? [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here. > > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=20 > the first indented bullet states that the service function can be > embedded in a service chain proxy. From a software implementation > perspective that makes perfect sense. But from a network topology > perspective, the proxy would not be explicitly observable -- the=20 > service function would look like it had native SFC capabilities with=20 > respect to other SFC service nodes and/or classifiers. [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario? [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. Maybe we can chat face to face in Vancouver for the following points. [Ron] It would be my pleasure :). Please contact me privately. Linda > Section 4.2 (traffic steering). Consistent with my comment above, my > feeling is that one of the biggest advantages of SFC is to become=20 > topology and transport unaware so that a new mechanism need not be=20 > invented for every combination of network topology (i.e., 1 hop away, > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=20 > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). > > Section 5.1 (multiple instances). Consistent with comments above, > with correct separation of the logical and physical, steering tables=20 > would not need to be updated each time an NFV event occurred (i.e.,=20 > instace up, down, moved, expanded, contracted, etc.). > > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar > comments to above. If we choose a topology and transport independent > mechanism to follow a service chain, the complexity is reduced and the > reliability is improved. Something akin to the steering that you > mention is constrained to the classification node(s), greatly=20 > simplifying the service nodes. > > > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Linda Dunbar > Sent: Monday, October 21, 2013 5:15 PM > To: nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: [nsc] New Version Notification for > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt > > There have been many drafts submitted for SFC (Service Function > Chaining) BOF already. However, we felt that architecture and issues=20 > associated with chaining existing Layer 4-7 service functions that are=20 > not aware of Service Encapsulation header haven't been addressed by=20 > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). > > We put together a draft to analyze the issues associated with chaining=20 > existing > Layer 4-7 service functions that are not aware of service > encapsulation layers. This draft also examines the network > architecture for chaining existing L4-L7 service functions. The > intent is to identify and describe gaps that have not been > addressed by other SFC drafts. > > Your comments are greatly appreciated. > > > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > Revision: 00 > Title: Architecture for Chaining Legacy Layer 4-7 Service > Functions > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture-00.txt > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- > l7-chain-architecture-00 > > > Linda, Ning, Ian, Sumandra, and Donald > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From paulq@cisco.com Thu Oct 24 09:37:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8D011E837C for ; Thu, 24 Oct 2013 09:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNEB+DbuU7UA for ; Thu, 24 Oct 2013 09:36:56 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0AE611E829B for ; Thu, 24 Oct 2013 09:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12828; q=dns/txt; s=iport; t=1382632557; x=1383842157; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=agAQrtMFEtVXy/d57UY3gUOct7TlYT9QSSWirqHln0A=; b=b/QZf/ZvWU8l263i4KUyLHDZWvfYBxvUC3Sv52R2PmrS5SmbkyuoHULW hEXBpA868rn+yjRlNTeM5kEdZTsucZ5+uGVeJ6DTM848jzAn9TqjKZ99h yhdfzeThLV8a5cLAk7tSBRoCrMqeeP4srDn0gDNomTZpEWRjbvqCleLjZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFRLaVKtJXG8/2dsb2JhbABPCoMHOFS+V4EdFnSCJQEBAQMBAQEBCywrCQkCBQcCAgIBCA4DAQMBAQsUCQcbDAsUAwYIAgQOBQgBh3gGDbo+BI4GgRACBgUmBwaDGYENA5QqhQ+QWIFmgT6CKg X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="276232695" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 24 Oct 2013 16:35:49 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OGZmdn016432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 16:35:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 11:35:48 -0500 From: "Paul Quinn (paulq)" To: Ian Smith Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqlaL/09QYDFt0is5t0q76x+UJoBgdKAgAAVmgCAAYBDgIABPz4AgAAESwCAAAQSAIAABWUA Date: Thu, 24 Oct 2013 16:35:48 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.92.91] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:37:01 -0000 Hi Ian, On Oct 24, 2013, at 9:16 AM, Ian Smith wrote: > Yeah. I'm not in agreement - the classification function isn't necessari= ly co-located with the "start the chain" policy enforcement function. >=20 Not all classification is related to SFC, however rhe SFC classification is= the start of the chain. You can have non-SFC classification (i.e. packets = are classified but orthogonal to the SFC chain) that reside anywhere. =20 > Basically, there are millions of DPI platforms that don't need to be repl= aced for you to be able to use their marking for steering decisions, and th= ere are much, much more complex marking/classification mechanisms that can'= t be done in-line on the wire that will also need to be accommodated by a p= olicy enforcement point. >=20 > Also, while having the ability to "reclassify" in the middle of the chain= is conceptually useful, you aren't chaining at that point anymore and you'= ve entered a realm of content switching, which is, if I understand correctl= y, one of the things that is being called too complex/expensive as a justif= ication for creating a service chains in the first place. >=20 I disagree. Re-classfiication essentially duplicate the "start of chain" l= ogic which is certainly understood and implementable =20 >=20 > ________________________________________ > From: Ron Parker [Ron_Parker@affirmednetworks.com] > Sent: Thursday, October 24, 2013 12:01 PM > To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org > Cc: Donald Eastlake; Ning So > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-= legacy-l4-l7-chain-architecture-00.txt >=20 > Hi, Ian. >=20 > I agree conceptually that there is a difference between making a local po= licy based decision as to how to progress a packet vs. respecting a decisio= n that was made by an upstream entity. >=20 > Extending those concepts into the SFC realm, the classifier makes a full = "source-routed" decision as to which logical "mid-boxes" shall be visited a= nd in which order. Any midbox that is also a classifier may optionally re= classify and optionally choose a different chain. Any midbox that is not = a classifier (or chooses not to reclassify) is obligated to follow the chai= n determined by the most recent upstream classifier. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Ian Smith [mailto:I.Smith@F5.com] > Sent: Thursday, October 24, 2013 11:47 AM > To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org > Cc: Donald Eastlake; Ning So > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt >=20 > In my mind, steering is more "smart" than chaining because a host making = a steering decision has to evaluate a lot of options to arrive at the next = hop, whereas a host in the middle of a chain is, I think, only supposed to = have one option for the next-hop. >=20 > There are a lot more nuance and context to service chains, but in this pa= rticular case it seems to me that there is a pretty clear parallel between = a host that is a router and a host that has a single default gateway; steer= ing gets you into a chain, but once in the chain you can only get to the ne= xt link in that chain (because otherwise it isn't really a chain). >=20 > this is a steering rule: >=20 > match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:F= FFF/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp= =3D=3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D= =3D2001:DB8:0:FFFF::AAAA/132] > (for traffic port 80 using the phone.west1.example.net access point name,= and coming from the IP prefix and that is either classified as video or as= signed DSCP 32, insert an options header designating the policy for the nex= t four hops and forward to the next hop.) >=20 > this is a chaining rule: >=20 > match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D= 2001:DB8:0:FFFF::AAAA/132] > (for traffic from the source prefix, send to the default gateway) >=20 > or >=20 > match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D200= 1:DB8:0:FFFF::AAAA/132] > (for traffic with policy 1000, send to the default gateway) >=20 >=20 >=20 > ________________________________________ > From: Sumandra Majee > Sent: Wednesday, October 23, 2013 4:43 PM > To: Ron Parker; Linda Dunbar; nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-= legacy-l4-l7-chain-architecture-00.txt >=20 >> I do have a few comments and one overall theme regarding "steering", whi= ch I consider the legacy approach that we are trying to improve in SFC. >=20 > [SM] Not sure I get the distinction between "chaining" and "steering". T= he L7 services are often inserted dynamically to the service chain based on= 1) later classification 2) based on network condition like "steering" to v= ideo optimizer when available bandwidth falls below certain threshold. >=20 >>=20 >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >>=20 > [Linda] In this context, the Proxy nodes are topology unaware. But proxy= nodes know their connection to the directly connected service functions. I= s it OK? > [Ron] I think this goes to where the intelligence is for the forwarding. >=20 > [SM] Agreed that the forwarding point need to be aware of the topology bu= t proxy-node itself doesn't need to. >=20 > -----Original Message----- > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] > Sent: Tuesday, October 22, 2013 2:49 PM > To: Linda Dunbar; nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt >=20 > Hi, Linda. >=20 > Responses inline. >=20 > Ron >=20 >=20 > -----Original Message----- > From: Linda Dunbar [mailto:linda.dunbar@huawei.com] > Sent: Tuesday, October 22, 2013 4:31 PM > To: Ron Parker; nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt >=20 > Ron, >=20 > Thank you very much for the valuable comments. See my response inserted b= elow: >=20 >> -----Original Message----- >>=20 >>=20 >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). >=20 > [Linda] are you saying that multiple instances are co-located? What if mu= ltiple instances for one network function are located in different places? > Do you think the "proxy node" should balance them, or should the controll= er balance them and simply inform the "proxy node"? or combination of both= ? >=20 >=20 > [Ron] My thinking, so far, is that a load-balancer is, itself a network s= ervice function which understands that it manges some set of functionally e= quivalent subtended network service function instances. But, from a logi= cal perspective, I think that I have argued myself out of co-mingling the p= roxy concept and the load balancing concept. They can be mixed and matche= d as necessary, and co-located as desired. For example, a chain may indic= ate that a load-balancer must be visited. The load balancer balances to m= ultiple instances of proxy-fronted non-SFC-aware service functions. But,= all of this is off-topic, so I apologize for introducing it here. >=20 >>=20 >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), >> the first indented bullet states that the service function can be >> embedded in a service chain proxy. From a software implementation >> perspective that makes perfect sense. But from a network topology >> perspective, the proxy would not be explicitly observable -- the >> service function would look like it had native SFC capabilities with >> respect to other SFC service nodes and/or classifiers. >=20 > [Linda] I will change the text to reflect this point. On the other hand, = many of today's service functions are independent. They don't care who is a= head of them and who is after. How would you describe this scenario? >=20 >=20 > [Ron] I think we are saying that to be SFC-aware is to know, explicitly, = which service function is next. A service function which doesn't understa= nd that concept is front-ended by an SFC-proxy. >=20 >=20 >>=20 >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >>=20 > [Linda] In this context, the Proxy nodes are topology unaware. But proxy= nodes know their connection to the directly connected service functions. I= s it OK? >=20 > [Ron] I think this goes to where the intelligence is for the forwarding. >=20 > Maybe we can chat face to face in Vancouver for the following points. >=20 > [Ron] It would be my pleasure :). Please contact me privately. >=20 >=20 > Linda >> Section 4.2 (traffic steering). Consistent with my comment above, my >> feeling is that one of the biggest advantages of SFC is to become >> topology and transport unaware so that a new mechanism need not be >> invented for every combination of network topology (i.e., 1 hop away, >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). >>=20 >> Section 5.1 (multiple instances). Consistent with comments above, >> with correct separation of the logical and physical, steering tables >> would not need to be updated each time an NFV event occurred (i.e., >> instace up, down, moved, expanded, contracted, etc.). >>=20 >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar >> comments to above. If we choose a topology and transport independent >> mechanism to follow a service chain, the complexity is reduced and the >> reliability is improved. Something akin to the steering that you >> mention is constrained to the classification node(s), greatly >> simplifying the service nodes. >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Monday, October 21, 2013 5:15 PM >> To: nsc@ietf.org >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >> Subject: [nsc] New Version Notification for >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt >>=20 >> There have been many drafts submitted for SFC (Service Function >> Chaining) BOF already. However, we felt that architecture and issues >> associated with chaining existing Layer 4-7 service functions that are >> not aware of Service Encapsulation header haven't been addressed by >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). >>=20 >> We put together a draft to analyze the issues associated with chaining >> existing >> Layer 4-7 service functions that are not aware of service >> encapsulation layers. This draft also examines the network >> architecture for chaining existing L4-L7 service functions. The >> intent is to identify and describe gaps that have not been >> addressed by other SFC drafts. >>=20 >> Your comments are greatly appreciated. >>=20 >>=20 >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture >> Revision: 00 >> Title: Architecture for Chaining Legacy Layer 4-7 Servic= e >> Functions >> Creation date: 2013-10-16 >> Group: Individual Submission >> Number of pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture-00.txt >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- >> l7-chain-architecture-00 >>=20 >>=20 >> Linda, Ning, Ian, Sumandra, and Donald >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Thu Oct 24 09:37:33 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207EF11E8389 for ; Thu, 24 Oct 2013 09:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.531 X-Spam-Level: X-Spam-Status: No, score=-10.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB3EXheWkTlj for ; Thu, 24 Oct 2013 09:37:22 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8295411E8354 for ; Thu, 24 Oct 2013 09:36:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11328; q=dns/txt; s=iport; t=1382632611; x=1383842211; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7qfD1Eq06mERSJ6y9EallsjK1M1+kEaKQgiHlFFo7qc=; b=mGjXp/aWns9wKo0rB0/UNebiJvvGnahKULSDj05YjUWPC+IvIe/Fd+cq +0ZF7h2jYFsbwsYki37cB3Hheni1YnqGLrFTTF8recvG+helfNlLU5Zue xgZcMH/ioB+JjLWxEPr89Lt1pldMd77rWo1k8mdjhBDi9zRZAdYYroNqT U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFADlMaVKtJV2b/2dsb2JhbABPCoMHOFS+V4EdFnSCJQEBAQMBAQEBCywrCQkCBQcCBAEIEQEDAQELFAkiDAsUAwYIAgQBDQUIAYd4Bg26QASOBoEQAgYFJgcGgxmBDQOUKoUPkFiBZoE+gio X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="276218822" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 24 Oct 2013 16:36:46 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9OGak2g001347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 16:36:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 11:36:45 -0500 From: "Jim Guichard (jguichar)" To: Ron Parker , Ian Smith , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0Nc6ABwl+G/vf0CxSI0i3TCdow== Date: Thu, 24 Oct 2013 16:36:44 +0000 Message-ID: <68B171751455884590F8E38E96416F363F709239@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:37:33 -0000 Hi Ron, On 10/24/13 12:01 PM, "Ron Parker" wrote: >Hi, Ian. > >I agree conceptually that there is a difference between making a local >policy based decision as to how to progress a packet vs. respecting a >decision that was made by an upstream entity. > >Extending those concepts into the SFC realm, the classifier makes a full >"source-routed" decision as to which logical "mid-boxes" shall be visited >and in which order. Jim> The classifier *may* make a source routed decision but it is not required by the architecture. In the general sense the classifier need only classify traffic into a service chain and then forward that traffic to the *first* service node that hosts the *first* service function of the chain; it need not know which subsequent service nodes will perform the rest of the service functions. > Any midbox that is also a classifier may optionally reclassify and >optionally choose a different chain. Any midbox that is not a >classifier (or chooses not to reclassify) is obligated to follow the >chain determined by the most recent upstream classifier. > > Ron > > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 11:47 AM >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >In my mind, steering is more "smart" than chaining because a host making >a steering decision has to evaluate a lot of options to arrive at the >next hop, whereas a host in the middle of a chain is, I think, only >supposed to have one option for the next-hop. > >There are a lot more nuance and context to service chains, but in this >particular case it seems to me that there is a pretty clear parallel >between a host that is a router and a host that has a single default >gateway; steering gets you into a chain, but once in the chain you can >only get to the next link in that chain (because otherwise it isn't >really a chain). > >this is a steering rule: > >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ] >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic port 80 using the phone.west1.example.net access point name, >and coming from the IP prefix and that is either classified as video or >assigned DSCP 32, insert an options header designating the policy for the >next four hops and forward to the next hop.) > >this is a chaining rule: > >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic from the source prefix, send to the default gateway) > >or > >match=3D=3D[ip.option.253.[1]=3D=3D1000] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic with policy 1000, send to the default gateway) > > > >________________________________________ >From: Sumandra Majee >Sent: Wednesday, October 23, 2013 4:43 PM >To: Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >>I do have a few comments and one overall theme regarding "steering", >>which I consider the legacy approach that we are trying to improve in >>SFC. > >[SM] Not sure I get the distinction between "chaining" and "steering". >The L7 services are often inserted dynamically to the service chain based >on 1) later classification 2) based on network condition like "steering" >to video optimizer when available bandwidth falls below certain threshold. > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? >[Ron] I think this goes to where the intelligence is for the forwarding. > >[SM] Agreed that the forwarding point need to be aware of the topology >but proxy-node itself doesn't need to. > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Tuesday, October 22, 2013 2:49 PM >To: Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Linda. > >Responses inline. > > Ron > > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Tuesday, October 22, 2013 4:31 PM >To: Ron Parker; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Ron, > >Thank you very much for the valuable comments. See my response inserted >below: > >> -----Original Message----- >> >> >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). > >[Linda] are you saying that multiple instances are co-located? What if >multiple instances for one network function are located in different >places? >Do you think the "proxy node" should balance them, or should the >controller balance them and simply inform the "proxy node"? or >combination of both? > > >[Ron] My thinking, so far, is that a load-balancer is, itself a network >service function which understands that it manges some set of >functionally equivalent subtended network service function instances. >But, from a logical perspective, I think that I have argued myself out of >co-mingling the proxy concept and the load balancing concept. They can >be mixed and matched as necessary, and co-located as desired. For >example, a chain may indicate that a load-balancer must be visited. The >load balancer balances to multiple instances of proxy-fronted >non-SFC-aware service functions. But, all of this is off-topic, so I >apologize for introducing it here. > >> >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), >> the first indented bullet states that the service function can be >> embedded in a service chain proxy. From a software implementation >> perspective that makes perfect sense. But from a network topology >> perspective, the proxy would not be explicitly observable -- the >> service function would look like it had native SFC capabilities with >> respect to other SFC service nodes and/or classifiers. > >[Linda] I will change the text to reflect this point. On the other hand, >many of today's service functions are independent. They don't care who is >ahead of them and who is after. How would you describe this scenario? > > >[Ron] I think we are saying that to be SFC-aware is to know, explicitly, >which service function is next. A service function which doesn't >understand that concept is front-ended by an SFC-proxy. > > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? > >[Ron] I think this goes to where the intelligence is for the forwarding. > >Maybe we can chat face to face in Vancouver for the following points. > >[Ron] It would be my pleasure :). Please contact me privately. > > >Linda >> Section 4.2 (traffic steering). Consistent with my comment above, my >> feeling is that one of the biggest advantages of SFC is to become >> topology and transport unaware so that a new mechanism need not be >> invented for every combination of network topology (i.e., 1 hop away, >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). >> >> Section 5.1 (multiple instances). Consistent with comments above, >> with correct separation of the logical and physical, steering tables >> would not need to be updated each time an NFV event occurred (i.e., >> instace up, down, moved, expanded, contracted, etc.). >> >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar >> comments to above. If we choose a topology and transport independent >> mechanism to follow a service chain, the complexity is reduced and the >> reliability is improved. Something akin to the steering that you >> mention is constrained to the classification node(s), greatly >> simplifying the service nodes. >> >> >> >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Monday, October 21, 2013 5:15 PM >> To: nsc@ietf.org >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >> Subject: [nsc] New Version Notification for >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt >> >> There have been many drafts submitted for SFC (Service Function >> Chaining) BOF already. However, we felt that architecture and issues >> associated with chaining existing Layer 4-7 service functions that are >> not aware of Service Encapsulation header haven't been addressed by >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). >> >> We put together a draft to analyze the issues associated with chaining >> existing >> Layer 4-7 service functions that are not aware of service >> encapsulation layers. This draft also examines the network >> architecture for chaining existing L4-L7 service functions. The >> intent is to identify and describe gaps that have not been >> addressed by other SFC drafts. >> >> Your comments are greatly appreciated. >> >> >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture >> Revision: 00 >> Title: Architecture for Chaining Legacy Layer 4-7 >>Service >> Functions >> Creation date: 2013-10-16 >> Group: Individual Submission >> Number of pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture-00.txt >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- >> l7-chain-architecture-00 >> >> >> Linda, Ning, Ian, Sumandra, and Donald >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Thu Oct 24 09:41:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B34A11E8377 for ; Thu, 24 Oct 2013 09:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.303 X-Spam-Level: X-Spam-Status: No, score=-10.303 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9DC5YjxQUTl for ; Thu, 24 Oct 2013 09:41:16 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id D776511E8368 for ; Thu, 24 Oct 2013 09:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382632844; x=1414168844; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Bi2hm7PolC7z5DWg9SEBiE/Xv9f7Px7kORWSH8U1I1I=; b=ZRb4J1G+7G4LI9IxZA2hZ91VaW9SXr5EBfKg3kNXKgSDpSsT4MUsjTrO AqPH1ly8BmXmOU/Cc5P/xQr40u63vJj/LJYbtJX2qvbpvtQ/LgdnYK9k4 WT7wybMAWggCLWprQc3e1wBQCNDb2LsOR5gMnHZY48W7Mh/Qn5I7gsXyx c=; X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="84349052" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 16:40:27 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:40:26 -0700 From: Ian Smith To: Ron Parker , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrw1GG5M74Ck+l8hfL728XsJoBo1qAgAAVmgCAAYBCgIAAvrU/gACE1QD//41DA4AAeveA//+K/N8= Date: Thu, 24 Oct 2013 16:40:26 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70BFE3@SEAEMBX02.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:41:28 -0000 =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:31 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= Please see inline below.=0A= =0A= Ron=0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 12:17 PM=0A= To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function.=0A= =0A= =0A= Ron> Sure, the "start the chain" enforcement function is free to engage the= services of a remote policy evaluation engine. Nothing in the architectu= re precludes that.=0A= =0A= =0A= Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point.=0A= =0A= =0A= Ron> Are you saying that DPI platforms should become "start the chain" enfo= rcement functions? Nothing in the architecture precludes that. Can you = elaborate on the "marking" concept, please? In an SFC environment, would = that become the addition of the SFC service header encapsulation?=0A= =0A= [ims] no, but when you say "the classifier makes a full "source-routed" dec= ision" that does imply that classification function is going to do more tha= n just setting of DSCP/ToS/QoS based on the packet inspection.=0A= =0A= Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place.=0A= =0A= =0A= Ron> This capability would not be restricted to flows carrying "content" as= commonly defined (i.e., HTTP objects, FTP files, etc.). One example coul= d be a service function that is performing some sort of quota accounting --= after reaching some quota threshold, a different set of services is chosen= (perhaps a subset of what is selected at original policy classification).= =0A= =0A= [ims] I suppose, but that is a novel use of chaining, since quota manageme= nt is ordinarily done out-of-and and enforced in-band, i.e., you don't alte= r the chain you are in, you quench the existing flows in the old chain set = a new chain for new flows so that you don't break the transport layer.=0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:01 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity.=0A= =0A= Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 11:47 AM=0A= To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop.=0A= =0A= There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain).=0A= =0A= this is a steering rule:=0A= =0A= match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.)=0A= =0A= this is a chaining rule:=0A= =0A= match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic from the source prefix, send to the default gateway)=0A= =0A= or=0A= =0A= match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132]=0A= (for traffic with policy 1000, send to the default gateway)=0A= =0A= =0A= =0A= ________________________________________=0A= From: Sumandra Majee=0A= Sent: Wednesday, October 23, 2013 4:43 PM=0A= To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC.=0A= =0A= [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold.=0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to.=0A= =0A= -----Original Message-----=0A= From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= Sent: Tuesday, October 22, 2013 2:49 PM=0A= To: Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hi, Linda.=0A= =0A= Responses inline.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= Sent: Tuesday, October 22, 2013 4:31 PM=0A= To: Ron Parker; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ron,=0A= =0A= Thank you very much for the valuable comments. See my response inserted bel= ow:=0A= =0A= > -----Original Message-----=0A= >=0A= >=0A= > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= > -=0A= > - although it may be slightly off topic for your draft, it occurs to=0A= > me that the proxy nodes would be ideal locations to load balance=0A= > towards multiple instances of the same type of service node (i.e.,=0A= > combining proxy-node and load-balancing).=0A= =0A= [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places?=0A= Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both?= =0A= =0A= =0A= [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here.=0A= =0A= >=0A= > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= > the first indented bullet states that the service function can be=0A= > embedded in a service chain proxy. From a software implementation=0A= > perspective that makes perfect sense. But from a network topology=0A= > perspective, the proxy would not be explicitly observable -- the=0A= > service function would look like it had native SFC capabilities with=0A= > respect to other SFC service nodes and/or classifiers.=0A= =0A= [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario?=0A= =0A= =0A= [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy.=0A= =0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= =0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= Maybe we can chat face to face in Vancouver for the following points.=0A= =0A= [Ron] It would be my pleasure :). Please contact me privately.=0A= =0A= =0A= Linda=0A= > Section 4.2 (traffic steering). Consistent with my comment above, my=0A= > feeling is that one of the biggest advantages of SFC is to become=0A= > topology and transport unaware so that a new mechanism need not be=0A= > invented for every combination of network topology (i.e., 1 hop away,=0A= > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >=0A= > Section 5.1 (multiple instances). Consistent with comments above,=0A= > with correct separation of the logical and physical, steering tables=0A= > would not need to be updated each time an NFV event occurred (i.e.,=0A= > instace up, down, moved, expanded, contracted, etc.).=0A= >=0A= > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= > comments to above. If we choose a topology and transport independent=0A= > mechanism to follow a service chain, the complexity is reduced and the=0A= > reliability is improved. Something akin to the steering that you=0A= > mention is constrained to the classification node(s), greatly=0A= > simplifying the service nodes.=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Linda Dunbar=0A= > Sent: Monday, October 21, 2013 5:15 PM=0A= > To: nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: [nsc] New Version Notification for=0A= > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >=0A= > There have been many drafts submitted for SFC (Service Function=0A= > Chaining) BOF already. However, we felt that architecture and issues=0A= > associated with chaining existing Layer 4-7 service functions that are=0A= > not aware of Service Encapsulation header haven't been addressed by=0A= > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >=0A= > We put together a draft to analyze the issues associated with chaining=0A= > existing=0A= > Layer 4-7 service functions that are not aware of service=0A= > encapsulation layers. This draft also examines the network=0A= > architecture for chaining existing L4-L7 service functions. The=0A= > intent is to identify and describe gaps that have not been=0A= > addressed by other SFC drafts.=0A= >=0A= > Your comments are greatly appreciated.=0A= >=0A= >=0A= > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= > Revision: 00=0A= > Title: Architecture for Chaining Legacy Layer 4-7 Service= =0A= > Functions=0A= > Creation date: 2013-10-16=0A= > Group: Individual Submission=0A= > Number of pages: 16=0A= > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture-00.txt=0A= > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture=0A= > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= > l7-chain-architecture-00=0A= >=0A= >=0A= > Linda, Ning, Ian, Sumandra, and Donald=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From I.Smith@F5.com Thu Oct 24 09:46:00 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7209E11E81B7 for ; Thu, 24 Oct 2013 09:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.301 X-Spam-Level: X-Spam-Status: No, score=-10.301 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0D3hHHOFYjS for ; Thu, 24 Oct 2013 09:45:50 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4129111E837D for ; Thu, 24 Oct 2013 09:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382633146; x=1414169146; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=M17E3JH5PcjhVmLW3VqletTvxDwKBfV4nrVPv23FfEU=; b=agFu0TK5CWKyRrOBzZswH+2ryijE8B3OA6edNiIN8gaGz0ZfsjgyE0Ji GmIdlNMEO/M3K3R4amFuf6FyvjNh/tpWTgwxu4i26uTOJRQnfgfdzeaeH OVXNvxidlL4v/mM0VjSl6NVFVgbp52nraAfSl6x2jTcQ85+Au2gBEyRzq 0=; X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="84349717" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 16:45:41 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:45:40 -0700 From: Ian Smith To: "Paul Quinn (paulq)" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0NcaPg57sWUGA0WqKsu75rBrdZoEDjnP Date: Thu, 24 Oct 2013 16:45:40 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70C018@SEAEMBX02.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:46:27 -0000 X-List-Received-Date: Thu, 24 Oct 2013 16:46:27 -0000 > Re-classfiication essentially duplicate the "start of chain" logic which = is certainly understood and implementable=0A= =0A= no, reclassification _within a chain_ is branching, which is the same as co= ntent switching, which again, I understand to be an existing methodology th= at SFC is asserting is failing and needs to be superseded. When you branch= you lose all the advantages of chaining (namely that you can set up a sequ= ence of hosts that will only get traffic delivered to them that they will a= ct on, so they don't have to make decisions and pipe the traffic directly t= o them)=0A= =0A= =0A= ________________________________________=0A= From: Paul Quinn (paulq) [paulq@cisco.com]=0A= Sent: Thursday, October 24, 2013 12:35 PM=0A= To: Ian Smith=0A= Cc: nsc@ietf.org=0A= Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi Ian,=0A= =0A= =0A= On Oct 24, 2013, at 9:16 AM, Ian Smith wrote:=0A= =0A= > Yeah. I'm not in agreement - the classification function isn't necessari= ly co-located with the "start the chain" policy enforcement function.=0A= >=0A= =0A= Not all classification is related to SFC, however rhe SFC classification is= the start of the chain. You can have non-SFC classification (i.e. packets = are classified but orthogonal to the SFC chain) that reside anywhere.=0A= =0A= =0A= > Basically, there are millions of DPI platforms that don't need to be repl= aced for you to be able to use their marking for steering decisions, and th= ere are much, much more complex marking/classification mechanisms that can'= t be done in-line on the wire that will also need to be accommodated by a p= olicy enforcement point.=0A= >=0A= > Also, while having the ability to "reclassify" in the middle of the chain= is conceptually useful, you aren't chaining at that point anymore and you'= ve entered a realm of content switching, which is, if I understand correctl= y, one of the things that is being called too complex/expensive as a justif= ication for creating a service chains in the first place.=0A= >=0A= =0A= I disagree. Re-classfiication essentially duplicate the "start of chain" l= ogic which is certainly understood and implementable=0A= =0A= =0A= =0A= >=0A= > ________________________________________=0A= > From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= > Sent: Thursday, October 24, 2013 12:01 PM=0A= > To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So=0A= > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-= legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= > Hi, Ian.=0A= >=0A= > I agree conceptually that there is a difference between making a local po= licy based decision as to how to progress a packet vs. respecting a decisio= n that was made by an upstream entity.=0A= >=0A= > Extending those concepts into the SFC realm, the classifier makes a full = "source-routed" decision as to which logical "mid-boxes" shall be visited a= nd in which order. Any midbox that is also a classifier may optionally re= classify and optionally choose a different chain. Any midbox that is not = a classifier (or chooses not to reclassify) is obligated to follow the chai= n determined by the most recent upstream classifier.=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Ian Smith [mailto:I.Smith@F5.com]=0A= > Sent: Thursday, October 24, 2013 11:47 AM=0A= > To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So=0A= > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt=0A= >=0A= > In my mind, steering is more "smart" than chaining because a host making = a steering decision has to evaluate a lot of options to arrive at the next = hop, whereas a host in the middle of a chain is, I think, only supposed to = have one option for the next-hop.=0A= >=0A= > There are a lot more nuance and context to service chains, but in this pa= rticular case it seems to me that there is a pretty clear parallel between = a host that is a router and a host that has a single default gateway; steer= ing gets you into a chain, but once in the chain you can only get to the ne= xt link in that chain (because otherwise it isn't really a chain).=0A= >=0A= > this is a steering rule:=0A= >=0A= > match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:F= FFF/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp= =3D=3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D= =3D2001:DB8:0:FFFF::AAAA/132]=0A= > (for traffic port 80 using the phone.west1.example.net access point name,= and coming from the IP prefix and that is either classified as video or as= signed DSCP 32, insert an options header designating the policy for the nex= t four hops and forward to the next hop.)=0A= >=0A= > this is a chaining rule:=0A= >=0A= > match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D= 2001:DB8:0:FFFF::AAAA/132]=0A= > (for traffic from the source prefix, send to the default gateway)=0A= >=0A= > or=0A= >=0A= > match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D200= 1:DB8:0:FFFF::AAAA/132]=0A= > (for traffic with policy 1000, send to the default gateway)=0A= >=0A= >=0A= >=0A= > ________________________________________=0A= > From: Sumandra Majee=0A= > Sent: Wednesday, October 23, 2013 4:43 PM=0A= > To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith=0A= > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-= legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >> I do have a few comments and one overall theme regarding "steering", whi= ch I consider the legacy approach that we are trying to improve in SFC.=0A= >=0A= > [SM] Not sure I get the distinction between "chaining" and "steering". T= he L7 services are often inserted dynamically to the service chain based on= 1) later classification 2) based on network condition like "steering" to v= ideo optimizer when available bandwidth falls below certain threshold.=0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= > [Linda] In this context, the Proxy nodes are topology unaware. But proxy= nodes know their connection to the directly connected service functions. I= s it OK?=0A= > [Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= > [SM] Agreed that the forwarding point need to be aware of the topology bu= t proxy-node itself doesn't need to.=0A= >=0A= > -----Original Message-----=0A= > From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= > Sent: Tuesday, October 22, 2013 2:49 PM=0A= > To: Linda Dunbar; nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt=0A= >=0A= > Hi, Linda.=0A= >=0A= > Responses inline.=0A= >=0A= > Ron=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= > Sent: Tuesday, October 22, 2013 4:31 PM=0A= > To: Ron Parker; nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l= 4-l7-chain-architecture-00.txt=0A= >=0A= > Ron,=0A= >=0A= > Thank you very much for the valuable comments. See my response inserted b= elow:=0A= >=0A= >> -----Original Message-----=0A= >>=0A= >>=0A= >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= >> -=0A= >> - although it may be slightly off topic for your draft, it occurs to=0A= >> me that the proxy nodes would be ideal locations to load balance=0A= >> towards multiple instances of the same type of service node (i.e.,=0A= >> combining proxy-node and load-balancing).=0A= >=0A= > [Linda] are you saying that multiple instances are co-located? What if mu= ltiple instances for one network function are located in different places?= =0A= > Do you think the "proxy node" should balance them, or should the controll= er balance them and simply inform the "proxy node"? or combination of both= ?=0A= >=0A= >=0A= > [Ron] My thinking, so far, is that a load-balancer is, itself a network s= ervice function which understands that it manges some set of functionally e= quivalent subtended network service function instances. But, from a logi= cal perspective, I think that I have argued myself out of co-mingling the p= roxy concept and the load balancing concept. They can be mixed and matche= d as necessary, and co-located as desired. For example, a chain may indic= ate that a load-balancer must be visited. The load balancer balances to m= ultiple instances of proxy-fronted non-SFC-aware service functions. But,= all of this is off-topic, so I apologize for introducing it here.=0A= >=0A= >>=0A= >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= >> the first indented bullet states that the service function can be=0A= >> embedded in a service chain proxy. From a software implementation=0A= >> perspective that makes perfect sense. But from a network topology=0A= >> perspective, the proxy would not be explicitly observable -- the=0A= >> service function would look like it had native SFC capabilities with=0A= >> respect to other SFC service nodes and/or classifiers.=0A= >=0A= > [Linda] I will change the text to reflect this point. On the other hand, = many of today's service functions are independent. They don't care who is a= head of them and who is after. How would you describe this scenario?=0A= >=0A= >=0A= > [Ron] I think we are saying that to be SFC-aware is to know, explicitly, = which service function is next. A service function which doesn't understa= nd that concept is front-ended by an SFC-proxy.=0A= >=0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= > [Linda] In this context, the Proxy nodes are topology unaware. But proxy= nodes know their connection to the directly connected service functions. I= s it OK?=0A= >=0A= > [Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= > Maybe we can chat face to face in Vancouver for the following points.=0A= >=0A= > [Ron] It would be my pleasure :). Please contact me privately.=0A= >=0A= >=0A= > Linda=0A= >> Section 4.2 (traffic steering). Consistent with my comment above, my= =0A= >> feeling is that one of the biggest advantages of SFC is to become=0A= >> topology and transport unaware so that a new mechanism need not be=0A= >> invented for every combination of network topology (i.e., 1 hop away,=0A= >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >>=0A= >> Section 5.1 (multiple instances). Consistent with comments above,=0A= >> with correct separation of the logical and physical, steering tables=0A= >> would not need to be updated each time an NFV event occurred (i.e.,=0A= >> instace up, down, moved, expanded, contracted, etc.).=0A= >>=0A= >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= >> comments to above. If we choose a topology and transport independent= =0A= >> mechanism to follow a service chain, the complexity is reduced and the= =0A= >> reliability is improved. Something akin to the steering that you=0A= >> mention is constrained to the classification node(s), greatly=0A= >> simplifying the service nodes.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Linda Dunbar=0A= >> Sent: Monday, October 21, 2013 5:15 PM=0A= >> To: nsc@ietf.org=0A= >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >> Subject: [nsc] New Version Notification for=0A= >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >>=0A= >> There have been many drafts submitted for SFC (Service Function=0A= >> Chaining) BOF already. However, we felt that architecture and issues=0A= >> associated with chaining existing Layer 4-7 service functions that are= =0A= >> not aware of Service Encapsulation header haven't been addressed by=0A= >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >>=0A= >> We put together a draft to analyze the issues associated with chaining= =0A= >> existing=0A= >> Layer 4-7 service functions that are not aware of service=0A= >> encapsulation layers. This draft also examines the network=0A= >> architecture for chaining existing L4-L7 service functions. The=0A= >> intent is to identify and describe gaps that have not been=0A= >> addressed by other SFC drafts.=0A= >>=0A= >> Your comments are greatly appreciated.=0A= >>=0A= >>=0A= >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= >> Revision: 00=0A= >> Title: Architecture for Chaining Legacy Layer 4-7 Servic= e=0A= >> Functions=0A= >> Creation date: 2013-10-16=0A= >> Group: Individual Submission=0A= >> Number of pages: 16=0A= >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-= =0A= >> legacy-l4-l7-chain-architecture-00.txt=0A= >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= >> legacy-l4-l7-chain-architecture=0A= >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= >> l7-chain-architecture-00=0A= >>=0A= >>=0A= >> Linda, Ning, Ian, Sumandra, and Donald=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= From S.Majee@F5.com Thu Oct 24 09:48:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CE711E835E for ; Thu, 24 Oct 2013 09:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0iDa59Cc3Ve for ; Thu, 24 Oct 2013 09:48:04 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 52ACA11E8365 for ; Thu, 24 Oct 2013 09:47:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="85138153" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 24 Oct 2013 16:47:05 +0000 Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 09:47:04 -0700 From: Sumandra Majee To: Ian Smith , Ron Parker , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrLfNNaagQZEeSXSekqoV235oBo1qAgAAVmgCAAPm68IABxccAgAAESwCAAAQSAP//kJRj Date: Thu, 24 Oct 2013 16:47:04 +0000 Message-ID: <0BF7E0211CA62B42AE3FD4020E416098848D263C@SEAEMBX01.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, , <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 16:48:26 -0000 >>Also, while having the ability to "reclassify" in the middle of the chain= is conceptually useful, you aren't chaining at that point anymore and you'= ve entered a realm of content switching, which is, if I understand correctl= y, one of the things that is being called too complex/expensive as a justif= ication for creating a service chains in the first place.=0A= =0A= [sm] For transactional "steering" the classification often happens on the = response path (it may or may not have to remember request side classificati= on). This type of reclassification for steering is not conceptual but deplo= yed. =0A= =0A= If I visualize a service chain as ordered list of Network function as drive= n by a few packets at the start of a flow then it may not be able to solve = a variety of use cases in the application services area in particular.=0A= =0A= ________________________________________=0A= From: Ian Smith=0A= Sent: Thursday, October 24, 2013 9:16 AM=0A= To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function.=0A= =0A= Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point.=0A= =0A= Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place.=0A= =0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:01 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity.=0A= =0A= Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 11:47 AM=0A= To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop.=0A= =0A= There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain).=0A= =0A= this is a steering rule:=0A= =0A= match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.)=0A= =0A= this is a chaining rule:=0A= =0A= match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic from the source prefix, send to the default gateway)=0A= =0A= or=0A= =0A= match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132]=0A= (for traffic with policy 1000, send to the default gateway)=0A= =0A= =0A= =0A= ________________________________________=0A= From: Sumandra Majee=0A= Sent: Wednesday, October 23, 2013 4:43 PM=0A= To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC.=0A= =0A= [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold.=0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to.=0A= =0A= -----Original Message-----=0A= From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= Sent: Tuesday, October 22, 2013 2:49 PM=0A= To: Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hi, Linda.=0A= =0A= Responses inline.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= Sent: Tuesday, October 22, 2013 4:31 PM=0A= To: Ron Parker; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ron,=0A= =0A= Thank you very much for the valuable comments. See my response inserted bel= ow:=0A= =0A= > -----Original Message-----=0A= >=0A= >=0A= > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= > -=0A= > - although it may be slightly off topic for your draft, it occurs to=0A= > me that the proxy nodes would be ideal locations to load balance=0A= > towards multiple instances of the same type of service node (i.e.,=0A= > combining proxy-node and load-balancing).=0A= =0A= [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places?=0A= Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both?= =0A= =0A= =0A= [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here.=0A= =0A= >=0A= > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= > the first indented bullet states that the service function can be=0A= > embedded in a service chain proxy. From a software implementation=0A= > perspective that makes perfect sense. But from a network topology=0A= > perspective, the proxy would not be explicitly observable -- the=0A= > service function would look like it had native SFC capabilities with=0A= > respect to other SFC service nodes and/or classifiers.=0A= =0A= [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario?=0A= =0A= =0A= [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy.=0A= =0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= =0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= Maybe we can chat face to face in Vancouver for the following points.=0A= =0A= [Ron] It would be my pleasure :). Please contact me privately.=0A= =0A= =0A= Linda=0A= > Section 4.2 (traffic steering). Consistent with my comment above, my=0A= > feeling is that one of the biggest advantages of SFC is to become=0A= > topology and transport unaware so that a new mechanism need not be=0A= > invented for every combination of network topology (i.e., 1 hop away,=0A= > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >=0A= > Section 5.1 (multiple instances). Consistent with comments above,=0A= > with correct separation of the logical and physical, steering tables=0A= > would not need to be updated each time an NFV event occurred (i.e.,=0A= > instace up, down, moved, expanded, contracted, etc.).=0A= >=0A= > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= > comments to above. If we choose a topology and transport independent=0A= > mechanism to follow a service chain, the complexity is reduced and the=0A= > reliability is improved. Something akin to the steering that you=0A= > mention is constrained to the classification node(s), greatly=0A= > simplifying the service nodes.=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Linda Dunbar=0A= > Sent: Monday, October 21, 2013 5:15 PM=0A= > To: nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: [nsc] New Version Notification for=0A= > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >=0A= > There have been many drafts submitted for SFC (Service Function=0A= > Chaining) BOF already. However, we felt that architecture and issues=0A= > associated with chaining existing Layer 4-7 service functions that are=0A= > not aware of Service Encapsulation header haven't been addressed by=0A= > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >=0A= > We put together a draft to analyze the issues associated with chaining=0A= > existing=0A= > Layer 4-7 service functions that are not aware of service=0A= > encapsulation layers. This draft also examines the network=0A= > architecture for chaining existing L4-L7 service functions. The=0A= > intent is to identify and describe gaps that have not been=0A= > addressed by other SFC drafts.=0A= >=0A= > Your comments are greatly appreciated.=0A= >=0A= >=0A= > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= > Revision: 00=0A= > Title: Architecture for Chaining Legacy Layer 4-7 Service= =0A= > Functions=0A= > Creation date: 2013-10-16=0A= > Group: Individual Submission=0A= > Number of pages: 16=0A= > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture-00.txt=0A= > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture=0A= > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= > l7-chain-architecture-00=0A= >=0A= >=0A= > Linda, Ning, Ian, Sumandra, and Donald=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From Ron_Parker@affirmednetworks.com Thu Oct 24 10:16:09 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 965F321F9609 for ; Thu, 24 Oct 2013 10:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zo2xQM9W7O1D for ; Thu, 24 Oct 2013 10:16:04 -0700 (PDT) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) by ietfa.amsl.com (Postfix) with ESMTP id 398B121E8090 for ; Thu, 24 Oct 2013 10:14:43 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 10:14:26 -0700 From: Ron Parker To: Ian Smith , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOyqbFMh4sqlECy0uBm/XyzTjVBJn/rpoAgAAKa5CAAfJagP//ndDQgAH4DICAAT8+AP//jMiQgAB7lQD//4yx4AAPP/UAAA2EAlA= Date: Thu, 24 Oct 2013 17:14:26 +0000 Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BFE3@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70BFE3@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 17:16:09 -0000 [ims] no, but when you say "the classifier makes a full "source-routed" dec= ision" that does imply that classification function is going to do more tha= n just setting of DSCP/ToS/QoS based on the packet inspection. [Ron] The classifier adds the SFC service encapsulation which carries the c= hain ID and optionally metadata, the specifics of which will be defined by = the WG. -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com]=20 Sent: Thursday, October 24, 2013 12:40 PM To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt ________________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Thursday, October 24, 2013 12:31 PM To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt Hi, Ian. Please see inline below. Ron -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: Thursday, October 24, 2013 12:17 PM To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function. Ron> Sure, the "start the chain" enforcement function is free to engage the= services of a remote policy evaluation engine. Nothing in the architectu= re precludes that. Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point. Ron> Are you saying that DPI platforms should become "start the chain" enfo= rcement functions? Nothing in the architecture precludes that. Can you = elaborate on the "marking" concept, please? In an SFC environment, would = that become the addition of the SFC service header encapsulation? [ims] no, but when you say "the classifier makes a full "source-routed" dec= ision" that does imply that classification function is going to do more tha= n just setting of DSCP/ToS/QoS based on the packet inspection. Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place. Ron> This capability would not be restricted to flows carrying "content" as= commonly defined (i.e., HTTP objects, FTP files, etc.). One example coul= d be a service function that is performing some sort of quota accounting --= after reaching some quota threshold, a different set of services is chosen= (perhaps a subset of what is selected at original policy classification). [ims] I suppose, but that is a novel use of chaining, since quota manageme= nt is ordinarily done out-of-and and enforced in-band, i.e., you don't alte= r the chain you are in, you quench the existing flows in the old chain set = a new chain for new flows so that you don't break the transport layer. ________________________________________ From: Ron Parker [Ron_Parker@affirmednetworks.com] Sent: Thursday, October 24, 2013 12:01 PM To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt Hi, Ian. I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity. Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier. Ron -----Original Message----- From: Ian Smith [mailto:I.Smith@F5.com] Sent: Thursday, October 24, 2013 11:47 AM To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop. There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain). this is a steering rule: match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.) this is a chaining rule: match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132] (for traffic from the source prefix, send to the default gateway) or match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132] (for traffic with policy 1000, send to the default gateway) ________________________________________ From: Sumandra Majee Sent: Wednesday, October 23, 2013 4:43 PM To: Ron Parker; Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC. [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to. -----Original Message----- From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] Sent: Tuesday, October 22, 2013 2:49 PM To: Linda Dunbar; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Hi, Linda. Responses inline. Ron -----Original Message----- From: Linda Dunbar [mailto:linda.dunbar@huawei.com] Sent: Tuesday, October 22, 2013 4:31 PM To: Ron Parker; nsc@ietf.org Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt Ron, Thank you very much for the valuable comments. See my response inserted bel= ow: > -----Original Message----- > > > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) > - > - although it may be slightly off topic for your draft, it occurs to=20 > me that the proxy nodes would be ideal locations to load balance=20 > towards multiple instances of the same type of service node (i.e.,=20 > combining proxy-node and load-balancing). [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places? Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both? [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here. > > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=20 > the first indented bullet states that the service function can be > embedded in a service chain proxy. From a software implementation > perspective that makes perfect sense. But from a network topology > perspective, the proxy would not be explicitly observable -- the=20 > service function would look like it had native SFC capabilities with=20 > respect to other SFC service nodes and/or classifiers. [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario? [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy. > > Also in section 4.1, there is discussion of particular network > topologies. It has been proposed in other drafts that the SFC > approach be topology unaware. > [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK? [Ron] I think this goes to where the intelligence is for the forwarding. Maybe we can chat face to face in Vancouver for the following points. [Ron] It would be my pleasure :). Please contact me privately. Linda > Section 4.2 (traffic steering). Consistent with my comment above, my > feeling is that one of the biggest advantages of SFC is to become=20 > topology and transport unaware so that a new mechanism need not be=20 > invented for every combination of network topology (i.e., 1 hop away, > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=20 > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). > > Section 5.1 (multiple instances). Consistent with comments above, > with correct separation of the logical and physical, steering tables=20 > would not need to be updated each time an NFV event occurred (i.e.,=20 > instace up, down, moved, expanded, contracted, etc.). > > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar > comments to above. If we choose a topology and transport independent > mechanism to follow a service chain, the complexity is reduced and the > reliability is improved. Something akin to the steering that you > mention is constrained to the classification node(s), greatly=20 > simplifying the service nodes. > > > > > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=20 > Linda Dunbar > Sent: Monday, October 21, 2013 5:15 PM > To: nsc@ietf.org > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee > Subject: [nsc] New Version Notification for > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt > > There have been many drafts submitted for SFC (Service Function > Chaining) BOF already. However, we felt that architecture and issues=20 > associated with chaining existing Layer 4-7 service functions that are=20 > not aware of Service Encapsulation header haven't been addressed by=20 > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). > > We put together a draft to analyze the issues associated with chaining=20 > existing > Layer 4-7 service functions that are not aware of service > encapsulation layers. This draft also examines the network > architecture for chaining existing L4-L7 service functions. The > intent is to identify and describe gaps that have not been > addressed by other SFC drafts. > > Your comments are greatly appreciated. > > > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture > Revision: 00 > Title: Architecture for Chaining Legacy Layer 4-7 Service > Functions > Creation date: 2013-10-16 > Group: Individual Submission > Number of pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture-00.txt > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- > legacy-l4-l7-chain-architecture > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- > l7-chain-architecture-00 > > > Linda, Ning, Ian, Sumandra, and Donald > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Thu Oct 24 11:05:26 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9235411E8354 for ; Thu, 24 Oct 2013 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDZnBcdrkpoz for ; Thu, 24 Oct 2013 11:05:20 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 59F6C11E8347 for ; Thu, 24 Oct 2013 11:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382637918; x=1414173918; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GSA5B8NZhxe/qgxJEHrfjRt4U7/SuruQUXqKFtSkQes=; b=qX+oxOfwvIwoZpwv4T2ggN3nplUC63l6Q6Z/ImJUcgZ9QU7u9QUacOYd eWin6ttS/Sxi7dXqicyRRwW0nwIIingpp9qah4F35iFxTR3JHGKSt2co0 bddDaMfgWTOpkCIck9fWZ/0FnIb+LhCezkKjKs6n6sP8Jk3lW4NzC+/0a 4=; X-IronPort-AV: E=Sophos;i="4.93,563,1378857600"; d="scan'208";a="84359020" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 18:05:17 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 11:05:17 -0700 From: Ian Smith To: Ron Parker , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHOzqkrw1GG5M74Ck+l8hfL728XsJoBo1qAgAAVmgCAAYBCgIAAvrU/gACE1QD//41DA4AAeveA//+K/N+AAIELAP//i6q1 Date: Thu, 24 Oct 2013 18:05:16 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BDC2D1@dfweml509-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645BDC884@dfweml509-mbx.china.huawei.com> , <0BF7E0211CA62B42AE3FD4020E416098848D0F14@SEAEMBX01.olympus.F5Net.com> <419417C345CA5F48BF45F0A23955A0634A70BDFB@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BF33@SEAEMBX02.olympus.F5Net.com>, <419417C345CA5F48BF45F0A23955A0634A70BFE3@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:05:28 -0000 Which is why I say that you're lumping the decision of what something is (c= lassification), what policy that matches (start the chain), and where it's = next hop is (traffic steering) into a single functional block.=0A= =0A= They _MAY_ be the same host, but saying they _MUST_ be the same host seems = to be missing a lot about how this is already working today. =0A= =0A= If you want, as Paul is saying, a multi-tiered classification where the net= work might have packet classification but the SFC system has something more= , you are adding complexity and expense to the solution (since most custome= rs already have commodity DPIs and transport layer policy routing in place)= just to arrive at the opportunity to make a policy selection instead of be= ing able to make a policy selection with what is already there (DSCP). The= difference between each step of specificity from tcp:80, HTTP, HTTP video,= HTTP video from YouTube, to this particular HTTP video from YouTube is sig= nificant in terms of the amount of work you need to do and what you can do = once you've done it; in most cases, the most granular result isn't worth mu= ch more than a less granular one so it doesn't justify the extra effort (an= d corresponding UX impact). =0A= =0A= Furthermore, a policy selection outcome that decides "which logical "mid-bo= xes" shall be visited and in which order" is just source routing or label s= tacking, which we know how to do already and have standards for and can do = with a sightly smarter router (cheap and not terribly complex). If you are= insistent on having a new overlay networking protocol defined, then the ac= tual policy selection outcome is more like "decides which logical "middle-b= oxes" shall be visited and in which order _and then instantiates a service = chain of network hosts that matches and creates an SFC tunnel endpoint to f= orward the packets into". At which point you've just ramped up the sophist= ication (and the complexity and expense) of that box from a slightly smarte= r router to a slightly smarter application delivery controller plus a dynam= ic infrastructure that is a little bit out in front of where NFV is today b= ut not quite all the way to a fully realized SDN. =0A= =0A= Which means that, "carries the chain ID and optionally metadata" probably i= sn't necessary if you have the service orchestration framework that all of = this implies that you have in order to get all the moving parts in sync; yo= u have to have the infrastructure being orchestrated, so passing policy upd= ates or embedding new config state as part of deploying resources isn't don= e on the wire in the forwarding plane since you are doing it as part of con= figuration state updates.=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 1:14 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= [ims] no, but when you say "the classifier makes a full "source-routed" dec= ision" that does imply that classification function is going to do more tha= n just setting of DSCP/ToS/QoS based on the packet inspection.=0A= =0A= [Ron] The classifier adds the SFC service encapsulation which carries the c= hain ID and optionally metadata, the specifics of which will be defined by = the WG.=0A= =0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 12:40 PM=0A= To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:31 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= Please see inline below.=0A= =0A= Ron=0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 12:17 PM=0A= To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Yeah. I'm not in agreement - the classification function isn't necessarily= co-located with the "start the chain" policy enforcement function.=0A= =0A= =0A= Ron> Sure, the "start the chain" enforcement function is free to engage the= services of a remote policy evaluation engine. Nothing in the architectu= re precludes that.=0A= =0A= =0A= Basically, there are millions of DPI platforms that don't need to be replac= ed for you to be able to use their marking for steering decisions, and ther= e are much, much more complex marking/classification mechanisms that can't = be done in-line on the wire that will also need to be accommodated by a pol= icy enforcement point.=0A= =0A= =0A= Ron> Are you saying that DPI platforms should become "start the chain" enfo= rcement functions? Nothing in the architecture precludes that. Can you = elaborate on the "marking" concept, please? In an SFC environment, would = that become the addition of the SFC service header encapsulation?=0A= =0A= [ims] no, but when you say "the classifier makes a full "source-routed" dec= ision" that does imply that classification function is going to do more tha= n just setting of DSCP/ToS/QoS based on the packet inspection.=0A= =0A= Also, while having the ability to "reclassify" in the middle of the chain i= s conceptually useful, you aren't chaining at that point anymore and you've= entered a realm of content switching, which is, if I understand correctly,= one of the things that is being called too complex/expensive as a justific= ation for creating a service chains in the first place.=0A= =0A= =0A= Ron> This capability would not be restricted to flows carrying "content" as= commonly defined (i.e., HTTP objects, FTP files, etc.). One example coul= d be a service function that is performing some sort of quota accounting --= after reaching some quota threshold, a different set of services is chosen= (perhaps a subset of what is selected at original policy classification).= =0A= =0A= [ims] I suppose, but that is a novel use of chaining, since quota manageme= nt is ordinarily done out-of-and and enforced in-band, i.e., you don't alte= r the chain you are in, you quench the existing flows in the old chain set = a new chain for new flows so that you don't break the transport layer.=0A= =0A= ________________________________________=0A= From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= Sent: Thursday, October 24, 2013 12:01 PM=0A= To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= Hi, Ian.=0A= =0A= I agree conceptually that there is a difference between making a local poli= cy based decision as to how to progress a packet vs. respecting a decision = that was made by an upstream entity.=0A= =0A= Extending those concepts into the SFC realm, the classifier makes a full "s= ource-routed" decision as to which logical "mid-boxes" shall be visited and= in which order. Any midbox that is also a classifier may optionally recl= assify and optionally choose a different chain. Any midbox that is not a = classifier (or chooses not to reclassify) is obligated to follow the chain = determined by the most recent upstream classifier.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Ian Smith [mailto:I.Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 11:47 AM=0A= To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= In my mind, steering is more "smart" than chaining because a host making a = steering decision has to evaluate a lot of options to arrive at the next ho= p, whereas a host in the middle of a chain is, I think, only supposed to ha= ve one option for the next-hop.=0A= =0A= There are a lot more nuance and context to service chains, but in this part= icular case it seems to me that there is a pretty clear parallel between a = host that is a router and a host that has a single default gateway; steerin= g gets you into a chain, but once in the chain you can only get to the next= link in that chain (because otherwise it isn't really a chain).=0A= =0A= this is a steering rule:=0A= =0A= match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FFF= F/64 and tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D= =3D32) ] action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic port 80 using the phone.west1.example.net access point name, a= nd coming from the IP prefix and that is either classified as video or assi= gned DSCP 32, insert an options header designating the policy for the next = four hops and forward to the next hop.)=0A= =0A= this is a chaining rule:=0A= =0A= match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] action=3D=3D[ip.nexthop=3D=3D20= 01:DB8:0:FFFF::AAAA/132]=0A= (for traffic from the source prefix, send to the default gateway)=0A= =0A= or=0A= =0A= match=3D=3D[ip.option.253.[1]=3D=3D1000] action=3D=3D[ip.nexthop=3D=3D2001:= DB8:0:FFFF::AAAA/132]=0A= (for traffic with policy 1000, send to the default gateway)=0A= =0A= =0A= =0A= ________________________________________=0A= From: Sumandra Majee=0A= Sent: Wednesday, October 23, 2013 4:43 PM=0A= To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-le= gacy-l4-l7-chain-architecture-00.txt=0A= =0A= >I do have a few comments and one overall theme regarding "steering", which= I consider the legacy approach that we are trying to improve in SFC.=0A= =0A= [SM] Not sure I get the distinction between "chaining" and "steering". The= L7 services are often inserted dynamically to the service chain based on 1= ) later classification 2) based on network condition like "steering" to vid= eo optimizer when available bandwidth falls below certain threshold.=0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= [SM] Agreed that the forwarding point need to be aware of the topology but = proxy-node itself doesn't need to.=0A= =0A= -----Original Message-----=0A= From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= Sent: Tuesday, October 22, 2013 2:49 PM=0A= To: Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hi, Linda.=0A= =0A= Responses inline.=0A= =0A= Ron=0A= =0A= =0A= -----Original Message-----=0A= From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= Sent: Tuesday, October 22, 2013 4:31 PM=0A= To: Ron Parker; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= Subject: RE: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ron,=0A= =0A= Thank you very much for the valuable comments. See my response inserted bel= ow:=0A= =0A= > -----Original Message-----=0A= >=0A= >=0A= > In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= > -=0A= > - although it may be slightly off topic for your draft, it occurs to=0A= > me that the proxy nodes would be ideal locations to load balance=0A= > towards multiple instances of the same type of service node (i.e.,=0A= > combining proxy-node and load-balancing).=0A= =0A= [Linda] are you saying that multiple instances are co-located? What if mult= iple instances for one network function are located in different places?=0A= Do you think the "proxy node" should balance them, or should the controller= balance them and simply inform the "proxy node"? or combination of both?= =0A= =0A= =0A= [Ron] My thinking, so far, is that a load-balancer is, itself a network ser= vice function which understands that it manges some set of functionally equ= ivalent subtended network service function instances. But, from a logica= l perspective, I think that I have argued myself out of co-mingling the pro= xy concept and the load balancing concept. They can be mixed and matched = as necessary, and co-located as desired. For example, a chain may indicat= e that a load-balancer must be visited. The load balancer balances to mul= tiple instances of proxy-fronted non-SFC-aware service functions. But, a= ll of this is off-topic, so I apologize for introducing it here.=0A= =0A= >=0A= > In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= > the first indented bullet states that the service function can be=0A= > embedded in a service chain proxy. From a software implementation=0A= > perspective that makes perfect sense. But from a network topology=0A= > perspective, the proxy would not be explicitly observable -- the=0A= > service function would look like it had native SFC capabilities with=0A= > respect to other SFC service nodes and/or classifiers.=0A= =0A= [Linda] I will change the text to reflect this point. On the other hand, ma= ny of today's service functions are independent. They don't care who is ahe= ad of them and who is after. How would you describe this scenario?=0A= =0A= =0A= [Ron] I think we are saying that to be SFC-aware is to know, explicitly, wh= ich service function is next. A service function which doesn't understand= that concept is front-ended by an SFC-proxy.=0A= =0A= =0A= >=0A= > Also in section 4.1, there is discussion of particular network=0A= > topologies. It has been proposed in other drafts that the SFC=0A= > approach be topology unaware.=0A= >=0A= [Linda] In this context, the Proxy nodes are topology unaware. But proxy n= odes know their connection to the directly connected service functions. Is = it OK?=0A= =0A= [Ron] I think this goes to where the intelligence is for the forwarding.=0A= =0A= Maybe we can chat face to face in Vancouver for the following points.=0A= =0A= [Ron] It would be my pleasure :). Please contact me privately.=0A= =0A= =0A= Linda=0A= > Section 4.2 (traffic steering). Consistent with my comment above, my=0A= > feeling is that one of the biggest advantages of SFC is to become=0A= > topology and transport unaware so that a new mechanism need not be=0A= > invented for every combination of network topology (i.e., 1 hop away,=0A= > 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= > forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >=0A= > Section 5.1 (multiple instances). Consistent with comments above,=0A= > with correct separation of the logical and physical, steering tables=0A= > would not need to be updated each time an NFV event occurred (i.e.,=0A= > instace up, down, moved, expanded, contracted, etc.).=0A= >=0A= > Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= > comments to above. If we choose a topology and transport independent=0A= > mechanism to follow a service chain, the complexity is reduced and the=0A= > reliability is improved. Something akin to the steering that you=0A= > mention is constrained to the classification node(s), greatly=0A= > simplifying the service nodes.=0A= >=0A= >=0A= >=0A= >=0A= > -----Original Message-----=0A= > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= > Linda Dunbar=0A= > Sent: Monday, October 21, 2013 5:15 PM=0A= > To: nsc@ietf.org=0A= > Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= > Subject: [nsc] New Version Notification for=0A= > draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >=0A= > There have been many drafts submitted for SFC (Service Function=0A= > Chaining) BOF already. However, we felt that architecture and issues=0A= > associated with chaining existing Layer 4-7 service functions that are=0A= > not aware of Service Encapsulation header haven't been addressed by=0A= > any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >=0A= > We put together a draft to analyze the issues associated with chaining=0A= > existing=0A= > Layer 4-7 service functions that are not aware of service=0A= > encapsulation layers. This draft also examines the network=0A= > architecture for chaining existing L4-L7 service functions. The=0A= > intent is to identify and describe gaps that have not been=0A= > addressed by other SFC drafts.=0A= >=0A= > Your comments are greatly appreciated.=0A= >=0A= >=0A= > Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= > Revision: 00=0A= > Title: Architecture for Chaining Legacy Layer 4-7 Service= =0A= > Functions=0A= > Creation date: 2013-10-16=0A= > Group: Individual Submission=0A= > Number of pages: 16=0A= > URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture-00.txt=0A= > Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= > legacy-l4-l7-chain-architecture=0A= > Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= > l7-chain-architecture-00=0A= >=0A= >=0A= > Linda, Ning, Ian, Sumandra, and Donald=0A= >=0A= > _______________________________________________=0A= > nsc mailing list=0A= > nsc@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/nsc=0A= From jguichar@cisco.com Thu Oct 24 12:21:40 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8425A11E83B4 for ; Thu, 24 Oct 2013 12:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iriS3lTxFeHV for ; Thu, 24 Oct 2013 12:21:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8018B11E839A for ; Thu, 24 Oct 2013 12:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19269; q=dns/txt; s=iport; t=1382642491; x=1383852091; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6L15UsEdlJU5npfLC8pX95fPWmo0U0PiL/yDTcjy2O0=; b=hCmuxluRlvPvy40AHO3RdzlMvjIcabcGzcswoNEZwGyoCzMS5Vz74sAy TYazXfscA7/1kz6IEF86OFFBqd/sFzMDSmF3P3+7TJcAe8fznzC8LLf0o 0eGQmNgnT5H2Yvlcr2/yIAXTKXdQKVyipHM1Sv97JGFmbqqO+w8Df4fAD 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAD5yaVKtJXG8/2dsb2JhbABPCoMHOFS+XoEdFnSCJQEBAQMBAQEBCywrAgQDCQIFBwIEAQgOAwEDAQELFAkiDAsUAwYIAgQBDQUIARKHZgYNuh8EjgYMgQQCBgUmBwaDGYENA5QqhQ+QWIFmgT6BaUE X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="276099527" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 24 Oct 2013 19:21:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9OJLULj014231 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Oct 2013 19:21:30 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 24 Oct 2013 14:21:29 -0500 From: "Jim Guichard (jguichar)" To: Ian Smith , Ron Parker , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0O49go7VjM529k+4x+Y0pd9Cfg== Date: Thu, 24 Oct 2013 19:21:28 +0000 Message-ID: <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:21:40 -0000 Ian, On 10/24/13 2:05 PM, "Ian Smith" wrote: >Which is why I say that you're lumping the decision of what something is >(classification), what policy that matches (start the chain), and where >it's next hop is (traffic steering) into a single functional block. Jim> with the counter argument that the detailed splitting of functions and the naming each interface that connects the functions of the architecture (like IMS or other mobility architectures are so fond of doing) not only adds arbitrary complexity to the architecture (making it difficult for non experts to grasp), but in addition leads to over specification and limits implementation freedom, and this rigidity tends to lead to fragility in the overall system. > >They _MAY_ be the same host, but saying they _MUST_ be the same host >seems to be missing a lot about how this is already working today. > >If you want, as Paul is saying, a multi-tiered classification where the >network might have packet classification but the SFC system has something >more, you are adding complexity and expense to the solution (since most >customers already have commodity DPIs and transport layer policy routing >in place) just to arrive at the opportunity to make a policy selection >instead of being able to make a policy selection with what is already >there (DSCP). Jim> classification based on policy for packet forwarding with associated marking/re-marking/policing/forwarding is different from classification to enable policy selection at the services layer. Policy in this case may not simply mean how to forward packets but rather how a service function should process said packets upon receipt. > The difference between each step of specificity from tcp:80, HTTP, HTTP >video, HTTP video from YouTube, to this particular HTTP video from >YouTube is significant in terms of the amount of work you need to do and >what you can do once you've done it; in most cases, the most granular >result isn't worth much more than a less granular one so it doesn't >justify the extra effort (and corresponding UX impact). >=20 > >Furthermore, a policy selection outcome that decides "which logical >"mid-boxes" shall be visited and in which order" is just source routing >or label stacking, which we know how to do already and have standards for >and can do with a sightly smarter router (cheap and not terribly >complex). If you are insistent on having a new overlay networking >protocol defined, then the actual policy selection outcome is more like >"decides which logical "middle-boxes" shall be visited and in which order >_and then instantiates a service chain of network hosts that matches and >creates an SFC tunnel endpoint to forward the packets into". At which >point you've just ramped up the sophistication (and the complexity and >expense) of that box from a slightly smarter router to a slightly smarter >application delivery controller plus a dynamic infrastructure that is a >little bit out in front of where NFV is today but not quite all the way >to a fully realized SDN. Jim> it is neither source routing or label stacking. Policy selection at a classifier determines which service chain packets should be directed through but it does *not* decide which logical mid-boxes shall be visited but only infers this by the encapsulation and simply forwards to the next-hop (which could be one of multiple available) that is able to apply the first service function of the chain. >=20 > >Which means that, "carries the chain ID and optionally metadata" probably >isn't necessary if you have the service orchestration framework that all >of this implies that you have in order to get all the moving parts in >sync; you have to have the infrastructure being orchestrated, so passing >policy updates or embedding new config state as part of deploying >resources isn't done on the wire in the forwarding plane since you are >doing it as part of configuration state updates. > > > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 1:14 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >[ims] no, but when you say "the classifier makes a full "source-routed" >decision" that does imply that classification function is going to do >more than just setting of DSCP/ToS/QoS based on the packet inspection. > >[Ron] The classifier adds the SFC service encapsulation which carries the >chain ID and optionally metadata, the specifics of which will be defined >by the WG. > > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 12:40 PM >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 12:31 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Ian. > >Please see inline below. > > Ron > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 12:17 PM >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Yeah. I'm not in agreement - the classification function isn't >necessarily co-located with the "start the chain" policy enforcement >function. > > >Ron> Sure, the "start the chain" enforcement function is free to engage >the services of a remote policy evaluation engine. Nothing in the >architecture precludes that. > > >Basically, there are millions of DPI platforms that don't need to be >replaced for you to be able to use their marking for steering decisions, >and there are much, much more complex marking/classification mechanisms >that can't be done in-line on the wire that will also need to be >accommodated by a policy enforcement point. > > >Ron> Are you saying that DPI platforms should become "start the chain" >enforcement functions? Nothing in the architecture precludes that. >Can you elaborate on the "marking" concept, please? In an SFC >environment, would that become the addition of the SFC service header >encapsulation? > >[ims] no, but when you say "the classifier makes a full "source-routed" >decision" that does imply that classification function is going to do >more than just setting of DSCP/ToS/QoS based on the packet inspection. > >Also, while having the ability to "reclassify" in the middle of the chain >is conceptually useful, you aren't chaining at that point anymore and >you've entered a realm of content switching, which is, if I understand >correctly, one of the things that is being called too complex/expensive >as a justification for creating a service chains in the first place. > > >Ron> This capability would not be restricted to flows carrying "content" >as commonly defined (i.e., HTTP objects, FTP files, etc.). One example >could be a service function that is performing some sort of quota >accounting -- after reaching some quota threshold, a different set of >services is chosen (perhaps a subset of what is selected at original >policy classification). > >[ims] I suppose, but that is a novel use of chaining, since quota >management is ordinarily done out-of-and and enforced in-band, i.e., you >don't alter the chain you are in, you quench the existing flows in the >old chain set a new chain for new flows so that you don't break the >transport layer. > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 12:01 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Ian. > >I agree conceptually that there is a difference between making a local >policy based decision as to how to progress a packet vs. respecting a >decision that was made by an upstream entity. > >Extending those concepts into the SFC realm, the classifier makes a full >"source-routed" decision as to which logical "mid-boxes" shall be visited >and in which order. Any midbox that is also a classifier may optionally >reclassify and optionally choose a different chain. Any midbox that is >not a classifier (or chooses not to reclassify) is obligated to follow >the chain determined by the most recent upstream classifier. > > Ron > > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 11:47 AM >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >In my mind, steering is more "smart" than chaining because a host making >a steering decision has to evaluate a lot of options to arrive at the >next hop, whereas a host in the middle of a chain is, I think, only >supposed to have one option for the next-hop. > >There are a lot more nuance and context to service chains, but in this >particular case it seems to me that there is a pretty clear parallel >between a host that is a router and a host that has a single default >gateway; steering gets you into a chain, but once in the chain you can >only get to the next link in that chain (because otherwise it isn't >really a chain). > >this is a steering rule: > >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ] >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic port 80 using the phone.west1.example.net access point name, >and coming from the IP prefix and that is either classified as video or >assigned DSCP 32, insert an options header designating the policy for the >next four hops and forward to the next hop.) > >this is a chaining rule: > >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic from the source prefix, send to the default gateway) > >or > >match=3D=3D[ip.option.253.[1]=3D=3D1000] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic with policy 1000, send to the default gateway) > > > >________________________________________ >From: Sumandra Majee >Sent: Wednesday, October 23, 2013 4:43 PM >To: Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >>I do have a few comments and one overall theme regarding "steering", >>which I consider the legacy approach that we are trying to improve in >>SFC. > >[SM] Not sure I get the distinction between "chaining" and "steering". >The L7 services are often inserted dynamically to the service chain based >on 1) later classification 2) based on network condition like "steering" >to video optimizer when available bandwidth falls below certain threshold. > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? >[Ron] I think this goes to where the intelligence is for the forwarding. > >[SM] Agreed that the forwarding point need to be aware of the topology >but proxy-node itself doesn't need to. > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Tuesday, October 22, 2013 2:49 PM >To: Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Linda. > >Responses inline. > > Ron > > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Tuesday, October 22, 2013 4:31 PM >To: Ron Parker; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Ron, > >Thank you very much for the valuable comments. See my response inserted >below: > >> -----Original Message----- >> >> >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). > >[Linda] are you saying that multiple instances are co-located? What if >multiple instances for one network function are located in different >places? >Do you think the "proxy node" should balance them, or should the >controller balance them and simply inform the "proxy node"? or >combination of both? > > >[Ron] My thinking, so far, is that a load-balancer is, itself a network >service function which understands that it manges some set of >functionally equivalent subtended network service function instances. >But, from a logical perspective, I think that I have argued myself out of >co-mingling the proxy concept and the load balancing concept. They can >be mixed and matched as necessary, and co-located as desired. For >example, a chain may indicate that a load-balancer must be visited. The >load balancer balances to multiple instances of proxy-fronted >non-SFC-aware service functions. But, all of this is off-topic, so I >apologize for introducing it here. > >> >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), >> the first indented bullet states that the service function can be >> embedded in a service chain proxy. From a software implementation >> perspective that makes perfect sense. But from a network topology >> perspective, the proxy would not be explicitly observable -- the >> service function would look like it had native SFC capabilities with >> respect to other SFC service nodes and/or classifiers. > >[Linda] I will change the text to reflect this point. On the other hand, >many of today's service functions are independent. They don't care who is >ahead of them and who is after. How would you describe this scenario? > > >[Ron] I think we are saying that to be SFC-aware is to know, explicitly, >which service function is next. A service function which doesn't >understand that concept is front-ended by an SFC-proxy. > > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? > >[Ron] I think this goes to where the intelligence is for the forwarding. > >Maybe we can chat face to face in Vancouver for the following points. > >[Ron] It would be my pleasure :). Please contact me privately. > > >Linda >> Section 4.2 (traffic steering). Consistent with my comment above, my >> feeling is that one of the biggest advantages of SFC is to become >> topology and transport unaware so that a new mechanism need not be >> invented for every combination of network topology (i.e., 1 hop away, >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). >> >> Section 5.1 (multiple instances). Consistent with comments above, >> with correct separation of the logical and physical, steering tables >> would not need to be updated each time an NFV event occurred (i.e., >> instace up, down, moved, expanded, contracted, etc.). >> >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar >> comments to above. If we choose a topology and transport independent >> mechanism to follow a service chain, the complexity is reduced and the >> reliability is improved. Something akin to the steering that you >> mention is constrained to the classification node(s), greatly >> simplifying the service nodes. >> >> >> >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Monday, October 21, 2013 5:15 PM >> To: nsc@ietf.org >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >> Subject: [nsc] New Version Notification for >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt >> >> There have been many drafts submitted for SFC (Service Function >> Chaining) BOF already. However, we felt that architecture and issues >> associated with chaining existing Layer 4-7 service functions that are >> not aware of Service Encapsulation header haven't been addressed by >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). >> >> We put together a draft to analyze the issues associated with chaining >> existing >> Layer 4-7 service functions that are not aware of service >> encapsulation layers. This draft also examines the network >> architecture for chaining existing L4-L7 service functions. The >> intent is to identify and describe gaps that have not been >> addressed by other SFC drafts. >> >> Your comments are greatly appreciated. >> >> >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture >> Revision: 00 >> Title: Architecture for Chaining Legacy Layer 4-7 >>Service >> Functions >> Creation date: 2013-10-16 >> Group: Individual Submission >> Number of pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture-00.txt >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- >> l7-chain-architecture-00 >> >> >> Linda, Ning, Ian, Sumandra, and Donald >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Thu Oct 24 12:52:04 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA07411E822B for ; Thu, 24 Oct 2013 12:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.442 X-Spam-Level: X-Spam-Status: No, score=-4.442 tagged_above=-999 required=5 tests=[AWL=-2.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jh5XSKdGKrvx for ; Thu, 24 Oct 2013 12:52:00 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 1194E11E8218 for ; Thu, 24 Oct 2013 12:51:58 -0700 (PDT) Received: from mail152-db9-R.bigfish.com (10.174.16.252) by DB9EHSOBE002.bigfish.com (10.174.14.65) with Microsoft SMTP Server id 14.1.225.22; Thu, 24 Oct 2013 19:51:57 +0000 Received: from mail152-db9 (localhost [127.0.0.1]) by mail152-db9-R.bigfish.com (Postfix) with ESMTP id DFEC4E0226; Thu, 24 Oct 2013 19:51:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -20 X-BigFish: VPS-20(zzbb2dI98dI9371I936eI542I1432I1418I11f6N89ccuzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail152-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(189002)(199002)(51444003)(45984002)(51704005)(377424004)(13464003)(24454002)(31966008)(63696002)(74662001)(65816001)(74366001)(15202345003)(80022001)(76796001)(74876001)(56776001)(74502001)(47446002)(85306002)(77982001)(59766001)(46102001)(81542001)(53806001)(54356001)(83072001)(56816003)(36756003)(51856001)(77096001)(81342001)(79102001)(81686001)(4396001)(47736001)(49866001)(50986001)(47976001)(81816001)(76176001)(74706001)(76786001)(69226001)(15975445006)(19580405001)(83322001)(76482001)(83506001)(54316002)(19580395003)(80976001)(352764002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB082; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail152-db9 (localhost.localdomain [127.0.0.1]) by mail152-db9 (MessageSwitch) id 1382644314308697_23792; Thu, 24 Oct 2013 19:51:54 +0000 (UTC) Received: from DB9EHSMHS026.bigfish.com (unknown [10.174.16.250]) by mail152-db9.bigfish.com (Postfix) with ESMTP id 44C932A00B8; Thu, 24 Oct 2013 19:51:54 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS026.bigfish.com (10.174.14.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 24 Oct 2013 19:51:48 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.371.2; Thu, 24 Oct 2013 19:51:39 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) with Microsoft SMTP Server (TLS) id 15.0.785.10; Thu, 24 Oct 2013 19:51:38 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.214]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.182]) with mapi id 15.00.0785.001; Thu, 24 Oct 2013 19:51:38 +0000 From: Ken Gray To: Ian Smith , Ron Parker , Sumandra Majee , Linda Dunbar , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0PJzkvFYQRNYeUqt7dnqMPKdHw== Date: Thu, 24 Oct 2013 19:51:38 +0000 Message-ID: In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 000947967F Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 19:52:05 -0000 Hey, Ian. A few inlines ... While I agree that we shouldn't ignore the way things work today, and what works well, I don't think we should assume they are optimal or that a solution for an environment like mobile (which is dictated architecturally based on a long, long history) is necessarily optimal for an emerging domain like a DC. =20 =20 On 10/24/13 2:05 PM, "Ian Smith" wrote: >Which is why I say that you're lumping the decision of what something is >(classification), what policy that matches (start the chain), and where >it's next hop is (traffic steering) into a single functional block. > >They _MAY_ be the same host, but saying they _MUST_ be the same host >seems to be missing a lot about how this is already working today. > >If you want, as Paul is saying, a multi-tiered classification where the >network might have packet classification but the SFC system has something >more, you are adding complexity and expense to the solution (since most >customers already have commodity DPIs and transport layer policy routing >in place) just to arrive at the opportunity to make a policy selection >instead of being able to make a policy selection with what is already >there (DSCP). The difference between each step of specificity from >tcp:80, HTTP, HTTP video, HTTP video from YouTube, to this particular >HTTP video from YouTube is significant in terms of the amount of work you >need to do and what you can do once you've done it; in most cases, the >most granular result isn't worth much more than a less granular one so it >doesn't justify the extra effort (and corresponding UX impact). I agree that we should take into consideration what's already out there, but we also shouldn't assume that what works in one domain (maybe because of architectural dictate) like mobile is an optimal solution for another like DC. Nor should we assume that what works today is actually desirable or least cost. For example, I think a large number of providers would say being able to tell HTTP video from HTTP IS a step worth taking for their environment. And I find the use of the term "commodity DPI" kind of funny ... because while DPI costs may be dropping as virtualized versions are introduced (or smaller scope, integral agents are licensed) I wouldn't assume it's an expense that even current users wouldn't want to minimize further. =20 >=20 > >Furthermore, a policy selection outcome that decides "which logical >"mid-boxes" shall be visited and in which order" is just source routing >or label stacking, which we know how to do already and have standards for >and can do with a sightly smarter router (cheap and not terribly >complex). If you are insistent on having a new overlay networking >protocol defined, then the actual policy selection outcome is more like >"decides which logical "middle-boxes" shall be visited and in which order >_and then instantiates a service chain of network hosts that matches and >creates an SFC tunnel endpoint to forward the packets into". At which >point you've just ramped up the sophistication (and the complexity and >expense) of that box from a slightly smarter router to a slightly smarter >application delivery controller plus a dynamic infrastructure that is a >little bit out in front of where NFV is today but not quite all the way >to a fully realized SDN. I fully expect that there's a few vendors that think they're already there - the problem is that without standards they don't interoperate. I also think that reactive chain building vs proactive chain building will depend on your environment. >=20 > >Which means that, "carries the chain ID and optionally metadata" probably >isn't necessary if you have the service orchestration framework that all >of this implies that you have in order to get all the moving parts in >sync; you have to have the infrastructure being orchestrated, so passing >policy updates or embedding new config state as part of deploying >resources isn't done on the wire in the forwarding plane since you are >doing it as part of configuration state updates. This seems like an independent assertion rather than something conclusive from the former argument. I think we're still debating the metadata issue and thus it is on the agenda. I don't think that I could agree you don't need metadata at all. Whether you're an advocate of inline or out of band metadata, a lookup flag/tag inline would certainly be helpful. =20 > > > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 1:14 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >[ims] no, but when you say "the classifier makes a full "source-routed" >decision" that does imply that classification function is going to do >more than just setting of DSCP/ToS/QoS based on the packet inspection. > >[Ron] The classifier adds the SFC service encapsulation which carries the >chain ID and optionally metadata, the specifics of which will be defined >by the WG. > > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 12:40 PM >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 12:31 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Ian. > >Please see inline below. > > Ron > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 12:17 PM >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Yeah. I'm not in agreement - the classification function isn't >necessarily co-located with the "start the chain" policy enforcement >function. > > >Ron> Sure, the "start the chain" enforcement function is free to engage >the services of a remote policy evaluation engine. Nothing in the >architecture precludes that. > > >Basically, there are millions of DPI platforms that don't need to be >replaced for you to be able to use their marking for steering decisions, >and there are much, much more complex marking/classification mechanisms >that can't be done in-line on the wire that will also need to be >accommodated by a policy enforcement point. > > >Ron> Are you saying that DPI platforms should become "start the chain" >enforcement functions? Nothing in the architecture precludes that. >Can you elaborate on the "marking" concept, please? In an SFC >environment, would that become the addition of the SFC service header >encapsulation? > >[ims] no, but when you say "the classifier makes a full "source-routed" >decision" that does imply that classification function is going to do >more than just setting of DSCP/ToS/QoS based on the packet inspection. > >Also, while having the ability to "reclassify" in the middle of the chain >is conceptually useful, you aren't chaining at that point anymore and >you've entered a realm of content switching, which is, if I understand >correctly, one of the things that is being called too complex/expensive >as a justification for creating a service chains in the first place. > > >Ron> This capability would not be restricted to flows carrying "content" >as commonly defined (i.e., HTTP objects, FTP files, etc.). One example >could be a service function that is performing some sort of quota >accounting -- after reaching some quota threshold, a different set of >services is chosen (perhaps a subset of what is selected at original >policy classification). > >[ims] I suppose, but that is a novel use of chaining, since quota >management is ordinarily done out-of-and and enforced in-band, i.e., you >don't alter the chain you are in, you quench the existing flows in the >old chain set a new chain for new flows so that you don't break the >transport layer. > >________________________________________ >From: Ron Parker [Ron_Parker@affirmednetworks.com] >Sent: Thursday, October 24, 2013 12:01 PM >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Ian. > >I agree conceptually that there is a difference between making a local >policy based decision as to how to progress a packet vs. respecting a >decision that was made by an upstream entity. > >Extending those concepts into the SFC realm, the classifier makes a full >"source-routed" decision as to which logical "mid-boxes" shall be visited >and in which order. Any midbox that is also a classifier may optionally >reclassify and optionally choose a different chain. Any midbox that is >not a classifier (or chooses not to reclassify) is obligated to follow >the chain determined by the most recent upstream classifier. > > Ron > > >-----Original Message----- >From: Ian Smith [mailto:I.Smith@F5.com] >Sent: Thursday, October 24, 2013 11:47 AM >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >In my mind, steering is more "smart" than chaining because a host making >a steering decision has to evaluate a lot of options to arrive at the >next hop, whereas a host in the middle of a chain is, I think, only >supposed to have one option for the next-hop. > >There are a lot more nuance and context to service chains, but in this >particular case it seems to me that there is a pretty clear parallel >between a host that is a router and a host that has a single default >gateway; steering gets you into a chain, but once in the chain you can >only get to the next link in that chain (because otherwise it isn't >really a chain). > >this is a steering rule: > >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ] >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic port 80 using the phone.west1.example.net access point name, >and coming from the IP prefix and that is either classified as video or >assigned DSCP 32, insert an options header designating the policy for the >next four hops and forward to the next hop.) > >this is a chaining rule: > >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic from the source prefix, send to the default gateway) > >or > >match=3D=3D[ip.option.253.[1]=3D=3D1000] >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132] >(for traffic with policy 1000, send to the default gateway) > > > >________________________________________ >From: Sumandra Majee >Sent: Wednesday, October 23, 2013 4:43 PM >To: Ron Parker; Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >>I do have a few comments and one overall theme regarding "steering", >>which I consider the legacy approach that we are trying to improve in >>SFC. > >[SM] Not sure I get the distinction between "chaining" and "steering". >The L7 services are often inserted dynamically to the service chain based >on 1) later classification 2) based on network condition like "steering" >to video optimizer when available bandwidth falls below certain threshold. > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? >[Ron] I think this goes to where the intelligence is for the forwarding. > >[SM] Agreed that the forwarding point need to be aware of the topology >but proxy-node itself doesn't need to. > >-----Original Message----- >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com] >Sent: Tuesday, October 22, 2013 2:49 PM >To: Linda Dunbar; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Hi, Linda. > >Responses inline. > > Ron > > >-----Original Message----- >From: Linda Dunbar [mailto:linda.dunbar@huawei.com] >Sent: Tuesday, October 22, 2013 4:31 PM >To: Ron Parker; nsc@ietf.org >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >Subject: RE: [nsc] New Version Notification for >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt > >Ron, > >Thank you very much for the valuable comments. See my response inserted >below: > >> -----Original Message----- >> >> >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes) >> - >> - although it may be slightly off topic for your draft, it occurs to >> me that the proxy nodes would be ideal locations to load balance >> towards multiple instances of the same type of service node (i.e., >> combining proxy-node and load-balancing). > >[Linda] are you saying that multiple instances are co-located? What if >multiple instances for one network function are located in different >places? >Do you think the "proxy node" should balance them, or should the >controller balance them and simply inform the "proxy node"? or >combination of both? > > >[Ron] My thinking, so far, is that a load-balancer is, itself a network >service function which understands that it manges some set of >functionally equivalent subtended network service function instances. >But, from a logical perspective, I think that I have argued myself out of >co-mingling the proxy concept and the load balancing concept. They can >be mixed and matched as necessary, and co-located as desired. For >example, a chain may indicate that a load-balancer must be visited. The >load balancer balances to multiple instances of proxy-fronted >non-SFC-aware service functions. But, all of this is off-topic, so I >apologize for introducing it here. > >> >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes), >> the first indented bullet states that the service function can be >> embedded in a service chain proxy. From a software implementation >> perspective that makes perfect sense. But from a network topology >> perspective, the proxy would not be explicitly observable -- the >> service function would look like it had native SFC capabilities with >> respect to other SFC service nodes and/or classifiers. > >[Linda] I will change the text to reflect this point. On the other hand, >many of today's service functions are independent. They don't care who is >ahead of them and who is after. How would you describe this scenario? > > >[Ron] I think we are saying that to be SFC-aware is to know, explicitly, >which service function is next. A service function which doesn't >understand that concept is front-ended by an SFC-proxy. > > >> >> Also in section 4.1, there is discussion of particular network >> topologies. It has been proposed in other drafts that the SFC >> approach be topology unaware. >> >[Linda] In this context, the Proxy nodes are topology unaware. But proxy >nodes know their connection to the directly connected service functions. >Is it OK? > >[Ron] I think this goes to where the intelligence is for the forwarding. > >Maybe we can chat face to face in Vancouver for the following points. > >[Ron] It would be my pleasure :). Please contact me privately. > > >Linda >> Section 4.2 (traffic steering). Consistent with my comment above, my >> feeling is that one of the biggest advantages of SFC is to become >> topology and transport unaware so that a new mechanism need not be >> invented for every combination of network topology (i.e., 1 hop away, >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.). >> >> Section 5.1 (multiple instances). Consistent with comments above, >> with correct separation of the logical and physical, steering tables >> would not need to be updated each time an NFV event occurred (i.e., >> instace up, down, moved, expanded, contracted, etc.). >> >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar >> comments to above. If we choose a topology and transport independent >> mechanism to follow a service chain, the complexity is reduced and the >> reliability is improved. Something akin to the steering that you >> mention is constrained to the classification node(s), greatly >> simplifying the service nodes. >> >> >> >> >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Linda Dunbar >> Sent: Monday, October 21, 2013 5:15 PM >> To: nsc@ietf.org >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee >> Subject: [nsc] New Version Notification for >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt >> >> There have been many drafts submitted for SFC (Service Function >> Chaining) BOF already. However, we felt that architecture and issues >> associated with chaining existing Layer 4-7 service functions that are >> not aware of Service Encapsulation header haven't been addressed by >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01). >> >> We put together a draft to analyze the issues associated with chaining >> existing >> Layer 4-7 service functions that are not aware of service >> encapsulation layers. This draft also examines the network >> architecture for chaining existing L4-L7 service functions. The >> intent is to identify and describe gaps that have not been >> addressed by other SFC drafts. >> >> Your comments are greatly appreciated. >> >> >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture >> Revision: 00 >> Title: Architecture for Chaining Legacy Layer 4-7 >>Service >> Functions >> Creation date: 2013-10-16 >> Group: Individual Submission >> Number of pages: 16 >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture-00.txt >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc- >> legacy-l4-l7-chain-architecture >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4- >> l7-chain-architecture-00 >> >> >> Linda, Ning, Ian, Sumandra, and Donald >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From I.Smith@F5.com Thu Oct 24 13:21:19 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED07411E81A0 for ; Thu, 24 Oct 2013 13:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7WANi9bviEF for ; Thu, 24 Oct 2013 13:21:15 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1958211E825C for ; Thu, 24 Oct 2013 13:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382646075; x=1414182075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JgOxoQFZvkumxdk4W0W7sCB+4XfHIQD6T3TrKhqeS84=; b=msK7fL8b86TOo1u68ykqKLc8jMovtU0TjfwnICH2AOu2dCIChn51kA9C hsULYZkSQcHMSNreQcw7solVeKWHIFiqJTJEw5NO4gK+RKm45cxCkE5hi JdUNUtZNyIgB3DXwdOLSw3OR1a579L1nJhTJmVXgG95O1WH8VuUAMcp2R U=; X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="84372410" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 20:21:13 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 13:21:12 -0700 From: Ian Smith To: "Jim Guichard (jguichar)" , Ron Parker , Sumandra Majee , "Linda Dunbar" , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0O5A0MVQLeY+CkOlucbf3LPW0poEPEpp Date: Thu, 24 Oct 2013 20:21:12 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:21:20 -0000 > with the counter argument that the detailed splitting of functions and th= e naming each interface that connects the functions of the architecture =0A= =0A= Granted, and i'm not advocating that, I am arguing however that these are f= unctions (and subsequently implementation requirements) that need to be cle= arly delineated because they are different in kind and when you draw it out= as a UML diagram, you don't put all three in the same box; that may or may= not lead to them being different classes or processes or products, which i= s an implementation time decision.=0A= =0A= >Policy in this case may not simply mean how to forward packets but rather = how a service function should process said packets upon receipt.=0A= =0A= This is a rfc2460 Hop-by-Hop options header: "The Hop-by-Hop Options heade= r is used to carry optional information that must be examined by every node= along a packet's delivery path." If you have IPv4 traffic, we have rfc247= 3 to use IPv6 as your encapsulation protocol.=0A= =0A= > Policy selection at a classifier determines which service chain packets = should be directed through but it does *not* decide which logical mid-boxes= shall be visited but only infers this by the encapsulation and simply forw= ards to the next-hop (which could be one of multiple available) that is abl= e to apply the first service function of the chain.=0A= =0A= How do you determine which one-of-many is the next-hop? Some actor somewhe= re MUST make that decision, so why aren't you doing that when you can do it= once per policy assignment? If not, then what is? You have to assume tha= t either every link in the chain has multiple target hosts or that the chai= n is instantiated with one and only one host per link; you can't reasonably= assume that there is a mix of that. Therefore you need to either pick the= one-and-only one link when you start, as Ron is suggesting, or you need to= have a directory service that each host uses to select the next hop which = can be pull (i.e., DNS) or push (i.e., orchestration). The fundamental que= stion that we need to answer at each node is "What does the forwarding tabl= e say and why does it say it?" and we need to provide an easy to implement = way to delivering that that doesn't require the server OS to do a lot of wo= rk or need a lot of new code. And ideally, you want to be able to say the = same for the network device OSs as well.=0A= =0A= Doing it once at the beginning is an rfc2460 Routing options header (probab= ly with a new routing type definition, since we've deprecated type 0, even = though the type 0 behavior is what you want).=0A= Doing it at every link is another rfc2460 Hop-By-Hop options header=0A= =0A= The combination of ipip encapsulation, routing options, and hop-by-hop opti= ons, as well as the opportunity to use locally defined options, appears to = satisfy every need statement on the table.=0A= =0A= > ...which logical mid-boxes shall be visited but only infers this by the e= ncapsulation...=0A= =0A= This seems to me to be somewhat naively assuming that "the overlay network = will take care of everything" instead of actually figuring out what has to = happen to make a set of packets result in a desired service delivery outcom= e, which is part of why I'm arguing against pre-supposing an overlay networ= k being part of the solution. I know you aren't being naive, but the conti= nued presence of comments like this from some parts of the list is worrisom= e and makes me feel like this is just a push to write a wire protocol not a= n attempt to actually solve the problem as it is being stated (which may no= t actually need a new wire protocol). There are a lot of tools already in = the tool kit and the combination of IPv6, ipip encapsulation for IPv4 traff= ic, routing options, and hop-by-hop options, as well as the opportunity to = use locally defined options, appears to satisfy every need on the table.=0A= =0A= =0A= ________________________________________=0A= From: Jim Guichard (jguichar) [jguichar@cisco.com]=0A= Sent: Thursday, October 24, 2013 3:21 PM=0A= To: Ian Smith; Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Ian,=0A= =0A= On 10/24/13 2:05 PM, "Ian Smith" wrote:=0A= =0A= >Which is why I say that you're lumping the decision of what something is= =0A= >(classification), what policy that matches (start the chain), and where=0A= >it's next hop is (traffic steering) into a single functional block.=0A= =0A= Jim> with the counter argument that the detailed splitting of functions=0A= and the naming each interface that connects the functions of the=0A= architecture (like IMS or other mobility architectures are so fond of=0A= doing) not only adds arbitrary complexity to the architecture (making it=0A= difficult for non experts to grasp), but in addition leads to over=0A= specification and limits implementation freedom, and this rigidity tends=0A= to lead to fragility in the overall system.=0A= =0A= >=0A= >They _MAY_ be the same host, but saying they _MUST_ be the same host=0A= >seems to be missing a lot about how this is already working today.=0A= >=0A= >If you want, as Paul is saying, a multi-tiered classification where the=0A= >network might have packet classification but the SFC system has something= =0A= >more, you are adding complexity and expense to the solution (since most=0A= >customers already have commodity DPIs and transport layer policy routing= =0A= >in place) just to arrive at the opportunity to make a policy selection=0A= >instead of being able to make a policy selection with what is already=0A= >there (DSCP).=0A= =0A= Jim> classification based on policy for packet forwarding with associated= =0A= marking/re-marking/policing/forwarding is different from classification to= =0A= enable policy selection at the services layer. Policy in this case may not= =0A= simply mean how to forward packets but rather how a service function=0A= should process said packets upon receipt.=0A= =0A= > The difference between each step of specificity from tcp:80, HTTP, HTTP= =0A= >video, HTTP video from YouTube, to this particular HTTP video from=0A= >YouTube is significant in terms of the amount of work you need to do and= =0A= >what you can do once you've done it; in most cases, the most granular=0A= >result isn't worth much more than a less granular one so it doesn't=0A= >justify the extra effort (and corresponding UX impact).=0A= >=0A= >=0A= >Furthermore, a policy selection outcome that decides "which logical=0A= >"mid-boxes" shall be visited and in which order" is just source routing=0A= >or label stacking, which we know how to do already and have standards for= =0A= >and can do with a sightly smarter router (cheap and not terribly=0A= >complex). If you are insistent on having a new overlay networking=0A= >protocol defined, then the actual policy selection outcome is more like=0A= >"decides which logical "middle-boxes" shall be visited and in which order= =0A= >_and then instantiates a service chain of network hosts that matches and= =0A= >creates an SFC tunnel endpoint to forward the packets into". At which=0A= >point you've just ramped up the sophistication (and the complexity and=0A= >expense) of that box from a slightly smarter router to a slightly smarter= =0A= >application delivery controller plus a dynamic infrastructure that is a=0A= >little bit out in front of where NFV is today but not quite all the way=0A= >to a fully realized SDN.=0A= =0A= Jim> it is neither source routing or label stacking. Policy selection at a= =0A= classifier determines which service chain packets should be directed=0A= through but it does *not* decide which logical mid-boxes shall be visited= =0A= but only infers this by the encapsulation and simply forwards to the=0A= next-hop (which could be one of multiple available) that is able to apply= =0A= the first service function of the chain.=0A= =0A= >=0A= >=0A= >Which means that, "carries the chain ID and optionally metadata" probably= =0A= >isn't necessary if you have the service orchestration framework that all= =0A= >of this implies that you have in order to get all the moving parts in=0A= >sync; you have to have the infrastructure being orchestrated, so passing= =0A= >policy updates or embedding new config state as part of deploying=0A= >resources isn't done on the wire in the forwarding plane since you are=0A= >doing it as part of configuration state updates.=0A= >=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 1:14 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >[Ron] The classifier adds the SFC service encapsulation which carries the= =0A= >chain ID and optionally metadata, the specifics of which will be defined= =0A= >by the WG.=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:40 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:31 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >Please see inline below.=0A= >=0A= > Ron=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:17 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Yeah. I'm not in agreement - the classification function isn't=0A= >necessarily co-located with the "start the chain" policy enforcement=0A= >function.=0A= >=0A= >=0A= >Ron> Sure, the "start the chain" enforcement function is free to engage=0A= >the services of a remote policy evaluation engine. Nothing in the=0A= >architecture precludes that.=0A= >=0A= >=0A= >Basically, there are millions of DPI platforms that don't need to be=0A= >replaced for you to be able to use their marking for steering decisions,= =0A= >and there are much, much more complex marking/classification mechanisms=0A= >that can't be done in-line on the wire that will also need to be=0A= >accommodated by a policy enforcement point.=0A= >=0A= >=0A= >Ron> Are you saying that DPI platforms should become "start the chain"=0A= >enforcement functions? Nothing in the architecture precludes that.=0A= >Can you elaborate on the "marking" concept, please? In an SFC=0A= >environment, would that become the addition of the SFC service header=0A= >encapsulation?=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >Also, while having the ability to "reclassify" in the middle of the chain= =0A= >is conceptually useful, you aren't chaining at that point anymore and=0A= >you've entered a realm of content switching, which is, if I understand=0A= >correctly, one of the things that is being called too complex/expensive=0A= >as a justification for creating a service chains in the first place.=0A= >=0A= >=0A= >Ron> This capability would not be restricted to flows carrying "content"= =0A= >as commonly defined (i.e., HTTP objects, FTP files, etc.). One example= =0A= >could be a service function that is performing some sort of quota=0A= >accounting -- after reaching some quota threshold, a different set of=0A= >services is chosen (perhaps a subset of what is selected at original=0A= >policy classification).=0A= >=0A= >[ims] I suppose, but that is a novel use of chaining, since quota=0A= >management is ordinarily done out-of-and and enforced in-band, i.e., you= =0A= >don't alter the chain you are in, you quench the existing flows in the=0A= >old chain set a new chain for new flows so that you don't break the=0A= >transport layer.=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:01 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >I agree conceptually that there is a difference between making a local=0A= >policy based decision as to how to progress a packet vs. respecting a=0A= >decision that was made by an upstream entity.=0A= >=0A= >Extending those concepts into the SFC realm, the classifier makes a full= =0A= >"source-routed" decision as to which logical "mid-boxes" shall be visited= =0A= >and in which order. Any midbox that is also a classifier may optionally= =0A= >reclassify and optionally choose a different chain. Any midbox that is= =0A= >not a classifier (or chooses not to reclassify) is obligated to follow=0A= >the chain determined by the most recent upstream classifier.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 11:47 AM=0A= >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >In my mind, steering is more "smart" than chaining because a host making= =0A= >a steering decision has to evaluate a lot of options to arrive at the=0A= >next hop, whereas a host in the middle of a chain is, I think, only=0A= >supposed to have one option for the next-hop.=0A= >=0A= >There are a lot more nuance and context to service chains, but in this=0A= >particular case it seems to me that there is a pretty clear parallel=0A= >between a host that is a router and a host that has a single default=0A= >gateway; steering gets you into a chain, but once in the chain you can=0A= >only get to the next link in that chain (because otherwise it isn't=0A= >really a chain).=0A= >=0A= >this is a steering rule:=0A= >=0A= >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and=0A= >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ]= =0A= >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and=0A= >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic port 80 using the phone.west1.example.net access point name,= =0A= >and coming from the IP prefix and that is either classified as video or=0A= >assigned DSCP 32, insert an options header designating the policy for the= =0A= >next four hops and forward to the next hop.)=0A= >=0A= >this is a chaining rule:=0A= >=0A= >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic from the source prefix, send to the default gateway)=0A= >=0A= >or=0A= >=0A= >match=3D=3D[ip.option.253.[1]=3D=3D1000]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic with policy 1000, send to the default gateway)=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Sumandra Majee=0A= >Sent: Wednesday, October 23, 2013 4:43 PM=0A= >To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >>I do have a few comments and one overall theme regarding "steering",=0A= >>which I consider the legacy approach that we are trying to improve in=0A= >>SFC.=0A= >=0A= >[SM] Not sure I get the distinction between "chaining" and "steering".=0A= >The L7 services are often inserted dynamically to the service chain based= =0A= >on 1) later classification 2) based on network condition like "steering"= =0A= >to video optimizer when available bandwidth falls below certain threshold.= =0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >[SM] Agreed that the forwarding point need to be aware of the topology=0A= >but proxy-node itself doesn't need to.=0A= >=0A= >-----Original Message-----=0A= >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= >Sent: Tuesday, October 22, 2013 2:49 PM=0A= >To: Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Linda.=0A= >=0A= >Responses inline.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= >Sent: Tuesday, October 22, 2013 4:31 PM=0A= >To: Ron Parker; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Ron,=0A= >=0A= >Thank you very much for the valuable comments. See my response inserted=0A= >below:=0A= >=0A= >> -----Original Message-----=0A= >>=0A= >>=0A= >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= >> -=0A= >> - although it may be slightly off topic for your draft, it occurs to=0A= >> me that the proxy nodes would be ideal locations to load balance=0A= >> towards multiple instances of the same type of service node (i.e.,=0A= >> combining proxy-node and load-balancing).=0A= >=0A= >[Linda] are you saying that multiple instances are co-located? What if=0A= >multiple instances for one network function are located in different=0A= >places?=0A= >Do you think the "proxy node" should balance them, or should the=0A= >controller balance them and simply inform the "proxy node"? or=0A= >combination of both?=0A= >=0A= >=0A= >[Ron] My thinking, so far, is that a load-balancer is, itself a network=0A= >service function which understands that it manges some set of=0A= >functionally equivalent subtended network service function instances.=0A= >But, from a logical perspective, I think that I have argued myself out of= =0A= >co-mingling the proxy concept and the load balancing concept. They can= =0A= >be mixed and matched as necessary, and co-located as desired. For=0A= >example, a chain may indicate that a load-balancer must be visited. The= =0A= >load balancer balances to multiple instances of proxy-fronted=0A= >non-SFC-aware service functions. But, all of this is off-topic, so I=0A= >apologize for introducing it here.=0A= >=0A= >>=0A= >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= >> the first indented bullet states that the service function can be=0A= >> embedded in a service chain proxy. From a software implementation=0A= >> perspective that makes perfect sense. But from a network topology=0A= >> perspective, the proxy would not be explicitly observable -- the=0A= >> service function would look like it had native SFC capabilities with=0A= >> respect to other SFC service nodes and/or classifiers.=0A= >=0A= >[Linda] I will change the text to reflect this point. On the other hand,= =0A= >many of today's service functions are independent. They don't care who is= =0A= >ahead of them and who is after. How would you describe this scenario?=0A= >=0A= >=0A= >[Ron] I think we are saying that to be SFC-aware is to know, explicitly,= =0A= >which service function is next. A service function which doesn't=0A= >understand that concept is front-ended by an SFC-proxy.=0A= >=0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >Maybe we can chat face to face in Vancouver for the following points.=0A= >=0A= >[Ron] It would be my pleasure :). Please contact me privately.=0A= >=0A= >=0A= >Linda=0A= >> Section 4.2 (traffic steering). Consistent with my comment above, my= =0A= >> feeling is that one of the biggest advantages of SFC is to become=0A= >> topology and transport unaware so that a new mechanism need not be=0A= >> invented for every combination of network topology (i.e., 1 hop away,=0A= >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >>=0A= >> Section 5.1 (multiple instances). Consistent with comments above,=0A= >> with correct separation of the logical and physical, steering tables=0A= >> would not need to be updated each time an NFV event occurred (i.e.,=0A= >> instace up, down, moved, expanded, contracted, etc.).=0A= >>=0A= >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= >> comments to above. If we choose a topology and transport independent= =0A= >> mechanism to follow a service chain, the complexity is reduced and the= =0A= >> reliability is improved. Something akin to the steering that you=0A= >> mention is constrained to the classification node(s), greatly=0A= >> simplifying the service nodes.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Linda Dunbar=0A= >> Sent: Monday, October 21, 2013 5:15 PM=0A= >> To: nsc@ietf.org=0A= >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >> Subject: [nsc] New Version Notification for=0A= >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >>=0A= >> There have been many drafts submitted for SFC (Service Function=0A= >> Chaining) BOF already. However, we felt that architecture and issues=0A= >> associated with chaining existing Layer 4-7 service functions that are= =0A= >> not aware of Service Encapsulation header haven't been addressed by=0A= >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >>=0A= >> We put together a draft to analyze the issues associated with chaining= =0A= >> existing=0A= >> Layer 4-7 service functions that are not aware of service=0A= >> encapsulation layers. This draft also examines the network=0A= >> architecture for chaining existing L4-L7 service functions. The=0A= >> intent is to identify and describe gaps that have not been=0A= >> addressed by other SFC drafts.=0A= >>=0A= >> Your comments are greatly appreciated.=0A= >>=0A= >>=0A= >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= >> Revision: 00=0A= >> Title: Architecture for Chaining Legacy Layer 4-7=0A= >>Service=0A= >> Functions=0A= >> Creation date: 2013-10-16=0A= >> Group: Individual Submission=0A= >> Number of pages: 16=0A= >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-= =0A= >> legacy-l4-l7-chain-architecture-00.txt=0A= >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= >> legacy-l4-l7-chain-architecture=0A= >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= >> l7-chain-architecture-00=0A= >>=0A= >>=0A= >> Linda, Ning, Ian, Sumandra, and Donald=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= >_______________________________________________=0A= >nsc mailing list=0A= >nsc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/nsc=0A= =0A= From I.Smith@F5.com Thu Oct 24 13:39:18 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E915811E838A for ; Thu, 24 Oct 2013 13:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mE-1VhdxLyAe for ; Thu, 24 Oct 2013 13:39:14 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id CAF7721F83EF for ; Thu, 24 Oct 2013 13:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382647139; x=1414183139; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kMd6rEkP7wr4LmcmFU8o94euSP5e/ErgsnPNHl3NVPs=; b=MrbyP+6tUevVXAHN6aAz6NkRJ7sqrcCIefz6NnD13IL5aIXDjg0r0I3P AKEM2khux+Hp8kZtNrFx/xm7tA3pKlxnY838GraRwZqJ5wFmktoWu4mwr UOpy0o6Ip6umWzqnikT+Eu9081njnsWz4/KtvhE77gmQKY9ulvcuI91yr 0=; X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="84374196" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 20:38:56 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 13:38:55 -0700 From: Ian Smith To: Ken Gray , Ron Parker , Sumandra Majee , "Linda Dunbar" , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0PKBTbIAusYCIEqkf1y+SxRAt5oES0t/ Date: Thu, 24 Oct 2013 20:38:54 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70C5E1@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:39:19 -0000 =0A= ________________________________________=0A= From: Ken Gray [kgray@juniper.net]=0A= Sent: Thursday, October 24, 2013 3:51 PM=0A= To: Ian Smith; Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hey, Ian. A few inlines ...=0A= =0A= While I agree that we shouldn't ignore the way things work today, and what= =0A= works well, I don't think we should assume they are optimal or that a=0A= solution for an environment like mobile (which is dictated architecturally= =0A= based on a long, long history) is necessarily optimal for an emerging=0A= domain like a DC.=0A= =0A= =0A= On 10/24/13 2:05 PM, "Ian Smith" wrote:=0A= =0A= >Which is why I say that you're lumping the decision of what something is= =0A= >(classification), what policy that matches (start the chain), and where=0A= >it's next hop is (traffic steering) into a single functional block.=0A= >=0A= >They _MAY_ be the same host, but saying they _MUST_ be the same host=0A= >seems to be missing a lot about how this is already working today.=0A= >=0A= >If you want, as Paul is saying, a multi-tiered classification where the=0A= >network might have packet classification but the SFC system has something= =0A= >more, you are adding complexity and expense to the solution (since most=0A= >customers already have commodity DPIs and transport layer policy routing= =0A= >in place) just to arrive at the opportunity to make a policy selection=0A= >instead of being able to make a policy selection with what is already=0A= >there (DSCP). The difference between each step of specificity from=0A= >tcp:80, HTTP, HTTP video, HTTP video from YouTube, to this particular=0A= >HTTP video from YouTube is significant in terms of the amount of work you= =0A= >need to do and what you can do once you've done it; in most cases, the=0A= >most granular result isn't worth much more than a less granular one so it= =0A= >doesn't justify the extra effort (and corresponding UX impact).=0A= =0A= I agree that we should take into consideration what's already out=0A= there, but we also shouldn't assume that what works in one domain (maybe=0A= because of architectural dictate) like mobile is an optimal solution for=0A= another like DC. Nor should we assume that what works today is actually=0A= desirable or least cost. For example, I think a large number of providers= =0A= would say being able to tell HTTP video from HTTP IS a step worth taking=0A= for their environment. And I find the use of the term "commodity DPI" kind= =0A= of funny ... because while DPI costs may be dropping as virtualized=0A= versions are introduced (or smaller scope, integral agents are licensed) I= =0A= wouldn't assume it's an expense that even current users wouldn't want to=0A= minimize further.=0A= =0A= [ims] I agree, that PBR isn't enough, but I'm not sure a lot of providers = really want to go down the rabbit hole of knowing HTTP video on a per URI b= asis (this one particular video). Granted, this is an unbalanced example -= the origin server DC has a much smaller problem space than the access netw= ork provider, but they also control the software of the server (so they can= do access controls in the application, not the network, for example). But = for any similar level of granularity, the numbers just become too big to do= real-time classification from the wire. "This is HTTP video that can be o= ptimized" is the current state of the art in my world, and there is a nice = bit of stability there for now.=0A= =0A= Commodity DIP - ok, in fairness that is probably too harsh, but I refer to = it like that because you can buy merchant silicon and OEM classification li= braries and achieve 80-90% of the results of a purpose built DPI and the pr= ices are falling.=0A= =0A= >=0A= >=0A= >Furthermore, a policy selection outcome that decides "which logical=0A= >"mid-boxes" shall be visited and in which order" is just source routing=0A= >or label stacking, which we know how to do already and have standards for= =0A= >and can do with a sightly smarter router (cheap and not terribly=0A= >complex). If you are insistent on having a new overlay networking=0A= >protocol defined, then the actual policy selection outcome is more like=0A= >"decides which logical "middle-boxes" shall be visited and in which order= =0A= >_and then instantiates a service chain of network hosts that matches and= =0A= >creates an SFC tunnel endpoint to forward the packets into". At which=0A= >point you've just ramped up the sophistication (and the complexity and=0A= >expense) of that box from a slightly smarter router to a slightly smarter= =0A= >application delivery controller plus a dynamic infrastructure that is a=0A= >little bit out in front of where NFV is today but not quite all the way=0A= >to a fully realized SDN.=0A= =0A= I fully expect that there's a few vendors that think they're already= =0A= there - the problem is that without standards they don't interoperate. I= =0A= also think that reactive chain building vs proactive chain building will=0A= depend on your environment.=0A= =0A= [ims] agreed.=0A= >=0A= >=0A= >Which means that, "carries the chain ID and optionally metadata" probably= =0A= >isn't necessary if you have the service orchestration framework that all= =0A= >of this implies that you have in order to get all the moving parts in=0A= >sync; you have to have the infrastructure being orchestrated, so passing= =0A= >policy updates or embedding new config state as part of deploying=0A= >resources isn't done on the wire in the forwarding plane since you are=0A= >doing it as part of configuration state updates.=0A= =0A= This seems like an independent assertion rather than something=0A= conclusive from the former argument. I think we're still debating the=0A= metadata issue and thus it is on the agenda. I don't think that I could=0A= agree you don't need metadata at all. Whether you're an advocate of=0A= inline or out of band metadata, a lookup flag/tag inline would certainly=0A= be helpful.=0A= =0A= [ims] Yes, i'm making a distinction between the policy or chain ID and thin= gs like subscriberID, contentType, destinationID, etc. that seem like pure = metadata and can be referential. I agree that if you have chain-links that= are going to make decisions, you have to stick something into the packet f= or them to key that decision on if it isn't already there. =0A= >=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 1:14 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >[Ron] The classifier adds the SFC service encapsulation which carries the= =0A= >chain ID and optionally metadata, the specifics of which will be defined= =0A= >by the WG.=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:40 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:31 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >Please see inline below.=0A= >=0A= > Ron=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:17 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Yeah. I'm not in agreement - the classification function isn't=0A= >necessarily co-located with the "start the chain" policy enforcement=0A= >function.=0A= >=0A= >=0A= >Ron> Sure, the "start the chain" enforcement function is free to engage=0A= >the services of a remote policy evaluation engine. Nothing in the=0A= >architecture precludes that.=0A= >=0A= >=0A= >Basically, there are millions of DPI platforms that don't need to be=0A= >replaced for you to be able to use their marking for steering decisions,= =0A= >and there are much, much more complex marking/classification mechanisms=0A= >that can't be done in-line on the wire that will also need to be=0A= >accommodated by a policy enforcement point.=0A= >=0A= >=0A= >Ron> Are you saying that DPI platforms should become "start the chain"=0A= >enforcement functions? Nothing in the architecture precludes that.=0A= >Can you elaborate on the "marking" concept, please? In an SFC=0A= >environment, would that become the addition of the SFC service header=0A= >encapsulation?=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >Also, while having the ability to "reclassify" in the middle of the chain= =0A= >is conceptually useful, you aren't chaining at that point anymore and=0A= >you've entered a realm of content switching, which is, if I understand=0A= >correctly, one of the things that is being called too complex/expensive=0A= >as a justification for creating a service chains in the first place.=0A= >=0A= >=0A= >Ron> This capability would not be restricted to flows carrying "content"= =0A= >as commonly defined (i.e., HTTP objects, FTP files, etc.). One example= =0A= >could be a service function that is performing some sort of quota=0A= >accounting -- after reaching some quota threshold, a different set of=0A= >services is chosen (perhaps a subset of what is selected at original=0A= >policy classification).=0A= >=0A= >[ims] I suppose, but that is a novel use of chaining, since quota=0A= >management is ordinarily done out-of-and and enforced in-band, i.e., you= =0A= >don't alter the chain you are in, you quench the existing flows in the=0A= >old chain set a new chain for new flows so that you don't break the=0A= >transport layer.=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:01 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >I agree conceptually that there is a difference between making a local=0A= >policy based decision as to how to progress a packet vs. respecting a=0A= >decision that was made by an upstream entity.=0A= >=0A= >Extending those concepts into the SFC realm, the classifier makes a full= =0A= >"source-routed" decision as to which logical "mid-boxes" shall be visited= =0A= >and in which order. Any midbox that is also a classifier may optionally= =0A= >reclassify and optionally choose a different chain. Any midbox that is= =0A= >not a classifier (or chooses not to reclassify) is obligated to follow=0A= >the chain determined by the most recent upstream classifier.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 11:47 AM=0A= >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >In my mind, steering is more "smart" than chaining because a host making= =0A= >a steering decision has to evaluate a lot of options to arrive at the=0A= >next hop, whereas a host in the middle of a chain is, I think, only=0A= >supposed to have one option for the next-hop.=0A= >=0A= >There are a lot more nuance and context to service chains, but in this=0A= >particular case it seems to me that there is a pretty clear parallel=0A= >between a host that is a router and a host that has a single default=0A= >gateway; steering gets you into a chain, but once in the chain you can=0A= >only get to the next link in that chain (because otherwise it isn't=0A= >really a chain).=0A= >=0A= >this is a steering rule:=0A= >=0A= >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and=0A= >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ]= =0A= >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and=0A= >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic port 80 using the phone.west1.example.net access point name,= =0A= >and coming from the IP prefix and that is either classified as video or=0A= >assigned DSCP 32, insert an options header designating the policy for the= =0A= >next four hops and forward to the next hop.)=0A= >=0A= >this is a chaining rule:=0A= >=0A= >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic from the source prefix, send to the default gateway)=0A= >=0A= >or=0A= >=0A= >match=3D=3D[ip.option.253.[1]=3D=3D1000]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic with policy 1000, send to the default gateway)=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Sumandra Majee=0A= >Sent: Wednesday, October 23, 2013 4:43 PM=0A= >To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >>I do have a few comments and one overall theme regarding "steering",=0A= >>which I consider the legacy approach that we are trying to improve in=0A= >>SFC.=0A= >=0A= >[SM] Not sure I get the distinction between "chaining" and "steering".=0A= >The L7 services are often inserted dynamically to the service chain based= =0A= >on 1) later classification 2) based on network condition like "steering"= =0A= >to video optimizer when available bandwidth falls below certain threshold.= =0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >[SM] Agreed that the forwarding point need to be aware of the topology=0A= >but proxy-node itself doesn't need to.=0A= >=0A= >-----Original Message-----=0A= >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= >Sent: Tuesday, October 22, 2013 2:49 PM=0A= >To: Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Linda.=0A= >=0A= >Responses inline.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= >Sent: Tuesday, October 22, 2013 4:31 PM=0A= >To: Ron Parker; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Ron,=0A= >=0A= >Thank you very much for the valuable comments. See my response inserted=0A= >below:=0A= >=0A= >> -----Original Message-----=0A= >>=0A= >>=0A= >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= >> -=0A= >> - although it may be slightly off topic for your draft, it occurs to=0A= >> me that the proxy nodes would be ideal locations to load balance=0A= >> towards multiple instances of the same type of service node (i.e.,=0A= >> combining proxy-node and load-balancing).=0A= >=0A= >[Linda] are you saying that multiple instances are co-located? What if=0A= >multiple instances for one network function are located in different=0A= >places?=0A= >Do you think the "proxy node" should balance them, or should the=0A= >controller balance them and simply inform the "proxy node"? or=0A= >combination of both?=0A= >=0A= >=0A= >[Ron] My thinking, so far, is that a load-balancer is, itself a network=0A= >service function which understands that it manges some set of=0A= >functionally equivalent subtended network service function instances.=0A= >But, from a logical perspective, I think that I have argued myself out of= =0A= >co-mingling the proxy concept and the load balancing concept. They can= =0A= >be mixed and matched as necessary, and co-located as desired. For=0A= >example, a chain may indicate that a load-balancer must be visited. The= =0A= >load balancer balances to multiple instances of proxy-fronted=0A= >non-SFC-aware service functions. But, all of this is off-topic, so I=0A= >apologize for introducing it here.=0A= >=0A= >>=0A= >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= >> the first indented bullet states that the service function can be=0A= >> embedded in a service chain proxy. From a software implementation=0A= >> perspective that makes perfect sense. But from a network topology=0A= >> perspective, the proxy would not be explicitly observable -- the=0A= >> service function would look like it had native SFC capabilities with=0A= >> respect to other SFC service nodes and/or classifiers.=0A= >=0A= >[Linda] I will change the text to reflect this point. On the other hand,= =0A= >many of today's service functions are independent. They don't care who is= =0A= >ahead of them and who is after. How would you describe this scenario?=0A= >=0A= >=0A= >[Ron] I think we are saying that to be SFC-aware is to know, explicitly,= =0A= >which service function is next. A service function which doesn't=0A= >understand that concept is front-ended by an SFC-proxy.=0A= >=0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >Maybe we can chat face to face in Vancouver for the following points.=0A= >=0A= >[Ron] It would be my pleasure :). Please contact me privately.=0A= >=0A= >=0A= >Linda=0A= >> Section 4.2 (traffic steering). Consistent with my comment above, my= =0A= >> feeling is that one of the biggest advantages of SFC is to become=0A= >> topology and transport unaware so that a new mechanism need not be=0A= >> invented for every combination of network topology (i.e., 1 hop away,=0A= >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >>=0A= >> Section 5.1 (multiple instances). Consistent with comments above,=0A= >> with correct separation of the logical and physical, steering tables=0A= >> would not need to be updated each time an NFV event occurred (i.e.,=0A= >> instace up, down, moved, expanded, contracted, etc.).=0A= >>=0A= >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= >> comments to above. If we choose a topology and transport independent= =0A= >> mechanism to follow a service chain, the complexity is reduced and the= =0A= >> reliability is improved. Something akin to the steering that you=0A= >> mention is constrained to the classification node(s), greatly=0A= >> simplifying the service nodes.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Linda Dunbar=0A= >> Sent: Monday, October 21, 2013 5:15 PM=0A= >> To: nsc@ietf.org=0A= >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >> Subject: [nsc] New Version Notification for=0A= >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >>=0A= >> There have been many drafts submitted for SFC (Service Function=0A= >> Chaining) BOF already. However, we felt that architecture and issues=0A= >> associated with chaining existing Layer 4-7 service functions that are= =0A= >> not aware of Service Encapsulation header haven't been addressed by=0A= >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >>=0A= >> We put together a draft to analyze the issues associated with chaining= =0A= >> existing=0A= >> Layer 4-7 service functions that are not aware of service=0A= >> encapsulation layers. This draft also examines the network=0A= >> architecture for chaining existing L4-L7 service functions. The=0A= >> intent is to identify and describe gaps that have not been=0A= >> addressed by other SFC drafts.=0A= >>=0A= >> Your comments are greatly appreciated.=0A= >>=0A= >>=0A= >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= >> Revision: 00=0A= >> Title: Architecture for Chaining Legacy Layer 4-7=0A= >>Service=0A= >> Functions=0A= >> Creation date: 2013-10-16=0A= >> Group: Individual Submission=0A= >> Number of pages: 16=0A= >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-= =0A= >> legacy-l4-l7-chain-architecture-00.txt=0A= >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= >> legacy-l4-l7-chain-architecture=0A= >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= >> l7-chain-architecture-00=0A= >>=0A= >>=0A= >> Linda, Ning, Ian, Sumandra, and Donald=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= >_______________________________________________=0A= >nsc mailing list=0A= >nsc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= >=0A= =0A= =0A= From I.Smith@F5.com Thu Oct 24 13:40:01 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798D911E8222 for ; Thu, 24 Oct 2013 13:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.296 X-Spam-Level: X-Spam-Status: No, score=-10.296 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG8ImygNF52b for ; Thu, 24 Oct 2013 13:39:57 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4454911E829B for ; Thu, 24 Oct 2013 13:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=I.Smith@f5.com; q=dns/txt; s=seattle; t=1382647190; x=1414183190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=CX/1aD9gz2+7qGoAp2ZssR+eGO6x0vP1/WB2ebSXqTU=; b=dz0DHWStDNhlWYB1VrldPSCn6t6se77dXRE3eF8NwEgr+gU6mn9ZrRdy NHvyRtHB/AywJ7ikspQh5Dvjo6uOK9wJ5MF+LZjQpgM91s4G1F74ssXG/ 161b1optUnYWKfMq7tOe/RZL/oVTjt5FPcqFlcsiJGjTjOUpJqNLCWMyB Y=; X-IronPort-AV: E=Sophos;i="4.93,564,1378857600"; d="scan'208";a="84374291" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES128-SHA; 24 Oct 2013 20:39:49 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Thu, 24 Oct 2013 13:39:48 -0700 From: Ian Smith To: Ken Gray , Ron Parker , Sumandra Majee , "Linda Dunbar" , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0PKBTbIAusYCIEqkf1y+SxRAt5oES0t/gAAFHNM= Date: Thu, 24 Oct 2013 20:39:48 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70C601@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, , <419417C345CA5F48BF45F0A23955A0634A70C5E1@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70C5E1@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Donald Eastlake , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 20:40:01 -0000 oops - inline comments=0A= ________________________________________=0A= From: nsc-bounces@ietf.org [nsc-bounces@ietf.org] on behalf of Ian Smith [I= .Smith@F5.com]=0A= Sent: Thursday, October 24, 2013 4:38 PM=0A= To: Ken Gray; Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= ________________________________________=0A= From: Ken Gray [kgray@juniper.net]=0A= Sent: Thursday, October 24, 2013 3:51 PM=0A= To: Ian Smith; Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= Cc: Donald Eastlake; Ning So=0A= Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-= l7-chain-architecture-00.txt=0A= =0A= Hey, Ian. A few inlines ...=0A= =0A= While I agree that we shouldn't ignore the way things work today, and what= =0A= works well, I don't think we should assume they are optimal or that a=0A= solution for an environment like mobile (which is dictated architecturally= =0A= based on a long, long history) is necessarily optimal for an emerging=0A= domain like a DC.=0A= =0A= =0A= On 10/24/13 2:05 PM, "Ian Smith" wrote:=0A= =0A= >Which is why I say that you're lumping the decision of what something is= =0A= >(classification), what policy that matches (start the chain), and where=0A= >it's next hop is (traffic steering) into a single functional block.=0A= >=0A= >They _MAY_ be the same host, but saying they _MUST_ be the same host=0A= >seems to be missing a lot about how this is already working today.=0A= >=0A= >If you want, as Paul is saying, a multi-tiered classification where the=0A= >network might have packet classification but the SFC system has something= =0A= >more, you are adding complexity and expense to the solution (since most=0A= >customers already have commodity DPIs and transport layer policy routing= =0A= >in place) just to arrive at the opportunity to make a policy selection=0A= >instead of being able to make a policy selection with what is already=0A= >there (DSCP). The difference between each step of specificity from=0A= >tcp:80, HTTP, HTTP video, HTTP video from YouTube, to this particular=0A= >HTTP video from YouTube is significant in terms of the amount of work you= =0A= >need to do and what you can do once you've done it; in most cases, the=0A= >most granular result isn't worth much more than a less granular one so it= =0A= >doesn't justify the extra effort (and corresponding UX impact).=0A= =0A= I agree that we should take into consideration what's already out=0A= there, but we also shouldn't assume that what works in one domain (maybe=0A= because of architectural dictate) like mobile is an optimal solution for=0A= another like DC. Nor should we assume that what works today is actually=0A= desirable or least cost. For example, I think a large number of providers= =0A= would say being able to tell HTTP video from HTTP IS a step worth taking=0A= for their environment. And I find the use of the term "commodity DPI" kind= =0A= of funny ... because while DPI costs may be dropping as virtualized=0A= versions are introduced (or smaller scope, integral agents are licensed) I= =0A= wouldn't assume it's an expense that even current users wouldn't want to=0A= minimize further.=0A= =0A= [ims] I agree, that PBR isn't enough, but I'm not sure a lot of providers = really want to go down the rabbit hole of knowing HTTP video on a per URI b= asis (this one particular video). Granted, this is an unbalanced example -= the origin server DC has a much smaller problem space than the access netw= ork provider, but they also control the software of the server (so they can= do access controls in the application, not the network, for example). But = for any similar level of granularity, the numbers just become too big to do= real-time classification from the wire. "This is HTTP video that can be o= ptimized" is the current state of the art in my world, and there is a nice = bit of stability there for now.=0A= =0A= Commodity DIP - ok, in fairness that is probably too harsh, but I refer to = it like that because you can buy merchant silicon and OEM classification li= braries and achieve 80-90% of the results of a purpose built DPI and the pr= ices are falling.=0A= =0A= >=0A= >=0A= >Furthermore, a policy selection outcome that decides "which logical=0A= >"mid-boxes" shall be visited and in which order" is just source routing=0A= >or label stacking, which we know how to do already and have standards for= =0A= >and can do with a sightly smarter router (cheap and not terribly=0A= >complex). If you are insistent on having a new overlay networking=0A= >protocol defined, then the actual policy selection outcome is more like=0A= >"decides which logical "middle-boxes" shall be visited and in which order= =0A= >_and then instantiates a service chain of network hosts that matches and= =0A= >creates an SFC tunnel endpoint to forward the packets into". At which=0A= >point you've just ramped up the sophistication (and the complexity and=0A= >expense) of that box from a slightly smarter router to a slightly smarter= =0A= >application delivery controller plus a dynamic infrastructure that is a=0A= >little bit out in front of where NFV is today but not quite all the way=0A= >to a fully realized SDN.=0A= =0A= I fully expect that there's a few vendors that think they're already= =0A= there - the problem is that without standards they don't interoperate. I= =0A= also think that reactive chain building vs proactive chain building will=0A= depend on your environment.=0A= =0A= [ims] agreed.=0A= >=0A= >=0A= >Which means that, "carries the chain ID and optionally metadata" probably= =0A= >isn't necessary if you have the service orchestration framework that all= =0A= >of this implies that you have in order to get all the moving parts in=0A= >sync; you have to have the infrastructure being orchestrated, so passing= =0A= >policy updates or embedding new config state as part of deploying=0A= >resources isn't done on the wire in the forwarding plane since you are=0A= >doing it as part of configuration state updates.=0A= =0A= This seems like an independent assertion rather than something=0A= conclusive from the former argument. I think we're still debating the=0A= metadata issue and thus it is on the agenda. I don't think that I could=0A= agree you don't need metadata at all. Whether you're an advocate of=0A= inline or out of band metadata, a lookup flag/tag inline would certainly=0A= be helpful.=0A= =0A= [ims] Yes, i'm making a distinction between the policy or chain ID and thin= gs like subscriberID, contentType, destinationID, etc. that seem like pure = metadata and can be referential. I agree that if you have chain-links that= are going to make decisions, you have to stick something into the packet f= or them to key that decision on if it isn't already there.=0A= >=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 1:14 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >[Ron] The classifier adds the SFC service encapsulation which carries the= =0A= >chain ID and optionally metadata, the specifics of which will be defined= =0A= >by the WG.=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:40 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:31 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >Please see inline below.=0A= >=0A= > Ron=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 12:17 PM=0A= >To: Ron Parker; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Yeah. I'm not in agreement - the classification function isn't=0A= >necessarily co-located with the "start the chain" policy enforcement=0A= >function.=0A= >=0A= >=0A= >Ron> Sure, the "start the chain" enforcement function is free to engage=0A= >the services of a remote policy evaluation engine. Nothing in the=0A= >architecture precludes that.=0A= >=0A= >=0A= >Basically, there are millions of DPI platforms that don't need to be=0A= >replaced for you to be able to use their marking for steering decisions,= =0A= >and there are much, much more complex marking/classification mechanisms=0A= >that can't be done in-line on the wire that will also need to be=0A= >accommodated by a policy enforcement point.=0A= >=0A= >=0A= >Ron> Are you saying that DPI platforms should become "start the chain"=0A= >enforcement functions? Nothing in the architecture precludes that.=0A= >Can you elaborate on the "marking" concept, please? In an SFC=0A= >environment, would that become the addition of the SFC service header=0A= >encapsulation?=0A= >=0A= >[ims] no, but when you say "the classifier makes a full "source-routed"=0A= >decision" that does imply that classification function is going to do=0A= >more than just setting of DSCP/ToS/QoS based on the packet inspection.=0A= >=0A= >Also, while having the ability to "reclassify" in the middle of the chain= =0A= >is conceptually useful, you aren't chaining at that point anymore and=0A= >you've entered a realm of content switching, which is, if I understand=0A= >correctly, one of the things that is being called too complex/expensive=0A= >as a justification for creating a service chains in the first place.=0A= >=0A= >=0A= >Ron> This capability would not be restricted to flows carrying "content"= =0A= >as commonly defined (i.e., HTTP objects, FTP files, etc.). One example= =0A= >could be a service function that is performing some sort of quota=0A= >accounting -- after reaching some quota threshold, a different set of=0A= >services is chosen (perhaps a subset of what is selected at original=0A= >policy classification).=0A= >=0A= >[ims] I suppose, but that is a novel use of chaining, since quota=0A= >management is ordinarily done out-of-and and enforced in-band, i.e., you= =0A= >don't alter the chain you are in, you quench the existing flows in the=0A= >old chain set a new chain for new flows so that you don't break the=0A= >transport layer.=0A= >=0A= >________________________________________=0A= >From: Ron Parker [Ron_Parker@affirmednetworks.com]=0A= >Sent: Thursday, October 24, 2013 12:01 PM=0A= >To: Ian Smith; Sumandra Majee; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Ian.=0A= >=0A= >I agree conceptually that there is a difference between making a local=0A= >policy based decision as to how to progress a packet vs. respecting a=0A= >decision that was made by an upstream entity.=0A= >=0A= >Extending those concepts into the SFC realm, the classifier makes a full= =0A= >"source-routed" decision as to which logical "mid-boxes" shall be visited= =0A= >and in which order. Any midbox that is also a classifier may optionally= =0A= >reclassify and optionally choose a different chain. Any midbox that is= =0A= >not a classifier (or chooses not to reclassify) is obligated to follow=0A= >the chain determined by the most recent upstream classifier.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Ian Smith [mailto:I.Smith@F5.com]=0A= >Sent: Thursday, October 24, 2013 11:47 AM=0A= >To: Sumandra Majee; Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >In my mind, steering is more "smart" than chaining because a host making= =0A= >a steering decision has to evaluate a lot of options to arrive at the=0A= >next hop, whereas a host in the middle of a chain is, I think, only=0A= >supposed to have one option for the next-hop.=0A= >=0A= >There are a lot more nuance and context to service chains, but in this=0A= >particular case it seems to me that there is a pretty clear parallel=0A= >between a host that is a router and a host that has a single default=0A= >gateway; steering gets you into a chain, but once in the chain you can=0A= >only get to the next link in that chain (because otherwise it isn't=0A= >really a chain).=0A= >=0A= >this is a steering rule:=0A= >=0A= >match=3D=3D[apn=3D=3Dphone.west1.example.net and ip.src=3D=3D2001:DB8:0:FF= FF/64 and=0A= >tcp.dst=3D=3D80 and (flow.classification=3D=3Dvideo or ip.dscp=3D=3D32) ]= =0A= >action=3D=3D[ip.option=3D=3D0,64,253,4,1000 and=0A= >ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic port 80 using the phone.west1.example.net access point name,= =0A= >and coming from the IP prefix and that is either classified as video or=0A= >assigned DSCP 32, insert an options header designating the policy for the= =0A= >next four hops and forward to the next hop.)=0A= >=0A= >this is a chaining rule:=0A= >=0A= >match=3D=3D[ip.src=3D=3D2001:DB8:0:FFFF/64]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic from the source prefix, send to the default gateway)=0A= >=0A= >or=0A= >=0A= >match=3D=3D[ip.option.253.[1]=3D=3D1000]=0A= >action=3D=3D[ip.nexthop=3D=3D2001:DB8:0:FFFF::AAAA/132]=0A= >(for traffic with policy 1000, send to the default gateway)=0A= >=0A= >=0A= >=0A= >________________________________________=0A= >From: Sumandra Majee=0A= >Sent: Wednesday, October 23, 2013 4:43 PM=0A= >To: Ron Parker; Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >>I do have a few comments and one overall theme regarding "steering",=0A= >>which I consider the legacy approach that we are trying to improve in=0A= >>SFC.=0A= >=0A= >[SM] Not sure I get the distinction between "chaining" and "steering".=0A= >The L7 services are often inserted dynamically to the service chain based= =0A= >on 1) later classification 2) based on network condition like "steering"= =0A= >to video optimizer when available bandwidth falls below certain threshold.= =0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >[SM] Agreed that the forwarding point need to be aware of the topology=0A= >but proxy-node itself doesn't need to.=0A= >=0A= >-----Original Message-----=0A= >From: Ron Parker [mailto:Ron_Parker@affirmednetworks.com]=0A= >Sent: Tuesday, October 22, 2013 2:49 PM=0A= >To: Linda Dunbar; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Hi, Linda.=0A= >=0A= >Responses inline.=0A= >=0A= > Ron=0A= >=0A= >=0A= >-----Original Message-----=0A= >From: Linda Dunbar [mailto:linda.dunbar@huawei.com]=0A= >Sent: Tuesday, October 22, 2013 4:31 PM=0A= >To: Ron Parker; nsc@ietf.org=0A= >Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >Subject: RE: [nsc] New Version Notification for=0A= >draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt=0A= >=0A= >Ron,=0A= >=0A= >Thank you very much for the valuable comments. See my response inserted=0A= >below:=0A= >=0A= >> -----Original Message-----=0A= >>=0A= >>=0A= >> In section 3.3, figure 2 (Chainging existing Layer 4-7 service nodes)=0A= >> -=0A= >> - although it may be slightly off topic for your draft, it occurs to=0A= >> me that the proxy nodes would be ideal locations to load balance=0A= >> towards multiple instances of the same type of service node (i.e.,=0A= >> combining proxy-node and load-balancing).=0A= >=0A= >[Linda] are you saying that multiple instances are co-located? What if=0A= >multiple instances for one network function are located in different=0A= >places?=0A= >Do you think the "proxy node" should balance them, or should the=0A= >controller balance them and simply inform the "proxy node"? or=0A= >combination of both?=0A= >=0A= >=0A= >[Ron] My thinking, so far, is that a load-balancer is, itself a network=0A= >service function which understands that it manges some set of=0A= >functionally equivalent subtended network service function instances.=0A= >But, from a logical perspective, I think that I have argued myself out of= =0A= >co-mingling the proxy concept and the load balancing concept. They can= =0A= >be mixed and matched as necessary, and co-located as desired. For=0A= >example, a chain may indicate that a load-balancer must be visited. The= =0A= >load balancer balances to multiple instances of proxy-fronted=0A= >non-SFC-aware service functions. But, all of this is off-topic, so I=0A= >apologize for introducing it here.=0A= >=0A= >>=0A= >> In section 4.1 (L4-L7 nodes connection to Service Chain Proxy Nodes),=0A= >> the first indented bullet states that the service function can be=0A= >> embedded in a service chain proxy. From a software implementation=0A= >> perspective that makes perfect sense. But from a network topology=0A= >> perspective, the proxy would not be explicitly observable -- the=0A= >> service function would look like it had native SFC capabilities with=0A= >> respect to other SFC service nodes and/or classifiers.=0A= >=0A= >[Linda] I will change the text to reflect this point. On the other hand,= =0A= >many of today's service functions are independent. They don't care who is= =0A= >ahead of them and who is after. How would you describe this scenario?=0A= >=0A= >=0A= >[Ron] I think we are saying that to be SFC-aware is to know, explicitly,= =0A= >which service function is next. A service function which doesn't=0A= >understand that concept is front-ended by an SFC-proxy.=0A= >=0A= >=0A= >>=0A= >> Also in section 4.1, there is discussion of particular network=0A= >> topologies. It has been proposed in other drafts that the SFC=0A= >> approach be topology unaware.=0A= >>=0A= >[Linda] In this context, the Proxy nodes are topology unaware. But proxy= =0A= >nodes know their connection to the directly connected service functions.= =0A= >Is it OK?=0A= >=0A= >[Ron] I think this goes to where the intelligence is for the forwarding.= =0A= >=0A= >Maybe we can chat face to face in Vancouver for the following points.=0A= >=0A= >[Ron] It would be my pleasure :). Please contact me privately.=0A= >=0A= >=0A= >Linda=0A= >> Section 4.2 (traffic steering). Consistent with my comment above, my= =0A= >> feeling is that one of the biggest advantages of SFC is to become=0A= >> topology and transport unaware so that a new mechanism need not be=0A= >> invented for every combination of network topology (i.e., 1 hop away,=0A= >> 2 hops away, more) and transport technology (i.e., MAC bridging, IP=0A= >> forwarding, MPLS LER/LSR, ACL-based filtered forwarding, etc.).=0A= >>=0A= >> Section 5.1 (multiple instances). Consistent with comments above,=0A= >> with correct separation of the logical and physical, steering tables=0A= >> would not need to be updated each time an NFV event occurred (i.e.,=0A= >> instace up, down, moved, expanded, contracted, etc.).=0A= >>=0A= >> Section 5.2 (challenges of Layer 4-7 traffic steering). Similar=0A= >> comments to above. If we choose a topology and transport independent= =0A= >> mechanism to follow a service chain, the complexity is reduced and the= =0A= >> reliability is improved. Something akin to the steering that you=0A= >> mention is constrained to the classification node(s), greatly=0A= >> simplifying the service nodes.=0A= >>=0A= >>=0A= >>=0A= >>=0A= >> -----Original Message-----=0A= >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of=0A= >> Linda Dunbar=0A= >> Sent: Monday, October 21, 2013 5:15 PM=0A= >> To: nsc@ietf.org=0A= >> Cc: Donald Eastlake; Ning So; Ian Smith; Sumandra Majee=0A= >> Subject: [nsc] New Version Notification for=0A= >> draft-dunbar-sfc-legacy-l4- l7-chain-architecture-00.txt=0A= >>=0A= >> There have been many drafts submitted for SFC (Service Function=0A= >> Chaining) BOF already. However, we felt that architecture and issues=0A= >> associated with chaining existing Layer 4-7 service functions that are= =0A= >> not aware of Service Encapsulation header haven't been addressed by=0A= >> any drafts (which is called "Proxy Nodes" by draft-quinn-nsh-01).=0A= >>=0A= >> We put together a draft to analyze the issues associated with chaining= =0A= >> existing=0A= >> Layer 4-7 service functions that are not aware of service=0A= >> encapsulation layers. This draft also examines the network=0A= >> architecture for chaining existing L4-L7 service functions. The=0A= >> intent is to identify and describe gaps that have not been=0A= >> addressed by other SFC drafts.=0A= >>=0A= >> Your comments are greatly appreciated.=0A= >>=0A= >>=0A= >> Filename: draft-dunbar-sfc-legacy-l4-l7-chain-architecture=0A= >> Revision: 00=0A= >> Title: Architecture for Chaining Legacy Layer 4-7=0A= >>Service=0A= >> Functions=0A= >> Creation date: 2013-10-16=0A= >> Group: Individual Submission=0A= >> Number of pages: 16=0A= >> URL: http://www.ietf.org/internet-drafts/draft-dunbar-sfc-= =0A= >> legacy-l4-l7-chain-architecture-00.txt=0A= >> Status: http://datatracker.ietf.org/doc/draft-dunbar-sfc-=0A= >> legacy-l4-l7-chain-architecture=0A= >> Htmlized: http://tools.ietf.org/html/draft-dunbar-sfc-legacy-l4-= =0A= >> l7-chain-architecture-00=0A= >>=0A= >>=0A= >> Linda, Ning, Ian, Sumandra, and Donald=0A= >>=0A= >> _______________________________________________=0A= >> nsc mailing list=0A= >> nsc@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/nsc=0A= >_______________________________________________=0A= >nsc mailing list=0A= >nsc@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/nsc=0A= >=0A= >=0A= =0A= =0A= _______________________________________________=0A= nsc mailing list=0A= nsc@ietf.org=0A= https://www.ietf.org/mailman/listinfo/nsc=0A= From narten@us.ibm.com Fri Oct 25 08:00:58 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5764011E83DD for ; Fri, 25 Oct 2013 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nqLnN81qZKw for ; Fri, 25 Oct 2013 08:00:50 -0700 (PDT) Received: from e39.co.us.ibm.com (e39.co.us.ibm.com [32.97.110.160]) by ietfa.amsl.com (Postfix) with ESMTP id 2774421F9E8D for ; Fri, 25 Oct 2013 08:00:42 -0700 (PDT) Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Oct 2013 09:00:28 -0600 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; Fri, 25 Oct 2013 09:00:26 -0600 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id CE2171FF0049 for ; Fri, 25 Oct 2013 09:00:13 -0600 (MDT) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9PF0MIv274766 for ; Fri, 25 Oct 2013 09:00:23 -0600 Received: from d03av02.boulder.ibm.com (localhost [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id r9PF0L3b022272 for ; Fri, 25 Oct 2013 09:00:22 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-41-17.mts.ibm.com [9.65.41.17]) by d03av02.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r9PF0I1Y021918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 09:00:19 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9PF0G08015228; Fri, 25 Oct 2013 11:00:16 -0400 Message-Id: <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> To: Ian Smith In-reply-to: <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com> Comments: In-reply-to Ian Smith message dated "Thu, 24 Oct 2013 20:21:12 -0000." Date: Fri, 25 Oct 2013 11:00:16 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102515-9332-0000-0000-000001ECAC03 Cc: nsc@ietf.org Subject: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:00:58 -0000 Hi Ian. Ian Smith writes: > The combination of ipip encapsulation, routing options, and > hop-by-hop options, as well as the opportunity to use locally > defined options, appears to satisfy every need statement on the > table. This is an assertion that the WG can work through. I personally don't believe HBH options are a panacea -- there are a number of reasons why they may not be a good choice -- but the WG can have a discussion about this where it looks at requirements and how well existing approaches address the requirements. Is your specific issue that this WG is not needed at all (because there are already solutions that work) or just that a new encapsulation is not needed, as existing ones are good enough? Thomas From narten@us.ibm.com Fri Oct 25 08:16:37 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7959511E8341 for ; Fri, 25 Oct 2013 08:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulUotiHKvzuq for ; Fri, 25 Oct 2013 08:16:27 -0700 (PDT) Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.153]) by ietfa.amsl.com (Postfix) with ESMTP id B151D11E81A1 for ; Fri, 25 Oct 2013 08:16:04 -0700 (PDT) Received: from /spool/local by e35.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Oct 2013 09:16:04 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e35.co.us.ibm.com (192.168.1.135) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 Oct 2013 09:16:02 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id A77DF3E40042 for ; Fri, 25 Oct 2013 09:16:01 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9PFG01S256062 for ; Fri, 25 Oct 2013 09:16:00 -0600 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 r9PFG0hQ020877 for ; Fri, 25 Oct 2013 09:16:00 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-41-17.mts.ibm.com [9.65.41.17]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r9PFFwND020815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Oct 2013 09:16:00 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9PFFwJ6017622 for ; Fri, 25 Oct 2013 11:15:58 -0400 Message-Id: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> From: Thomas Narten To: nsc@ietf.org Date: Fri, 25 Oct 2013 11:15:57 -0400 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102515-6688-0000-0000-000002DD62C4 Subject: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:16:37 -0000 The document draft-bitar-i2rs-service-chaining-00.txt gets into describing services in a very concrete way. E.g., they have names, they have properties/attributes, etc. Something like this is presumably needed by SFC if one has service functions scattered around the network that one wants to find dynamically. And when creating a service chain, one needs to match specific service function instances to specific flows. But that means we need a language of some sort for describing services - so that service requestors can be matched against service providers. That can only be done if services can be described in a machine readable way so that a service can advertise itself (exact details of service advertisement don't matter for this discussion) and that someone wanting a service can choose from advertised services to find the one they need. E.g, it's not enough to say "firewall". A FW may need to support particular rules or features -- and AFAICT, FWs are hardly standard, and different FWs support different sets of feaures. Question for this group: how much of the area of service representation does NSC need to tackle? Seems to me if the answer can't be "none" if we want interoperability, so something is needed. Note that this topic presumably overlaps with other work groups/areas, like I2RS, network management, etc. We presumably also want to leverage work done elsewhere where possible. But if there is nothing we can leverage, is there specific work that NSC (or some other group) will need to do regarding the representation of service functions? Thomas From I.Smith@F5.com Fri Oct 25 08:54:13 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5311E818E for ; Fri, 25 Oct 2013 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.453 X-Spam-Level: X-Spam-Status: No, score=-10.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chu4YR9+bt2R for ; Fri, 25 Oct 2013 08:54:08 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 46B6E11E8155 for ; Fri, 25 Oct 2013 08:54:08 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,571,1378857600"; d="scan'208";a="85235038" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 25 Oct 2013 15:54:08 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by SEAECAS04.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 08:54:07 -0700 From: Ian Smith To: Thomas Narten Thread-Topic: encap for SFC [was Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0ZL3SrKpq1ggSkOIwtIsJPxpfJoFi2Gp Date: Fri, 25 Oct 2013 15:54:05 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com>, <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> In-Reply-To: <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 15:54:13 -0000 My perception is that that is a foregone conclusion the working group shoul= d be chartered to create a new protocol and that seems premature. =0A= =0A= I do believe that there is work to be done in a working group, but that inf= ormational and cbp documents may be all that is required to solve the probl= em statements that I've seen put forth. Some have argued that a standard p= rotocol is required for interoperability, and I agree, but I contend that w= e ought to look at existing options before starting from scratch because it= will allow us to deliver faster and it makes for a simpler and more manage= able adoption. =0A= =0A= I'm open to the potential that new problem statements do arise that cannot = be solved sufficiently by using or extending existing standards to do that,= but I haven't seen them presented in any of the sfc drafts.=0A= =0A= The drafts are very casual in their dismissal of using existing protocols a= s part of the solution and they don't explain why enough to justify committ= ing to a new protocol in the charter, in my view.=0A= =0A= In particular, we already have a number of on-going efforts that are creati= ng new encapsulation protocols or methodologies and we have several existin= g encapsulation protocols that have already been standardized, so trying to= deal with non-standard encapsulation protocol proliferation by creating st= andardized encapsulation protocol proliferation seems foolish, particularly= when we've already delivered a road forward in IPv6, which for better or w= orse is the way forward. Both IPv6 and IPIP have extensibility built into = them if the current extension headers aren't sufficient.=0A= =0A= Of peripheral concern is the activity of those advocating for programmable,= elastic, and virtualized infrastructure as an operational and logistical m= ethodology and the amount of overlap those orchestration efforts have on th= is work, both in form and consumers; we could end up writing a new protocol= for nothing because a PEV infrastructure is doing everything that sfc is c= laiming needs to be done with dynamic configuration orchestration and the p= rospective customers have already solved their problem.=0A= =0A= =0A= ________________________________________=0A= From: Thomas Narten [narten@us.ibm.com]=0A= Sent: Friday, October 25, 2013 11:00 AM=0A= To: Ian Smith=0A= Cc: nsc@ietf.org=0A= Subject: encap for SFC [was Re: [nsc] New Version Notification for draft-du= nbar-sfc-legacy-l4-l7-chain-architecture-00.txt]=0A= =0A= Hi Ian.=0A= =0A= Ian Smith writes:=0A= =0A= > The combination of ipip encapsulation, routing options, and=0A= > hop-by-hop options, as well as the opportunity to use locally=0A= > defined options, appears to satisfy every need statement on the=0A= > table.=0A= =0A= This is an assertion that the WG can work through. I personally don't=0A= believe HBH options are a panacea -- there are a number of reasons why=0A= they may not be a good choice -- but the WG can have a discussion=0A= about this where it looks at requirements and how well existing=0A= approaches address the requirements.=0A= =0A= Is your specific issue that this WG is not needed at all (because=0A= there are already solutions that work) or just that a new=0A= encapsulation is not needed, as existing ones are good enough?=0A= =0A= Thomas=0A= =0A= From narten@us.ibm.com Fri Oct 25 09:11:28 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B913511E8381 for ; Fri, 25 Oct 2013 09:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qL6DGacZyXW7 for ; Fri, 25 Oct 2013 09:11:22 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by ietfa.amsl.com (Postfix) with ESMTP id 005F611E834C for ; Fri, 25 Oct 2013 09:11:21 -0700 (PDT) Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 25 Oct 2013 10:11:21 -0600 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 25 Oct 2013 10:11:20 -0600 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 608E63E40044 for ; Fri, 25 Oct 2013 10:11:19 -0600 (MDT) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9PGB79w082026 for ; Fri, 25 Oct 2013 10:11:13 -0600 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 r9PG9w6G020663 for ; Fri, 25 Oct 2013 10:09:58 -0600 Received: from cichlid.raleigh.ibm.com (sig-9-65-41-17.mts.ibm.com [9.65.41.17]) by d03av05.boulder.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id r9PG9voO020629 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 25 Oct 2013 10:09:58 -0600 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9PG9u8W026578 for ; Fri, 25 Oct 2013 12:09:56 -0400 Message-Id: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> From: Thomas Narten To: nsc@ietf.org Date: Fri, 25 Oct 2013 12:09:56 -0400 X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102516-0928-0000-0000-000002CA35DE Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:11:28 -0000 Hi. To date, one problem statement draft (draft-quinn-nsc-problem-statement-03.txt) has been produced for the SFC effort. It has served as the basis for both the current and prior BOF, and my read of the mailing list discussions suggests that folk seem generally OK with it. I have not seen fundamental disagreements with its content or calls for substantial additions. Any disagreement with this assessment? Assuming there is agreement with the above, and that a WG is formed, I would expect that: 1) we would formally adopt the document as a WG document in fairly short order and 2) close its contents in relatively short order and send to the IESG for publication. For most WGs, a problem statement is the highest priority work item to complete, as it sets the stage for all followup work. Also, if there are significant gaps or shortcomings in a problem statement, it tends to spell trouble for the WG as it starts doing work (it's hard to get agreement on solutions when there isn't really agreement on what the solution needs to actually do). Thus, complete the problem statement is a priority, and we want to get the contents right. So with that in mind, are there still substantive issues we need to work out in the problem statement? Or do people think it is in pretty good shape? What still needs to be added to the document? (These questions are aimed at both the list and the document authors...) Thomas From mn1921@att.com Fri Oct 25 10:43:27 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9920811E81B6 for ; Fri, 25 Oct 2013 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk7x+WEvQz-K for ; Fri, 25 Oct 2013 10:43:20 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id A202911E817B for ; Fri, 25 Oct 2013 10:43:20 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 8bdaa625.7ecfc940.5506316.00-541.15446125.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 25 Oct 2013 17:43:20 +0000 (UTC) X-MXL-Hash: 526aadb827478bc8-090fefbfe2ca5a4d5020c6a3509e253643c6ef74 Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 1bdaa625.0.5506252.00-497.15445937.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 25 Oct 2013 17:43:14 +0000 (UTC) X-MXL-Hash: 526aadb23ec09132-9e8d4ce0a558e6497f37a7a32eda356bcc07390f Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9PHhCiC022212; Fri, 25 Oct 2013 13:43:13 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9PHh3av022091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 13:43:08 -0400 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (MISOUT7MSGHUB9D.itservices.sbc.com [144.151.223.93]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Fri, 25 Oct 2013 17:42:55 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 13:42:55 -0400 From: "NAPIERALA, MARIA H" To: Ian Smith , Thomas Narten Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0Zp4fxPBT14daUWITaBEZdm0tpoFplsA Date: Fri, 25 Oct 2013 17:42:54 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012C424C@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com>, <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=cK5XRCiN c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=ceQ0FeSBR0wA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=SYW-wE-neswA:10 a=Jd6rssS-htTXJmIE-bIA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10] Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:43:27 -0000 > The drafts are very casual in their dismissal of using existing > protocols as part of the solution and they don't explain why enough to > justify committing to a new protocol in the charter, in my view. I tend to agree with this statement.=20 I would also add that this effort should separate signaling of metadata fro= m signaling of a service path. In TCP/IP stack there is a distinction betwe= en data/payload being transported and data used on the networking layer. So= , using the same header for metadata and path signaling is unusual and not = in common with IP protocols. There can be many ways to signal a path, hence= , tying together the metadata and path signaling is not a good idea, IMO. W= e should keep those two mechanisms independent. If we have the best path signaling protocol, we should be able to use not o= nly for services ;-)=20 From jguichar@cisco.com Fri Oct 25 11:28:07 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9368A11E81B4 for ; Fri, 25 Oct 2013 11:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.528 X-Spam-Level: X-Spam-Status: No, score=-10.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5nxydM0aybu for ; Fri, 25 Oct 2013 11:28:02 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 99DC311E81AB for ; Fri, 25 Oct 2013 11:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3061; q=dns/txt; s=iport; t=1382725682; x=1383935282; h=from:to:subject:date:message-id:mime-version; bh=meXts00vYEGoAdKrHjB+oKoUpK5JV1koAyfabglwXhg=; b=JnceI6qSE55RhcqbyAWVl2gvORdrDOABROUaRzCX7GWtUqJKkg0W6TS5 epkdgMr8MEKnD9sUiXIZI/jRaTtFAN7BSaAjjRK6pn8rh9vIHnlkdVCqZ VRoYJttAOYHfs1QWqU0z811YtpAk/gsGe8nbI+BTB5eGs4b2EOSM3qIvM U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUHAE+3alKtJV2Z/2dsb2JhbABZgkNEOFSsHIlmiEeBIhZtB4InAQQnRx0BDB5WJwQbh38NmAGhU48ig1eBDQOZOZBYgyaCKg X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208,217";a="276764260" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 25 Oct 2013 18:27:56 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9PIRruk016184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 25 Oct 2013 18:27:53 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 13:27:53 -0500 From: "Jim Guichard (jguichar)" To: "nsc@ietf.org" Thread-Topic: SFC WG charter Thread-Index: AQHO0a/qaKCM55gkbUC6qVHLV+RQPQ== Date: Fri, 25 Oct 2013 18:27:53 +0000 Message-ID: <68B171751455884590F8E38E96416F363F70B35B@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: multipart/alternative; boundary="_000_68B171751455884590F8E38E96416F363F70B35Bxmbrcdx01ciscoc_" MIME-Version: 1.0 Subject: [nsc] SFC WG charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:28:07 -0000 --_000_68B171751455884590F8E38E96416F363F70B35Bxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greetings, As we get closer to the SFC BOF in Vancouver I would like to solicit any ad= ditional feedback on the SFC charter. The charter has been discussed at length on the mailing list and the curren= t version may be found here -> http://datatracker.ietf.org/wg/sfc/charter/. Assuming that a WG is formed, I believe that we have a reasonably solid cha= rter that will produce a set of work items for the new WG. Any disagreement= with this assessment? Does anyone believe the charter is missing any subst= antial items that the WG should be addressing, or contains items that shoul= d not be in scope for the WG? Jim --_000_68B171751455884590F8E38E96416F363F70B35Bxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <9ABEE8F65A1FB2409DC0FC110F79F079@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Greetings,

As we get closer to the SFC BOF in Vancouver I would like to solicit any ad= ditional feedback on the SFC charter. 

The charter has been discussed at length on the mailing list and the curren= t version may be found here -> http://datatracker.ietf.org/wg/sfc/charter/. 

Assuming that a WG= is formed, I believe that we have a reasonably solid charter that will pro= duce a set of work items for the new WG. Any disagreement with this assessment? Does anyone believe the charter is = missing any substantial items that the WG should be addressing, or contains= items that should not be in scope for the WG?

Jim<= /div> --_000_68B171751455884590F8E38E96416F363F70B35Bxmbrcdx01ciscoc_-- From kgray@juniper.net Fri Oct 25 12:03:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7811E81F3 for ; Fri, 25 Oct 2013 12:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.52 X-Spam-Level: X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=-0.921, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQsT0zg4fWtI for ; Fri, 25 Oct 2013 12:03:34 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0185.outbound.messaging.microsoft.com [213.199.154.185]) by ietfa.amsl.com (Postfix) with ESMTP id 92DD511E83CA for ; Fri, 25 Oct 2013 12:03:03 -0700 (PDT) Received: from mail117-db8-R.bigfish.com (10.174.8.237) by DB8EHSOBE012.bigfish.com (10.174.4.75) with Microsoft SMTP Server id 14.1.225.22; Fri, 25 Oct 2013 19:03:01 +0000 Received: from mail117-db8 (localhost [127.0.0.1]) by mail117-db8-R.bigfish.com (Postfix) with ESMTP id D28463C00A5; Fri, 25 Oct 2013 19:03:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) Received-SPF: pass (mail117-db8: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(24454002)(377454003)(479174003)(74502001)(53806001)(79102001)(54356001)(63696002)(65816001)(80022001)(74366001)(47446002)(74662001)(47736001)(49866001)(47976001)(76176001)(50986001)(81686001)(81816001)(54316002)(76796001)(76786001)(56816003)(56776001)(77096001)(76482001)(4396001)(69226001)(19580395003)(19580405001)(83322001)(81542001)(81342001)(36756003)(59766001)(80976001)(85306002)(77982001)(31966008)(46102001)(74706001)(83072001)(74876001)(83506001)(51856001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB089; H:BN1PR05MB089.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail117-db8 (localhost.localdomain [127.0.0.1]) by mail117-db8 (MessageSwitch) id 1382727769167699_12657; Fri, 25 Oct 2013 19:02:49 +0000 (UTC) Received: from DB8EHSMHS017.bigfish.com (unknown [10.174.8.239]) by mail117-db8.bigfish.com (Postfix) with ESMTP id 2509532037C; Fri, 25 Oct 2013 19:02:49 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by DB8EHSMHS017.bigfish.com (10.174.4.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 25 Oct 2013 19:02:48 +0000 Received: from BN1PR05MB089.namprd05.prod.outlook.com (10.255.199.14) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.371.2; Fri, 25 Oct 2013 19:02:48 +0000 Received: from BN1PR05MB089.namprd05.prod.outlook.com (10.255.199.14) by BN1PR05MB089.namprd05.prod.outlook.com (10.255.199.14) with Microsoft SMTP Server (TLS) id 15.0.800.7; Fri, 25 Oct 2013 19:02:47 +0000 Received: from BN1PR05MB089.namprd05.prod.outlook.com ([169.254.12.146]) by BN1PR05MB089.namprd05.prod.outlook.com ([169.254.12.45]) with mapi id 15.00.0800.005; Fri, 25 Oct 2013 19:02:47 +0000 From: Ken Gray To: "NAPIERALA, MARIA H" , Ian Smith , Thomas Narten Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0Zp/CDfe0/hJZU+CByGGqiQ815oFsA8A///TOwA= Date: Fri, 25 Oct 2013 19:02:47 +0000 Message-ID: In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012C424C@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 0010D93EFE Content-Type: text/plain; charset="us-ascii" Content-ID: <2916CAA39765EE46A28187100E47BA6F@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:03:38 -0000 I think I've already commented that we shouldn't be making blanket assumptions that what we have now works "best". The problem statement is relatively generic. There are no real standards for swathes of NFV/NSC/SFC. I don't know anyone disagreeing with that. I don't think the statement contains anything about there not being implementations or methods that work. Even though solutions might exist (and I don't know one that doesn't claim to be based on a standard ...or at least the draft of a standard) they're hardly universal - they are either domain specific or network architecture specific. Examples: You probably think policy and diameter are just groovy for this application if you work in mobility - you probably don't if these have stuff you don't think you need for your application and have some other favorite. =20 You might think IF-MAP is groovy if you're working with security (and maybe it has use in metadata passing in your architecture as well) - a lot of people don't use IF-MAP and think Yang is better for creating info/data models because it's more extensible and universal. You might think extending a protocol you understand really, really well (and have build YOUR network on) by giving its existing bits overloaded meaning or adding new bits to it is a groovy idea too - and somebody else might think that either that protocol is already expensive to maintain in the human capital they have to hire or already overloaded with too many meanings and want a simpler method. In fact, by merely pointing at all of these possibilities - you can see why we're here. =20 On 10/25/13 1:42 PM, "NAPIERALA, MARIA H" wrote: >> The drafts are very casual in their dismissal of using existing >> protocols as part of the solution and they don't explain why enough to >> justify committing to a new protocol in the charter, in my view. > >I tend to agree with this statement. > >I would also add that this effort should separate signaling of metadata >from signaling of a service path. In TCP/IP stack there is a distinction >between data/payload being transported and data used on the networking >layer. So, using the same header for metadata and path signaling is >unusual and not in common with IP protocols. There can be many ways to >signal a path, hence, tying together the metadata and path signaling is >not a good idea, IMO. We should keep those two mechanisms independent. >If we have the best path signaling protocol, we should be able to use not >only for services ;-) >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From smkumar@cisco.com Fri Oct 25 12:11:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2BE11E81C5 for ; Fri, 25 Oct 2013 12:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZnl7XxxVuYl for ; Fri, 25 Oct 2013 12:11:41 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 348C511E8198 for ; Fri, 25 Oct 2013 12:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1702; q=dns/txt; s=iport; t=1382728301; x=1383937901; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=RdByINpU/MMJZzzbXXWmMT3P4OTDEeapu8jN7w+ePzA=; b=bJc9QY2D5ecD09pIagK1dg6SbrdxpcIZCeqdoS865AUX5wmZLshs+pEH UE//6bHfMYQGCnWcavK+bePIChVyC/YUTqiP1TSB7CuUXf1T1q5beoqO5 mSTGZncuyyGL5/+ho9H4L92FxL66LQSRSoslkLc0Z8/rWXm88iqIKuLs9 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACjBalKtJXG//2dsb2JhbABTBoMHOFS+SYEiFnSCJQEBAQMBAQEBNzQJAhIBCBIQFAUyCxcOAgQBDQUIE4dmBg25UgSOJnwxB4MfgQ0DqhGBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276770643" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 19:11:40 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9PJBem6021016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 19:11:40 GMT Received: from xmb-aln-x09.cisco.com ([169.254.4.202]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 14:11:40 -0500 From: "Surendra Kumar (smkumar)" To: "NAPIERALA, MARIA H" , Ian Smith , "Thomas Narten" Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0Zp4uvJpPjggoU+fIz4kYGyHg5oGA+AA//+jcgA= Date: Fri, 25 Oct 2013 19:11:39 +0000 Message-ID: <8E86B6E7C6FB9F40A00B0E269045A7C9211AC240@xmb-aln-x09.cisco.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012C424C@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.155.164.145] Content-Type: text/plain; charset="us-ascii" Content-ID: <7BEE691B3E5CB74C9A310121F010041B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:11:48 -0000 On 10/25/13 10:42 AM, "NAPIERALA, MARIA H" wrote: >> The drafts are very casual in their dismissal of using existing >> protocols as part of the solution and they don't explain why enough to >> justify committing to a new protocol in the charter, in my view. > >I tend to agree with this statement. > >I would also add that this effort should separate signaling of metadata >from signaling of a service path. In TCP/IP stack there is a distinction >between data/payload being transported and data used on the networking >layer. So, using the same header for metadata and path signaling is >unusual and not in common with IP protocols. There can be many ways to >signal a path, hence, tying together the metadata and path signaling is >not a good idea, IMO. We should keep those two mechanisms independent. >If we have the best path signaling protocol, we should be able to use not >only for services ;-) I disagree with this analogy. Service path is identifying a certain forwarding path because of additionally intelligence by way of policy. The same policy could also specify metadata or metadata may be derived as a result of the policy application. This metadata is meaningful in the context of that service path and hence it makes sense to carry them together. While path+metadata are related to the actual data, is still a separate from it. In this sense, the entire original data (frame/packet being serviced) becomes payload and is still distinct from the service header - consist with the norm. Surendra. >=20 >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From mn1921@att.com Fri Oct 25 12:15:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1786011E813A for ; Fri, 25 Oct 2013 12:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHSd+s5g8gHT for ; Fri, 25 Oct 2013 12:15:24 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id EF04311E81B6 for ; Fri, 25 Oct 2013 12:15:17 -0700 (PDT) Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 443ca625.0.313729.00-359.897250.nbfkord-smmo07.seg.att.com (envelope-from ); Fri, 25 Oct 2013 19:15:17 +0000 (UTC) X-MXL-Hash: 526ac3453e716fd5-f465fa68dff0a95dfa6f433739bf25c14bcd2370 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9PJFGvd001473; Fri, 25 Oct 2013 15:15:16 -0400 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id r9PJF6mE001242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Oct 2013 15:15:09 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Fri, 25 Oct 2013 19:14:54 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 15:14:54 -0400 From: "NAPIERALA, MARIA H" To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzhNMw/ImQFzEyJJMdohEG2WpoFyWIg Date: Fri, 25 Oct 2013 19:14:53 +0000 Message-ID: <1D70D757A2C9D54D83B4CBD7625FA80E012C44F2@MISOUT7MSGUSR9I.ITServices.sbc.com> References: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> In-Reply-To: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=YJEoP26x c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=-s3I2kwCOWQA:10 a=U7eYCuE-jJoA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=mQFj4zS2cDwA:10 a=48vgC7mUAAAA:8 a=whQTSwouRIZw5s] X-AnalysisOut: [BCgKgA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=qOEZP2EvBHs] X-AnalysisOut: [w8eQr:21 a=3AEnSLpjxDx1cnpE:21] Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:15:32 -0000 Tom, I have few questions on this draft: Section 1.1.: "Service Chain: A service chain defines the required functions and associated order (service-function1 --> service-function 2) that must be applied to packets and/or frames. A service chain does not specify the network location or specific instance of service functions (e.g. firewall1 vs. firewall2)." What does "specific instance of service function" means in this context?=20 Section 3: "Service Overlay: Service chaining utilizes a service specific overlay that creates the service topology: the overlay creates a path between service nodes. The service overlay is independent of the network topology and allows operators to use whatever overlay or underlay they prefer and to locate service functions in the network as needed." This is not a clear definition of a "service overlay". It just refers to a = "path" but does not define it. Section 5: "L3VPN[L3VPN]: The L3VPN working group is responsible for defining, specifying and extending BGP/MPLS IP VPNs solutions. Although BGP/MPLS IP VPNs can be used as transport for service chaining deployments, the service chaining WG focuses on the service specific protocols, not the general case of VPNs. Furthermore, BGP/MPLS IP VPNs do not address the requirements for service chaining." What are the "service specific protocols"? draft-filsfils-rtgwg-segment-routing has a section on "Service Segments". = Is there any relation to this work?=20 Maria > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, October 25, 2013 12:10 PM > To: nsc@ietf.org > Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement >=20 > Hi. >=20 > To date, one problem statement draft > (draft-quinn-nsc-problem-statement-03.txt) has been produced for the > SFC effort. >=20 > It has served as the basis for both the current and prior BOF, and my > read of the mailing list discussions suggests that folk seem generally > OK with it. I have not seen fundamental disagreements with its content > or calls for substantial additions. >=20 > Any disagreement with this assessment? >=20 > Assuming there is agreement with the above, and that a WG is formed, I > would expect that: >=20 > 1) we would formally adopt the document as a WG document in fairly > short order and >=20 > 2) close its contents in relatively short order and send to the IESG > for publication. >=20 > For most WGs, a problem statement is the highest priority work item to > complete, as it sets the stage for all followup work. Also, if there > are significant gaps or shortcomings in a problem statement, it tends > to spell trouble for the WG as it starts doing work (it's hard to get > agreement on solutions when there isn't really agreement on what the > solution needs to actually do). Thus, complete the problem > statement is a priority, and we want to get the contents right. >=20 > So with that in mind, are there still substantive issues we need to > work out in the problem statement? Or do people think it is in pretty > good shape? What still needs to be added to the document? (These > questions are aimed at both the list and the document authors...) >=20 > Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Fri Oct 25 12:22:38 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC211E810C for ; Fri, 25 Oct 2013 12:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.414 X-Spam-Level: X-Spam-Status: No, score=-10.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwZNADs6mhgo for ; Fri, 25 Oct 2013 12:22:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1D78311E81AB for ; Fri, 25 Oct 2013 12:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3687; q=dns/txt; s=iport; t=1382728953; x=1383938553; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=fxnkF+fzyqM5+cvCB1U8AakZjMdDbKXn9GwaYbax29c=; b=TzKUg+ejFkBPFPWVCgyP2ySvFdiPqnDcDjqomskuJa2H4BzuaHo48RmH cNtOcY7jlEfIzdjR01KpEWhVdnPvyeN7+GozU92HyKAA2nF21ISd7mNwr 7XyQXFWNvQwf2D1GNOnX5F6B9AUA0vT11G7dPbxcRYVuAyaVopXD36mFl w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAL3DalKtJV2b/2dsb2JhbABTBoMHOFS+SYEiFnSCJQEBAQQBAQE3NAkCEgEIDgQGChQFMgsXDgIEAQ0FCBOHbA25WASOJnwxB4MfgQ0DqhGBaIE+gio X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276774533" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 19:22:32 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9PJMWNV007098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 19:22:32 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 14:22:32 -0500 From: "Jim Guichard (jguichar)" To: Ken Gray , "NAPIERALA, MARIA H" , "Ian Smith" , Thomas Narten Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0Zp44oDfIyWcDUSA2GTHlDYwiZoGA+AAgAAWUoD//8JzgA== Date: Fri, 25 Oct 2013 19:22:31 +0000 Message-ID: <68B171751455884590F8E38E96416F363F70B4D7@xmb-rcd-x01.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: <092CD05C1E444042A06DF297CB2D828C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 19:22:38 -0000 While I appreciate this discussion and there are certainly a number of differing opinions on whats "best" in terms of encapsulations, extending existing or adding new protocols, etc etc, I do not think we need reconcile all viewpoints prior to formation of the WG, or get bogged down in the intricacies of individual solutions or draft submissions. Right now we are working on chartering the WG and ironing out any kinks in the problem statement and/or charter. Once the WG is formed we will have plenty of opportunities to debate; indeed, part of our job will be to reconcile and debate differing opinions and solutions. So for now, let me respectfully ask that we focus on the charter and problem statement. On 10/25/13 3:02 PM, "Ken Gray" wrote: >I think I've already commented that we shouldn't be making blanket >assumptions that what we have now works "best". > >The problem statement is relatively generic. There are no real standards >for swathes of NFV/NSC/SFC. I don't know anyone disagreeing with that. I >don't think the statement contains anything about there not being >implementations or methods that work. > >Even though solutions might exist (and I don't know one that doesn't claim >to be based on a standard ...or at least the draft of a standard) they're >hardly universal - they are either domain specific or network architecture >specific. > >Examples: > >You probably think policy and diameter are just groovy for this >application if you work in mobility - you probably don't if these have >stuff you don't think you need for your application and have some other >favorite. =20 > >You might think IF-MAP is groovy if you're working with security (and >maybe it has use in metadata passing in your architecture as well) - a lot >of people don't use IF-MAP and think Yang is better for creating info/data >models because it's more extensible and universal. > >You might think extending a protocol you understand really, really well >(and have build YOUR network on) by giving its existing bits overloaded >meaning or adding new bits to it is a groovy idea too - and somebody else >might think that either that protocol is already expensive to maintain in >the human capital they have to hire or already overloaded with too many >meanings and want a simpler method. > >In fact, by merely pointing at all of these possibilities - you can see >why we're here. =20 > >On 10/25/13 1:42 PM, "NAPIERALA, MARIA H" wrote: > >>> The drafts are very casual in their dismissal of using existing >>> protocols as part of the solution and they don't explain why enough to >>> justify committing to a new protocol in the charter, in my view. >> >>I tend to agree with this statement. >> >>I would also add that this effort should separate signaling of metadata >>from signaling of a service path. In TCP/IP stack there is a distinction >>between data/payload being transported and data used on the networking >>layer. So, using the same header for metadata and path signaling is >>unusual and not in common with IP protocols. There can be many ways to >>signal a path, hence, tying together the metadata and path signaling is >>not a good idea, IMO. We should keep those two mechanisms independent. >>If we have the best path signaling protocol, we should be able to use not >>only for services ;-) >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc >> >> > > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From jguichar@cisco.com Fri Oct 25 13:32:04 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B50511E8152 for ; Fri, 25 Oct 2013 13:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKTXnWRrDPZE for ; Fri, 25 Oct 2013 13:31:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DABAA11E81E0 for ; Fri, 25 Oct 2013 13:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1889; q=dns/txt; s=iport; t=1382733113; x=1383942713; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=fsnhh+G8+3p57llIbL91JYok7+y5xU2ejgA2m0qOFI0=; b=dBSAPhOuFHAilhCSYx9vi8x4H1AzDQfURypenpLPoWI41Yt9fwrOFy9u pbUi4VxkpmByvboRH0HbDe+SPZtVgV1YPgXg069gGX308WvHkrA7A6KIS PW6sE21wm8inTkP0TJjZuFW1jdsMkci6YnseZ6OXfY8JNpM7wluOB2byd 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFABfUalKtJXHB/2dsb2JhbABZgwc4VL5IgSMWdIInAQQBAQE3NAYXAQgiFDcLJQIEARIIE4dsDbk9jyI4gx+BDQOUKoUPkFiDJoIq X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276809382" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Oct 2013 20:31:52 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r9PKVn0f009995 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 20:31:49 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 15:31:49 -0500 From: "Jim Guichard (jguichar)" To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzfI8kI/VXD7k2owsnIhDoXyJoF7/2A Date: Fri, 25 Oct 2013 20:31:49 +0000 Message-ID: <68B171751455884590F8E38E96416F363F70B5E7@xmb-rcd-x01.cisco.com> In-Reply-To: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:32:04 -0000 Quick clarification: Draft-quinn-nsc-problem-statement-03 was replaced by http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please refer to this version if commenting. On 10/25/13 12:09 PM, "Thomas Narten" wrote: >Hi. > >To date, one problem statement draft >(draft-quinn-nsc-problem-statement-03.txt) has been produced for the >SFC effort. > >It has served as the basis for both the current and prior BOF, and my >read of the mailing list discussions suggests that folk seem generally >OK with it. I have not seen fundamental disagreements with its content >or calls for substantial additions. > >Any disagreement with this assessment? > >Assuming there is agreement with the above, and that a WG is formed, I >would expect that: > >1) we would formally adopt the document as a WG document in fairly >short order and > >2) close its contents in relatively short order and send to the IESG >for publication. > >For most WGs, a problem statement is the highest priority work item to >complete, as it sets the stage for all followup work. Also, if there >are significant gaps or shortcomings in a problem statement, it tends >to spell trouble for the WG as it starts doing work (it's hard to get >agreement on solutions when there isn't really agreement on what the >solution needs to actually do). Thus, complete the problem >statement is a priority, and we want to get the contents right. > >So with that in mind, are there still substantive issues we need to >work out in the problem statement? Or do people think it is in pretty >good shape? What still needs to be added to the document? (These >questions are aimed at both the list and the document authors...) > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc From paulq@cisco.com Fri Oct 25 13:33:59 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CEB11E8194 for ; Fri, 25 Oct 2013 13:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.576 X-Spam-Level: X-Spam-Status: No, score=-10.576 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exs9+bvvGvEb for ; Fri, 25 Oct 2013 13:33:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4209F11E81DC for ; Fri, 25 Oct 2013 13:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2410; q=dns/txt; s=iport; t=1382733233; x=1383942833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CAyT+kTrkTpAOZUbL8WHmzGDW/21e0MEHelMbFQmXv4=; b=lAgTfvOPcnEPv0IM7RSgLuagBKq/JJyb6BcYPeAzezZjmygvOJyik7vB YkcFHNqQUxaNQPgNxg0X5pJ2JmwpqkLk1ZSxeUkoHH3i6LlkX5zYpUjvJ qgOnEvkj9L+GjLQymr/mvV5qNW8apiJqpTBEuOm/MAAJVudX6Tfdgdiqo 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAJvUalKtJXHA/2dsb2JhbABZgwc4SAy+SIEjFnSCJQEBAQMBAQEBNzQGBQULAgEIGAoUECcLJQIEDgUIE4dmBg25P48gAjEHgx+BDQOUKoUPkFiDJoIq X-IronPort-AV: E=Sophos;i="4.93,572,1378857600"; d="scan'208";a="276788255" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 25 Oct 2013 20:33:52 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9PKXqRK004834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 Oct 2013 20:33:52 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 25 Oct 2013 15:33:51 -0500 From: "Paul Quinn (paulq)" To: "Jim Guichard (jguichar)" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzfrvjQdK/P3UmXhAsUEPLW+poGMw6AgAAAngA= Date: Fri, 25 Oct 2013 20:33:51 +0000 Message-ID: References: <68B171751455884590F8E38E96416F363F70B5E7@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F70B5E7@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <6C24A34788F9BC4193F0A64B76F0E4B9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:33:59 -0000 Thanks Jim. One extra note: we'll post an "edited" version with editors an= d contributors (in lieu of the long author list) once submission open again= . Paul On Oct 25, 2013, at 1:31 PM, "Jim Guichard (jguichar)" wrote: > Quick clarification: >=20 > Draft-quinn-nsc-problem-statement-03 was replaced by > http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please > refer to this version if commenting. >=20 > On 10/25/13 12:09 PM, "Thomas Narten" wrote: >=20 >> Hi. >>=20 >> To date, one problem statement draft >> (draft-quinn-nsc-problem-statement-03.txt) has been produced for the >> SFC effort. >>=20 >> It has served as the basis for both the current and prior BOF, and my >> read of the mailing list discussions suggests that folk seem generally >> OK with it. I have not seen fundamental disagreements with its content >> or calls for substantial additions. >>=20 >> Any disagreement with this assessment? >>=20 >> Assuming there is agreement with the above, and that a WG is formed, I >> would expect that: >>=20 >> 1) we would formally adopt the document as a WG document in fairly >> short order and >>=20 >> 2) close its contents in relatively short order and send to the IESG >> for publication. >>=20 >> For most WGs, a problem statement is the highest priority work item to >> complete, as it sets the stage for all followup work. Also, if there >> are significant gaps or shortcomings in a problem statement, it tends >> to spell trouble for the WG as it starts doing work (it's hard to get >> agreement on solutions when there isn't really agreement on what the >> solution needs to actually do). Thus, complete the problem >> statement is a priority, and we want to get the contents right. >>=20 >> So with that in mind, are there still substantive issues we need to >> work out in the problem statement? Or do people think it is in pretty >> good shape? What still needs to be added to the document? (These >> questions are aimed at both the list and the document authors...) >>=20 >> Thomas >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Fri Oct 25 13:38:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F57411E8200 for ; Fri, 25 Oct 2013 13:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGWqe8eWXvmE for ; Fri, 25 Oct 2013 13:37:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ACA1411E8190 for ; Fri, 25 Oct 2013 13:37:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZL93514; Fri, 25 Oct 2013 20:37:54 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 21:37:47 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 25 Oct 2013 21:37:54 +0100 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Fri, 25 Oct 2013 13:37:46 -0700 From: Linda Dunbar To: "Jim Guichard (jguichar)" , Linda Dunbar , Sumandra Majee , Ron Parker , "nsc@ietf.org" Thread-Topic: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt Thread-Index: AQHO0D7SNf/CZ5QE9EyYtVfHaKGq/ZoC3t/QgAB8bYD//4uYIIAAeQwAgAI+cxA= Date: Fri, 25 Oct 2013 20:37:46 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BE9DA2@dfweml509-mbb.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F645BE7CA2@dfweml509-mbb.china.huawei.com> <68B171751455884590F8E38E96416F363F7082D0@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F7082D0@xmb-rcd-x01.cisco.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.132.95] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Donald Eastlake , Ian Smith , Ning So Subject: Re: [nsc] New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:38:03 -0000 Jim,=20 > -----Original Message----- >=20 > That's an implementation detail and not a requirement of the > architecture; [Linda] Architecturally, there is a proxy node, who doesn't have to know th= e underlay network topology, whose primary job is to steer traffic to the s= ervice functions connected based on some header fields/bits in the packets,= and/or policies from external entity (e.g. classification nodes, or contro= ller).=20 Whether this "proxy node" is a standalone device, or embedded in a router c= an be an implementation issue.=20 Linda > it is unnecessary in my opinion to assume that the proxy component is > independent of the forwarding component. >=20 > On 10/23/13 7:06 PM, "Linda Dunbar" wrote: >=20 > >Jim > > > >> -----Original Message----- > >> > >> Linda, > >> That may or may not be a valid assumption. While it is true that > some > >> proxies may rely upon an upstream node to perform packet forwarding > >> into > >> the underlay on their behalf (think TOR), it is also true that the > >> proxy > >> may simply have that capability itself (think router). > > > >[Linda] Then there are (at least) two components on this "router": > proxy > >for service functions and the routing for the underlay networks. > > > >The "proxy component" don't know the underlay network. It is like > having > >service functions embedded in a router. > >The service functions don't know the underlay network. > > > >Linda > > > >_______________________________________________ > >nsc mailing list > >nsc@ietf.org > >https://www.ietf.org/mailman/listinfo/nsc From diego@tid.es Fri Oct 25 16:34:21 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136D911E81DF for ; Fri, 25 Oct 2013 16:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3q+ZsfSsFWD for ; Fri, 25 Oct 2013 16:34:17 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 885AB11E81C7 for ; Fri, 25 Oct 2013 16:34:16 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MV9000P705368@tid.hi.inet> for nsc@ietf.org; Sat, 26 Oct 2013 01:34:15 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 93.B9.28420.7FFFA625; Sat, 26 Oct 2013 01:34:15 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MV9000P305268@tid.hi.inet> for nsc@ietf.org; Sat, 26 Oct 2013 01:34:15 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS6-MAD.hi.inet ([::1]) with mapi id 14.03.0123.003; Sat, 26 Oct 2013 01:34:14 +0200 Date: Fri, 25 Oct 2013 23:34:13 +0000 From: "Diego R. Lopez" In-reply-to: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> X-Originating-IP: [10.95.64.115] To: Thomas Narten Message-id: <6592A442-3FA7-495F-8CEC-443CC3C7AF0C@tid.es> Content-id: <4A1D0B39A2790D40AD812385C886E369@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [nsc] Representations of services Thread-index: AQHO0ZU56hjR22vSAkKt2bmJ4zOokZoF4w0A X-AuditID: 0a5f4e69-b7fe58e000006f04-59-526afff79115 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42Lhivcz1P3+PyvI4N4RHovj+/azOTB6LFny kymAMYrLJiU1J7MstUjfLoErY/X1ZqaCTTIVVz+8Z25gvCLdxcjJISFgIrF7+zkWCFtM4sK9 9WxdjFwcQgLbGSUu/jrCCuF8Z5S48OwwO4Qzk1HiR18DWAuLgKpE6/KJbCA2G5D9qPk3O4gt LKAnMfHSHlYQm1PASaL51xeoFQoSf849BrNFgOovXOwHq2cWUJZ4fvwXWJxXwFKi69FuFoi4 mcTsNe9ZIeKCEj8m3wOKcwDF1SWmTMmFKBGXaG69CVWuKDFtUQMjiM0oICvxbv58VohV+hJb /j5kBGkVETCSONehDnGNgMSSPeeZIWxRiZeP/4GVCwk4SkxevplpAqPELCRHzEJyxCyEI2Yh OWIWkiMWMLKuYhQrTirKTM8oyU3MzEk3MNLLyNTLzEst2cQIibnMHYzLd6ocYhTgYFTi4W2Y mhUkxJpYVlyZe4hRgoNZSYR39Q+gEG9KYmVValF+fFFpTmrxIUYmDk6pBsYjUjJtkqsP/Ju5 /+yfResWzciOjbX59n7Psx08W/7YvOfgi2HLOJhcfDn57bfj01p+dotPTEm6fWp++6m5Finu PzLPX/xcGSoS8uBA5a/VJ/ydYnnDHvzJVM15wexy/f6m9/zCQac6xU5flfkeomnwN2N/wdKT T2Zpfsy4lZ/38nJ95dNPlY5LlViKMxINtZiLihMBw9ArgZcCAAA= References: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> Cc: "" Subject: Re: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:34:21 -0000 SGkgVG9tLA0KDQpDYW5ub3QgYWdyZWUgbW9yZS4gSW4gbXkgbWluZCwgc2VydmljZSBtZXRhZGF0 YSBhbmQgdGhlIG1lY2hhbmlzbXMgZm9yIGhpcyBhbm5vdW5jZW1lbnQgaGF2ZSBhbHdheXMgYmVl biBhbW9uZyB0aGUgZ29hbHMgb2YgdGhlIGdyb3VwLi4uDQoNCkJlIGdvb2RlLA0KDQpPbiAyNSBP Y3QgMjAxMywgYXQgMTc6MTUgLCBUaG9tYXMgTmFydGVuIHdyb3RlOg0KDQo+IFRoZSBkb2N1bWVu dCBkcmFmdC1iaXRhci1pMnJzLXNlcnZpY2UtY2hhaW5pbmctMDAudHh0IGdldHMgaW50bw0KPiBk ZXNjcmliaW5nIHNlcnZpY2VzIGluIGEgdmVyeSBjb25jcmV0ZSB3YXkuIEUuZy4sIHRoZXkgaGF2 ZSBuYW1lcywNCj4gdGhleSBoYXZlIHByb3BlcnRpZXMvYXR0cmlidXRlcywgZXRjLg0KPg0KPiBT b21ldGhpbmcgbGlrZSB0aGlzIGlzIHByZXN1bWFibHkgbmVlZGVkIGJ5IFNGQyBpZiBvbmUgaGFz IHNlcnZpY2UNCj4gZnVuY3Rpb25zIHNjYXR0ZXJlZCBhcm91bmQgdGhlIG5ldHdvcmsgdGhhdCBv bmUgd2FudHMgdG8gZmluZA0KPiBkeW5hbWljYWxseS4gQW5kIHdoZW4gY3JlYXRpbmcgYSBzZXJ2 aWNlIGNoYWluLCBvbmUgbmVlZHMgdG8gbWF0Y2gNCj4gc3BlY2lmaWMgc2VydmljZSBmdW5jdGlv biBpbnN0YW5jZXMgdG8gc3BlY2lmaWMgZmxvd3MuIEJ1dCB0aGF0IG1lYW5zDQo+IHdlIG5lZWQg YSBsYW5ndWFnZSBvZiBzb21lIHNvcnQgZm9yIGRlc2NyaWJpbmcgc2VydmljZXMgLSBzbyB0aGF0 DQo+IHNlcnZpY2UgcmVxdWVzdG9ycyBjYW4gYmUgbWF0Y2hlZCBhZ2FpbnN0IHNlcnZpY2UgcHJv dmlkZXJzLiAgVGhhdCBjYW4NCj4gb25seSBiZSBkb25lIGlmIHNlcnZpY2VzIGNhbiBiZSBkZXNj cmliZWQgaW4gYSBtYWNoaW5lIHJlYWRhYmxlIHdheSBzbw0KPiB0aGF0IGEgc2VydmljZSBjYW4g YWR2ZXJ0aXNlIGl0c2VsZiAoZXhhY3QgZGV0YWlscyBvZiBzZXJ2aWNlDQo+IGFkdmVydGlzZW1l bnQgZG9uJ3QgbWF0dGVyIGZvciB0aGlzIGRpc2N1c3Npb24pIGFuZCB0aGF0IHNvbWVvbmUNCj4g d2FudGluZyBhIHNlcnZpY2UgY2FuIGNob29zZSBmcm9tIGFkdmVydGlzZWQgc2VydmljZXMgdG8g ZmluZCB0aGUgb25lDQo+IHRoZXkgbmVlZC4NCj4NCj4gRS5nLCBpdCdzIG5vdCBlbm91Z2ggdG8g c2F5ICJmaXJld2FsbCIuIEEgRlcgbWF5IG5lZWQgdG8gc3VwcG9ydA0KPiBwYXJ0aWN1bGFyIHJ1 bGVzIG9yIGZlYXR1cmVzIC0tIGFuZCBBRkFJQ1QsIEZXcyBhcmUgaGFyZGx5IHN0YW5kYXJkLA0K PiBhbmQgZGlmZmVyZW50IEZXcyBzdXBwb3J0IGRpZmZlcmVudCBzZXRzIG9mIGZlYXVyZXMuDQo+ DQo+IFF1ZXN0aW9uIGZvciB0aGlzIGdyb3VwOiBob3cgbXVjaCBvZiB0aGUgYXJlYSBvZiBzZXJ2 aWNlDQo+IHJlcHJlc2VudGF0aW9uIGRvZXMgTlNDIG5lZWQgdG8gdGFja2xlPyBTZWVtcyB0byBt ZSBpZiB0aGUgYW5zd2VyDQo+IGNhbid0IGJlICJub25lIiBpZiB3ZSB3YW50IGludGVyb3BlcmFi aWxpdHksIHNvIHNvbWV0aGluZyBpcw0KPiBuZWVkZWQuDQo+DQo+IE5vdGUgdGhhdCB0aGlzIHRv cGljIHByZXN1bWFibHkgb3ZlcmxhcHMgd2l0aCBvdGhlciB3b3JrIGdyb3Vwcy9hcmVhcywNCj4g bGlrZSBJMlJTLCBuZXR3b3JrIG1hbmFnZW1lbnQsIGV0Yy4NCj4NCj4gV2UgcHJlc3VtYWJseSBh bHNvIHdhbnQgdG8gbGV2ZXJhZ2Ugd29yayBkb25lIGVsc2V3aGVyZSB3aGVyZQ0KPiBwb3NzaWJs ZS4gQnV0IGlmIHRoZXJlIGlzIG5vdGhpbmcgd2UgY2FuIGxldmVyYWdlLCBpcyB0aGVyZSBzcGVj aWZpYw0KPiB3b3JrIHRoYXQgTlNDIChvciBzb21lIG90aGVyIGdyb3VwKSB3aWxsIG5lZWQgdG8g ZG8gcmVnYXJkaW5nIHRoZQ0KPiByZXByZXNlbnRhdGlvbiBvZiBzZXJ2aWNlIGZ1bmN0aW9ucz8N Cj4NCj4gVGhvbWFzDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IG5zYyBtYWlsaW5nIGxpc3QNCj4gbnNjQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbnNjDQoNCg0KLS0NCiJFc3RhIHZleiBubyBm YWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9u aWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGll Z29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAw OTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNs dXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9s w610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBl bCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4 Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1h aWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0Og0KaHR0cDovL3d3dy50aWQu ZXMvRVMvUEFHSU5BUy9kaXNjbGFpbWVyLmFzcHgNCg== From jmh@joelhalpern.com Sat Oct 26 03:04:48 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3F811E8232 for ; Sat, 26 Oct 2013 03:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ7A5dIBtxVV for ; Sat, 26 Oct 2013 03:04:43 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id E7F0D11E8175 for ; Sat, 26 Oct 2013 03:04:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C3AB21BCC0B3; Sat, 26 Oct 2013 03:04:43 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 1491C1BCC0B2; Sat, 26 Oct 2013 03:04:42 -0700 (PDT) Message-ID: <526B93BB.3060909@joelhalpern.com> Date: Sat, 26 Oct 2013 06:04:43 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Narten References: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> In-Reply-To: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: nsc@ietf.org Subject: Re: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 10:04:48 -0000 Maybe I am naive, but this looks to be completely outside the scope of what I understand SFC to be working on. Architecturally, naming or identification has to be assumed. But that does not mean we have to define it. In particular, the identification of services / service instances / servers / virtual instances ... would seem to be a control function. Once we get to the data plane, SFC service delivery points have to be meaningful to the data plane. Hence, the process of discovery and selection service entities seems to me to be outside of our problem domain. Yours, Joel On 10/25/13 11:15 AM, Thomas Narten wrote: > The document draft-bitar-i2rs-service-chaining-00.txt gets into > describing services in a very concrete way. E.g., they have names, > they have properties/attributes, etc. > > Something like this is presumably needed by SFC if one has service > functions scattered around the network that one wants to find > dynamically. And when creating a service chain, one needs to match > specific service function instances to specific flows. But that means > we need a language of some sort for describing services - so that > service requestors can be matched against service providers. That can > only be done if services can be described in a machine readable way so > that a service can advertise itself (exact details of service > advertisement don't matter for this discussion) and that someone > wanting a service can choose from advertised services to find the one > they need. > > E.g, it's not enough to say "firewall". A FW may need to support > particular rules or features -- and AFAICT, FWs are hardly standard, > and different FWs support different sets of feaures. > > Question for this group: how much of the area of service > representation does NSC need to tackle? Seems to me if the answer > can't be "none" if we want interoperability, so something is > needed. > > Note that this topic presumably overlaps with other work groups/areas, > like I2RS, network management, etc. > > We presumably also want to leverage work done elsewhere where > possible. But if there is nothing we can leverage, is there specific > work that NSC (or some other group) will need to do regarding the > representation of service functions? > > Thomas > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From linda.dunbar@huawei.com Sun Oct 27 18:45:42 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5AA411E82E4 for ; Sun, 27 Oct 2013 18:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-zVpBFCQJ3N for ; Sun, 27 Oct 2013 18:44:50 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1556A11E8205 for ; Sun, 27 Oct 2013 18:44:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZN84348; Mon, 28 Oct 2013 01:44:45 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:30 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:37 +0000 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Sun, 27 Oct 2013 18:44:34 -0700 From: Linda Dunbar To: Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0Z5siAs3TK+XwUqp4sOieR1Fp5oIuFKw Date: Mon, 28 Oct 2013 01:44:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BEAAF2@dfweml509-mbb.china.huawei.com> References: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> In-Reply-To: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:45:43 -0000 Thomas,=20 There is another Service Chaining problem statement draft: "Layer 4-7 Service Chain problem statement" (https://datatracker.ietf.org/d= oc/draft-dunbar-l4-l7-sc-problem-statement/ ) Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Thomas Narten > Sent: Friday, October 25, 2013 11:10 AM > To: nsc@ietf.org > Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement >=20 > Hi. >=20 > To date, one problem statement draft > (draft-quinn-nsc-problem-statement-03.txt) has been produced for the > SFC effort. >=20 > It has served as the basis for both the current and prior BOF, and my > read of the mailing list discussions suggests that folk seem generally > OK with it. I have not seen fundamental disagreements with its content > or calls for substantial additions. >=20 > Any disagreement with this assessment? >=20 > Assuming there is agreement with the above, and that a WG is formed, I > would expect that: >=20 > 1) we would formally adopt the document as a WG document in fairly > short order and >=20 > 2) close its contents in relatively short order and send to the IESG > for publication. >=20 > For most WGs, a problem statement is the highest priority work item to > complete, as it sets the stage for all followup work. Also, if there > are significant gaps or shortcomings in a problem statement, it tends > to spell trouble for the WG as it starts doing work (it's hard to get > agreement on solutions when there isn't really agreement on what the > solution needs to actually do). Thus, complete the problem > statement is a priority, and we want to get the contents right. >=20 > So with that in mind, are there still substantive issues we need to > work out in the problem statement? Or do people think it is in pretty > good shape? What still needs to be added to the document? (These > questions are aimed at both the list and the document authors...) >=20 > Thomas >=20 > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From linda.dunbar@huawei.com Sun Oct 27 18:46:03 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1424211E82EA for ; Sun, 27 Oct 2013 18:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbiVZbVwVnQU for ; Sun, 27 Oct 2013 18:45:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4511E82E1 for ; Sun, 27 Oct 2013 18:44:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZN84352; Mon, 28 Oct 2013 01:44:46 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:30 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:39 +0000 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Sun, 27 Oct 2013 18:44:34 -0700 From: Linda Dunbar To: Ian Smith , Thomas Narten Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO0ZqB56LuS3OqWU2v9koSph2D4poIumMQ Date: Mon, 28 Oct 2013 01:44:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BEAAF7@dfweml509-mbb.china.huawei.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com>, <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> In-Reply-To: <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:46:03 -0000 > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Ian Smith > Sent: Friday, October 25, 2013 10:54 AM > To: Thomas Narten > Cc: nsc@ietf.org > Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for > draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] >=20 > My perception is that that is a foregone conclusion the working group > should be chartered to create a new protocol and that seems premature. [Linda] There are flexible service chaining without new encapsulation at da= ta plane. So I would say "it may be premature to assume creating a new data= plane protocol"=20 >=20 > I do believe that there is work to be done in a working group,=20 [Linda] such as management plane or control plane to make service chaining = more flexible?=20 My two cents. =20 Linda From linda.dunbar@huawei.com Sun Oct 27 18:46:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C02F111E82EB for ; Sun, 27 Oct 2013 18:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIMidj4TDhfU for ; Sun, 27 Oct 2013 18:46:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C301211E82E9 for ; Sun, 27 Oct 2013 18:45:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZN84347; Mon, 28 Oct 2013 01:44:44 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:29 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 28 Oct 2013 01:44:36 +0000 Received: from DFWEML509-MBB.china.huawei.com ([169.254.2.181]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Sun, 27 Oct 2013 18:44:32 -0700 From: Linda Dunbar To: "Joel M. Halpern" , Thomas Narten Thread-Topic: [nsc] Representations of services Thread-Index: AQHO0ZU53LVuMQ8jlUO/Fxs3v5TCsZoHN8OAgADyuTA= Date: Mon, 28 Oct 2013 01:44:31 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645BEAAC4@dfweml509-mbb.china.huawei.com> References: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> <526B93BB.3060909@joelhalpern.com> In-Reply-To: <526B93BB.3060909@joelhalpern.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.145.212] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 01:46:15 -0000 Just want to add one more point to what Joel said:=20 There are vast diverse types of service functions. Defining each individual= service and its associated attributes for "Controller" to manage can quick= ly become a kitchen sink. The attributes for FW is completely different fro= m Video Optimization, which is again different from content caching, TCP ac= celeration, NAT, or AntiDos scrubbing services. More importantly, there are= new service functions popping up faster than ever. Their attributes are al= l different.=20 It is a moving target to chase them and try to characterize attributes for = them.=20 My two cents.=20 Linda > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Joel M. Halpern > Sent: Saturday, October 26, 2013 5:05 AM > To: Thomas Narten > Cc: nsc@ietf.org > Subject: Re: [nsc] Representations of services >=20 > Maybe I am naive, but this looks to be completely outside the scope of > what I understand SFC to be working on. > Architecturally, naming or identification has to be assumed. But that > does not mean we have to define it. In particular, the identification > of services / service instances / servers / virtual instances ... would > seem to be a control function. Once we get to the data plane, SFC > service delivery points have to be meaningful to the data plane. >=20 > Hence, the process of discovery and selection service entities seems to > me to be outside of our problem domain. >=20 > Yours, > Joel >=20 > On 10/25/13 11:15 AM, Thomas Narten wrote: > > The document draft-bitar-i2rs-service-chaining-00.txt gets into > > describing services in a very concrete way. E.g., they have names, > > they have properties/attributes, etc. > > > > Something like this is presumably needed by SFC if one has service > > functions scattered around the network that one wants to find > > dynamically. And when creating a service chain, one needs to match > > specific service function instances to specific flows. But that means > > we need a language of some sort for describing services - so that > > service requestors can be matched against service providers. That > can > > only be done if services can be described in a machine readable way > so > > that a service can advertise itself (exact details of service > > advertisement don't matter for this discussion) and that someone > > wanting a service can choose from advertised services to find the one > > they need. > > > > E.g, it's not enough to say "firewall". A FW may need to support > > particular rules or features -- and AFAICT, FWs are hardly standard, > > and different FWs support different sets of feaures. > > > > Question for this group: how much of the area of service > > representation does NSC need to tackle? Seems to me if the answer > > can't be "none" if we want interoperability, so something is > > needed. > > > > Note that this topic presumably overlaps with other work groups/areas, > > like I2RS, network management, etc. > > > > We presumably also want to leverage work done elsewhere where > > possible. But if there is nothing we can leverage, is there specific > > work that NSC (or some other group) will need to do regarding the > > representation of service functions? > > > > Thomas > > > > _______________________________________________ > > nsc mailing list > > nsc@ietf.org > > https://www.ietf.org/mailman/listinfo/nsc > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From narten@us.ibm.com Mon Oct 28 11:04:06 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA5D11E819B for ; Mon, 28 Oct 2013 11:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-DKrjGCDlcJ for ; Mon, 28 Oct 2013 11:04:00 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id B159C21E80B1 for ; Mon, 28 Oct 2013 11:03:44 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Oct 2013 14:03:44 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 28 Oct 2013 14:03:41 -0400 Received: from b01cxnp22034.gho.pok.ibm.com (b01cxnp22034.gho.pok.ibm.com [9.57.198.24]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 13F78C90042 for ; Mon, 28 Oct 2013 14:03:40 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp22034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9SI3erG57606340 for ; Mon, 28 Oct 2013 18:03:40 GMT Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9SI3elA021271 for ; Mon, 28 Oct 2013 14:03:40 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-77-133-4.mts.ibm.com [9.77.133.4]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9SI3cN5021099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 14:03:38 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9SI3b3M004866; Mon, 28 Oct 2013 14:03:37 -0400 Message-Id: <201310281803.r9SI3b3M004866@cichlid.raleigh.ibm.com> To: "Joel M. Halpern" In-reply-to: <526B93BB.3060909@joelhalpern.com> References: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> <526B93BB.3060909@joelhalpern.com> Comments: In-reply-to "Joel M. Halpern" message dated "Sat, 26 Oct 2013 06:04:43 -0400." Date: Mon, 28 Oct 2013 14:03:36 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102818-0320-0000-0000-0000018A2ADB Cc: nsc@ietf.org Subject: Re: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:04:06 -0000 Hi Joel. "Joel M. Halpern" writes: > Maybe I am naive, but this looks to be completely outside the scope of > what I understand SFC to be working on. To be clear, I mostly agree. IMO, this is mostly outside of the current charter as I understand it. However, the question really is what (if any) work in this space is needed in order for SFC to be successful more generally. I.e., would the lack of work/solutions just mean all that stuff gets done in a proprietary manner? Is that what we want? To me, SFC is part of a bigger picture that involves orchestration of VMs and services. SFC is one piece of that, but not the only one. > Architecturally, naming or identification has to be assumed. But that > does not mean we have to define it. In particular, the identification > of services / service instances / servers / virtual instances ... would > seem to be a control function. Once we get to the data plane, SFC > service delivery points have to be meaningful to the data plane. The proposed charter isn't just data plane/encap, there are hints of control plane too. Look at the following paragraph from the charter and the last paragraph in particular: The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment. It will produce a framework for service function chaining that includes the necessary protocols or protocol extensions to convey the service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. The working group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions. > Hence, the process of discovery and selection service entities seems to > me to be outside of our problem domain. Let me ask again though: 1) Do we already have solutions/standards in place that do this today? If so, what are they? 2) Is there work in this space that needs doing (somewhere)? If so, what is that work and where should it be done? Thomas From narten@us.ibm.com Mon Oct 28 11:11:56 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF22321E80AF for ; Mon, 28 Oct 2013 11:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuyoItqClduV for ; Mon, 28 Oct 2013 11:11:51 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id DFA0F11E828D for ; Mon, 28 Oct 2013 11:11:50 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Oct 2013 14:11:50 -0400 Received: from d01dlp03.pok.ibm.com (9.56.250.168) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 28 Oct 2013 14:11:47 -0400 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp03.pok.ibm.com (Postfix) with ESMTP id 9B1F5C90042 for ; Mon, 28 Oct 2013 14:11:45 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9SIBkES61079682 for ; Mon, 28 Oct 2013 18:11:46 GMT Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9SIBhLJ012933 for ; Mon, 28 Oct 2013 16:11:46 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-77-133-4.mts.ibm.com [9.77.133.4]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9SIBdSq012553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 16:11:40 -0200 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9SIBcDG006253; Mon, 28 Oct 2013 14:11:38 -0400 Message-Id: <201310281811.r9SIBcDG006253@cichlid.raleigh.ibm.com> To: Linda Dunbar In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F645BEAAF2@dfweml509-mbb.china.huawei.com> References: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> <4A95BA014132FF49AE685FAB4B9F17F645BEAAF2@dfweml509-mbb.china.huawei.com> Comments: In-reply-to Linda Dunbar message dated "Mon, 28 Oct 2013 01:44:33 -0000." Date: Mon, 28 Oct 2013 14:11:38 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102818-0320-0000-0000-0000018A3096 Cc: "nsc@ietf.org" Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 18:11:56 -0000 Hi Linda. Linda Dunbar writes: > There is another Service Chaining problem statement draft: > "Layer 4-7 Service Chain problem statement" > (https://datatracker.ietf.org/doc/draft-dunbar-l4-l7-sc-problem-statement/ > ) Right. But the contents of this draft deals with specific subset of the overall problem space covered in draft-quinn-sfc-arch-02.txt. The two documents are not in conflict with each other and draft-dunbar is not an alternate problem statement formulation. I.e., the two documents complement each other. Agreed? Thomas From narten@us.ibm.com Mon Oct 28 13:05:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A351A11E81E2 for ; Mon, 28 Oct 2013 13:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IX-m3Gim8rRR for ; Mon, 28 Oct 2013 13:04:44 -0700 (PDT) Received: from e7.ny.us.ibm.com (e7.ny.us.ibm.com [32.97.182.137]) by ietfa.amsl.com (Postfix) with ESMTP id CC1E721F9EED for ; Mon, 28 Oct 2013 13:04:43 -0700 (PDT) Received: from /spool/local by e7.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Oct 2013 16:04:43 -0400 Received: from d01dlp01.pok.ibm.com (9.56.250.166) by e7.ny.us.ibm.com (192.168.1.107) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 28 Oct 2013 16:04:41 -0400 Received: from b01cxnp23032.gho.pok.ibm.com (b01cxnp23032.gho.pok.ibm.com [9.57.198.27]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 2EFD938C8047 for ; Mon, 28 Oct 2013 16:04:40 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by b01cxnp23032.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9SK4eU165798334 for ; Mon, 28 Oct 2013 20:04:41 GMT Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9SK3edE019477 for ; Mon, 28 Oct 2013 18:03:40 -0200 Received: from cichlid.raleigh.ibm.com (sig-9-77-133-4.mts.ibm.com [9.77.133.4]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9SK3di7019379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 18:03:40 -0200 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9SK3bHV024499; Mon, 28 Oct 2013 16:03:37 -0400 Message-Id: <201310282003.r9SK3bHV024499@cichlid.raleigh.ibm.com> To: "Jim Guichard (jguichar)" In-reply-to: <68B171751455884590F8E38E96416F363F70B35B@xmb-rcd-x01.cisco.com> References: <68B171751455884590F8E38E96416F363F70B35B@xmb-rcd-x01.cisco.com> Comments: In-reply-to "Jim Guichard (jguichar)" message dated "Fri, 25 Oct 2013 18:27:53 -0000." Date: Mon, 28 Oct 2013 16:03:37 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102820-5806-0000-0000-0000233DC05A Cc: "nsc@ietf.org" Subject: Re: [nsc] SFC WG charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:05:29 -0000 Hi Jim. One thing I think should be clarified is that the charter refers to both architecture and framework documents and in the deliverables even implies both will be produced. I assume that we want to produce only one document, not two. The IETF seems to use framework and architecture mostly interchangably, and unless someone can articulate why we need two documents, and what the difference between them would be, we should clarify the charter. Thomas From jguichar@cisco.com Mon Oct 28 13:05:46 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511AE21F9EED for ; Mon, 28 Oct 2013 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpvy7MAYNJ2T for ; Mon, 28 Oct 2013 13:05:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1D84711E81D9 for ; Mon, 28 Oct 2013 13:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=627; q=dns/txt; s=iport; t=1382990715; x=1384200315; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8PaR97Uxel/O7bC3We0meU995GIrL45Rsa4VN2NFQH8=; b=Q9p4FtHxM9Xs3ONABpw3KW75cnr4Sd20EOxdAcIrIewYl9OJNpLrMXGi JctIyxDVew73+2sgbZ4JlbHAIn/M2h6EPNNfiEdLqdYt/KvdSxyazixyb qsHd+OTCHxXCi/oK+cfPE2wVIzx8nUhgLJgbL8YdF0MLIE+we3IOSpQ9g o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4FAMfCblKtJXG8/2dsb2JhbABZgwe/cIEpFnSCJQEBAQMBOj8FCwIBCBIGHhAyFw4CBA4FiAEGuDOPVQeDH4ENA5gKkgeDJg X-IronPort-AV: E=Sophos;i="4.93,587,1378857600"; d="scan'208";a="277695709" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 28 Oct 2013 20:04:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r9SK4pHr012293 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 20:04:51 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 15:04:51 -0500 From: "Jim Guichard (jguichar)" To: Thomas Narten Thread-Topic: [nsc] SFC WG charter Thread-Index: AQHO0a/qaKCM55gkbUC6qVHLV+RQPZoK4gWA//+shqI= Date: Mon, 28 Oct 2013 20:04:50 +0000 Message-ID: <78DF360D-57E2-4365-B27E-D07DEC5085F4@cisco.com> References: <68B171751455884590F8E38E96416F363F70B35B@xmb-rcd-x01.cisco.com>, <201310282003.r9SK3bHV024499@cichlid.raleigh.ibm.com> In-Reply-To: <201310282003.r9SK3bHV024499@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] SFC WG charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:05:46 -0000 I agree. Sent from my iPhone > On Oct 28, 2013, at 4:03 PM, "Thomas Narten" wrote: >=20 > Hi Jim. >=20 > One thing I think should be clarified is that the charter refers to > both architecture and framework documents and in the deliverables even > implies both will be produced. I assume that we want to produce only > one document, not two. >=20 > The IETF seems to use framework and architecture mostly > interchangably, and unless someone can articulate why we need two > documents, and what the difference between them would be, we should > clarify the charter. >=20 > Thomas >=20 From jmh@joelhalpern.com Mon Oct 28 13:17:52 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22EB111E81BB for ; Mon, 28 Oct 2013 13:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g1fhTbYWousB for ; Mon, 28 Oct 2013 13:17:47 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF111E81C4 for ; Mon, 28 Oct 2013 13:17:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CEDCE1C0E10; Mon, 28 Oct 2013 13:17:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 813161C03B5; Mon, 28 Oct 2013 13:17:41 -0700 (PDT) Message-ID: <526EC663.6040803@joelhalpern.com> Date: Mon, 28 Oct 2013 16:17:39 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Thomas Narten References: <68B171751455884590F8E38E96416F363F70B35B@xmb-rcd-x01.cisco.com> <201310282003.r9SK3bHV024499@cichlid.raleigh.ibm.com> In-Reply-To: <201310282003.r9SK3bHV024499@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "nsc@ietf.org" , "Jim Guichard \(jguichar\)" Subject: Re: [nsc] SFC WG charter X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:17:52 -0000 I had hoped that we could produce an architecture document. While the IETF sometimes uses "framework" to mean the same thing, sometimes it uses the word to mean something more general. Yours, Joel On 10/28/13 4:03 PM, Thomas Narten wrote: > Hi Jim. > > One thing I think should be clarified is that the charter refers to > both architecture and framework documents and in the deliverables even > implies both will be produced. I assume that we want to produce only > one document, not two. > > The IETF seems to use framework and architecture mostly > interchangably, and unless someone can articulate why we need two > documents, and what the difference between them would be, we should > clarify the charter. > > Thomas > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From narten@us.ibm.com Mon Oct 28 13:41:29 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C43B11E826B for ; Mon, 28 Oct 2013 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjTkgueo68xG for ; Mon, 28 Oct 2013 13:41:22 -0700 (PDT) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 4806611E828D for ; Mon, 28 Oct 2013 13:41:22 -0700 (PDT) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 28 Oct 2013 16:41:21 -0400 Received: from d01dlp02.pok.ibm.com (9.56.250.167) by e8.ny.us.ibm.com (192.168.1.108) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 28 Oct 2013 16:41:18 -0400 Received: from b01cxnp23033.gho.pok.ibm.com (b01cxnp23033.gho.pok.ibm.com [9.57.198.28]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id A5EB96E804B for ; Mon, 28 Oct 2013 16:41:16 -0400 (EDT) Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by b01cxnp23033.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r9SKfITM3080524 for ; Mon, 28 Oct 2013 20:41:18 GMT Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r9SKfHpi014510 for ; Mon, 28 Oct 2013 16:41:17 -0400 Received: from cichlid.raleigh.ibm.com (sig-9-77-133-4.mts.ibm.com [9.77.133.4]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r9SKfE2Q014416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 16:41:15 -0400 Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id r9SKfDDl030460; Mon, 28 Oct 2013 16:41:14 -0400 Message-Id: <201310282041.r9SKfDDl030460@cichlid.raleigh.ibm.com> To: Ian Smith In-reply-to: <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com>, <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com> Comments: In-reply-to Ian Smith message dated "Fri, 25 Oct 2013 15:54:05 -0000." Date: Mon, 28 Oct 2013 16:41:13 -0400 From: Thomas Narten X-TM-AS-MML: No X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13102820-0320-0000-0000-0000018AAB12 Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 20:41:29 -0000 Ian Smith writes: > My perception is that that is a foregone conclusion the working > group should be chartered to create a new protocol and that seems > premature. > I do believe that there is work to be done in a working group, but > that informational and cbp documents may be all that is required to > solve the problem statements that I've seen put forth. Some have > argued that a standard protocol is required for interoperability, > and I agree, but I contend that we ought to look at existing options > before starting from scratch because it will allow us to deliver > faster and it makes for a simpler and more manageable adoption. So let me (perhaps) be a bit provocative in order to draw out the discussion a bit more. My understanding is that one can do service chaining today. But it isn't always easy, and at least some folk are looking for a different way that has less pain. I see two major assumptions behind the SFC work: 1) One can do traffic steering today by manipulating/modifying the network. E.g., one can place Service Functions on the data path or one can reprogram the network to steer the traffic to the places it needs to go. But this is viewed as painful and looking forward, increasingly inflexible in terms of doing this in an automated, dynamic way. Hence, SFC is very definitely looking at addressing this problem in a different manner than just continuing to use protocols that manipulate the L2/L3 forwarding plane. Specifically, SFC wants to decouple the "steering" from the underlying network. If one doesn't want to modify the network forwarding plane, using tunneling between Service Functions (e.g., via something like draft-quinn-sfc) is an obvious approach. The key point here though is that reather than changing the data plane to make packets go where we want, we tunnel instead, so that this can be done without modifying the data plane of the underlay. 2) Even in cases where current data plane steering approaches work good enough (i.e,. 1 above isn't needed), there is also a separate need to carry meta-data with data packets so that the Service Functions along the chain can properly (or more easily) implement those services in a context-sensitive manner. I believe the charter and problem statement documents are pretty clear about the above need. While we might be able to use IP options and other existing mechanisms tocarry such meta-data, there is long history/experience with IP options that suggests they may not be a good approach. But the WG should describe what some of the possible existing approaches are and what issues (if any) there are with them. Personally, I don't see IP options as really viable for this stuff. We have a fair amount of experience/history with such options, and they are no panacea. What other *existing* approaches are there that we could consider? > I'm open to the potential that new problem statements do arise that > cannot be solved sufficiently by using or extending existing > standards to do that, but I haven't seen them presented in any of > the sfc drafts. > The drafts are very casual in their dismissal of using existing > protocols as part of the solution and they don't explain why enough > to justify committing to a new protocol in the charter, in my view. What other specific options should we consider? Thomas From paulq@cisco.com Mon Oct 28 14:08:05 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E9E11E82A1 for ; Mon, 28 Oct 2013 14:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hM6oVMV55htW for ; Mon, 28 Oct 2013 14:08:00 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7224311E81AC for ; Mon, 28 Oct 2013 14:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4986; q=dns/txt; s=iport; t=1382994480; x=1384204080; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=31PTkhKNjTswNU2BbyB8MiwwFGwQbpEWF88125+zfgA=; b=hXWECANyxvoMp//VHeV2i2mhz73xbtVIZ73XHqJ5AexopeylXXK31gO1 riJQ3/neKvPvqpst7V2tmrE5w8HHhdmXwrqDvqhbdRMF68xGi8QzpuKOV 3eMJV6MpMs/EeWNbZ2IdeqJ9dnKgBMxOMi+eyGe5JllRR87ei5CR5k41X w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAEnRblKtJXG9/2dsb2JhbABZgwc4VL5ogSoWdIIlAQEBAwEBAQEkEzQEAgUFBwQCAQgRBAEBCxQJBycLFAkIAgQOBQgTh2YGDbg8BI8iAjEHBoMZgQ0DlCqVZ4Mmgio X-IronPort-AV: E=Sophos;i="4.93,588,1378857600"; d="scan'208";a="277740745" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 28 Oct 2013 21:07:59 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r9SL7xFH009039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Oct 2013 21:07:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 28 Oct 2013 16:07:59 -0500 From: "Paul Quinn (paulq)" To: "NAPIERALA, MARIA H" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzfrvjQdK/P3UmXhAsUEPLW+poGHY+AgATWmIA= Date: Mon, 28 Oct 2013 21:07:59 +0000 Message-ID: References: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> <1D70D757A2C9D54D83B4CBD7625FA80E012C44F2@MISOUT7MSGUSR9I.ITServices.sbc.com> In-Reply-To: <1D70D757A2C9D54D83B4CBD7625FA80E012C44F2@MISOUT7MSGUSR9I.ITServices.sbc.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.83.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <3870C3697EC8BB47B0F594850497C0CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 21:08:05 -0000 Hi Maria, Please see inline. I hope to see you in Vancouver :) Paul On Oct 25, 2013, at 12:14 PM, "NAPIERALA, MARIA H" wrote: > Tom, >=20 > I have few questions on this draft: >=20 > Section 1.1.: >=20 > "Service Chain: A service chain defines the required functions and > associated order (service-function1 --> service-function 2) that > must be applied to packets and/or frames. A service chain does > not specify the network location or specific instance of service > functions (e.g. firewall1 vs. firewall2)." >=20 > What does "specific instance of service function" means in this context?= =20 >=20 A service function provides some kind of "functionality"; this functionalit= y may be required at multiple points in the network.=20 This by definition means that multiple "instances" of that service function= are available for consumption (e.g. Firewall1 vs. Firewall1@locationX, Fir= ewall1@locationY). Each service function is identifiable using a unique ID = (noting that a service function instance that provides the *same* functiona= lity as another service function instance may use the same ID). We will up= date the definition to be more detailed and include a definition of a servi= ce function ID (SFID)". > Section 3: >=20 > "Service Overlay: Service chaining utilizes a service specific > overlay that creates the service topology: the overlay creates a > path between service nodes. The service overlay is independent > of the network topology and allows operators to use whatever > overlay or underlay they prefer and to locate service functions > in the network as needed." >=20 > This is not a clear definition of a "service overlay". It just refers to = a "path" but does not define it. >=20 PQ> The reason we call it a service overlay is that the overlay topology is= not needed to src --> dst traffic except for the fact that service are being added.=20 > Section 5: >=20 > "L3VPN[L3VPN]: The L3VPN working group is responsible for > defining, specifying and extending BGP/MPLS IP VPNs solutions. > Although BGP/MPLS IP VPNs can be used as transport for service > chaining deployments, the service chaining WG focuses on the > service specific protocols, not the general case of VPNs. > Furthermore, BGP/MPLS IP VPNs do not address the requirements for > service chaining." >=20 > What are the "service specific protocols"? >=20 PQ> Any protocol defined by the proposed WG. >=20 > draft-filsfils-rtgwg-segment-routing has a section on "Service Segments".= Is there any relation to this work?=20 >=20 PQ> SR can be used as one of the _possible_ transports. There are many other we need to consider. > Maria >=20 >> -----Original Message----- >> From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of >> Thomas Narten >> Sent: Friday, October 25, 2013 12:10 PM >> To: nsc@ietf.org >> Subject: [nsc] Problem statement draft: quinn-nsc-problem-statement >>=20 >> Hi. >>=20 >> To date, one problem statement draft >> (draft-quinn-nsc-problem-statement-03.txt) has been produced for the >> SFC effort. >>=20 >> It has served as the basis for both the current and prior BOF, and my >> read of the mailing list discussions suggests that folk seem generally >> OK with it. I have not seen fundamental disagreements with its content >> or calls for substantial additions. >>=20 >> Any disagreement with this assessment? >>=20 >> Assuming there is agreement with the above, and that a WG is formed, I >> would expect that: >>=20 >> 1) we would formally adopt the document as a WG document in fairly >> short order and >>=20 >> 2) close its contents in relatively short order and send to the IESG >> for publication. >>=20 >> For most WGs, a problem statement is the highest priority work item to >> complete, as it sets the stage for all followup work. Also, if there >> are significant gaps or shortcomings in a problem statement, it tends >> to spell trouble for the WG as it starts doing work (it's hard to get >> agreement on solutions when there isn't really agreement on what the >> solution needs to actually do). Thus, complete the problem >> statement is a priority, and we want to get the contents right. >>=20 >> So with that in mind, are there still substantive issues we need to >> work out in the problem statement? Or do people think it is in pretty >> good shape? What still needs to be added to the document? (These >> questions are aimed at both the list and the document authors...) >>=20 >> Thomas >>=20 >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From I.Smith@F5.com Mon Oct 28 14:41:35 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B1211E82A5 for ; Mon, 28 Oct 2013 14:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.162 X-Spam-Level: X-Spam-Status: No, score=-10.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nebF-+2E3VkL for ; Mon, 28 Oct 2013 14:41:30 -0700 (PDT) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id C7AAC11E82A1 for ; Mon, 28 Oct 2013 14:41:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,588,1378857600"; d="scan'208";a="85457138" Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 28 Oct 2013 21:41:28 +0000 Received: from SEAEMBX02.olympus.F5Net.com ([fe80::a5e3:d11c:e46a:e7c7]) by seaecas02.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Mon, 28 Oct 2013 14:41:27 -0700 From: Ian Smith To: Thomas Narten Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO1B4QEDxgyWCCMkCp5OcL7GFVMZoKl/ui Date: Mon, 28 Oct 2013 21:41:26 +0000 Message-ID: <419417C345CA5F48BF45F0A23955A0634A7106AA@SEAEMBX02.olympus.F5Net.com> References: <419417C345CA5F48BF45F0A23955A0634A70C278@SEAEMBX02.olympus.F5Net.com>, <68B171751455884590F8E38E96416F363F7097DA@xmb-rcd-x01.cisco.com> <419417C345CA5F48BF45F0A23955A0634A70C5A6@SEAEMBX02.olympus.F5Net.com>, <201310251500.r9PF0G08015228@cichlid.raleigh.ibm.com> <419417C345CA5F48BF45F0A23955A0634A70D546@SEAEMBX02.olympus.F5Net.com>, <201310282041.r9SKfDDl030460@cichlid.raleigh.ibm.com> In-Reply-To: <201310282041.r9SKfDDl030460@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.16.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 21:41:35 -0000 I understand what you are saying, and thank you, since this is the clearest= enunciation of motives I've seen.=0A= =0A= It seems to me that you are saying in 1. that you believe that the issues t= hat keep you from solving the problem by dynamically updating the forwardin= g plane will not follow you into an overlay network, and I disagree strongl= y. It also sounds like the idea that traffic steering and service chaining= are different in kind to next-hop selection and therefore can be decoupled= from the router or switch, to which I also disagree. I also believe that = if you aren't going to address the challenges of updating the forwarding pl= ane, you are running away from the single most important unaddressed requir= ement for deploying a service delivery architecture. Tunnelling _is_ chang= ing the data plane; an encapsulation packet still must be sent to the corre= ct destination for the encapsulated payload, and now you've made that cost = more system resources in the infrastructure nodes.=0A= =0A= Furthermore, by pre-emptively declaring the only solution to be an overlay = network you are doing two things: First, you are requiring bigger and bigg= er forwarding plane platforms with greater and greater amounts of sophistic= ation to deal with the additional requirements of the proliferation of over= lay networks, which is not what the end-users of the standard are asking fo= r, isn't consistent with the work of other standards bodies working on dyna= mic networking, and results in a more catastrophic failure domain; Second, = you are staking out a need for a new working group where there are existing= working groups already formed and active based on a very narrow set of des= ired features that both nvo3 and l3vpn both would seem to be capable of emb= racing. =0A= =0A= If all you want is a dynamic multi-point vpn, which is functionally what yo= u are describing, then why can't either of those WGs, which are already wel= l into standardizing dmvpn protocols, provide the standard for dmvpns that = happen to hook together services that include firewalls, LSN, server LB, an= d VAS? Do we really need three IETF dmvpn working groups at the same time?= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= ________________________________________=0A= From: Thomas Narten [narten@us.ibm.com]=0A= Sent: Monday, October 28, 2013 4:41 PM=0A= To: Ian Smith=0A= Cc: nsc@ietf.org=0A= Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draf= t-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt]=0A= =0A= Ian Smith writes:=0A= =0A= > My perception is that that is a foregone conclusion the working=0A= > group should be chartered to create a new protocol and that seems=0A= > premature.=0A= =0A= > I do believe that there is work to be done in a working group, but=0A= > that informational and cbp documents may be all that is required to=0A= > solve the problem statements that I've seen put forth. Some have=0A= > argued that a standard protocol is required for interoperability,=0A= > and I agree, but I contend that we ought to look at existing options=0A= > before starting from scratch because it will allow us to deliver=0A= > faster and it makes for a simpler and more manageable adoption.=0A= =0A= So let me (perhaps) be a bit provocative in order to draw out the=0A= discussion a bit more.=0A= =0A= My understanding is that one can do service chaining today. But it=0A= isn't always easy, and at least some folk are looking for a different=0A= way that has less pain. I see two major assumptions behind the SFC=0A= work:=0A= =0A= 1) One can do traffic steering today by manipulating/modifying the=0A= network. E.g., one can place Service Functions on the data path or one=0A= can reprogram the network to steer the traffic to the places it needs=0A= to go. But this is viewed as painful and looking forward, increasingly=0A= inflexible in terms of doing this in an automated, dynamic way. Hence,=0A= SFC is very definitely looking at addressing this problem in a=0A= different manner than just continuing to use protocols that manipulate=0A= the L2/L3 forwarding plane. Specifically, SFC wants to decouple the=0A= "steering" from the underlying network.=0A= =0A= If one doesn't want to modify the network forwarding plane, using=0A= tunneling between Service Functions (e.g., via something like=0A= draft-quinn-sfc) is an obvious approach. The key point here though is=0A= that reather than changing the data plane to make packets go where we=0A= want, we tunnel instead, so that this can be done without modifying=0A= the data plane of the underlay.=0A= =0A= 2) Even in cases where current data plane steering approaches work=0A= good enough (i.e,. 1 above isn't needed), there is also a separate=0A= need to carry meta-data with data packets so that the Service=0A= Functions along the chain can properly (or more easily) implement=0A= those services in a context-sensitive manner.=0A= =0A= I believe the charter and problem statement documents are pretty clear=0A= about the above need.=0A= =0A= While we might be able to use IP options and other existing mechanisms=0A= tocarry such meta-data, there is long history/experience with IP=0A= options that suggests they may not be a good approach. But the WG=0A= should describe what some of the possible existing approaches are and=0A= what issues (if any) there are with them.=0A= =0A= Personally, I don't see IP options as really viable for this stuff. We=0A= have a fair amount of experience/history with such options, and they=0A= are no panacea. What other *existing* approaches are there that we=0A= could consider?=0A= =0A= > I'm open to the potential that new problem statements do arise that=0A= > cannot be solved sufficiently by using or extending existing=0A= > standards to do that, but I haven't seen them presented in any of=0A= > the sfc drafts.=0A= =0A= > The drafts are very casual in their dismissal of using existing=0A= > protocols as part of the solution and they don't explain why enough=0A= > to justify committing to a new protocol in the charter, in my view.=0A= =0A= What other specific options should we consider?=0A= =0A= Thomas=0A= =0A= From jmoisand@juniper.net Mon Oct 28 15:34:32 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29B511E81C1 for ; Mon, 28 Oct 2013 15:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBchJOVUxMxV for ; Mon, 28 Oct 2013 15:34:26 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF1421F9D30 for ; Mon, 28 Oct 2013 15:34:24 -0700 (PDT) Received: from mail69-ch1-R.bigfish.com (10.43.68.227) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Oct 2013 22:34:20 +0000 Received: from mail69-ch1 (localhost [127.0.0.1]) by mail69-ch1-R.bigfish.com (Postfix) with ESMTP id DC21AC01AF; Mon, 28 Oct 2013 22:34:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371I542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh2a8h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h2216h9a9j1155h) Received-SPF: pass (mail69-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jmoisand@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(479174003)(377454003)(24454002)(13464003)(51704005)(199002)(189002)(83072001)(33646001)(63696002)(66066001)(65816001)(80022001)(49866001)(47736001)(79102001)(50986001)(47976001)(74662001)(74502001)(59766001)(74316001)(47446002)(74876001)(31966008)(77982001)(74706001)(4396001)(56776001)(76482001)(54316002)(19580395003)(19580405001)(15975445006)(83322001)(81816001)(81686001)(80976001)(85306002)(77096001)(56816003)(51856001)(46102001)(53806001)(54356001)(76786001)(76796001)(76576001)(15202345003)(69226001)(81542001)(81342001)(74366001)(87266001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR05MB251; H:BN1PR05MB251.namprd05.prod.outlook.com; CLIP:66.129.241.16; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail69-ch1 (localhost.localdomain [127.0.0.1]) by mail69-ch1 (MessageSwitch) id 138299965840634_9875; Mon, 28 Oct 2013 22:34:18 +0000 (UTC) Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail69-ch1.bigfish.com (Postfix) with ESMTP id F07441E005F; Mon, 28 Oct 2013 22:34:17 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 28 Oct 2013 22:34:13 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 28 Oct 2013 22:34:13 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) by BN1PR05MB251.namprd05.prod.outlook.com (10.255.206.26) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 28 Oct 2013 22:34:12 +0000 Received: from BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.213]) by BN1PR05MB251.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0785.001; Mon, 28 Oct 2013 22:34:11 +0000 From: Jerome Moisand To: "Jim Guichard (jguichar)" , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzjdHEDohXJ8U6q9RO6C3aLc5oF3zyAgATPIZA= Date: Mon, 28 Oct 2013 22:34:11 +0000 Message-ID: <39641f97c06945cf8faeb8a826c15b5a@BN1PR05MB251.namprd05.prod.outlook.com> References: <201310251609.r9PG9u8W026578@cichlid.raleigh.ibm.com> <68B171751455884590F8E38E96416F363F70B5E7@xmb-rcd-x01.cisco.com> In-Reply-To: <68B171751455884590F8E38E96416F363F70B5E7@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.16] x-forefront-prvs: 0013079544 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 22:34:32 -0000 Hi Thomas, Good question! Given that: 1. the WG hasn't been formally formed yet 2. the list of documented use cases remain rather limited at the IETF level= , and a work in progress in other industry forums (e.g. BBF, ETSI NFV) It does seem a tad premature to conclude that the problem statement I-D is = nearing completion. It certainly did make very good progress though, but I = would think that it still deserves more rounds of reviews, notably fed by a= nalysis of new use cases. Now, to more directly answer your question, it seems to me that one importa= nt side of things is missing in the problem statement, in the context of br= oadband scenarios (fixed broadband ala BBF; mobile broadband ala 3GPP). How= to create a proper linkage to existing subscriber management mechanisms (4= levels: database, decision/authorization, enforcement, accounting), so tha= t service chaining can be used as an (hopefully fairly simple & natural) ex= tension of such mechanisms, hence minimizing OSS disruption and speeding up= deployment of new services. This is of course an issue specific to a given= class of use cases and may or may not apply in other contexts. In the same vein, the problem statement doesn't seem to touch very much on = implications of network-hosted business services, notably VPN concepts and = how to have service chaining co-exist and be compatible with such L2/L3 ser= vice mechanisms (e.g. running service chains in a VPN-contextualized manner= ). Maybe the higher level point here is that the current problem statement is = very generic (and doing a nice job of staying so!), while it would probably= be beneficial to expand it with considerations which are more specific to = a large class of use cases & applications. Tx Jerome -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim G= uichard (jguichar) Sent: Friday, October 25, 2013 4:32 PM To: Thomas Narten; nsc@ietf.org Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement Quick clarification: Draft-quinn-nsc-problem-statement-03 was replaced by http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please r= efer to this version if commenting. On 10/25/13 12:09 PM, "Thomas Narten" wrote: >Hi. > >To date, one problem statement draft >(draft-quinn-nsc-problem-statement-03.txt) has been produced for the=20 >SFC effort. > >It has served as the basis for both the current and prior BOF, and my=20 >read of the mailing list discussions suggests that folk seem generally=20 >OK with it. I have not seen fundamental disagreements with its content=20 >or calls for substantial additions. > >Any disagreement with this assessment? > >Assuming there is agreement with the above, and that a WG is formed, I=20 >would expect that: > >1) we would formally adopt the document as a WG document in fairly=20 >short order and > >2) close its contents in relatively short order and send to the IESG=20 >for publication. > >For most WGs, a problem statement is the highest priority work item to=20 >complete, as it sets the stage for all followup work. Also, if there=20 >are significant gaps or shortcomings in a problem statement, it tends=20 >to spell trouble for the WG as it starts doing work (it's hard to get=20 >agreement on solutions when there isn't really agreement on what the=20 >solution needs to actually do). Thus, complete the problem statement is=20 >a priority, and we want to get the contents right. > >So with that in mind, are there still substantive issues we need to=20 >work out in the problem statement? Or do people think it is in pretty=20 >good shape? What still needs to be added to the document? (These=20 >questions are aimed at both the list and the document authors...) > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From kgray@juniper.net Mon Oct 28 16:19:42 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A77111E81AF for ; Mon, 28 Oct 2013 16:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rwt3Fhtck6IR for ; Mon, 28 Oct 2013 16:19:37 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0248.outbound.messaging.microsoft.com [213.199.154.248]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAB021F9C81 for ; Mon, 28 Oct 2013 16:19:33 -0700 (PDT) Received: from mail130-db9-R.bigfish.com (10.174.16.235) by DB9EHSOBE033.bigfish.com (10.174.14.96) with Microsoft SMTP Server id 14.1.225.22; Mon, 28 Oct 2013 23:19:23 +0000 Received: from mail130-db9 (localhost [127.0.0.1]) by mail130-db9-R.bigfish.com (Postfix) with ESMTP id BB9BF400EA; Mon, 28 Oct 2013 23:19:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h1155h) Received-SPF: pass (mail130-db9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kgray@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(199002)(189002)(377454003)(479174003)(24454002)(74706001)(59766001)(63696002)(54356001)(69226001)(80022001)(77982001)(46102001)(81816001)(81686001)(80976001)(83506001)(65816001)(53806001)(87266001)(74876001)(76482001)(81342001)(56776001)(74366001)(81542001)(83072001)(51856001)(54316002)(36756003)(74662001)(74502001)(76176001)(31966008)(77096001)(47446002)(56816003)(85306002)(4396001)(49866001)(47736001)(50986001)(47976001)(76796001)(83322001)(19580395003)(76786001)(19580405001)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR05MB081; H:BL2PR05MB082.namprd05.prod.outlook.com; CLIP:10.255.129.4; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail130-db9 (localhost.localdomain [127.0.0.1]) by mail130-db9 (MessageSwitch) id 1383002362263917_15954; Mon, 28 Oct 2013 23:19:22 +0000 (UTC) Received: from DB9EHSMHS015.bigfish.com (unknown [10.174.16.227]) by mail130-db9.bigfish.com (Postfix) with ESMTP id 31AA3203C7; Mon, 28 Oct 2013 23:19:22 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by DB9EHSMHS015.bigfish.com (10.174.14.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 28 Oct 2013 23:19:21 +0000 Received: from BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.371.2; Mon, 28 Oct 2013 23:19:15 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com (10.255.232.21) by BL2PR05MB081.namprd05.prod.outlook.com (10.255.232.14) with Microsoft SMTP Server (TLS) id 15.0.810.5; Mon, 28 Oct 2013 23:19:14 +0000 Received: from BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.196]) by BL2PR05MB082.namprd05.prod.outlook.com ([169.254.2.196]) with mapi id 15.00.0810.005; Mon, 28 Oct 2013 23:19:13 +0000 From: Ken Gray To: Thomas Narten , Ian Smith Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO1DQcugvON4KhXEqqRzbOYdxi1A== Date: Mon, 28 Oct 2013 23:19:13 +0000 Message-ID: In-Reply-To: <201310282041.r9SKfDDl030460@cichlid.raleigh.ibm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [10.255.129.4] x-forefront-prvs: 0013079544 Content-Type: text/plain; charset="us-ascii" Content-ID: <68D690DF56C38349B0ADFD8058B8DD02@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "nsc@ietf.org" Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Oct 2013 23:19:42 -0000 +1 overloading protocol bit meanings has a BUNCH of downside and implementation headache On 10/28/13 4:41 PM, "Thomas Narten" wrote: >Ian Smith writes: > >> My perception is that that is a foregone conclusion the working >> group should be chartered to create a new protocol and that seems >> premature. > >> I do believe that there is work to be done in a working group, but >> that informational and cbp documents may be all that is required to >> solve the problem statements that I've seen put forth. Some have >> argued that a standard protocol is required for interoperability, >> and I agree, but I contend that we ought to look at existing options >> before starting from scratch because it will allow us to deliver >> faster and it makes for a simpler and more manageable adoption. > >So let me (perhaps) be a bit provocative in order to draw out the >discussion a bit more. > >My understanding is that one can do service chaining today. But it >isn't always easy, and at least some folk are looking for a different >way that has less pain. I see two major assumptions behind the SFC >work: > >1) One can do traffic steering today by manipulating/modifying the >network. E.g., one can place Service Functions on the data path or one >can reprogram the network to steer the traffic to the places it needs >to go. But this is viewed as painful and looking forward, increasingly >inflexible in terms of doing this in an automated, dynamic way. Hence, >SFC is very definitely looking at addressing this problem in a >different manner than just continuing to use protocols that manipulate >the L2/L3 forwarding plane. Specifically, SFC wants to decouple the >"steering" from the underlying network. > >If one doesn't want to modify the network forwarding plane, using >tunneling between Service Functions (e.g., via something like >draft-quinn-sfc) is an obvious approach. The key point here though is >that reather than changing the data plane to make packets go where we >want, we tunnel instead, so that this can be done without modifying >the data plane of the underlay. > >2) Even in cases where current data plane steering approaches work >good enough (i.e,. 1 above isn't needed), there is also a separate >need to carry meta-data with data packets so that the Service >Functions along the chain can properly (or more easily) implement >those services in a context-sensitive manner. > >I believe the charter and problem statement documents are pretty clear >about the above need. > >While we might be able to use IP options and other existing mechanisms >tocarry such meta-data, there is long history/experience with IP >options that suggests they may not be a good approach. But the WG >should describe what some of the possible existing approaches are and >what issues (if any) there are with them. > >Personally, I don't see IP options as really viable for this stuff. We >have a fair amount of experience/history with such options, and they >are no panacea. What other *existing* approaches are there that we >could consider? > >> I'm open to the potential that new problem statements do arise that >> cannot be solved sufficiently by using or extending existing >> standards to do that, but I haven't seen them presented in any of >> the sfc drafts. > >> The drafts are very casual in their dismissal of using existing >> protocols as part of the solution and they don't explain why enough >> to justify committing to a new protocol in the charter, in my view. > >What other specific options should we consider? > >Thomas > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > From jmh@joelhalpern.com Tue Oct 29 03:14:14 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC1E11E821E for ; Tue, 29 Oct 2013 03:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqWqP9FmocD8 for ; Tue, 29 Oct 2013 03:14:09 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by ietfa.amsl.com (Postfix) with ESMTP id 437A211E8220 for ; Tue, 29 Oct 2013 03:14:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 07E421CA386F; Tue, 29 Oct 2013 03:14:07 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from Joels-MacBook-Pro.local (c213-89-137-101.bredband.comhem.se [213.89.137.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id BB5011CA386C; Tue, 29 Oct 2013 03:14:05 -0700 (PDT) Message-ID: <526F8A6E.6020609@joelhalpern.com> Date: Tue, 29 Oct 2013 06:14:06 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ken Gray References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Narten , "nsc@ietf.org" , Ian Smith Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 10:14:14 -0000 For me, and important part of this is interoperability. WHile I can see many ways to do service chaining, I really want to make sure that our data plane solutions can work together. In particular, while there are existing techniques for the service chain forwarding that I would like to use, the techniques for carrying metadata with those are, at best, awkward. The detailed discussion of alternatives and issues belongs down the road, not at this point in the process. Yours, Joel On 10/28/13 7:19 PM, Ken Gray wrote: > +1 overloading protocol bit meanings has a BUNCH of downside and > implementation headache > > On 10/28/13 4:41 PM, "Thomas Narten" wrote: > >> Ian Smith writes: >> >>> My perception is that that is a foregone conclusion the working >>> group should be chartered to create a new protocol and that seems >>> premature. >> >>> I do believe that there is work to be done in a working group, but >>> that informational and cbp documents may be all that is required to >>> solve the problem statements that I've seen put forth. Some have >>> argued that a standard protocol is required for interoperability, >>> and I agree, but I contend that we ought to look at existing options >>> before starting from scratch because it will allow us to deliver >>> faster and it makes for a simpler and more manageable adoption. >> >> So let me (perhaps) be a bit provocative in order to draw out the >> discussion a bit more. >> >> My understanding is that one can do service chaining today. But it >> isn't always easy, and at least some folk are looking for a different >> way that has less pain. I see two major assumptions behind the SFC >> work: >> >> 1) One can do traffic steering today by manipulating/modifying the >> network. E.g., one can place Service Functions on the data path or one >> can reprogram the network to steer the traffic to the places it needs >> to go. But this is viewed as painful and looking forward, increasingly >> inflexible in terms of doing this in an automated, dynamic way. Hence, >> SFC is very definitely looking at addressing this problem in a >> different manner than just continuing to use protocols that manipulate >> the L2/L3 forwarding plane. Specifically, SFC wants to decouple the >> "steering" from the underlying network. >> >> If one doesn't want to modify the network forwarding plane, using >> tunneling between Service Functions (e.g., via something like >> draft-quinn-sfc) is an obvious approach. The key point here though is >> that reather than changing the data plane to make packets go where we >> want, we tunnel instead, so that this can be done without modifying >> the data plane of the underlay. >> >> 2) Even in cases where current data plane steering approaches work >> good enough (i.e,. 1 above isn't needed), there is also a separate >> need to carry meta-data with data packets so that the Service >> Functions along the chain can properly (or more easily) implement >> those services in a context-sensitive manner. >> >> I believe the charter and problem statement documents are pretty clear >> about the above need. >> >> While we might be able to use IP options and other existing mechanisms >> tocarry such meta-data, there is long history/experience with IP >> options that suggests they may not be a good approach. But the WG >> should describe what some of the possible existing approaches are and >> what issues (if any) there are with them. >> >> Personally, I don't see IP options as really viable for this stuff. We >> have a fair amount of experience/history with such options, and they >> are no panacea. What other *existing* approaches are there that we >> could consider? >> >>> I'm open to the potential that new problem statements do arise that >>> cannot be solved sufficiently by using or extending existing >>> standards to do that, but I haven't seen them presented in any of >>> the sfc drafts. >> >>> The drafts are very casual in their dismissal of using existing >>> protocols as part of the solution and they don't explain why enough >>> to justify committing to a new protocol in the charter, in my view. >> >> What other specific options should we consider? >> >> Thomas >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >> > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > From jguichar@cisco.com Tue Oct 29 06:07:47 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCFA11E8247 for ; Tue, 29 Oct 2013 06:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.546 X-Spam-Level: X-Spam-Status: No, score=-10.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaHXq9KALdy5 for ; Tue, 29 Oct 2013 06:07:39 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id A291D21E809A for ; Tue, 29 Oct 2013 06:07:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4788; q=dns/txt; s=iport; t=1383052046; x=1384261646; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=PY5asuMPxBCAUZzNDfSHkIhWTLx1rndsArQpaS/Px7c=; b=kHTPktOncLdpZzo6dBrCM2TREC+MJ4Wekxf/bbYZsLqVs8QIvjPyQnIP Hp9sgCej3lIOGAGm7RXj1jNaOVgCubmJZkzESHar1dHjicWzNsIywRmIY BHuyAlcV/HBopvCo37Oga5vtB2U2Rlm29z4IAaP8JMGd2U/hyVWku3+7L I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIyyb1KtJXHA/2dsb2JhbABZgwc4VL8xgScWdIIlAQEBBAEBATc0BhEGAQgOAwQBAQEKFAkuCxQJCAIEARIIE4dsDblGjgiBDjgGgxmBDQOUKoUPkFmDJoFoQg X-IronPort-AV: E=Sophos;i="4.93,593,1378857600"; d="scan'208";a="277964747" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 29 Oct 2013 13:07:19 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r9TD7Jxj009038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 Oct 2013 13:07:19 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.2]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 29 Oct 2013 08:07:18 -0500 From: "Jim Guichard (jguichar)" To: Jerome Moisand , Thomas Narten , "nsc@ietf.org" Thread-Topic: [nsc] Problem statement draft: quinn-nsc-problem-statement Thread-Index: AQHO0ZzfI8kI/VXD7k2owsnIhDoXyJoF7/2AgAUcP4CAALDnAA== Date: Tue, 29 Oct 2013 13:07:18 +0000 Message-ID: <68B171751455884590F8E38E96416F363F710CEC@xmb-rcd-x01.cisco.com> In-Reply-To: <39641f97c06945cf8faeb8a826c15b5a@BN1PR05MB251.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.98.43.180] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 13:07:47 -0000 Hi Jerome, We deliberately wrote the problem statement to be generic. As you pointed out there are many use cases with their own set of problems to solve. Therefore it seemed more appropriate to have a high level problem statement and then document the intricacies of individual use cases in separate documents; for broadband scenarios I would envisage a use case document with a more detailed description of the problem space, same thing for VPN (whether shared services within a VPN or service chains that are private to a given VPN). On 10/28/13 6:34 PM, "Jerome Moisand" wrote: >Hi Thomas, > >Good question! > >Given that: >1. the WG hasn't been formally formed yet >2. the list of documented use cases remain rather limited at the IETF >level, and a work in progress in other industry forums (e.g. BBF, ETSI >NFV) > >It does seem a tad premature to conclude that the problem statement I-D >is nearing completion. It certainly did make very good progress though, >but I would think that it still deserves more rounds of reviews, notably >fed by analysis of new use cases. > >Now, to more directly answer your question, it seems to me that one >important side of things is missing in the problem statement, in the >context of broadband scenarios (fixed broadband ala BBF; mobile broadband >ala 3GPP). How to create a proper linkage to existing subscriber >management mechanisms (4 levels: database, decision/authorization, >enforcement, accounting), so that service chaining can be used as an >(hopefully fairly simple & natural) extension of such mechanisms, hence >minimizing OSS disruption and speeding up deployment of new services. >This is of course an issue specific to a given class of use cases and may >or may not apply in other contexts. > >In the same vein, the problem statement doesn't seem to touch very much >on implications of network-hosted business services, notably VPN concepts >and how to have service chaining co-exist and be compatible with such >L2/L3 service mechanisms (e.g. running service chains in a >VPN-contextualized manner). > >Maybe the higher level point here is that the current problem statement >is very generic (and doing a nice job of staying so!), while it would >probably be beneficial to expand it with considerations which are more >specific to a large class of use cases & applications. > >Tx >Jerome > >-----Original Message----- >From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Jim >Guichard (jguichar) >Sent: Friday, October 25, 2013 4:32 PM >To: Thomas Narten; nsc@ietf.org >Subject: Re: [nsc] Problem statement draft: quinn-nsc-problem-statement > >Quick clarification: > >Draft-quinn-nsc-problem-statement-03 was replaced by >http://tools.ietf.org/html/draft-quinn-sfc-problem-statement-01 .. Please >refer to this version if commenting. > >On 10/25/13 12:09 PM, "Thomas Narten" wrote: > >>Hi. >> >>To date, one problem statement draft >>(draft-quinn-nsc-problem-statement-03.txt) has been produced for the >>SFC effort. >> >>It has served as the basis for both the current and prior BOF, and my >>read of the mailing list discussions suggests that folk seem generally >>OK with it. I have not seen fundamental disagreements with its content >>or calls for substantial additions. >> >>Any disagreement with this assessment? >> >>Assuming there is agreement with the above, and that a WG is formed, I >>would expect that: >> >>1) we would formally adopt the document as a WG document in fairly >>short order and >> >>2) close its contents in relatively short order and send to the IESG >>for publication. >> >>For most WGs, a problem statement is the highest priority work item to >>complete, as it sets the stage for all followup work. Also, if there >>are significant gaps or shortcomings in a problem statement, it tends >>to spell trouble for the WG as it starts doing work (it's hard to get >>agreement on solutions when there isn't really agreement on what the >>solution needs to actually do). Thus, complete the problem statement is >>a priority, and we want to get the contents right. >> >>So with that in mind, are there still substantive issues we need to >>work out in the problem statement? Or do people think it is in pretty >>good shape? What still needs to be added to the document? (These >>questions are aimed at both the list and the document authors...) >> >>Thomas >> >>_______________________________________________ >>nsc mailing list >>nsc@ietf.org >>https://www.ietf.org/mailman/listinfo/nsc > >_______________________________________________ >nsc mailing list >nsc@ietf.org >https://www.ietf.org/mailman/listinfo/nsc > > > From Ron_Parker@affirmednetworks.com Tue Oct 29 06:18:24 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6843521F9DC9 for ; Tue, 29 Oct 2013 06:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id codnIJGaMA0F for ; Tue, 29 Oct 2013 06:18:19 -0700 (PDT) Received: from hub021-ca-1.exch021.serverdata.net (hub021-ca-1.exch021.serverdata.net [64.78.22.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8135811E80F8 for ; Tue, 29 Oct 2013 06:18:19 -0700 (PDT) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-1.exch021.domain.local ([10.254.4.30]) with mapi id 14.03.0158.001; Tue, 29 Oct 2013 06:18:19 -0700 From: Ron Parker To: "Joel M. Halpern" , Ken Gray Thread-Topic: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] Thread-Index: AQHO1I+hduvVNMYaNE+MF3ojao7DwJoLp/hg Date: Tue, 29 Oct 2013 13:18:18 +0000 Message-ID: References: <526F8A6E.6020609@joelhalpern.com> In-Reply-To: <526F8A6E.6020609@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Thomas Narten , "nsc@ietf.org" , Ian Smith Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draft-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Oct 2013 13:18:24 -0000 Hi, Joel. I agree, and I think most on the thread do, that there are already various = techniques to achieve service chaining. =20 But, from my experience, the real issue is to get the set of devices/functi= ons all on the same page. Device/function 1 uses only technique A, device= /function 2 uses only technique B, etc. There may be some legitimate reas= ons why each device/function developer chose the particular supported techn= ique -- perhaps it is more efficient on the wire or perhaps it fits with a = network paradigm that is typical for networks where that device/function is= deployed. =20 As you've pointed out, the goal should be real-world, practical, multi-vend= or interoperability. Ron =20 -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Joel = M. Halpern Sent: Tuesday, October 29, 2013 6:14 AM To: Ken Gray Cc: Thomas Narten; nsc@ietf.org; Ian Smith Subject: Re: [nsc] encap for SFC [was Re: New Version Notification for draf= t-dunbar-sfc-legacy-l4-l7-chain-architecture-00.txt] For me, and important part of this is interoperability. WHile I can see ma= ny ways to do service chaining, I really want to make sure that our data pl= ane solutions can work together. In particular, while there are existing techniques for the service chain fo= rwarding that I would like to use, the techniques for carrying metadata wit= h those are, at best, awkward. The detailed discussion of alternatives and= issues belongs down the road, not at this point in the process. Yours, Joel On 10/28/13 7:19 PM, Ken Gray wrote: > +1 overloading protocol bit meanings has a BUNCH of downside and > implementation headache > > On 10/28/13 4:41 PM, "Thomas Narten" wrote: > >> Ian Smith writes: >> >>> My perception is that that is a foregone conclusion the working=20 >>> group should be chartered to create a new protocol and that seems=20 >>> premature. >> >>> I do believe that there is work to be done in a working group, but=20 >>> that informational and cbp documents may be all that is required to=20 >>> solve the problem statements that I've seen put forth. Some have=20 >>> argued that a standard protocol is required for interoperability,=20 >>> and I agree, but I contend that we ought to look at existing options=20 >>> before starting from scratch because it will allow us to deliver=20 >>> faster and it makes for a simpler and more manageable adoption. >> >> So let me (perhaps) be a bit provocative in order to draw out the=20 >> discussion a bit more. >> >> My understanding is that one can do service chaining today. But it=20 >> isn't always easy, and at least some folk are looking for a different=20 >> way that has less pain. I see two major assumptions behind the SFC >> work: >> >> 1) One can do traffic steering today by manipulating/modifying the=20 >> network. E.g., one can place Service Functions on the data path or=20 >> one can reprogram the network to steer the traffic to the places it=20 >> needs to go. But this is viewed as painful and looking forward,=20 >> increasingly inflexible in terms of doing this in an automated,=20 >> dynamic way. Hence, SFC is very definitely looking at addressing this=20 >> problem in a different manner than just continuing to use protocols=20 >> that manipulate the L2/L3 forwarding plane. Specifically, SFC wants=20 >> to decouple the "steering" from the underlying network. >> >> If one doesn't want to modify the network forwarding plane, using=20 >> tunneling between Service Functions (e.g., via something like >> draft-quinn-sfc) is an obvious approach. The key point here though is=20 >> that reather than changing the data plane to make packets go where we=20 >> want, we tunnel instead, so that this can be done without modifying=20 >> the data plane of the underlay. >> >> 2) Even in cases where current data plane steering approaches work=20 >> good enough (i.e,. 1 above isn't needed), there is also a separate=20 >> need to carry meta-data with data packets so that the Service=20 >> Functions along the chain can properly (or more easily) implement=20 >> those services in a context-sensitive manner. >> >> I believe the charter and problem statement documents are pretty=20 >> clear about the above need. >> >> While we might be able to use IP options and other existing=20 >> mechanisms tocarry such meta-data, there is long history/experience=20 >> with IP options that suggests they may not be a good approach. But=20 >> the WG should describe what some of the possible existing approaches=20 >> are and what issues (if any) there are with them. >> >> Personally, I don't see IP options as really viable for this stuff.=20 >> We have a fair amount of experience/history with such options, and=20 >> they are no panacea. What other *existing* approaches are there that=20 >> we could consider? >> >>> I'm open to the potential that new problem statements do arise that=20 >>> cannot be solved sufficiently by using or extending existing=20 >>> standards to do that, but I haven't seen them presented in any of=20 >>> the sfc drafts. >> >>> The drafts are very casual in their dismissal of using existing=20 >>> protocols as part of the solution and they don't explain why enough=20 >>> to justify committing to a new protocol in the charter, in my view. >> >> What other specific options should we consider? >> >> Thomas >> >> _______________________________________________ >> nsc mailing list >> nsc@ietf.org >> https://www.ietf.org/mailman/listinfo/nsc >> >> > > > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc > _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc From liushucheng@huawei.com Tue Oct 29 19:47:55 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48DB821E80D9 for ; Tue, 29 Oct 2013 19:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyOT9NQDCtaU for ; Tue, 29 Oct 2013 19:47:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6683921E80DA for ; Tue, 29 Oct 2013 19:47:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZP90770; Wed, 30 Oct 2013 02:47:42 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Oct 2013 02:47:12 +0000 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Oct 2013 02:47:32 +0000 Received: from szxeml559-mbx.china.huawei.com ([169.254.1.2]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.03.0146.000; Wed, 30 Oct 2013 10:47:26 +0800 From: "Liushucheng (Will)" To: "Cao,Zhen" , "nsc@ietf.org" Thread-Topic: [nsc] Fwd: New Version Notification for draft-cao-nsc-rtg-update-00.txt Thread-Index: AQHOzndNTQ4fqKFyJEq8em6Q8vqvapoMjCtA Date: Wed, 30 Oct 2013 02:47:25 +0000 Message-ID: References: <20131021105431.29409.44036.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [nsc] Fwd: New Version Notification for draft-cao-nsc-rtg-update-00.txt X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 02:47:55 -0000 Hi, I took a look at this draft and have the following comments: 1. It's a good idea to reuse the existing protocol. However, using IPv6 mob= ility Header may limit the scope. Is it possible to give a more general sol= ution, e.g., IPv6 header instead, or even provide a paralleled IPv4 solutio= n? IMHO, the main idea of this draft is hop by hop en/decapsulation and tun= neling, so there should be solutions more general. 2. The hop by hop en/decapsulation is easy to implement. However, it seems = that this is a pre-organized approach, meaning the controller handles every= thing at the beginning. How to treat the service flow that needs dynamical = routing might be a issue. Regards, Shucheng LIU (Will) > -----Original Message----- > From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of > Cao,Zhen > Sent: Monday, October 21, 2013 11:54 PM > To: nsc@ietf.org > Subject: [nsc] Fwd: New Version Notification for > draft-cao-nsc-rtg-update-00.txt >=20 > Hello, all >=20 > Comments welcome for this simple draft. >=20 > Best regards, > cz >=20 > ---------- Forwarded message ---------- > From: > Date: Mon, Oct 21, 2013 at 12:54 PM > Subject: New Version Notification for draft-cao-nsc-rtg-update-00.txt > To: Zehn Cao >=20 >=20 >=20 > A new version of I-D, draft-cao-nsc-rtg-update-00.txt has been successful= ly > submitted by Zhen Cao and posted to the IETF repository. >=20 > Filename: draft-cao-nsc-rtg-update > Revision: 00 > Title: Routing Update Mechanism for Network Service Chaining > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 7 > URL: > http://www.ietf.org/internet-drafts/draft-cao-nsc-rtg-update-00.txt > Status: http://datatracker.ietf.org/doc/draft-cao-nsc-rtg-update > Htmlized: http://tools.ietf.org/html/draft-cao-nsc-rtg-update-00 >=20 >=20 > Abstract: > This document proposes a mechanism of routing the packets through a > series of (virtual) service functions. The mechanism uses the > existing IPv6 Mobility Header for routing advertisements, updates and > acknowledgements. Comparison with existing service chaining > mechanisms is to be analyzed. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat > _______________________________________________ > nsc mailing list > nsc@ietf.org > https://www.ietf.org/mailman/listinfo/nsc From hongyu.li@huawei.com Wed Oct 30 16:07:25 2013 Return-Path: X-Original-To: nsc@ietfa.amsl.com Delivered-To: nsc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D211E82CA for ; Wed, 30 Oct 2013 16:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4ryz1VppSSn for ; Wed, 30 Oct 2013 16:07:21 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 188D711E82CF for ; Wed, 30 Oct 2013 16:06:55 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AZR83085; Wed, 30 Oct 2013 23:06:55 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Oct 2013 23:06:31 +0000 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 30 Oct 2013 23:06:53 +0000 Received: from szxeml560-mbx.china.huawei.com ([169.254.3.56]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.03.0146.000; Thu, 31 Oct 2013 07:06:46 +0800 From: "Hongyu Li (Julio)" To: Thomas Narten , "Joel M. Halpern" Thread-Topic: [nsc] Representations of services Thread-Index: AQHO0ZU5RVoQGO7ec0eaVtSUdU1kfJoGPE6AgAOqdgCAA8picA== Date: Wed, 30 Oct 2013 23:06:46 +0000 Message-ID: <6EB34CB5D82C4645B826C56144826EA97DFBBEC3@szxeml560-mbx.china.huawei.com> References: <201310251515.r9PFFwJ6017622@cichlid.raleigh.ibm.com> <526B93BB.3060909@joelhalpern.com> <201310281803.r9SI3b3M004866@cichlid.raleigh.ibm.com> In-Reply-To: <201310281803.r9SI3b3M004866@cichlid.raleigh.ibm.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.44] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "nsc@ietf.org" Subject: Re: [nsc] Representations of services X-BeenThere: nsc@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Network Service Chaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Oct 2013 23:07:25 -0000 Hi Thomas, This topic at least needs to be considered from three aspects. First is how a SFC is provisioned. Is it something like a routing next work= that routers can connect them by negotiation among themselves, or provisio= ned by a somehow centralized dominant role, an orchestrator maybe. My view = on this is the latter is what's demanded by operators. In other words, an S= FC is first designed by operators according to business requirements and th= en mapped to a set of service functions that need to be chained together. I= n that sense, advertising of capabilities by SF itself is not really necess= ary, even though not cool at all. Second aspect is Service Functions are so variant that if we are going to i= nclude details of these functions in our work, we are going to be either no= ending of work by enumerate all of them, or loose flexibility of the solut= ion by capable of supporting only limited functions. The last aspect is related to the second one. As service functions may impa= ct the way a packet is forwarded, e.g. NAT changes a packet, DPI may trigge= r different following processing of a packet, FW may drop certain packets, = we need to abstract some features of service functions so that our solution= is valid for all. Cheers, Hongyu -----Original Message----- From: nsc-bounces@ietf.org [mailto:nsc-bounces@ietf.org] On Behalf Of Thoma= s Narten Sent: Tuesday, October 29, 2013 2:04 AM To: Joel M. Halpern Cc: nsc@ietf.org Subject: Re: [nsc] Representations of services Hi Joel. "Joel M. Halpern" writes: > Maybe I am naive, but this looks to be completely outside the scope of=20 > what I understand SFC to be working on. To be clear, I mostly agree. IMO, this is mostly outside of the current cha= rter as I understand it. However, the question really is what (if any) work in this space is needed = in order for SFC to be successful more generally. I.e., would the lack of w= ork/solutions just mean all that stuff gets done in a proprietary manner? I= s that what we want? To me, SFC is part of a bigger picture that involves orchestration of VMs a= nd services. SFC is one piece of that, but not the only one. > Architecturally, naming or identification has to be assumed. But that=20 > does not mean we have to define it. In particular, the identification=20 > of services / service instances / servers / virtual instances ...=20 > would seem to be a control function. Once we get to the data plane,=20 > SFC service delivery points have to be meaningful to the data plane. The proposed charter isn't just data plane/encap, there are hints of contr= ol plane too. Look at the following paragraph from the charter and the last paragraph in = particular: The Service Function Chaining (SFC) working group will develop new approaches to service delivery and deployment. It will produce a=20 framework for service function chaining that includes the necessary protocols or protocol extensions to convey the service path and service path information to nodes that implement service functions, as well as mechanisms for steering traffic through service functions. The working= =20 group will also examine what information needs to be gathered from the network and service functions in support of service function chaining and how that information may be made available to nodes that implement the service functions.=20 > Hence, the process of discovery and selection service entities seems=20 > to me to be outside of our problem domain. Let me ask again though: 1) Do we already have solutions/standards in place that do this today? If so, what are they? 2) Is there work in this space that needs doing (somewhere)? If so, what is= that work and where should it be done? Thomas _______________________________________________ nsc mailing list nsc@ietf.org https://www.ietf.org/mailman/listinfo/nsc